[PATCH]: Fix get_compat_sigevent()

[David S. Miller]

I have no idea how a bug like this lasted so long.
Anyways, obvious memset()'ing of incorrect pointer.

Please apply, thanks.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

= kernel/compat.c 1.46 vs edited =
--- 1.46/kernel/compat.c2005-03-13 15:29:47 -08:00
+++ edited/kernel/compat.c  2005-04-04 22:36:13 -07:00
@@ -640,7 +640,7 @@
 int get_compat_sigevent(struct sigevent *event,
const struct compat_sigevent __user *u_event)
 {
-   memset(, 0, sizeof(*event));
+   memset(event, 0, sizeof(*event));
return (!access_ok(VERIFY_READ, u_event, sizeof(*u_event)) ||
__get_user(event->sigev_value.sival_int,
_event->sigev_value.sival_int) ||
-
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 00/04] Load keyspan firmware with hotplug

[Sven Luther]

On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > 
> > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > 
> > > Can you summarize the conclusion of the thread, or what you did get from 
> > > it,
> > > please ? 
> > 
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> > 
> > None have come.
> 
> Didn't know you were waiting for it. How about something like the
> following series of patches?
> 
> [01/04] - add simple Intel IHEX format parser to the firmware loader.
> [02/04] - make the keyspan driver use request_firmware.
> [03/04] - converter program used to dump the keyspan headers as IHex files.
> [04/04] - result of running the previous program.
> 
> This ofcourse doesn't actually solve Debian's distribution issues since
> the keyspan firmware can only be distributed as part of 'Linux or other
> Open Source operating system kernel'.

Well, if this is the case, it can be distributed on the non-free archive.

> > So I refuse to listen to talk about this, as obviously, no one cares
> > enough about this to actually fix the issue.
> 
> I got tired of always building my own kernels on Debian just to get my
> serial dongle to work since their included keyspan.ko driver is so
> useless that it isn't even worth having. The only way to use it with a
> Debian kernel is to have the dongle in a powered hub and first boot into
> Windows or a normal kernel.org kernel to get the thing initialized.

The non-free driver package should solve that for you.

> Didn't send the patch earlier since I wanted to split off the
> pre-numeration part of the driver so that after intialization we can
> unload the unused parts of the driver as well as the the firmware class
> module.

Friendly,

Sven Luther

-
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 0/5] ppc RT: Realtime preempt support for PPC

[Ingo Molnar]

* Frank Rowand <[EMAIL PROTECTED]> wrote:

> I looked at all the architectures and found that the disparity of the 
> type of the "lock" field in struct rwlock_t is even larger than I had 
> indicated in my earlier email.  I am attaching a proof of concept 
> patch to handle this.  If this looks like a good method to you then I 
> will create a real patch against your current patch, and include i386, 
> mips, x86_64, and ppc.

> +#include 

>  typedef struct {
> -   volatile unsigned long lock;
> +   ARCH_RAW_RWLOCK_LOCK

maybe the simplest method would be to let architectures to define the 
raw spinlock type after all. I was hoping to standardize things across 
all architectures, but maybe it's not possible.

Ingo
-
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Ingo Molnar]

* Esben Nielsen <[EMAIL PROTECTED]> wrote:

> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix, and I'm sure you have other things to do too.
> 
> How about adding a
>  if(rt_task(current)) {
> WARN_ON(1);
> mutex_setprio(current, MAX_PRIO-1)
>  }
> ?
> 
> to find all calls to yields from rt-tasks. That will force the user 
> (aka the real-time developer) to either stop calling the subsystems 
> still using yield from his RT-tasks, or fix those subsystems.

i've added this to the -43-08 patch, so that we can see the scope of the 
problem. But any yield() use could become a problem due to priority 
inheritance. (which might eventually be expanded to userspace locking 
too)

Ingo
-
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 / CBUS

[James Morris]

On Tue, 5 Apr 2005, James Morris wrote:

> A few questions:

Also, please allow cn_add_callback() allow it to be passed a NULL 
callback function, so the caller doesn't pass in a dummy function and your 
code doesn't waste time dealing with something which isn't real.


- 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/

Netlink Connector / CBUS

[James Morris]

Evgeniy,

Please send networking patches to [EMAIL PROTECTED]

Your connector code (under drivers/connector) is now in the -mm tree and 
as far as I can tell, has not received any review from the network 
developers.

Looking at it briefly, it seems quite unfinished.

I'm not entirely sure what it's purpose is.

A clear explanation of its purpose would be helpful (to me, at least), as 
well as documentation of the API and majore data structures (which akpm 
has also asked for, IIRC).

I can see one example of where it's being used with kobject_uevent, and it 
seems to have arrived via Greg-KH's I2C tree...

If you're trying to add a generic, psuedo-reliable Netlink communication 
system, perhaps this should be built into Netlink itself as an extension 
of the existing Netlink API.

I don't think this should be done as a separate "driver" off somewhere 
else with a new API.


A few questions:

- Why does it by default use NETLINK_NFLOG a kernel socket, and also allow 
this to be overriden by a module parameter?

- Why does the cn.o module (poor namespace choice) add a callback itself
on initialization?

- Where is the userspace code which uses this?  I checked out dbus from 
cvs and couldn't see anything obvious.


Thanks,


- 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/

Re: Linux 2.6.12-rc2

[Gene Heskett]

On Monday 04 April 2005 17:32, Linus Torvalds wrote:
>The diffstat output tells the story: this is a lot of very small
> changes, ie tons of small cleanups and bug fixes. With a few new
> drivers thrown in for good measure.
>
>This is also the point where I ask people to calm down, and not send
> me anything but clear bug-fixes etc. We're definitely well into -rc
> land. So keep it quiet out there,
>
>  Linus

Well, I'm happy to report that it not only built, it booted, and that 
the one program thats been a noshow for video, tvtime, in any kernel 
newer than -rc1, failing in all the . releases after .2, or any -mm I 
tried, is working quite nicely thank you in -rc2.  Its late, and I'll 
check the rest of my checklist in the morning.

-rc1 was one heck of an improvement in feel and usability, I hope -rc2 
will continue that tradition.  Great stuff.

-- 
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.34% 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 00/04] Load keyspan firmware with hotplug

[Dmitry Torokhov]

On Monday 04 April 2005 23:23, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > 
> > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > 
> > > Can you summarize the conclusion of the thread, or what you did get from 
> > > it,
> > > please ? 
> > 
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> > 
> > None have come.
> 
> Didn't know you were waiting for it. How about something like the
> following series of patches?
> 
> [01/04] - add simple Intel IHEX format parser to the firmware loader.

Firmware loader is format-agnostic, I think having IHEX parser in a separate
file would be better...

-- 
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: Isn't there race issue during fput() and the dentry_open()?

[Tomita, Haruo]

Hi Viro,
(B
(BThank you for your help and advice.
(BI made the following patches referring to your advice. 
(BI try to debugging by using this patch. 
(B
(BThanks again,
(BHaruo
(B
(Bdiff -urN linux-2.6.12-rc2.orig/fs/file_table.c linux-2.6.12-rc2/fs/file_table.c
(B--- linux-2.6.12-rc2.orig/fs/file_table.c   2005-03-02 16:37:47.0 
(B+0900
(B+++ linux-2.6.12-rc2/fs/file_table.c2005-04-05 11:21:58.0 +0900
(B@@ -26,6 +26,7 @@
(B 
(B /* public. Not pretty! */
(B  __cacheline_aligned_in_smp DEFINE_SPINLOCK(files_lock);
(B+pid_t holder_pid;
(B 
(B static DEFINE_SPINLOCK(filp_count_lock);
(B 
(Bdiff -urN linux-2.6.12-rc2.orig/include/linux/fs.h 
(Blinux-2.6.12-rc2/include/linux/fs.h
(B--- linux-2.6.12-rc2.orig/include/linux/fs.h2005-04-05 11:12:53.0 
(B+0900
(B+++ linux-2.6.12-rc2/include/linux/fs.h 2005-04-05 11:20:15.0 +0900
(B@@ -602,8 +602,17 @@
(Bstruct address_space*f_mapping;
(B };
(B extern spinlock_t files_lock;
(B-#define file_list_lock() spin_lock(_lock);
(B-#define file_list_unlock() spin_unlock(_lock);
(B+extern pid_t holder_pid;
(B+#define file_list_lock() \
(B+   do { \
(B+   spin_lock(_lock); \
(B+   holder_pid = current->pid; \
(B+   }while(0)
(B+#define file_list_unlock() \
(B+   do { \
(B+   holder_pid = 0; \
(B+   spin_unlock(_lock); \
(B+   }while(0)
(B 
(B #define get_file(x)atomic_inc(&(x)->f_count)
(B #define file_count(x)  atomic_read(&(x)->f_count)
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/04] Load keyspan firmware with hotplug

[Jan Harkes]

Simple program to convert the keyspan firmware header files to IHEX
formatted files that can be loaded with hotplug.

This is really only needed once to convert the existing keyspan firmware
headers, which is what the next patch will do.

Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>


Index: linux/drivers/usb/serial/dumpfw.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux/drivers/usb/serial/dumpfw.c   2005-03-10 23:16:37.240765747 -0500
@@ -0,0 +1,98 @@
+/*
+ * Convert keyspan firmware header files to Intel HEX format
+ * cc -I/usr/src/linux/drivers/usb/serial -o dumpfw dumpfw.c
+ */
+#include 
+#include 
+
+//#include "keyspan.h" /* ezusb_hex_record */
+
+struct ezusb_hex_record {
+uint16_t address;
+uint8_t  size;
+uint8_t  data[64];
+};
+
+#include "keyspan_usa28_fw.h"
+#include "keyspan_usa28x_fw.h"
+#include "keyspan_usa28xa_fw.h"
+#include "keyspan_usa28xb_fw.h"
+#include "keyspan_usa19_fw.h"
+#include "keyspan_usa19qi_fw.h"
+#include "keyspan_mpr_fw.h"
+#include "keyspan_usa19qw_fw.h"
+#include "keyspan_usa18x_fw.h"
+#include "keyspan_usa19w_fw.h"
+#include "keyspan_usa49w_fw.h"
+#include "keyspan_usa49wlc_fw.h"
+
+char *boilerplate = "\
+# This firmware for the Keyspan %s USB-to-Serial adapter is\n\
+#\n\
+#Copyright (C) 1999-2003\n\
+#Keyspan, A division of InnoSys Incorporated (\"Keyspan\")\n\
+#\n\
+# as an unpublished work. This notice does not imply unrestricted or\n\
+# public access to the source code from which this firmware image is\n\
+# derived.  Except as noted below this firmware image may not be\n\
+# reproduced, used, sold or transferred to any third party without\n\
+# Keyspan's prior written consent.  All Rights Reserved.\n\
+#\n\
+# Permission is hereby granted for the distribution of this firmware\n\
+# image as part of a Linux or other Open Source operating system kernel\n\
+# in text or binary form as required.\n\
+#\n\
+# This firmware may not be modified and may only be used with\n\
+# Keyspan hardware.  Distribution of this firmware, in whole or in\n\
+# part, requires the inclusion of this statement.\n\
+#\n";
+
+void dumpfw(char *name, const struct ezusb_hex_record *record)
+{
+char fw_name[20];
+char NAME[10];
+uint16_t address, i;
+uint8_t crc;
+FILE *f;
+
+for (i = 0; name[i] != '\0'; i++)
+   NAME[i] = toupper(name[i]);
+NAME[i] = '\0';
+
+sprintf(fw_name, "keyspan-%s.fw", name);
+printf("writing %s\n", fw_name);
+
+f = fopen(fw_name, "w");
+fprintf(f, boilerplate, NAME);
+
+while (record->address != 0x) {
+   crc = record->size + (record->address >> 8) + record->address;
+   fprintf(f, ":%02X%04X00", record->size, record->address);
+   for (i = 0; i < record->size; i++) {
+   fprintf(f, "%02X", record->data[i]);
+   crc += record->data[i];
+   }
+   fprintf(f, "%02X\n", (uint8_t)-crc);
+   record++;
+}
+fprintf(f, ":0001FF\n");
+
+fclose(f);
+}
+
+int main(int argc, char **argv)
+{
+dumpfw("mpr",  keyspan_mpr_firmware);
+dumpfw("usa18x",   keyspan_usa18x_firmware);
+dumpfw("usa19",keyspan_usa19_firmware);
+dumpfw("usa19qi",  keyspan_usa19qi_firmware);
+dumpfw("usa19qw",  keyspan_usa19qw_firmware);
+dumpfw("usa19w",   keyspan_usa19w_firmware);
+dumpfw("usa28",keyspan_usa28_firmware);
+dumpfw("usa28x",   keyspan_usa28x_firmware);
+dumpfw("usa28xa",  keyspan_usa28xa_firmware);
+dumpfw("usa28xb",  keyspan_usa28xb_firmware);
+dumpfw("usa49w",   keyspan_usa49w_firmware);
+dumpfw("usa49wlc", keyspan_usa49wlc_firmware);
+}
+
-
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 02/04] Load keyspan firmware with hotplug

[Jan Harkes]

Convert the keyspan USB serial driver to use request_firmware and
firmware_load_ihex.

Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>

Index: linux/drivers/usb/serial/keyspan.c
===
--- linux.orig/drivers/usb/serial/keyspan.c 2005-03-10 16:01:15.0 
-0500
+++ linux/drivers/usb/serial/keyspan.c  2005-03-10 23:07:21.070790916 -0500
@@ -28,6 +28,9 @@
 
   Change History
 
+2005mar10  Jan Harkes
+  Use generic request_firmware/firmware_load_ihex functions.
+
 2003sep04  LPM (Keyspan) add support for new single port product USA19HS.
Improve setup message handling for all devices.
 
@@ -106,6 +109,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "usb-serial.h"
@@ -1165,13 +1169,28 @@
port->tty = NULL;
 }
 
+static int keyspan_fw_load(struct ihex_record *record, void *arg)
+{
+   struct usb_serial *serial = (struct usb_serial *)arg;
+   int ret;
+
+   ret = ezusb_writememory(serial, record->address, record->data,
+   record->len, 0xa0);
+   if (ret < 0) {
+   dev_err(>dev->dev,
+   "ezusb_writememory failed for Keyspan"
+   "firmware (%d %08X %p %d)\n",
+   ret, record->address, record->data, record->len);
+   }
+   return ret;
+}
 
/* download the firmware to a pre-renumeration device */
 static int keyspan_fake_startup (struct usb_serial *serial)
 {
int response;
-   const struct ezusb_hex_record   *record;
-   char*fw_name;
+   char*model, fw_name[20];
+   const struct firmware   *fw;
 
dbg("Keyspan startup version %04x product %04x",
le16_to_cpu(serial->dev->descriptor.bcdDevice),
@@ -1182,97 +1201,43 @@
return(1);
}
 
-   /* Select firmware image on the basis of idProduct */
switch (le16_to_cpu(serial->dev->descriptor.idProduct)) {
-   case keyspan_usa28_pre_product_id:
-   record = _usa28_firmware[0];
-   fw_name = "USA28";
-   break;
-
-   case keyspan_usa28x_pre_product_id:
-   record = _usa28x_firmware[0];
-   fw_name = "USA28X";
-   break;
-
-   case keyspan_usa28xa_pre_product_id:
-   record = _usa28xa_firmware[0];
-   fw_name = "USA28XA";
-   break;
-
-   case keyspan_usa28xb_pre_product_id:
-   record = _usa28xb_firmware[0];
-   fw_name = "USA28XB";
-   break;
-
-   case keyspan_usa19_pre_product_id:
-   record = _usa19_firmware[0];
-   fw_name = "USA19";
-   break;
-
-   case keyspan_usa19qi_pre_product_id:
-   record = _usa19qi_firmware[0];
-   fw_name = "USA19QI";
-   break;
-
-   case keyspan_mpr_pre_product_id:
-   record = _mpr_firmware[0];
-   fw_name = "MPR";
-   break;
-
-   case keyspan_usa19qw_pre_product_id:
-   record = _usa19qw_firmware[0];
-   fw_name = "USA19QI";
-   break;
-
-   case keyspan_usa18x_pre_product_id:
-   record = _usa18x_firmware[0];
-   fw_name = "USA18X";
-   break;
-
-   case keyspan_usa19w_pre_product_id:
-   record = _usa19w_firmware[0];
-   fw_name = "USA19W";
-   break;
-   
-   case keyspan_usa49w_pre_product_id:
-   record = _usa49w_firmware[0];
-   fw_name = "USA49W";
-   break;
-
-   case keyspan_usa49wlc_pre_product_id:
-   record = _usa49wlc_firmware[0];
-   fw_name = "USA49WLC";
-   break;
-
+   case keyspan_usa18x_pre_product_id:   model = "usa18x";   break;
+   case keyspan_usa19_pre_product_id:model = "usa19";break;
+   case keyspan_usa19qi_pre_product_id:  model = "usa19qi";  break;
+   case keyspan_mpr_pre_product_id:  model = "mpr";  break;
+   case keyspan_usa19qw_pre_product_id:  model = "usa19qw";  break;
+   case keyspan_usa19w_pre_product_id:   model = "usa19w";   break;
+   case keyspan_usa28_pre_product_id:model = "usa28";break;
+   case keyspan_usa28x_pre_product_id:   model = "usa28x";   break;
+   case keyspan_usa28xa_pre_product_id:  model = "usa28xa";  break;
+   case keyspan_usa28xb_pre_product_id:  model = "usa28xb";  break;
+   case keyspan_usa49w_pre_product_id:   model = "usa49w";   break;
+   case keyspan_usa49wlc_pre_product_id: model = "usa49wlc"; break;
default:
-   record = NULL;
-

[PATCH 01/04] Load keyspan firmware with hotplug

[Jan Harkes]

Adding firmware_load_ihex, to load IHEX formatted firmware images.

Signed-off-by: Jan Harkes <[EMAIL PROTECTED]>


 drivers/base/firmware_class.c |  151 ++
 include/linux/firmware.h  |   26 +++
 2 files changed, 177 insertions(+)

Index: linux/include/linux/firmware.h
===
--- linux.orig/include/linux/firmware.h 2005-03-29 16:32:45.0 -0500
+++ linux/include/linux/firmware.h  2005-03-29 16:33:11.0 -0500
@@ -1,12 +1,34 @@
+/*
+ * Definitions for hotplug firmware loader
+ *
+ * Copyright (C) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * 2005-03-10  Jan Harkes <[EMAIL PROTECTED]>
+ * Added parser for IHEX formatted firmware files.
+ */
+
 #ifndef _LINUX_FIRMWARE_H
 #define _LINUX_FIRMWARE_H
+
 #include 
 #include 
 #define FIRMWARE_NAME_MAX 30 
+
 struct firmware {
size_t size;
u8 *data;
 };
+
+struct ihex_record {
+   __u32 address;
+   __u8  len;
+   __u8  data[255];
+};
+
 struct device;
 int request_firmware(const struct firmware **fw, const char *name,
 struct device *device);
@@ -15,6 +37,10 @@ int request_firmware_nowait(
const char *name, struct device *device, void *context,
void (*cont)(const struct firmware *fw, void *context));
 
+int firmware_load_ihex(const struct firmware *fw, void *context,
+  int (*load)(struct ihex_record *record, void *context));
+
 void release_firmware(const struct firmware *fw);
 void register_firmware(const char *name, const u8 *data, size_t size);
+
 #endif
Index: linux/drivers/base/firmware_class.c
===
--- linux.orig/drivers/base/firmware_class.c2005-03-29 16:32:45.0 
-0500
+++ linux/drivers/base/firmware_class.c 2005-03-29 16:33:11.0 -0500
@@ -5,6 +5,8 @@
  *
  * Please see Documentation/firmware_class/ for more information.
  *
+ * 2005-03-10 Jan Harkes <[EMAIL PROTECTED]>
+ * Added parser for IHEX formatted firmware files.
  */
 
 #include 
@@ -553,6 +555,153 @@ request_firmware_nowait(
return 0;
 }
 
+#ifdef VERBOSE_MSGS
+#define dbg(msg, ...) printk(KERN_WARNING "%s: line %d: " msg, __FUNCTION__, 
line, ## __VA_ARGS__)
+#else
+#define dbg(msg, ...) do {} while(0)
+#endif
+
+/**
+ * nibble/hex are little helpers to parse hexadecimal numbers to a byte value
+ **/
+static __u8 nibble(__u8 n)
+{
+   if  (n >= '0' && n <= '9') return n - '0';
+   else if (n >= 'A' && n <= 'F') return n - ('A' - 10);
+   else if (n >= 'a' && n <= 'f') return n - ('a' - 10);
+   return 0;
+}
+static __u8 hex(__u8 *data, __u8 *crc)
+{
+   __u8 val = (nibble(data[0]) << 4) | nibble(data[1]);
+   *crc += val;
+   return val;
+}
+
+/**
+ * firmware_load_ihex:
+ *
+ * Description:
+ * @fw is expected to contain Intel HEX formatted data.
+ *
+ * @load will be called for each record that is found in the IHEX data.
+ *
+ * @context will be passed on to @load.
+ *
+ **/
+int firmware_load_ihex(const struct firmware *fw, void *context,
+  int (*load)(struct ihex_record *record, void *context))
+{
+   struct ihex_record *record;
+   __u32 offset = 0;
+   __u8 type, crc = 0;
+   int i, j, err = 0;
+   int line = 1;
+
+   record = kmalloc(sizeof(*record), GFP_KERNEL);
+   if (!record) {
+   dbg("Allocation failed\n");
+   return -ENOMEM;
+   }
+
+   i = 0;
+next_record:
+   /* search for the start of record character */
+   while (i < fw->size) {
+   if (fw->data[i] == '\n') line++;
+   if (fw->data[i++] == ':') break;
+   }
+
+   /* Minimum record length would be about 10 characters */
+   if (i + 10 > fw->size) {
+   dbg("Can't find valid record\n");
+   err = -EINVAL;
+   goto done;
+   }
+
+   record->len = hex(fw->data + i, );
+   i += 2;
+
+   /* now check if we have enough data to read everything */
+   if (i + 8 + (record->len * 2) > fw->size) {
+   dbg("Not enough data to read complete record\n");
+   err = -EINVAL;
+   goto done;
+   }
+
+   record->address  = hex(fw->data + i, ) << 8; i += 2;
+   record->address |= hex(fw->data + i, ); i += 2;
+   record->address += offset;
+   type = hex(fw->data + i, ); i += 2;
+
+   for (j = 0; j < record->len; j++, i += 2)
+   record->data[j] = hex(fw->data + i, );
+
+   /* check CRC */
+   (void)hex(fw->data + i, ); i += 2;
+   if (crc != 0) {
+   dbg("CRC failure\n");
+   err = -EINVAL;
+   goto 

[PATCH 00/04] Load keyspan firmware with hotplug

[Jan Harkes]

On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > 
> >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > 
> > Can you summarize the conclusion of the thread, or what you did get from it,
> > please ? 
> 
> That people didn't like the inclusion of firmware, I posted how you can
> fix it by moving it outside of the kernel, and asked for patches.
> 
> None have come.

Didn't know you were waiting for it. How about something like the
following series of patches?

[01/04] - add simple Intel IHEX format parser to the firmware loader.
[02/04] - make the keyspan driver use request_firmware.
[03/04] - converter program used to dump the keyspan headers as IHex files.
[04/04] - result of running the previous program.

This ofcourse doesn't actually solve Debian's distribution issues since
the keyspan firmware can only be distributed as part of 'Linux or other
Open Source operating system kernel'.

> So I refuse to listen to talk about this, as obviously, no one cares
> enough about this to actually fix the issue.

I got tired of always building my own kernels on Debian just to get my
serial dongle to work since their included keyspan.ko driver is so
useless that it isn't even worth having. The only way to use it with a
Debian kernel is to have the dongle in a powered hub and first boot into
Windows or a normal kernel.org kernel to get the thing initialized.
Didn't send the patch earlier since I wanted to split off the
pre-numeration part of the driver so that after intialization we can
unload the unused parts of the driver as well as the the firmware class
module.

Jan
-
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: ext3 allocate-with-reservation latencies

[Ingo Molnar]

* Lee Revell <[EMAIL PROTECTED]> wrote:

> I can trigger latencies up to ~1.1 ms with a CVS checkout.  It looks
> like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
> loop:
> 
> ext3_test_allocatable (bitmap_search_next_usable_block)
> find_next_zero_bit (bitmap_search_next_usable_block)
> find_next_zero_bit (bitmap_search_next_usable_block)
> 
> ext3_test_allocatable (bitmap_search_next_usable_block)
> find_next_zero_bit (bitmap_search_next_usable_block)
> find_next_zero_bit (bitmap_search_next_usable_block)

Breaking the lock is not really possible at that point, and it doesnt 
look too easy to make that path preemptable either. (To make it 
preemptable rsv_lock would need to become a semaphore (this could be 
fine, as it's only used when a new reservation window is created).)

The hard part is the seqlock - the read side is performance-critical, 
maybe it could be solved via a preemptable but still scalable seqlock 
variant that uses a semaphore for the write side? It all depends on what 
the scalability impact of using a semaphore for the new-window code 
would be.

the best longterm solution for these types of tradeoffs seems to be to 
add a locking primitive that is a spinlock on !PREEMPT kernels and a 
semaphore on PREEMPT kernels. I.e. not as drastic as a full PREEMPT_RT 
kernel, but good enough to make latency-critical codepaths of ext3 
preemptable, without having to hurt scalability on !PREEMPT. The 
PREEMPT_RT kernel has all the 'compile-time type-switching' 
infrastructure for such tricks, all that needs to be changed to switch a 
lock's type is to change the spinlock definition - all the 
spin_lock() uses can remain unchanged. (The same method is used on 
PREEMPT_RT to have 'dual-type' spinlocks.)

the same thing could then also be used for things like the mm lock, and 
other longer-held locks that PREEMPT would like to see preemptable. It 
would also be a good first step towards merging the PREEMPT_RT 
infrastructure ;-) I'll cook up something.

Ingo
-
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: Crash during boot for 2.6.12-rc2.

[James Morris]

On Mon, 4 Apr 2005, Andrew Morton wrote:

> > I got this on a dual P4 Xeon with HT.  If anyone wants more information, 
> >  let me know.
> > 
> 
> .config, please..

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2
# Mon Apr  4 16:17:49 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODE is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_BKL is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y
# CONFIG_SECCOMP is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=m
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=m
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=m

#

help with the result of ksymoops < oops.txt

[sns_main]

ksymoops 2.4.9 on i686 2.4.26.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.26/ (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.

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle Kernel paging request at virtual address 2f087844
c01fbbb1
*pde = 
Oops: 0002
eax: 0001 ebx: f3dc53f0 ecx: 05ec108e edx: c0354000
esi: e9a9ca80 edi: 003f ebp: f62125e8 esp: c0355f18
ds: 0018 es: 0018 ss: 0018
Stack:  0001 d442a080 003f f7ece000 f7ece1f0  f7ede160 
f7ece2f8 c01fb897 f7ece160 f7ece000 f5fe0a80 1401  c0355fa0
c0108fd9 0012 f7ece000 c0355fa0 c0374300 0012 f5fe0a80 9000
Call Trace: [] [] [] [] []
[] [] [] []
Code: 00 8b 54 24 2c 3b 7a 0c 0f 44 f8 89 fd c1 e5 04 8b 02 01 05
Using defaults from ksymoops -t elf32-i386 -a i386


>>edx; c0354000 
>>esp; c0355f18 

Trace; c01fb897 
Trace; c0108fd9 
Trace; c01091f8 
Trace; c01053d0 
Trace; c010bd88 
Trace; c01053d0 
Trace; c01053f9 
Trace; c0105492 
Trace; c0105000 <_stext+0/0>

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   00 8b 54 24 2c 3b add%cl,0x3b2c2454(%ebx)
Code;  0006 Before first symbol
   6:   7a 0c jp 14 <_EIP+0x14>
Code;  0008 Before first symbol
   8:   0f 44 f8  cmove  %eax,%edi
Code;  000b Before first symbol
   b:   89 fd mov%edi,%ebp
Code;  000d Before first symbol
   d:   c1 e5 04  shl$0x4,%ebp
Code;  0010 Before first symbol
  10:   8b 02 mov(%edx),%eax
Code;  0012 Before first symbol
  12:   01 05 00 00 00 00 add%eax,0x0

<0>Kernel panic: Aiee, killing interrupts handler!

1 warning and 1 error 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: Adding a field to ext2_dir_entry_2

[Theodore Ts'o]

On Mon, Apr 04, 2005 at 07:12:51PM -0600, Andreas Dilger wrote:
> > Let me be more clear about what I am trying to do. In my masters
> > project, I am encrypting inodes along with the data part of the file. Keys
> > of different users are different. In the same directory, if there are
> > 2 files stored by different users, their inodes will be encrypted with
> > different keys. If user1 is doing "ls" on that directory, the inode
> > of the other file - which is encrypted by user2, will be decrypted by
> > using user1's key, resulting into garbage. To avoid this, I am trying
> > to store the uid in the directry entry, so that  I can match it with
> > current->fsuid and skip decrypting the inode if the file doesn't belong
> > to the current user. (assuming user1 doesnt want to share that file and
> > different users can store different files under same directory.)
> 
> This is broken by design.  What happens if you chown a file?  The UID will
> change in the inode, but nothing will be updated in the directory.  This
> key must be stored in the inode along with the ownership info (it can be
> an EA, and possibly a fast EA or fixed inode field in a large inode).

What else is broken about this design.  Let me count the ways...

1)  What about group access to files?

2)  It means that you can't do a filesystem consistency check without
knowing all of the keys, since the block pointers in the inode would
also be encrypted.

3) If user1 has previously accessed the file, the encrypted inode
information will already be cached, and visible when user2 accesses
the file; stat() doesn't result in a call into filesystem code if the
information is already cached.  

What's the point of encrypting the inode?  What problem are you trying
to solve?

As to why you're having problems:

"ext2-fs error (device fd(2,0)): ext2_check_page: bad entry in directory #2:
unaligned directory entry - offset=0, inode=2, rec_len=46, name_len=0"

46 is ascii for '.'.  You missed a spot in mke2fs where you changed
the directory entry structure.  Specifically, in libext2fs, and note
that some portions of the ext2fs library which still use
ext2_dir_entry as well as ext2_dir_entry_2, for historical / ABI
backwards compatibility reasons.

- 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/

ext3 allocate-with-reservation latencies

[Lee Revell]

I can trigger latencies up to ~1.1 ms with a CVS checkout.  It looks
like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
loop:

ext3_test_allocatable (bitmap_search_next_usable_block)
find_next_zero_bit (bitmap_search_next_usable_block)
find_next_zero_bit (bitmap_search_next_usable_block)

ext3_test_allocatable (bitmap_search_next_usable_block)
find_next_zero_bit (bitmap_search_next_usable_block)
find_next_zero_bit (bitmap_search_next_usable_block)

etc.

Lee


ext3_reservation.bz2
Description: application/bzip

Re: Logitech MX1000 Horizontal Scrolling

[David A. Desrosiers]

> This did it. I got it completely working now. Both the horizontal 
> and the vertical cruise control is working with no problems. I'm 
> scrolling and I can't find a single problem with the device.

Using these same instructions on Debian Unstable, with my 
Thinkpad T42P (2373Q1U), this doesn't work at all. I only get 
scrolling up/down and left/middle/right click, no horizontal 
scrolling, and none of the other buttons seem to do much of anything. 

I suspect the TP handles these events differently. 


David A. Desrosiers
[EMAIL PROTECTED]
http://gnu-designs.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/

Re: Crash during boot for 2.6.12-rc2.

[Andrew Morton]

James Morris <[EMAIL PROTECTED]> wrote:
>
> I got this on a dual P4 Xeon with HT.  If anyone wants more information, 
>  let me know.
> 

.config, please..
-
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: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

On Tue, 2005-04-05 at 07:46 +0530, Arun Srinivas wrote:

> 
> So, what I want from the above code is whenever process1 or process2 is 
> being scheduled measure the time and print the timedifference. But, when I 
> run my 2 processes as SCHED_FIFO processes i get only one set of 
> readingsindicating they have been scheduled only once and run till 
> completion.
> 
> But, as we saw above if interrupts have been processed they must have been 
> scheduled several times(i.e., schedule() called several times). Is my 
> measurement procedure not correct?

No! Interrupts are not scheduled. When an interrupt goes off, the
interrupt service routine (ISR) is executed. It doesn't need to be
scheduled. It runs right where it interrupted the CPU. That's why you
need to be careful about protecting data that ISRs manipulate with
spin_lock_irqsave. This not only protects against multiple CPUs, but
turns off interrupts so that an interrupt wont be called and one of the
ISRs modify the data you need to be atomic.

Your tasks are running and will be interrupted by an ISR, on return from
the routine, a check is made to see if your tasks should be preempted.
But since they are the highest running tasks and in FIFO mode, the check
determines that schedule should not be called.  So you will not see any
schedules while your tasks are running.

Now, if you where running Ingo's RT patch with PREEMPT_HARDIRQ enabled,
and your tasks were of lower priority than the ISR thread handlers, then
you would see the scheduling. Maybe that is what you want?

-- Steve


-
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/

Crash during boot for 2.6.12-rc2.

[James Morris]

I got this on a dual P4 Xeon with HT.  If anyone wants more information, 
let me know.


Creating /dev
Starting udev
input: AT Translated Set 2 keyboard on isa0060/serio0
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be 
trying access hardware directly.
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be 
trying access hardware directly.
[ cut here ]
kernel BUG at kernel/sched.c:2597!
invalid operand:  [#1]
PREEMPT SMP 
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.12-rc2) 
EIP is at sub_preempt_count+0x35/0x3f
eax: 0100   ebx: c03a0394   ecx: c03a0370   edx: 0001
esi:    edi: c01152db   ebp: f7fd464c   esp: f7fd464c
ds: 007b   es: 007b   ss: 0068
Process udev (pid: 57, threadinfo=f7fd4000 task=f7fd5a40)
Stack: f7fd4654 c034b416 f7fd466c c01342ec 0217 f7fd4754  f7fd46b0 
   f7fd4678 c0112192 f7fd4754 f7fd4698 c0103eaa c0359df2 0004 0006 
   f7fd4754  c01040e0 f7fd474c c0104177  f7fd4754  
Call Trace:
 [] show_stack+0x94/0xca
 [] show_registers+0x18b/0x225
 [] die+0xfb/0x176
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_unlock_irqrestore+0x24/0x4e
 [] search_module_extables+0x78/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock_irqsave+0x10/0x6f
 [] search_module_extables+0x15/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock_irqsave+0x10/0x6f
 [] search_module_extables+0x15/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock_irqsave+0x10/0x6f
 [] search_module_extables+0x15/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock_irqsave+0x10/0x6f
 [] search_module_extables+0x15/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock_irqsave+0x10/0x6f
 [] search_module_extables+0x15/0x82
 [] fixup_exception+0xe/0x2c
 [] do_trap+0x62/0xa4
 [] do_invalid_op+0x97/0xa1
 [] error_code+0x4f/0x54
 [] _spin_lock+0x10/0x68
 [] d_alloc+0x121/0x1a4
 [] real_lookup+0x9a/0xd4
 [] do_lookup+0x6a/0x75
 [] __link_path_walk+0x15b/0xdaf
 [] link_path_walk+0x4c/0xf2
 [] path_lookup+0xa3/0x19c
 [] __user_walk+0x28/0x3b
 [] vfs_lstat+0x17/0x3d
 [] sys_lstat64+0x14/0x28
 [] syscall_call+0x7/0xb
Code: 21 e0 8b 40 14 39 d0 7c 18 81 fa fe 00 00 00 77 04 84 c0 74 16 b8 00 f0 
ff ff 21 e0 29 50 14 5d c3 0f 0b 21 0a 3c b8 35 c0 eb de <0f> 0b 25 0a 3c b8 35 
c0 eb e0 55 89 e5 8b 40 04 5d e9 eb e2 ff 
 <0>Kernel panic - not syncing: Fatal exception in interrupt

-
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: Logitech MX1000 Horizontal Scrolling

[Esben Stien]

Jeremy Nickurak <[EMAIL PROTECTED]> writes:

> Now it's just the vertical scroller issue.

It's working perfectly here; just following that last link.

-- 
Esben Stien is [EMAIL PROTECTED]
 http://www.
  irc://irc./%23contact
  [sip|iax]:
   jid:b0ef@
-
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: Logitech MX1000 Horizontal Scrolling

[Esben Stien]

Juergen Kreileder <[EMAIL PROTECTED]> writes:

> http://blog.blackdown.de/2005/04/03/logitech-mx1000-configuration/

This did it. I got it completely working now. Both the horizontal and
the vertical cruise control is working with no problems. I'm scrolling
and I can't find a single problem with the device.

-- 
Esben Stien is [EMAIL PROTECTED]
 http://www.
  irc://irc./%23contact
  [sip|iax]:
   jid:b0ef@
-
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: ... no drivers for IEEE1394 product 0x/0x/0x in kernel 2.6.12-rc1-bk6

[Barry K. Nathan]

On Mon, Apr 04, 2005 at 08:22:56PM -0600, Bob Gill wrote:
> Hi.  I recently built 2.6.12-rc1-bk6.  The kernel seems to be tripping
> over sbp2.  The error messages keep right on rolling till I hit the
> reboot button (I let it run for more than 90 seconds last time).
> 2.6.11.6 builds/runs without any problems.
[snip]

I was having the same problem on a system of mine too, but it went away
after I disabled CONFIG_DEVFS_FS. You didn't include enough of your
.config for me to be able to tell if that is at all relevant in your
case however.

-Barry K. Nathan <[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: Processes stuck on D state on Dual Opteron

[Andrew Morton]

Claudio Martins <[EMAIL PROTECTED]> wrote:
>
>While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck in D 
>  state after some time.  
>This machine is a dual Opteron 248 with 2GB (ECC) on one node (the other 
>  node has no RAM modules plugged in, since this board works only with pairs).
> 
>I was using stress (http://weather.ou.edu/~apw/projects/stress/) with the 
>  following command line:
> 
>  stress -v -c 20 -i 12 -m 10 -d 20
> 
>This causes a constant load avg. of around 70, makes the machine go into 
>  swap a little, and writes up to about 20GB of random data to disk while 
>  eating up all CPU. After about half and hour random processes like top, df, 
>  etc get stuck in D state. Half of the 60 or so stress processes are also in 
> D 
>  state. The machine keeps being responsive for maybe some 15 minutes but then 
>  the shells just hang and sshd stops responding to connections, though the 
>  machine replies to pings (I don't have console acess till tomorrow).
> 
>The system is using ext3 with md software Raid1.
> 
>   I'm interested in knowing if anyone out there with dual Opterons can 
>  reproduce this or not. I also have access to an HP DL360 Dual Xeon, so I 
> will 
>  try to find out if this is AMD64 specific as soon as possible. Please let me 
>  know if you want me to run some other tests or give some more info to help 
>  solve this one.

Can you capture the output from alt-sysrq-T?
-
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] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

[Ingo Molnar]

latest patch attached. Changes:

 - stabilized calibration even more, by using cache flushing 
   instructions to generate a predictable working set. The cache 
   flushing itself is not timed, it is used to create quiescent
   cache  state.

   I only guessed the ia64 version - e.g. i didnt know what 'type' 
   argument to pass to ia64_sal_cache_flush() to get a d/cache 
   flush+invalidate. Same for ppc/ppc64 - i only guessed the function
   in question but didnt test it.

 - due to more stable results, reduced ITERATIONS from 3 to 2 - this 
   should further speed up calibration.

tested on x86, the calibration results look ok there.

Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -4640,6 +4641,506 @@ void __devinit init_sched_build_groups(s
 }
 
 
+/*
+ * Self-tuning task migration cost measurement between source and target CPUs.
+ *
+ * This is done by measuring the cost of manipulating buffers of varying
+ * sizes. For a given buffer-size here are the steps that are taken:
+ *
+ * 1) the source CPU reads+dirties a shared buffer 
+ * 2) the target CPU reads+dirties the same shared buffer
+ *
+ * We measure how long they take, in the following 4 scenarios:
+ *
+ *  - source: CPU1, target: CPU2 | cost1
+ *  - source: CPU2, target: CPU1 | cost2
+ *  - source: CPU1, target: CPU1 | cost3
+ *  - source: CPU2, target: CPU2 | cost4
+ *
+ * We then calculate the cost3+cost4-cost1-cost2 difference - this is
+ * the cost of migration.
+ *
+ * We then start off from a small buffer-size and iterate up to larger
+ * buffer sizes, in 5% steps - measuring each buffer-size separately, and
+ * doing a maximum search for the cost. (The maximum cost for a migration
+ * normally occurs when the working set size is around the effective cache
+ * size.)
+ */
+#define SEARCH_SCOPE   2
+#define MIN_CACHE_SIZE (64*1024U)
+#define DEFAULT_CACHE_SIZE (5*1024*1024U)
+#define ITERATIONS 2
+#define SIZE_THRESH130
+#define COST_THRESH130
+
+/*
+ * The migration cost is a function of 'domain distance'. Domain
+ * distance is the number of steps a CPU has to iterate down its
+ * domain tree to share a domain with the other CPU. The farther
+ * two CPUs are from each other, the larger the distance gets.
+ *
+ * Note that we use the distance only to cache measurement results,
+ * the distance value is not used numerically otherwise. When two
+ * CPUs have the same distance it is assumed that the migration
+ * cost is the same. (this is a simplification but quite practical)
+ */
+#define MAX_DOMAIN_DISTANCE 32
+
+static __initdata unsigned long long migration_cost[MAX_DOMAIN_DISTANCE] =
+   { [ 0 ... MAX_DOMAIN_DISTANCE-1 ] = -1LL };
+
+/*
+ * Allow override of migration cost - in units of microseconds.
+ * E.g. migration_cost=1000,2000,3000 will set up a level-1 cost
+ * of 1 msec, level-2 cost of 2 msecs and level3 cost of 3 msecs:
+ */
+static int __init migration_cost_setup(char *str)
+{
+   int ints[MAX_DOMAIN_DISTANCE+1], i;
+
+   str = get_options(str, ARRAY_SIZE(ints), ints);
+
+   printk("#ints: %d\n", ints[0]);
+   for (i = 1; i <= ints[0]; i++) {
+   migration_cost[i-1] = (unsigned long long)ints[i]*1000;
+   printk("migration_cost[%d]: %Ld\n", i-1, migration_cost[i-1]);
+   }
+   return 1;
+}
+
+__setup ("migration_cost=", migration_cost_setup);
+
+/*
+ * Global multiplier (divisor) for migration-cutoff values,
+ * in percentiles. E.g. use a value of 150 to get 1.5 times
+ * longer cache-hot cutoff times.
+ *
+ * (We scale it from 100 to 128 to long long handling easier.)
+ */
+
+#define MIGRATION_FACTOR_SCALE 128
+
+static __initdata unsigned int migration_factor = MIGRATION_FACTOR_SCALE;
+
+static int __init setup_migration_factor(char *str)
+{
+   get_option(, _factor);
+   migration_factor = migration_factor * MIGRATION_FACTOR_SCALE / 100;
+   return 1;
+}
+
+__setup("migration_factor=", setup_migration_factor);
+
+/*
+ * Estimated distance of two CPUs, measured via the number of domains
+ * we have to pass for the two CPUs to be in the same span:
+ */
+__init static unsigned long domain_distance(int cpu1, int cpu2)
+{
+   unsigned long distance = 0;
+   struct sched_domain *sd;
+
+   for_each_domain(cpu1, sd) {
+   WARN_ON(!cpu_isset(cpu1, sd->span));
+   if (cpu_isset(cpu2, sd->span))
+   return distance;
+   distance++;
+   }
+   if (distance >= MAX_DOMAIN_DISTANCE) {
+   WARN_ON(1);
+   distance = MAX_DOMAIN_DISTANCE-1;
+   }
+
+   return distance;
+}
+
+static __initdata unsigned int migration_debug = 1;
+
+static int __init setup_migration_debug(char *str)
+{
+   get_option(, _debug);
+   return 1;
+}
+
+__setup("migration_debug=", setup_migration_debug);
+
+/*
+ * 

... no drivers for IEEE1394 product 0x/0x/0x in kernel 2.6.12-rc1-bk6

[Bob Gill]

Hi.  I recently built 2.6.12-rc1-bk6.  The kernel seems to be tripping
over sbp2.  The error messages keep right on rolling till I hit the
reboot button (I let it run for more than 90 seconds last time).
2.6.11.6 builds/runs without any problems.
My build scripts includes:
# IEEE 1394 (FireWire) support
CONFIG_IEEE1394=m
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_OHCI1394=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_CMP is not set

#
# I2O device support
#
CONFIG_I2O=m
# CONFIG_I2O_CONFIG is not set
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
.and
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_IMM=m
CONFIG_SCSI_QLA2XXX=m

...The head end of the error message (/var/log/messages) is:
Apr  4 10:04:29 localhost kernel: Freeing unused kernel memory: 248k
freed
Apr  4 10:59:17 localhost kernel: SCSI subsystem initialized
Apr  4 10:59:17 localhost kernel: sbp2: $Rev: 1219 $ Ben Collins
<[EMAIL PROTECTED]>
Apr  4 10:59:17 localhost kernel: scsi0 : SCSI emulation for IEEE-1394
SBP-2 Devices
Apr  4 10:59:17 localhost kernel: ieee1394: sbp2: Logged into SBP-2
device
Apr  4 10:59:17 localhost kernel:   Vendor: Maxtor 4  Model: G160J8
Rev:
Apr  4 10:59:17 localhost kernel:   Type:   Direct-Access
ANSI SCSI revision: 06
Apr  4 10:59:17 localhost kernel: scsi1 : SCSI emulation for IEEE-1394
SBP-2 Devices
Apr  4 10:59:17 localhost kernel: SCSI device sda: 268435455 512-byte
hdwr sectors (137439 MB)
Apr  4 10:59:17 localhost kernel: sda: cache data unavailable
Apr  4 10:59:17 localhost kernel: sda: assuming drive cache: write
through
Apr  4 10:59:17 localhost kernel: SCSI device sda: 268435455 512-byte
hdwr sectors (137439 MB)
Apr  4 10:59:17 localhost kernel: sda: cache data unavailable
Apr  4 10:59:17 localhost kernel: sda: assuming drive cache: write
through
Apr  4 10:59:17 localhost kernel:  sda: sda1
Apr  4 10:59:17 localhost kernel: Attached scsi disk sda at scsi0,
channel 0, id 0, lun 0
Apr  4 10:59:17 localhost kernel: ieee1394: sbp2: Logged into SBP-2
device
Apr  4 10:59:17 localhost kernel:   Vendor: Maxtor 4  Model: G160J8
Rev:
Apr  4 10:59:17 localhost kernel:   Type:   Direct-Access
ANSI SCSI revision: 06
Apr  4 10:59:17 localhost kernel: SCSI device sdb: 268435455 512-byte
hdwr sectors (137439 MB)
Apr  4 10:59:17 localhost kernel: sdb: cache data unavailable
Apr  4 10:59:17 localhost kernel: sdb: assuming drive cache: write
through
Apr  4 10:59:17 localhost kernel: SCSI device sdb: 268435455 512-byte
hdwr sectors (137439 MB)
Apr  4 10:59:17 localhost kernel: sdb: cache data unavailable
Apr  4 10:59:17 localhost kernel: sdb: assuming drive cache: write
through
Apr  4 10:59:17 localhost kernel:  sdb: sdb1
Apr  4 10:59:17 localhost kernel: Attached scsi disk sdb at scsi1,
channel 0, id 0, lun 0
Apr  4 10:59:19 localhost smartd[5200]: Device: /dev/hdb, found in
smartd database.
 please note, I am taking from one /var/log/messages, but the time
seems to get a bit wierd here...I do use ntpd so
Apr  4 04:58:34 localhost rc.sysinit: -e
Apr  4 04:58:34 localhost start_udev: Starting udev:  succeeded
Apr  4 04:58:35 localhost udevsend[2633]: starting udevd daemon
Apr  4 04:58:39 localhost rc.sysinit: -e
Apr  4 04:58:39 localhost ieee1394.agent[3504]: ... no drivers for
IEEE1394 product 0x/0x/0x
Apr  4 04:58:39 localhost rc.sysinit: Configuring kernel parameters:
succeeded
Apr  4 04:58:40 localhost ieee1394.agent[3683]: ... no drivers for
IEEE1394 product 0x/0x/0x
Apr  4 04:58:40 localhost ieee1394.agent[3701]: ... no drivers for
IEEE1394 product 0x/0x/0x
Apr  4 04:58:40 localhost ieee1394.agent[3693]: ... no drivers for
IEEE1394 product 0x/0x/0x
Apr  4 10:58:40 localhost date: Mon Apr  4 10:58:40 MDT 2005
Apr  4 10:58:40 localhost rc.sysinit: Setting clock  (localtime): Mon
Apr  4 10:58:40 MDT 2005 succeeded
Apr  4 10:58:40 localhost rc.sysinit: Setting hostname
localhost.localdomain:  succeeded
Apr  4 10:59:20 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00ad
Apr  4 10:58:40 localhost scsi.agent[3909]: disk
at /devices/pci:00/:00:0d.0/fw-
host0/0030e000eb39/0030e000eb39-0/host0/target0:0:0/0:0:0:0
Apr  4 10:59:20 localhost smartd: smartd startup failed
Apr  4 10:59:20 localhost kernel:  printing eip:
Apr  4 10:58:40 localhost ieee1394.agent[3891]: ... no drivers for
IEEE1394 product 0x/0x/0x
Apr  4 10:59:20 localhost kernel: f88c242a
Apr  4 10:58:40 localhost fsck: Filesystem seems mounted read-only.
Skipping journal replay.
Apr  4 10:59:20 localhost kernel: *pde = 
Apr  4 10:58:41 localhost fsck: Checking 

Re: Touchpad does not work anymore

[Benoit Boissinot]

On Fri, Apr 01, 2005 at 07:29:15PM +0200, Benoit Boissinot wrote:
> On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote:
> > On Apr 1, 2005 11:43 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> > > > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > > > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > > > > > > It works, too. Which one is the best one?
> > > > > > >
> > > > > I tried to boot with the 2 patches applied (and the patch which solves
> > > > > noresume) and now touchpad/touchpoint no longer works (with this
> > > > > kernel or with an older kernel).
> > > > >
> > > >
> > 
> > Should work... The patches come into play only when
> > suspending/resuming. So you are saying even with an old, unpatched
> > kernel ALS stopped working, right?
> >
> I did a suspend/resume with the patches applied. And yes it doesn't work
> with an old unpatched kernel.
> Detected in dmesg, but no movement.
> 
When i booted the laptop today, the touchpad did work. I suppose it
was an hardware problem or something like that.

Sorry for bothering you.

Thanks

Benoit

-- 
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
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/

Processes stuck on D state on Dual Opteron

[Claudio Martins]

  Hi,

  While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck in D 
state after some time.  
  This machine is a dual Opteron 248 with 2GB (ECC) on one node (the other 
node has no RAM modules plugged in, since this board works only with pairs).

  I was using stress (http://weather.ou.edu/~apw/projects/stress/) with the 
following command line:

stress -v -c 20 -i 12 -m 10 -d 20

  This causes a constant load avg. of around 70, makes the machine go into 
swap a little, and writes up to about 20GB of random data to disk while 
eating up all CPU. After about half and hour random processes like top, df, 
etc get stuck in D state. Half of the 60 or so stress processes are also in D 
state. The machine keeps being responsive for maybe some 15 minutes but then 
the shells just hang and sshd stops responding to connections, though the 
machine replies to pings (I don't have console acess till tomorrow).

  The system is using ext3 with md software Raid1.

 I'm interested in knowing if anyone out there with dual Opterons can 
reproduce this or not. I also have access to an HP DL360 Dual Xeon, so I will 
try to find out if this is AMD64 specific as soon as possible. Please let me 
know if you want me to run some other tests or give some more info to help 
solve this one.

 Kernel config follows (compiled with gcc-3.4.4 on debian)...

 Best regards, thanks

  Claudio Martins

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2
# Tue Apr  5 00:15:41 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_SCHED_SMT is not set
CONFIG_K8_NUMA=y
# CONFIG_NUMA_EMU is not set
CONFIG_DISCONTIGMEM=y
CONFIG_NUMA=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NR_CPUS=2
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
CONFIG_SECCOMP=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
# CONFIG_ACPI_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_UNORDERED_IO is not set
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_NAMES is not set
# CONFIG_PCI_DEBUG is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_UID16=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not 

Re: scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

ok.My program runs for 30 sec. approx. I did
#!/bin/sh
cat /proc/interrupts
run_test
cat /proc/interrupts
and I see there is quite some difference in the numbers.meaning 
interrupts have been processed by the respective processor when my 
SCHED_FIFO processes have been running on both the cpu's.

But, then I am not sure why I am getting only 1 reading for the timediff. of 
schedule between my 2 processes.I do the following in my schedule() in 
sched.c:
( I make the kernel know the pid's of my 2 process...lets say pid1 and pid2)

/* in function schedule() in sched.c*/
schedule()
{
  need _resched:
   /* after now=sched_clock(); I insert my code 
here*/
 if(current->pid=pid1)
{
   time1=now;
 }
  elseif (current->pid=pid2)
{
   time2=now;
}
/*after i get the 2 values for time1 and 
time2*/
timediff= time1-time2;// or 
time2 - time1 which ever is greater*/
printk(KERN_ERR "%llu",timediff);
}

So, what I want from the above code is whenever process1 or process2 is 
being scheduled measure the time and print the timedifference. But, when I 
run my 2 processes as SCHED_FIFO processes i get only one set of 
readingsindicating they have been scheduled only once and run till 
completion.

But, as we saw above if interrupts have been processed they must have been 
scheduled several times(i.e., schedule() called several times). Is my 
measurement procedure not correct?

please help.
thanks
arun

From: Steven Rostedt <[EMAIL PROTECTED]>
To: Arun Srinivas <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], LKML 
Subject: Re: scheduler/SCHED_FIFO behaviour
Date: Mon, 04 Apr 2005 19:17:04 -0400
On Tue, 2005-04-05 at 04:36 +0530, Arun Srinivas wrote:
> I am scheduling 2 SCHED_FIFO processes and set them affinity( process A 
runs
> on processor 1 and process B runs on processor 2), on a HT processor.(I 
did
> this cause I wanted to run them together).Now, in schedule() I measure 
the
> timedifference between when they are scheduled. I found that when I
> introduce these 2 processes as SCHED_FIFO they are
>
> 1)scheduled only once and run till completion ( they running time is 
around
> 2 mins.)

If they are the highest priority task, and running as FIFO this is the
proper behavior.
> 2)entire system appears frozenno mouse/key presses detected until 
the
> processes exit.
>

If X is not at a higher priority than the test you are running, it will
never get a chance to run.
> >From what I observed does it mean that even the OS / interrupt handler 
does
> not occur during the entire period of time these real time processes 
run??
> (as I said the processes run in minutes).

The interrupts do get processed. Now the bottom halves and tasklets may
be starved if they are set at a lower priority than your test (ie. the
ksoftirqd thread). But most likely they are processed too.
> How can I verify that?
>
#!/bin/sh
cat /proc/interrupts
run_test
cat /proc/interrupts
If the run_test takes 2 minutes, you should see a large difference in
the two outputs.
-- Steve
> Thanks
> Arun

_
The MSN Survey! 
http://www.cross-tab.com/surveys/run/test.asp?sid=2026=1 Help us help 
you better!

-
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: [RFC 1/6]SEP initialization rework

[Li Shaohua]

On Tue, 2005-04-05 at 03:10, Zwane Mwaikambo wrote:
> On Mon, 4 Apr 2005, Li Shaohua wrote:
> 
> >  linux-2.6.11-root/arch/i386/kernel/smpboot.c   |6 ++
> >  linux-2.6.11-root/arch/i386/kernel/sysenter.c  |   10 ++
> >  linux-2.6.11-root/arch/i386/mach-voyager/voyager_smp.c |6 ++
> >  3 files changed, 18 insertions(+), 4 deletions(-)
> > 
> > diff -puN arch/i386/kernel/sysenter.c~sep_init_cleanup 
> > arch/i386/kernel/sysenter.c
> > --- linux-2.6.11/arch/i386/kernel/sysenter.c~sep_init_cleanup   
> > 2005-03-28 09:32:30.936304248 +0800
> > +++ linux-2.6.11-root/arch/i386/kernel/sysenter.c   2005-03-28 
> > 09:58:20.703703792 +0800
> > @@ -26,6 +26,11 @@ void enable_sep_cpu(void *info)
> > int cpu = get_cpu();
> > struct tss_struct *tss = _cpu(init_tss, cpu);
> >  
> > +   if (!boot_cpu_has(X86_FEATURE_SEP)) {
> > +   put_cpu();
> > +   return;
> > +   }
> > +
> 
> Do you have systems like this? Is it really skipping SEP if the boot 
> processor doesn't have SEP?
No, I haven't such system. This is the logic of original SEP
initialization. If the CPU hasn't SEP, original logic doesn't call
'on_each_cpu(enable_sep_cpu,...)'.

Thanks,
Shaohua

-
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: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Li Shaohua]

Hi,
On Mon, 2005-04-04 at 23:33, Nathan Lynch wrote:
> 
> I'd say fix the smpboot code so that it doesn't create new idle tasks
> except during boot.
I'd like the the CPU hotremove case just likes the case that CPU isn't
boot. A non-boot CPU hasn't a idle thread. But you may think it's not
worthy doing. Anyway, I will keep the idle thread in a updated patch
like what you said.

> > > We've been
> > > doing cpu removal on ppc64 logical partitions for a while and never
> > > needed to do anything like this. 
> > Did it remove idle thread? or dead cpu is in a busy loop of idle?
> 
> Neither.  The cpu is definitely offline, but there is no reason to
> free the idle thread.
> 
> > 
> > >  Maybe idle_task_exit would suffice?
> > idle_task_exit seems just drop mm. We need destroy the idle task for
> > physical CPU hotplug, right?
> 
> No.
> 
> > > 
> > > I don't understand the need for this, either.  The existing cpu
> > > hotplug notifier in the scheduler takes care of initializing the sched
> > > domains and groups appropriately for online/offline events; why do you
> > > need to touch the runqueue structures?
> > If a CPU is physically hotremoved from the system, shouldn't we clean
> > its runqueue?
> 
> No.  It should make zero difference to the scheduler whether the "play
> dead" cpu hotplug or "physical" hotplug is being used.  
Keeping some fields like 'cpu_load' are meanless for a hotadded CPU to
me. Just ignore them?

Thanks,
Shaohua

-
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] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

[Ingo Molnar]

* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:

> Perhaps, I'm not getting the latest patch?  It skipped measuring 
> because migration cost array is non-zero (initialized to -1LL):

yeah ... some mixup here. I've attached the latest.

> Also, the cost calculation in measure_one() looks fishy to me in this 
> version.

> > +   t0 = sched_clock();
> > +   touch_cache(cache, size);
> > +   t1 = sched_clock();

> > +   t2 = sched_clock();
> > +   touch_cache(cache, size);
> > +   t3 = sched_clock();

> > +   cost = t2-t1 + t3-t2;
> 
> Typo here ??

yeah - fixed this too in the attached snapshot.

Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -4640,6 +4641,478 @@ void __devinit init_sched_build_groups(s
 }
 
 
+/*
+ * Self-tuning task migration cost measurement between source and target CPUs.
+ *
+ * This is done by measuring the cost of manipulating buffers of varying
+ * sizes. For a given buffer-size here are the steps that are taken:
+ *
+ * 1) the source CPU reads+dirties a shared buffer 
+ * 2) the target CPU reads+dirties the same shared buffer
+ *
+ * We measure how long they take, in the following 4 scenarios:
+ *
+ *  - source: CPU1, target: CPU2 | cost1
+ *  - source: CPU2, target: CPU1 | cost2
+ *  - source: CPU1, target: CPU1 | cost3
+ *  - source: CPU2, target: CPU2 | cost4
+ *
+ * We then calculate the cost3+cost4-cost1-cost2 difference - this is
+ * the cost of migration.
+ *
+ * We then start off from a small buffer-size and iterate up to larger
+ * buffer sizes, in 5% steps - measuring each buffer-size separately, and
+ * doing a maximum search for the cost. (The maximum cost for a migration
+ * normally occurs when the working set size is around the effective cache
+ * size.)
+ */
+#define SEARCH_SCOPE   2
+#define MIN_CACHE_SIZE (64*1024U)
+#define DEFAULT_CACHE_SIZE (5*1024*1024U)
+#define ITERATIONS 3
+#define SIZE_THRESH130
+#define COST_THRESH130
+
+/*
+ * The migration cost is a function of 'domain distance'. Domain
+ * distance is the number of steps a CPU has to iterate down its
+ * domain tree to share a domain with the other CPU. The farther
+ * two CPUs are from each other, the larger the distance gets.
+ *
+ * Note that we use the distance only to cache measurement results,
+ * the distance value is not used numerically otherwise. When two
+ * CPUs have the same distance it is assumed that the migration
+ * cost is the same. (this is a simplification but quite practical)
+ */
+#define MAX_DOMAIN_DISTANCE 32
+
+static __initdata unsigned long long migration_cost[MAX_DOMAIN_DISTANCE] =
+   { -1LL , };
+
+/*
+ * Allow override of migration cost - in units of microseconds.
+ * E.g. migration_cost=1000,2000,3000 will set up a level-1 cost
+ * of 1 msec, level-2 cost of 2 msecs and level3 cost of 3 msecs:
+ */
+static int __init migration_cost_setup(char *str)
+{
+   int ints[MAX_DOMAIN_DISTANCE+1], i;
+
+   str = get_options(str, ARRAY_SIZE(ints), ints);
+
+   printk("#ints: %d\n", ints[0]);
+   for (i = 1; i <= ints[0]; i++) {
+   migration_cost[i-1] = (unsigned long long)ints[i]*1000;
+   printk("migration_cost[%d]: %Ld\n", i-1, migration_cost[i-1]);
+   }
+   return 1;
+}
+
+__setup ("migration_cost=", migration_cost_setup);
+
+/*
+ * Global multiplier (divisor) for migration-cutoff values,
+ * in percentiles. E.g. use a value of 150 to get 1.5 times
+ * longer cache-hot cutoff times.
+ *
+ * (We scale it from 100 to 128 to long long handling easier.)
+ */
+
+#define MIGRATION_FACTOR_SCALE 128
+
+static __initdata unsigned int migration_factor = MIGRATION_FACTOR_SCALE;
+
+static int __init setup_migration_factor(char *str)
+{
+   get_option(, _factor);
+   migration_factor = migration_factor * MIGRATION_FACTOR_SCALE / 100;
+   return 1;
+}
+
+__setup("migration_factor=", setup_migration_factor);
+
+/*
+ * Estimated distance of two CPUs, measured via the number of domains
+ * we have to pass for the two CPUs to be in the same span:
+ */
+__init static unsigned long domain_distance(int cpu1, int cpu2)
+{
+   unsigned long distance = 0;
+   struct sched_domain *sd;
+
+   for_each_domain(cpu1, sd) {
+   WARN_ON(!cpu_isset(cpu1, sd->span));
+   if (cpu_isset(cpu2, sd->span))
+   return distance;
+   distance++;
+   }
+   if (distance >= MAX_DOMAIN_DISTANCE) {
+   WARN_ON(1);
+   distance = MAX_DOMAIN_DISTANCE-1;
+   }
+
+   return distance;
+}
+
+static __initdata unsigned int migration_debug = 1;
+
+static int __init setup_migration_debug(char *str)
+{
+   get_option(, _debug);
+   return 1;
+}
+
+__setup("migration_debug=", setup_migration_debug);
+
+/*
+ * Maximum cache-size that the scheduler should try to measure.
+ * Architectures 

RE: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

[Chen, Kenneth W]

* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> The cache size information on ia64 is already available at the finger
> tip. Here is a patch that I whipped up to set max_cache_size for ia64.

Ingo Molnar wrote on Monday, April 04, 2005 4:38 AM
> thanks - i've added this to my tree.
>
> i've attached the latest snapshot. There are a number of changes in the
> patch: firstly, i changed the direction of the iteration to go from
> small sizes to larger sizes, and i added a method to detect the maximum.
>
> Furthermore, i tweaked the test some more to make it both faster and
> more reliable, and i cleaned up the code. (e.g. now we migrate via the
> scheduler, not via on_each_cpu().) The default patch should print enough
> debug information as-is.
>
> I changed the workload too so potentially the detected values might be
> off from the ideal value on your box. The values detected on x86 are
> mostly unchanged, relative to previous patches.

Perhaps, I'm not getting the latest patch?  It skipped measuring because
migration cost array is non-zero (initialized to -1LL):

[00][01][02][03]
[00]: - 0.0(0)  0.0(0)  0.0(0)
[01]:   0.0(0)- 0.0(0)  0.0(0)
[02]:   0.0(0)  0.0(0)- 0.0(0)
[03]:   0.0(0)  0.0(0)  0.0(0)-

| cacheflush times [1]: 0.0 (-1)
| calibration delay: 0 seconds



Need this change?  I bet you had that in your tree already.

--- ./kernel/sched.c.orig   2005-04-04 18:01:45.0 -0700
+++ ./kernel/sched.c2005-04-04 18:21:41.0 -0700
@@ -5050,7 +5050,7 @@ void __devinit calibrate_migration_costs
/*
 * Do we have the result cached already?
 */
-   if (migration_cost[distance])
+   if (migration_cost[distance] != -1LL)
cost = migration_cost[distance];
else {
cost = measure_migration_cost(cpu1, cpu2);



Also, the cost calculation in measure_one() looks fishy to me in this version.

> + /*
> +  * Dirty the working set:
> +  */
> + t0 = sched_clock();
> + touch_cache(cache, size);
> + t1 = sched_clock();
> +
> + /*
> +  * Migrate to the target CPU, dirty the L2 cache and access
> +  * the shared buffer. (which represents the working set
> +  * of a migrated task.)
> +  */
> + mask = cpumask_of_cpu(target);
> + set_cpus_allowed(current, mask);
> + WARN_ON(smp_processor_id() != target);
> +
> + t2 = sched_clock();
> + touch_cache(cache, size);
> + t3 = sched_clock();
> +
> + cost = t2-t1 + t3-t2;

Typo here ??


-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Dmitry Torokhov]

On Monday 04 April 2005 19:35, Jaco Kroon wrote:
> Dmitry Torokhov wrote:
> 
> > A-haa.. Well, in that case we'll cheat ;) and just disable MUX mode
> > for your Toshiba via a DMI quirk, like we do for certain Fujitsus. If
> > there is no external port there is no reason to have the controller in
> > MUX mode.
> > 
> > Could you please send me output of 'dmidecode' utility?
> 
> Ah yes.  Your lucky it's only a 37KB download.  Some nice tools...
> 
> It's a _lot_ of output so I'm again rather attaching it (gzipped).
>

Ok, great! Please try the patch below (against 2.6.12-rc{1|2}).
 
> Would this quirk also imply usb-handoff?
>

No, just nomux. We are still battling whether we shoudl have usb-handoff on
by default.
 
> One (hopefully) last query, lspci reports the following device (which I
> assume is the SD card reader):
> 
> :02:04.2 Class 0805: ENE Technology Inc: Unknown device 0550
> 
> How can one confirm what this is?

Not sure, sorry.

-- 
Dmitry

===

Input: automatically disable MUX mode on Toshiba Satellite P10
   because it interferes with ALPS touchpad detection and
   causes horrible death on reboot. Since P10 does not have
   external PS/2 ports MUX mode does not have any advantages
   over legacy mode anyway.


 i8042-x86ia64io.h |   11 ++-
 1 files changed, 10 insertions(+), 1 deletion(-)

Index: dtor/drivers/input/serio/i8042-x86ia64io.h
===
--- dtor.orig/drivers/input/serio/i8042-x86ia64io.h
+++ dtor/drivers/input/serio/i8042-x86ia64io.h
@@ -88,9 +88,11 @@ static struct dmi_system_id __initdata i
 };
 
 /*
- * Some Fujitsu notebooks are ahving trouble with touhcpads if
+ * Some Fujitsu notebooks are having trouble with touchpads if
  * active multiplexing mode is activated. Luckily they don't have
  * external PS/2 ports so we can safely disable it.
+ * ... apparently some Toshibas don't like MUX mode either and
+ * die horrible death on reboot.
  */
 static struct dmi_system_id __initdata i8042_dmi_nomux_table[] = {
{
@@ -121,6 +123,13 @@ static struct dmi_system_id __initdata i
DMI_MATCH(DMI_PRODUCT_NAME, "FMVLT70H"),
},
},
+   {
+   .ident = "Toshiba P10",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P10"),
+   },
+   },
{ }
 };
 
-
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: Adding a field to ext2_dir_entry_2

[Christopher Li]

That design sounds bad.

Anyway, I guess the error you are getting might have some thing to do with
the "." and ".." entry. Your current directory need to in the same
format as well. That is the price you pay for breaking the compatibility.

Chris


On Mon, Apr 04, 2005 at 08:08:57PM -0400, Vineet Joglekar wrote:
> 
> Hi Andreas,
> 
> I have created another file system - copied everything from ext2, renaming it 
> as some different file system and doing some experiments on that.
> 
> Let me be more clear about what I am trying to do. In my masters project, I 
> am encrypting inodes along with the data part of the file. Keys of different 
> users are different. In the same directory, if there are 2 files stored by 
> different users, their inodes will be encrypted with different keys. If user1 
> is doing "ls" on that directory, the inode of the other file - which is 
> encrypted by user2, will be decrypted by using user1's key, resulting into 
> garbage. To avoid this, I am trying to store the uid in the directry entry, 
> so that  I can match it with current->fsuid and skip decrypting the inode if 
> the file doesn't belong to the current user. (assuming user1 doesnt want to 
> share that file and different users can store different files under same 
> directory.)
> 
> Thanks and regards,
> 
> Vineet
> 
>  --- On Mon 04/04, Andreas Dilger < [EMAIL PROTECTED] > wrote:
> From: Andreas Dilger [mailto: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>  Cc: linux-kernel@vger.kernel.org, linux-c-programming@vger.kernel.org
> Date: Mon, 4 Apr 2005 17:17:59 -0600
> Subject: Re: Adding a field to ext2_dir_entry_2
> 
> On Apr 04, 2005  18:54 -0400, Vineet Joglekar wrote:> I working with 
> linux kernel 2.4.28. I want to add 1 more field to> ext2_dir_entry_2 - 
> the new version of directory entry for ext2fs.> > I did add the __u32 
> field to the struct ext2_dir_entry_2 defined in> ext2_fs.h I also 
> modified the EXT2_DIR_REC_LEN macro to:> > (((name_len) + 12 + 
> EXT2_DIR_ROUND) & ~EXT2_DIR_ROUND)> > (+12 instead of +8) to 
> incorporate newly added 4 bytes field.> > I made the similar changes 
> to the mke2fs utility also.This means your filesystem will not be 
> mountable by any other version ofLinux.  What is more important is why 
> you want to do this - there areother mechanisms that may be more 
> appropriate depending on what you aredoing.Cheers, 
> Andreas--Andreas DilgerPrincipal Software EngineerCluster 
> File Systems, Inc.Attachment: Attachment  (0.19KB)
> 
> ___
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> -
> 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: Adding a field to ext2_dir_entry_2

[Andreas Dilger]

On Apr 04, 2005  20:08 -0400, Vineet Joglekar wrote:
> I have created another file system - copied everything from ext2,
> renaming it as some different file system and doing some experiments on that.
> 
> Let me be more clear about what I am trying to do. In my masters
> project, I am encrypting inodes along with the data part of the file. Keys
> of different users are different. In the same directory, if there are
> 2 files stored by different users, their inodes will be encrypted with
> different keys. If user1 is doing "ls" on that directory, the inode
> of the other file - which is encrypted by user2, will be decrypted by
> using user1's key, resulting into garbage. To avoid this, I am trying
> to store the uid in the directry entry, so that  I can match it with
> current->fsuid and skip decrypting the inode if the file doesn't belong
> to the current user. (assuming user1 doesnt want to share that file and
> different users can store different files under same directory.)

This is broken by design.  What happens if you chown a file?  The UID will
change in the inode, but nothing will be updated in the directory.  This
key must be stored in the inode along with the ownership info (it can be
an EA, and possibly a fast EA or fixed inode field in a large inode).

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.



pgp4ctWP2BNB4.pgp
Description: PGP signature

Re: [RFC 5/6]clean cpu state after hotremove CPU

[Li Shaohua]

On Tue, 2005-04-05 at 03:11, Zwane Mwaikambo wrote:
> On Mon, 4 Apr 2005, Li Shaohua wrote:
> 
> > Clean up all CPU states including its runqueue and idle thread, 
> > so we can use boot time code without any changes.
> > Note this makes /sys/devices/system/cpu/cpux/online unworkable.
> >  
> >  #ifdef CONFIG_HOTPLUG_CPU
> >  #include 
> > +
> > +#ifdef CONFIG_STR_SMP
> > +extern void cpu_exit_clear(int);
> > +#endif
> 
> Perhaps change that ifdef to denote something which clearly shows that its 
> physical hotplug as we'll need this for other users too.
Ok.

> > +#ifdef CONFIG_STR_SMP
> > +extern void do_exit_idle(void);
> > +extern void cpu_uninit(void);
> > +void cpu_exit_clear(int cpu)
> > +{
> > +   int sibling;
> > +   cpucount --;
> 
> Is that protected by the cpu_control semaphore?
cpu_exit_clear is called before the dead CPU ack CPU_DEAD, so it's
finished before __cpu_die returns, which is protected by cpu_control.
Maybe I should add comments for it.

Thanks,
Shaohua

-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Jaco Kroon]

Dmitry Torokhov wrote:

> A-haa.. Well, in that case we'll cheat ;) and just disable MUX mode
> for your Toshiba via a DMI quirk, like we do for certain Fujitsus. If
> there is no external port there is no reason to have the controller in
> MUX mode.
> 
> Could you please send me output of 'dmidecode' utility?

Ah yes.  Your lucky it's only a 37KB download.  Some nice tools...

It's a _lot_ of output so I'm again rather attaching it (gzipped).

Would this quirk also imply usb-handoff?

One (hopefully) last query, lspci reports the following device (which I
assume is the SD card reader):

:02:04.2 Class 0805: ENE Technology Inc: Unknown device 0550

How can one confirm what this is?

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


dmidecode.gz
Description: application/gzip


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openib-general] [PATCH][RFC][3/4] IB: userspace verbs mthca changes

[Tom Duffy]

On Mon, 2005-04-04 at 15:09 -0700, Roland Dreier wrote:
> --- linux-export.orig/drivers/infiniband/hw/mthca/mthca_dev.h 2005-04-04 
> 14:57:12.254750421 -0700
> +++ linux-export/drivers/infiniband/hw/mthca/mthca_dev.h  2005-04-04 
> 14:58:12.411669307 -0700
> @@ -49,14 +49,6 @@
>  #define DRV_VERSION  "0.06-pre"
>  #define DRV_RELDATE  "November 8, 2004"
>  
> -/* XXX remove once SINAI defines make it into kernel.org */
> -#ifndef PCI_DEVICE_ID_MELLANOX_SINAI_OLD
> -#define PCI_DEVICE_ID_MELLANOX_SINAI_OLD 0x5e8c
> -#endif
> -#ifndef PCI_DEVICE_ID_MELLANOX_SINAI
> -#define PCI_DEVICE_ID_MELLANOX_SINAI 0x6274
> -#endif
> -
>  enum {
>   MTHCA_FLAG_DDR_HIDDEN = 1 << 1,
>   MTHCA_FLAG_SRQ= 1 << 2,

Now, you are really gonna hate me for asking you to put this in as you
probably did not want to include this in the patch to lkml.

So, maybe Grant was right ;-)

-tduffy


signature.asc
Description: This is a digitally signed message part

Re: i8042 controller on Toshiba Satellite P10 notebook - patch

[Dmitry Torokhov]

On Apr 4, 2005 6:54 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov wrote:
> > Ok, try booting with "usb-handoff i8042.nomux". If that cures
> 
> yes, it cures both problems (death on reboot and ALPS), in fact.  But I
> must have *both* params.  nomux without usb-handoff causes all input
> devices to fail.  Thanks goodness for ssh.  Anyway - I'm now running a
> clean 2.6.11.6 kernel that *works*.
> 
> > death-on-reboot problem then Vojtech already has a patch in
> > 2.6.12-rc1:
> >
> > http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]
> 
> Yes, this should fix the death-on-reboot (why oh why can't the BIOS just
> "do the right thing"), it still won't get me alps though.  For that I
> need the nomux option - ie, a total different codepath than what that
> patch attends to.  And it probably won't fix the keyboard problem.  This
> sucks (don't get me wrong - I appreciate that my hardware is now
> functioning properly - only things afaik that doesn't work now is the SD
> card reader and suspend/hibernate and with ati-drivers there is not a
> chance in hell that that'll ever work, neither of which is of critical
> importance for me).
> 
> > Yes, with 4 ports your external mouse is independent from the touhpad.
> > When you have only 1 port you can't use touchpad's extended mode
> > together with an external mouse.
> 
> No external PS/2 port :).
> 

A-haa.. Well, in that case we'll cheat ;) and just disable MUX mode
for your Toshiba via a DMI quirk, like we do for certain Fujitsus. If
there is no external port there is no reason to have the controller in
MUX mode.

Could you please send me output of 'dmidecode' utility?
 
-- 
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: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Nigel Cunningham]

Hi.

On Tue, 2005-04-05 at 08:46, Nathan Lynch wrote:
> Hi Nigel!
> 
> On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote:
> > 
> > On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
> > > > Yes, exactly. Someone who understand do_exit please help clean up the
> > > > code. I'd like to remove the idle thread, since the smpboot code will
> > > > create a new idle thread.
> > > 
> > > I'd say fix the smpboot code so that it doesn't create new idle tasks
> > > except during boot.
> > 
> > Would that mean that CPUs that were physically hotplugged wouldn't get
> > idle threads?
> 
> No, that wouldn't work.  I am saying that there's little to gain by
> adding all this complexity for destroying the idle tasks when it's
> fairly simple to create num_possible_cpus() - 1 idle tasks* to
> accommodate any additional cpus which may come along.  This is what
> ppc64 does now, and it should be feasible on any architecture which
> supports cpu hotplug.

Ah. Ta. I was a little confused :>

Nigel

> * num_possible_cpus() - 1 because the idle task for the boot cpu is
>   created in sched_init.
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

-
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: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Nathan Lynch]

Hi Nigel!

On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote:
> 
> On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
> > > Yes, exactly. Someone who understand do_exit please help clean up the
> > > code. I'd like to remove the idle thread, since the smpboot code will
> > > create a new idle thread.
> > 
> > I'd say fix the smpboot code so that it doesn't create new idle tasks
> > except during boot.
> 
> Would that mean that CPUs that were physically hotplugged wouldn't get
> idle threads?

No, that wouldn't work.  I am saying that there's little to gain by
adding all this complexity for destroying the idle tasks when it's
fairly simple to create num_possible_cpus() - 1 idle tasks* to
accommodate any additional cpus which may come along.  This is what
ppc64 does now, and it should be feasible on any architecture which
supports cpu hotplug.


Nathan

* num_possible_cpus() - 1 because the idle task for the boot cpu is
  created in sched_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: Adding a field to ext2_dir_entry_2

[Vineet Joglekar]

Hi Andreas,



I have created another file system - copied everything from ext2, renaming it 
as some different file system and doing some experiments on that.



Let me be more clear about what I am trying to do. In my masters project, I am 
encrypting inodes along with the data part of the file. Keys of different users 
are different. In the same directory, if there are 2 files stored by different 
users, their inodes will be encrypted with different keys. If user1 is doing 
"ls" on that directory, the inode of the other file - which is encrypted by 
user2, will be decrypted by using user1's key, resulting into garbage. To avoid 
this, I am trying to store the uid in the directry entry, so that  I can match 
it with current->fsuid and skip decrypting the inode if the file doesn't belong 
to the current user. (assuming user1 doesnt want to share that file and 
different users can store different files under same directory.)



Thanks and regards,



Vineet



 --- On Mon 04/04, Andreas Dilger < [EMAIL PROTECTED] > wrote:

From: Andreas Dilger [mailto: [EMAIL PROTECTED]

To: [EMAIL PROTECTED]

 Cc: linux-kernel@vger.kernel.org, linux-c-programming@vger.kernel.org

Date: Mon, 4 Apr 2005 17:17:59 -0600

Subject: Re: Adding a field to ext2_dir_entry_2



On Apr 04, 2005  18:54 -0400, Vineet Joglekar wrote:> I working with linux 
kernel 2.4.28. I want to add 1 more field to> ext2_dir_entry_2 - the new 
version of directory entry for ext2fs.> > I did add the __u32 field to 
the struct ext2_dir_entry_2 defined in> ext2_fs.h I also modified the 
EXT2_DIR_REC_LEN macro to:> > (((name_len) + 12 + EXT2_DIR_ROUND) & 
~EXT2_DIR_ROUND)> > (+12 instead of +8) to incorporate newly added 4 
bytes field.> > I made the similar changes to the mke2fs utility 
also.This means your filesystem will not be mountable by any other 
version ofLinux.  What is more important is why you want to do this - there 
areother mechanisms that may be more appropriate depending on what you 
aredoing.Cheers, Andreas--Andreas DilgerPrincipal 
Software EngineerCluster File Systems, Inc.Attachment: Attachment  
(0.19KB)

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-
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 2.6.12-rc1-mm4] mips: update VR41xx CPU-PCI bridge support

[Yoichi Yuasa]

Hello Andrew,

I received a comment from Mita-san.

On Tue, 5 Apr 2005 00:45:24 +0900
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:

> This patch updates NEC VR4100 series CPU-PCI bridge support.
> This patch already had applied to Ralf's cvs.
> 



> + if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
> + return -EBUSY;
> +
> + pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
> + if (pciu_base == NULL)
> + return -EBUSY;
> +

I forgot to put release_mem_region() in here.

I update this patch.
Please apply new one.

Yoichi

Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c 
rc1-mm4/arch/mips/pci/ops-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c Wed Mar  2 16:38:17 2005
+++ rc1-mm4/arch/mips/pci/ops-vr41xx.c  Mon Apr  4 22:46:44 2005
@@ -3,7 +3,7 @@
  *
  *  Copyright (C) 2001-2003 MontaVista Software Inc.
  *Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- *  Copyright (C) 2004  Yoichi Yuasa <[EMAIL PROTECTED]>
+ *  Copyright (C) 2004-2005  Yoichi Yuasa <[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
@@ -29,8 +29,8 @@
 
 #include 
 
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
 
 static inline int set_pci_configuration_address(unsigned char number,
 unsigned int devfn, int where)
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c 
rc1-mm4/arch/mips/pci/pci-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c Fri Apr  1 21:17:30 2005
+++ rc1-mm4/arch/mips/pci/pci-vr41xx.c  Tue Apr  5 07:47:17 2005
@@ -3,8 +3,8 @@
  *
  *  Copyright (C) 2001-2003 MontaVista Software Inc.
  *Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- *  Copyright (C) 2004  Yoichi Yuasa <[EMAIL PROTECTED]>
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ *  Copyright (C) 2004-2005  Yoichi Yuasa <[EMAIL PROTECTED]>
+ *  Copyright (C) 2004 by Ralf Baechle ([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
@@ -31,12 +31,18 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "pci-vr41xx.h"
 
 extern struct pci_ops vr41xx_pci_ops;
 
+static void __iomem *pciu_base;
+
+#define pciu_read(offset)  readl(pciu_base + (offset))
+#define pciu_write(offset, value)  writel((value), pciu_base + (offset))
+
 static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address   = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask   = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,15 @@
 
setup = _pci_controller_unit_setup;
 
+   if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
+   return -EBUSY;
+
+   pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+   if (pciu_base == NULL) {
+   release_mem_region(PCIU_BASE, PCIU_SIZE);
+   return -EBUSY;
+   }
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
 
@@ -129,14 +144,14 @@
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock < pci_clock_max)
-   writel(EQUAL_VTCLOCK, PCICLKSELREG);
+   pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) < pci_clock_max)
-   writel(HALF_VTCLOCK, PCICLKSELREG);
+   pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 &&
 (vtclock / 3) < pci_clock_max)
-   writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+   pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) < pci_clock_max)
-   writel(QUARTER_VTCLOCK, PCICLKSELREG);
+   pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR "PCI Clock is over 33MHz.\n");
return -EINVAL;
@@ -151,11 +166,11 @@
  MASTER_MSK(master->address_mask) |
  WINEN |
  PCIA(master->pci_base_address);
-   writel(val, PCIMMAW1REG);
+   pciu_write(PCIMMAW1REG, val);
} else {
-   val = readl(PCIMMAW1REG);
+   val = pciu_read(PCIMMAW1REG);
val &= ~WINEN;
-   writel(val, PCIMMAW1REG);
+   pciu_write(PCIMMAW1REG, val);
}
 
if (setup->master_memory2 != NULL) {
@@ -164,11 +179,11 @@
  MASTER_MSK(master->address_mask) |
  WINEN |
  

Re: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Ashok Raj]

On Mon, Apr 04, 2005 at 03:46:20PM -0700, Nathan Lynch wrote:
> 
>Hi Nigel!
> 
>On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote:
>>
>> On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
>>  >  > Yes, exactly. Someone who understand do_exit please help clean
> 
>No, that wouldn't work.  I am saying that there's little to gain by
>adding all this complexity for destroying the idle tasks when it's
>fairly simple to create num_possible_cpus() - 1 idle tasks* to
>accommodate any additional cpus which may come along.  This is what
>ppc64 does now, and it should be feasible on any architecture which
>supports cpu hotplug.
> 
>Nathan
> 
>* num_possible_cpus() - 1 because the idle task for the boot cpu is
>  created in sched_init.
> 

In ia64 we create idle threads on demand if one is not available for the same
logical cpu number, and re-used when the same logical cpu number is re-used. 

just a minor improvement, i also thought about idle exit, but wasnt worth
anything in return.

Cheers,
ashok
-
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: [openib-general] [PATCH][RFC][3/4] IB: userspace verbs mthca changes

[Roland Dreier]

Tom> Now, you are really gonna hate me for asking you to put this
Tom> in as you probably did not want to include this in the patch
Tom> to lkml.

Tom> So, maybe Grant was right ;-)

Oh well, I didn't read the patches over carefully enough.  Fortunately
it was just my "for review" version.

 - R.
-
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 2/3] hd eliminate bad section references

[Rusty Russell]

On Tue, 2005-04-05 at 01:05 +0200, maximilian attems wrote:
> On Mon, 04 Apr 2005, Randy.Dunlap wrote:
> > Rusty, can you explain when __setup functions are called relative
> > to in-kernel init functions?  or put another way, can a __setup
> > function safely call in __init function?

Yes.  init sections are discarded just before "init" is exec'ed, ie. at
the last moment in the boot process.  __setup() functions are called at
the same time as module_param() parsing, which is all done before the
various initcall/module_init calls.

Cheers,
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Jaco Kroon]

Dmitry Torokhov wrote:
> Ok, try booting with "usb-handoff i8042.nomux". If that cures

yes, it cures both problems (death on reboot and ALPS), in fact.  But I
must have *both* params.  nomux without usb-handoff causes all input
devices to fail.  Thanks goodness for ssh.  Anyway - I'm now running a
clean 2.6.11.6 kernel that *works*.

> death-on-reboot problem then Vojtech already has a patch in
> 2.6.12-rc1:
> 
> http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

Yes, this should fix the death-on-reboot (why oh why can't the BIOS just
"do the right thing"), it still won't get me alps though.  For that I
need the nomux option - ie, a total different codepath than what that
patch attends to.  And it probably won't fix the keyboard problem.  This
sucks (don't get me wrong - I appreciate that my hardware is now
functioning properly - only things afaik that doesn't work now is the SD
card reader and suspend/hibernate and with ati-drivers there is not a
chance in hell that that'll ever work, neither of which is of critical
importance for me).

> Yes, with 4 ports your external mouse is independent from the touhpad.
> When you have only 1 port you can't use touchpad's extended mode
> together with an external mouse.

No external PS/2 port :).

>>With my patch I do get the ALPS support though - something which I
>>didn't get with usb-handoff, nor with acpi=off, nor with simply hacking
>>out the AUX_LOOP and AUX_TEST tests and just assuming the hardware is
>>there (I saw ALPS yesterday for the first time in my life for that matter).
> 
> Hmm, I'd like to debug that once we resolve reboot problems.

Anything else that you would like me to try?

>>OT:  I think I prefer synaptics multi-finger tapping to the tapping in
>>specific locations to get right and middle clicking, but that is another
>>story that probably has nothing to do with the kernel, and quite likely
>>something that is configurable in the synaptics xorg driver.
> 
> You should be able to control that in xorg.conf.

My thoughts exactly.  The same goes for gpm.

Thanks a lot for your time, patience and knowledge.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote:
> IOW, when sysdev.h is updated to prototype the function pointer with
> pm_message_t, this'll also be solved.
> 
> Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
> the minimal patch.

OK...
-
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: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote:
> On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> 
> wrote:
> >
> >   o missing include in lanai.c
> 
> After this patch I have ended up with linux/dma-mapping.h included twice
> in this file ...

Argh.  Looks like the same fix went in twice (now and in -rc1-bk3) and
these patches added include in places just far enough from each other to
create no rejects when porting patchset to -bk3 and further.
-
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: Linux 2.6.12-rc2

[Russell King]

On Tue, Apr 05, 2005 at 12:24:19AM +0100, Al Viro wrote:
> On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> > This is also the point where I ask people to calm down, and not send me
> > anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> > keep it quiet out there,
> 
>   * missing include in arm/kernel/time.c - see #ifdef CONFIG_PM
> further down in the file.

See previous threads.

The include should be in linux/sysdev.h.  The reason this has come up is
because the ARM changes got merged before the generic changes, so there's
currently a minor disparity with the calling convention for system
device suspend methods.

IOW, when sysdev.h is updated to prototype the function pointer with
pm_message_t, this'll also be solved.

Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
the minimal patch.

-- 
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: iomapping a big endian area

[Benjamin Herrenschmidt]

On Mon, 2005-04-04 at 08:59 -0500, James Bottomley wrote:
> On Mon, 2005-04-04 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> > I disagree. The driver will never "know" ...
> 
> ? the driver has to know.  Look at the 53c700 to see exactly how awful
> it is.  This beast has byte and word registers.  When used BE, all the
> byte registers alter their position (to both inb and readb).

What I mean is that the driver doesn't have "know" whatever CPU/bus
combo endianness will require it to use "native" or "swapped" access.
What the driver knows is wether the device it tries to access need BE or
LE accessors.

> > I don't think it's sane. You know that your device is BE or LE and use
> > the appropriate interface. "native" doesn't make sense to me in this
> > context.
> 
> Well ... it's like this. Native means "pass through without swapping"
> and has an easy implementation on both BE and LE platforms.  Logically
> io{read,write}{16,32}be would have to do byte swaps on LE platforms.
> Being lazy, I'm opposed to doing the work if there's no actual use for
> it, so can you provide an example of a BE bus (or device) used on a LE
> platform that would actually benefit from this abstraction?

I don't think drivers will benefit from "native" vs. "swapping". Taht
means that pretty much all drivers that care will end up with #ifdef
crap to pick up the right one based on the CPU endian, and some wil get
it wrong of course. No, I _do_ thing that this should be hidden in the
implementation, and we should provide "le" and "be" accessors (le beeing
the current ones, be new ones). Which one swap or not is in the
implementation of those accessors for the architecture, but the driver
shouldn't have to care.

Ben.


-
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/

scheduler/SCHED_FIFO behaviour

[Arun Srinivas]

I am scheduling 2 SCHED_FIFO processes and set them affinity( process A runs 
on processor 1 and process B runs on processor 2), on a HT processor.(I did 
this cause I wanted to run them together).Now, in schedule() I measure the 
timedifference between when they are scheduled. I found that when I 
introduce these 2 processes as SCHED_FIFO they are

1)scheduled only once and run till completion ( they running time is around 
2 mins.)
2)entire system appears frozenno mouse/key presses detected until the 
processes exit.

From what I observed does it mean that even the OS / interrupt handler does 
not occur during the entire period of time these real time processes run?? 
(as I said the processes run in minutes).
How can I verify that?

Thanks
Arun
From: Steven Rostedt <[EMAIL PROTECTED]>
To: Arun Srinivas <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], LKML 
Subject: Re: sched /HT processor
Date: Sun, 03 Apr 2005 19:08:06 -0400
On Mon, 2005-04-04 at 04:22 +0530, Arun Srinivas wrote:
> Thanks. yes, a reschedule may not take place after a ms, if the 
currently
> running task cannot be preempted by another task.
>
> (1) But, can a reschedule happen within a millisec (or once a process is
> scheduled can schedule() be called before the next millisec.) ?
>

Yes.  For example: a high priority task may be waiting for some IO to
come in. Right after the normal timer interrupt scheduled another task,
the IO may come in and wake the high priority process up. This process
will preempt the other task right away. (ie. less than 1 ms).
> 2) Also in case argument (1) is not true, and I want rescheduling to be 
done
> (i.e., schedule() called) in less than 1 ms , can I directly change the 
HZ
> value in  and recompile my kernel so that my timer
> interrupt will occur frequently?
>

Well, 1) is true, but you can also increase HZ over 1000 if you like,
but that will usually cause more overhead, since, although a schedule
may not take place every HZ, a timer interrupt will.
-- Steve

_
Want to meet David Beckham? http://www.msn.co.in/gillette/ Fly to Madrid 
with Gillette!

-
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: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

> 
> 
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
> 
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,
> 
>   Linus
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue

These first two fixes were from Panagiotis Issaris
<[EMAIL PROTECTED]>; I merely forwarded them to gregkh & co.


>   o fix pci_disable_device in 8139too

-
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/3] pnpbios eliminate bad section references

[Adam Belay]

On Mon, Apr 04, 2005 at 12:56:32PM -0700, Randy.Dunlap wrote:
> maximilian attems wrote:
> >one of the last buildcheck errors on i386,
> >thanks Randy again for double checking.
> >
> >Fix pnpbios section references:
> >make dmi_system_id pnpbios_dmi_table __initdata
> >
> >Error: ./drivers/pnp/pnpbios/core.o .data refers to 0100 R_386_32
> >.init.text
> >Error: ./drivers/pnp/pnpbios/core.o .data refers to 012c R_386_32
> >.init.text
> >
> >Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
> >
> >
> >--- linux-2.6.12-rc1-bk5/drivers/pnp/pnpbios/core.c.orig 2005-04-04 
> >19:11:37.814477672 +0200
> >+++ linux-2.6.12-rc1-bk5/drivers/pnp/pnpbios/core.c  2005-04-04 
> >19:25:50.074402365 +0200
> >@@ -512,7 +512,7 @@
> > return 0;
> > }
> > 
> >-static struct dmi_system_id pnpbios_dmi_table[] = {
> >+static struct dmi_system_id pnpbios_dmi_table[] __initdata = {
> > {   /* PnPBIOS GPF on boot */
> > .callback = exploding_pnp_bios,
> > .ident = "Higraded P14H",
> 
> Looks OK to me, but I'd prefer to leave it up to Adam.

Thank you for forwarding this to me.  It looks good.

Cheers,
Adam
-
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: iomapping a big endian area

[Benjamin Herrenschmidt]

> > Well ... it's like this. Native means "pass through without swapping"
> > and has an easy implementation on both BE and LE platforms.  Logically
> > io{read,write}{16,32}be would have to do byte swaps on LE platforms.
> > Being lazy, I'm opposed to doing the work if there's no actual use for
> > it, so can you provide an example of a BE bus (or device) used on a LE
> > platform that would actually benefit from this abstraction?
> 
> I would probably spell "native" as "noswap".
> "native" just doesn't convey enough specific meaning...

But that implies that the driver has to know that the bus and the device
and the CPU are on the same byte endian etc that is rather specific,
and if they all know, then they can also just use the correct "be" or
"le" ... I really see no point in "native" abstraction.

Ben.


-
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: Linux 2.6.12-rc2

[Stephen Rothwell]

On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> 
wrote:
>
>   o missing include in lanai.c

After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpaAmtwPxCtH.pgp
Description: PGP signature

Re: Adding a field to ext2_dir_entry_2

[Andreas Dilger]

On Apr 04, 2005  18:54 -0400, Vineet Joglekar wrote:
> I working with linux kernel 2.4.28. I want to add 1 more field to
> ext2_dir_entry_2 - the new version of directory entry for ext2fs.
> 
> I did add the __u32 field to the struct ext2_dir_entry_2 defined in
> ext2_fs.h I also modified the EXT2_DIR_REC_LEN macro to:
> 
> (((name_len) + 12 + EXT2_DIR_ROUND) & ~EXT2_DIR_ROUND)
> 
> (+12 instead of +8) to incorporate newly added 4 bytes field.
> 
> I made the similar changes to the mke2fs utility also.

This means your filesystem will not be mountable by any other version of
Linux.  What is more important is why you want to do this - there are
other mechanisms that may be more appropriate depending on what you are
doing.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.



pgpgk0QSCZcUK.pgp
Description: PGP signature

Re: Oops in i810_audio (reply to herbert)

[Herbert Xu]

On Mon, Apr 04, 2005 at 10:07:30PM +0200, SuD (Alex) wrote:
> 
> /* Check for an AC97 1.0 soft modem (ID1) */
> codec->codec_read(codec, AC97_RESET) returned 0xd3a 
> ...
> 
> /* Check for an AC97 2.x soft modem */ ...
> codec->codec_read(codec, AC97_EXTENDED_MODEM_ID) returned 0x1

Interesting.  Can you please try the ALSA drivers and see whether
it works correctly? The modem detection logic lives in
sound/pci/ac97/ac97_codec.c.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/4] create mm/Kconfig for arch-independent memory options

[Mike Kravetz]

On Mon, Apr 04, 2005 at 10:50:09AM -0700, Dave Hansen wrote:
diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
--- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0 -0700
+++ memhotplug-dave/mm/Kconfig  2005-04-04 10:15:23.0 -0700
@@ -0,0 +1,25 @@
> +choice
> + prompt "Memory model"
> + default FLATMEM
> + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
> +

Yet the changes to the defconfig files that had DISCONTIGMEM as
the default look like.

-CONFIG_DISCONTIGMEM=y
+CONFIG_ARCH_DISCONTIGMEM_ENABLE=y

Do you need to set ARCH_DISCONTIGMEM_DEFAULT instead of just
CONFIG_ARCH_DISCONTIGMEM_ENABLE to have DISCONTIGMEM be the
default? or am I missing something?  I don't see
ARCH_DISCONTIGMEM_DEFAULT turned on by default in any of these
patches.

-- 
Mike
-
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/4] create mm/Kconfig for arch-independent memory options

[Dave Hansen]

On Mon, 2005-04-04 at 16:22 -0700, Mike Kravetz wrote:
> Do you need to set ARCH_DISCONTIGMEM_DEFAULT instead of just
> CONFIG_ARCH_DISCONTIGMEM_ENABLE to have DISCONTIGMEM be the
> default? or am I missing something?  I don't see
> ARCH_DISCONTIGMEM_DEFAULT turned on by default in any of these
> patches.

It's a wee bit confusing, but I think it all works out.

Doing ARCH_DISCONTIGMEM_ENABLE=y turns off the FLATMEM option in the
mm/Kconfig prompt because FLATMEM depends on !ARCH_DISCONTIGMEM_ENABLE.
So, if you enable it, it will end up being the default because there's
no other choice.

For configs that *need* both options, you can re-enable FLATMEM with
ARCH_FLATMEM_ENABLE

-- Dave

-
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: Linux 2.6.12-rc2

[Al Viro]

On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,

* missing include in arm/kernel/time.c - see #ifdef CONFIG_PM
further down in the file.

diff -urN RC12-rc2-base/arch/arm/kernel/time.c current/arch/arm/kernel/time.c
--- RC12-rc2-base/arch/arm/kernel/time.c2005-04-04 18:20:42.0 
-0400
+++ current/arch/arm/kernel/time.c  2005-04-04 19:17:12.446004816 -0400
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-
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 2.4] PCI 2/2 update pci.ids (0/2)

[Grant Coady]

On Tue, 05 Apr 2005 08:24:20 +1000, Grant Coady <[EMAIL PROTECTED]> wrote:

>Hi Marcelo,
>
>This patch updates pci.ids to latest snapshot, requires patch 1/2 
>to compile.  gzip'd due to size.  Compile and run tested.
>
>Sign-off-by: Grant Coady <[EMAIL PROTECTED]>

Sorry about the borked attachment, grab it from:
  http://scatter.mine.nu/misc/patch-2.4.30-pci.ids.bz2

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

Cheers,
Grant.

-
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: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

> 
> 
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
> 
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,
> 
>   Linus
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue
>   o fix pci_disable_device in 8139too
> 

The first two fixes were from Panagiotis Issaris
<[EMAIL PROTECTED]>; I merely forwarded them on.


-
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: UPDATE: out of vmalloc space - but vmalloc parameter does not allow boot

[Ranko Zivojnovic]

Ok, I think I've figured it out so I will try and answer my own
questions (the best part is at the end)...

On Mon, 2005-04-04 at 17:36 +0300, Ranko Zivojnovic wrote:
> (please do CC replies as I am still not on the list)
> 
> As I am kind of pressured to resolve this issue, I've set up a test
> environment using VMWare in order to reproduce the problem and
> (un)fortunately the attempt was successful.
> 
> I have noticed a few points that relate to the size of the physical RAM
> and the behavior vmalloc. As I am not sure if this is by design or a
> bug, so please someone enlighten me:
> 
> The strange thing I have seen is that with the increase of the physical
> RAM, the VmallocTotal in the /proc/meminfo gets smaller! Is this how it
> is supposed to be?
> 

As the size of memory grows, more gets allocated to the low memory, less
to the vmalloc memory - within first 1GB of RAM.

> Now the question: Is this behavior normal? 
I guess it is (nobody said the oposite).

> Should it not be in reverse -
> more RAM equals more space for vmalloc?
> 

It really depends on the setup and the workload - some reasonable
defaults (i.e. 128M) have been defined - you can change them using
vmalloc parameter - but with the _extreme_ care as it gets really tricky
if your RAM is 1G and above - read on...

> With regards to the 'vmalloc' kernel parameter, I was able to boot
> normally using kernel parameter vmalloc=192m with RAM sizes 256, 512,
> 768 but _not_ with 1024M of RAM and above. 
> 
> With 1024M of RAM (and apparently everything above), it is unable to
> boot if vmalloc parameter is specified to a value lager than default
> 128m. It panics with the following:
> 
> EXT2-fs: unable to read superblock
> isofs_fill_super: bread failed, dev=md0, iso_blknum=16, block=32
> XFS: SB read failed
> VFS: Cannot open root device "md0" or unknown-block(9,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(9,0)
> 
And not just - I have just seen the actual culprit message (way up
front):
initrd extends beyond end of memory (0x37fef33a > 0x3400)
disabling initrd

> Question: Is this inability to boot related to the fact that the system
> is unable to reserve enough space for vmalloc?
> 

The resolution (or rather workaround) to the above is to _trick_ the
GRUB into loading the initrd image into the area below what is _going_
to be the calculated "end of memory" using the "uppermem" command.

Now:
1. I hope this is the right way around the problem.
2. I hope this is going to help someone.

Best regards,

Ranko


-
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: scheduler/SCHED_FIFO behaviour

[Steven Rostedt]

On Tue, 2005-04-05 at 04:36 +0530, Arun Srinivas wrote:
> I am scheduling 2 SCHED_FIFO processes and set them affinity( process A runs 
> on processor 1 and process B runs on processor 2), on a HT processor.(I did 
> this cause I wanted to run them together).Now, in schedule() I measure the 
> timedifference between when they are scheduled. I found that when I 
> introduce these 2 processes as SCHED_FIFO they are
> 
> 1)scheduled only once and run till completion ( they running time is around 
> 2 mins.)

If they are the highest priority task, and running as FIFO this is the
proper behavior.

> 2)entire system appears frozenno mouse/key presses detected until the 
> processes exit.
> 

If X is not at a higher priority than the test you are running, it will
never get a chance to run.

> >From what I observed does it mean that even the OS / interrupt handler does 
> not occur during the entire period of time these real time processes run?? 
> (as I said the processes run in minutes).

The interrupts do get processed. Now the bottom halves and tasklets may
be starved if they are set at a lower priority than your test (ie. the
ksoftirqd thread). But most likely they are processed too.

> How can I verify that?
> 

#!/bin/sh
cat /proc/interrupts
run_test
cat /proc/interrupts

If the run_test takes 2 minutes, you should see a large difference in
the two outputs.

-- Steve

> Thanks
> Arun


-
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 2/3] hd eliminate bad section references

[maximilian attems]

On Mon, 04 Apr 2005, Randy.Dunlap wrote:

> >-static int parse_hd_setup (char *line) {
> >+static int __init parse_hd_setup (char *line) {
.. 
> This one is fairly interesting and needs some resolution by someone
> who knows

thanks a lot for your quick and profund feedback.
 
> On the surface, the patch is correct.
> 
> Rusty, can you explain when __setup functions are called relative
> to in-kernel init functions?  or put another way, can a __setup
> function safely call in __init function?
> 
> Here's the function in question:
> 
> static int parse_hd_setup (char *line) {
>   int ints[6];
> 
>   (void) get_options(line, ARRAY_SIZE(ints), ints);
>   hd_setup(NULL, ints);
> 
>   return 1;
> }
> __setup("hd=", parse_hd_setup);
> 
> 
> 
> Should we make parse_hd_setup() __init,
> or make hd_setup() non-__init, or something else?
> 
> {time passes, he looks]
> 
> OK, I looked at include/linux/init.h.  From what I can see
> there, __setup() causes an .init.setup section to be emitted,
> so marking __setup() function as __init would make sense.
> I think that this patch is good.

i saw that ide_setup() is __init as a bunch of lots others.
yes init.h confirms that. :)

--
maks
kernel janitor  http://janitor.kernelnewbies.org/

-
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] network configs: disconnect network options from drivers

[Randy.Dunlap]

Sam Ravnborg wrote:

- Move submenu to the top
- Rename top menu to "Networking" and located it just before
"File systems"
I still prefer Networking to come before Device Drivers FWIW.
Just makes some kind of hierarchical sense to me.
Moved up as suggested.

I propose that the new file net/atm/Kconfig be sourced somewhere.
Thanks, I have missed that one - added just before wanrouter.
 

I'll look at it more to see if I have any other comments.
OK. I will await and post an updated patch if you do not beat me.
Sam,
Here are a few more suggestions for you to consider.
- in Networking support, move Network testing and Netpoll
support to the end of the menu (basically put the devel.
tools toward the bottom of the menu)
- I would rather not "hide" Amateur Radio, IrDA, and
Bluetooth in the Networking protocols area, but have them
near 802.1x and ATM in the top-level Networking support
menu.  How does that sound to you?
Thanks.
--
~Randy
-
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Esben Nielsen]

On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:

> On Mon, 4 Apr 2005, Steven Rostedt wrote:
> 
> > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> > 
> > > > Currently my fix is in yield to lower the priority of the task calling 
> > > > yield and raise it after the schedule.  This is NOT a proper fix. It's 
> > > > just a hack so I can get by it and test other parts.
> > > 
> > > yeah, yield() is a quite RT-incompatible concept, which could livelock 
> > > an upstream kernel just as much - if the task in question is SCHED_FIFO.  
> > > Almost all yield() uses should be eliminated from the upstream kernel, 
> > > step by step.
> > 
> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix, and I'm sure you have other things to do too.
> 
> I'm sure a lot of the yield() users could be converted to 
> schedule_timeout(), some of the users i saw were for low memory conditions 
> where we want other tasks to make progress and complete so that we a bit 
> more free memory.
> 

Easy, but damn ugly. Completions are the right answer. The memory system
needs a queue system where tasks can sleep (with a timeout) until the
right amount of memory is available instead of half busy-looping.

Esben


-
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Esben Nielsen]

On Mon, 4 Apr 2005, Steven Rostedt wrote:

> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> 
> > > Currently my fix is in yield to lower the priority of the task calling 
> > > yield and raise it after the schedule.  This is NOT a proper fix. It's 
> > > just a hack so I can get by it and test other parts.
> > 
> > yeah, yield() is a quite RT-incompatible concept, which could livelock 
> > an upstream kernel just as much - if the task in question is SCHED_FIFO.  
> > Almost all yield() uses should be eliminated from the upstream kernel, 
> > step by step.
> 
> Now the question is, who will fix it? Preferably the maintainers, but I
> don't know how much of a priority this is to them. I don't have the time
> now to look at this and understand enough about the code to be able to
> make a proper fix, and I'm sure you have other things to do too.

How about adding a
 if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
 }
?

to find all calls to yields from rt-tasks. That will force the user (aka
the real-time developer) to either stop calling the subsystems still using
yield from his RT-tasks, or fix those subsystems.

Esben

> 
> -- Steve
> 


-
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] create a kstrdup library function

[Andres Salomon]

On Mon, 04 Apr 2005 20:44:17 +0100, Paulo Marques wrote:

> 
> Hi,
> 
> This patch creates a new kstrdup library function and changes the 
> "local" implementations in several places to use this function.
> 
> This is just a cleanup to allow reusing the strdup code, and to prevent 
> bugs in future duplications of strdup.
> 

Just a minor nit; I would use a size_t in kstrdup(),
instead of an int, for the len.  All other functions dealing w/ the len
(strlen, kmalloc, memcpy) expect a size_t.




-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Dmitry Torokhov]

On Apr 4, 2005 4:51 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov wrote:
> > On Apr 4, 2005 3:35 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> >
> >>As for loading the modules i8042, atkbd and psmouse (in that order):
> >>black void of death.
> >>
> > Hmm.. remind me, if you boot with usb-handoff does it switch the i8042
> > into active multiplexing mode (you get 4 AUX serio ports)?
> >
> Checking my logs it actually looks like usb-handoff did get 4 ports.
> With my patch, however, I only get:
> 
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 AUX port at 0x60,0x64 irq 1
> 

Ok, try booting with "usb-handoff i8042.nomux". If that cures
death-on-reboot problem then Vojtech already has a patch in
2.6.12-rc1:

http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]

> >From the code I understand that this means that i8042_nomux != 0 or
> i8042_check_mux() return != 0.  So I assume that with the patch that
> check_mux returns non-zero (and reversed logic means that 0 implies the
> check succeeds, ie, it _fails_ with my patch installed).  I don't know
> which is the prefered mode of operation though (I guess MUX with 4 AUX
> ports?).
> 

Yes, with 4 ports your external mouse is independent from the touhpad.
When you have only 1 port you can't use touchpad's extended mode
together with an external mouse.

> With my patch I do get the ALPS support though - something which I
> didn't get with usb-handoff, nor with acpi=off, nor with simply hacking
> out the AUX_LOOP and AUX_TEST tests and just assuming the hardware is
> there (I saw ALPS yesterday for the first time in my life for that matter).
> 

Hmm, I'd like to debug that once we resolve reboot problems.

> OT:  I think I prefer synaptics multi-finger tapping to the tapping in
> specific locations to get right and middle clicking, but that is another
> story that probably has nothing to do with the kernel, and quite likely
> something that is configurable in the synaptics xorg driver.
> 

You should be able to control that in xorg.conf.

-- 
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: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

[...]
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> 
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue

Those two were from Panagiotis Issaris <[EMAIL PROTECTED]>; I just
forwarded them on.


>   o fix pci_disable_device in 8139too


-
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Steven Rostedt]

On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote:

> I'm sure a lot of the yield() users could be converted to 
> schedule_timeout(), some of the users i saw were for low memory conditions 
> where we want other tasks to make progress and complete so that we a bit 
> more free memory.
> 

I've stated earlier that I was locked up in fs/inode.c with the
__wait_on_freeing_inode. Can this be switched to a schedule_timeout?

Of course schedule_timeout is not too good with RT as well. Although you
can prevent a live_deadlock, but we bring up the problem of priority
inversion again. The process needing to run can still be starved by
another higher priority process that is lower in priority as the one
doing the waiting.

The schedule_timeout should stop the livelock. But what is the effect of
switching to it?

-- Steve


-
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: security issue: hard disk lock

[Chris Friesen]

Horst von Brand wrote:
Doing it in initrd should be plenty of time, no need to involve the kernel.
Not everyone uses an initrd.
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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00

[Zwane Mwaikambo]

On Mon, 4 Apr 2005, Steven Rostedt wrote:

> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> 
> > > Currently my fix is in yield to lower the priority of the task calling 
> > > yield and raise it after the schedule.  This is NOT a proper fix. It's 
> > > just a hack so I can get by it and test other parts.
> > 
> > yeah, yield() is a quite RT-incompatible concept, which could livelock 
> > an upstream kernel just as much - if the task in question is SCHED_FIFO.  
> > Almost all yield() uses should be eliminated from the upstream kernel, 
> > step by step.
> 
> Now the question is, who will fix it? Preferably the maintainers, but I
> don't know how much of a priority this is to them. I don't have the time
> now to look at this and understand enough about the code to be able to
> make a proper fix, and I'm sure you have other things to do too.

I'm sure a lot of the yield() users could be converted to 
schedule_timeout(), some of the users i saw were for low memory conditions 
where we want other tasks to make progress and complete so that we a bit 
more free memory.

-
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/

Adding a field to ext2_dir_entry_2

[Vineet Joglekar]

Hi All,



I working with linux kernel 2.4.28. I want to add 1 more field to 
ext2_dir_entry_2 - the new version of directory entry for ext2fs.



I did add the __u32 field to the struct ext2_dir_entry_2 defined in  ext2_fs.h 
I also modified the EXT2_DIR_REC_LEN macro to:



(((name_len) + 12 + EXT2_DIR_ROUND) & ~EXT2_DIR_ROUND)



(+12 instead of +8) to incorporate newly added 4 bytes field.



I made the similar changes to the mke2fs utility also.



When I try to copy a file on that file system, I am getting the following error:



"ext2-fs error (device fd(2,0)): ext2_check_page: bad entry in directory #2: 
unaligned directory entry - offset=0, inode=2, rec_len=46, name_len=0"



Can someone please tell me where am I going wrong or what other changes do I 
need to do to add the field I want?



Thanks and regards,



Vineet Joglekar

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-
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: [Fwd: Re: [Bug] invalid mac address after rebooting (kernel 2.6.11.5)]

[Daniel Ritz]

On Sunday 03 April 2005 16:02, Daniel Drake wrote:
> Peter Baumann wrote:
> > On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
> > 
> >>Peter Baumann <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>>I'm hitting an annoying bug in kernel 2.6.11.5
> >>>
> >>>Every time I _reboot_ (warmstart) my pc my two network cards won't get
> >>>recognized any longer.
> >>>
> >>>Following error message appears on my screen:
> >>>
> >>>PCI: Enabling device :00:0b.0 ( -> 0003)
> >>>ACPI: PCI interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> >>>3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> >>>:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
> >>>PCI: Setting latency timer of device :00:0b.0 to 64
> >>>*** EEPROM MAC address is invalid.
> >>>3c59x: vortex_probe1 fails.  Returns -22
> >>>3c59x: probe of :00:0b.0 failed with error -22
> >>>PCI: Enabling device :00:0d.0 ( -> 0003)
> >>>ACPI: PCI interrupt :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19
> >>>:00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19
> >>>PCI: Setting latency timer of device :00:0d.0 to 64
> >>>*** EEPROM MAC address is invalid.
> >>>3c59x: vortex_probe1 fails.  Returns -22
> >>>3c59x: probe of :00:0d.0 failed with error -22
> >>>
> >>>This doesn't happen with older kernels (especially with 2.6.10) and so
> >>>I've done a binary search and narrowed it down to 2.6.11-rc5 where it
> >>>first hits me.
> >>>
> >>>My config, lspci output and the dmesg output of the working and non-working
> >>>version can be found at [1]
> >>>
> >>>Feel free to ask if any information is missing or if I am supposed to try
> >>>a patch.
> >>
> >>Thanks for doing the bsearch - it helps.
> >>
> >>There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.
> >>
> >>The only PCI change I see is
> >>
> >>--- drivers/pci/pci.c   22 Jan 2005 03:20:37 -  1.71
> >>+++ drivers/pci/pci.c   24 Feb 2005 18:02:37 -  1.72
> >>@@ -268,7 +268,7 @@
> >>return -EIO; 
> >> 
> >>pci_read_config_word(dev,pm + PCI_PM_PMC,);
> >>-   if ((pmc & PCI_PM_CAP_VER_MASK) != 2) {
> >>+   if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
> >>printk(KERN_DEBUG
> >>   "PCI: %s has unsupported PM cap regs version (%u)\n",
> >>   dev->slot_name, pmc & PCI_PM_CAP_VER_MASK);
> >>
> >>and you're not getting that message (are you?)
> >>
> > 
> > 
> > Reverting the above patch solved it.

nice. could i get dmesg output, lspci, lspci -vvvn output with the attached
patch applied?

thanks, rgds
-daniel

--- 1.81/drivers/pci/pci.c  2005-03-03 08:17:57 +01:00
+++ edited/drivers/pci/pci.c2005-04-05 00:37:13 +02:00
@@ -268,7 +268,7 @@
return -EIO; 
 
pci_read_config_word(dev,pm + PCI_PM_PMC,);
-   if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
+   if ((pmc & PCI_PM_CAP_VER_MASK) > 3) {
printk(KERN_DEBUG
   "PCI: %s has unsupported PM cap regs version (%u)\n",
   pci_name(dev), pmc & PCI_PM_CAP_VER_MASK);
@@ -287,15 +287,19 @@
 * This doesn't affect PME_Status, disables PME_En, and
 * sets PowerState to 0.
 */
-   if (dev->current_state >= PCI_D3hot)
+   printk("PCI: %s pmc: %04x, current_state: %08x, pmcsr: ", 
pci_name(dev), pmc, dev->current_state);
+   if (dev->current_state >= PCI_D3hot) {
pmcsr = 0;
-   else {
+   printk("0");
+   } else {
pci_read_config_word(dev, pm + PCI_PM_CTRL, );
+   printk("%04x", pmcsr);
pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
pmcsr |= state;
}
 
/* enter specified state */
+   printk(", new: %04x\n", pmcsr);
pci_write_config_word(dev, pm + PCI_PM_CTRL, pmcsr);
 
/* Mandatory power management transition delays */

-
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] meminfo: add Cached underflow check

[Martin Hicks]

On Mon, Apr 04, 2005 at 03:10:49PM -0700, Andrew Morton wrote:
> Martin Hicks <[EMAIL PROTECTED]> wrote:
> >
> > Working on some code lately I've been getting huge values
> > for "Cached".  The cause is that get_page_cache_size() is an
> > approximate value, and for a sufficiently small returned value
> > of get_page_cache_size() the value underflows.
> 
> OK..
> 
> I think I'd prefer to do it this way - it's simpler and the original patch
> had a teeny race wrt changes in total_swapcache_pages.

Fine by me.

mh

-- 
Martin Hicks   ||   Silicon Graphics Inc.   ||   [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][RFC][0/4] InfiniBand userspace verbs implementation

[Roland Dreier]

Here is an initial implementation of InfiniBand userspace verbs.  I
plan to commit this code to the OpenIB repository shortly, and submit
it for inclusion during the 2.6.13 cycle, so I am posting it early for
comments.

This code, in conjunction with the libibverbs and libmthca userspace
libraries available from the subversion trees at

https://openib.org/svn/gen2/branches/roland-uverbs/src/userspace/libibverbs
https://openib.org/svn/gen2/branches/roland-uverbs/src/userspace/libmthca

enables userspace processes to access InfiniBand HCAs directly.

For those not familiar with the InfiniBand architecture, this
so-called "userspace verbs" support allows userspace to post data path
commands directly to the HCA.  Resource allocation and other control
path operations still go through the kernel driver.

Please take a look at this code if you have a chance.  I would
appreciate high-level criticism of the design and implementation as
well as nitpicky complaints about coding style and typos.

In particular, the memory pinning code in in uverbs_mem.c could stand
a looking over.  In addition, a sanity check of the write()-based
scheme for passing commands into the kernel in uverbs_main.c and
uverbs_cmd.c is probably worthwhile.

Thanks,
  Roland


-
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][RFC][3/4] IB: userspace verbs mthca changes

[Roland Dreier]

Add Mellanox HCA-specific userspace verbs support to mthca.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- linux-export.orig/drivers/infiniband/hw/mthca/mthca_cq.c2005-04-04 
14:57:12.228756073 -0700
+++ linux-export/drivers/infiniband/hw/mthca/mthca_cq.c 2005-04-04 
14:58:12.364679525 -0700
@@ -743,6 +743,7 @@
 }
 
 int mthca_init_cq(struct mthca_dev *dev, int nent,
+ struct mthca_ucontext *ctx, u32 pdn,
  struct mthca_cq *cq)
 {
int size = nent * MTHCA_CQ_ENTRY_SIZE;
@@ -754,30 +755,33 @@
 
might_sleep();
 
-   cq->ibcq.cqe = nent - 1;
+   cq->ibcq.cqe  = nent - 1;
+   cq->is_kernel = !ctx;
 
cq->cqn = mthca_alloc(>cq_table.alloc);
if (cq->cqn == -1)
return -ENOMEM;
 
if (mthca_is_memfree(dev)) {
-   cq->arm_sn = 1;
-
err = mthca_table_get(dev, dev->cq_table.table, cq->cqn);
if (err)
goto err_out;
 
-   err = -ENOMEM;
+   if (cq->is_kernel) {
+   cq->arm_sn = 1;
+
+   err = -ENOMEM;
 
-   cq->set_ci_db_index = mthca_alloc_db(dev, 
MTHCA_DB_TYPE_CQ_SET_CI,
-cq->cqn, >set_ci_db);
-   if (cq->set_ci_db_index < 0)
-   goto err_out_icm;
-
-   cq->arm_db_index = mthca_alloc_db(dev, MTHCA_DB_TYPE_CQ_ARM,
- cq->cqn, >arm_db);
-   if (cq->arm_db_index < 0)
-   goto err_out_ci;
+   cq->set_ci_db_index = mthca_alloc_db(dev, 
MTHCA_DB_TYPE_CQ_SET_CI,
+cq->cqn, 
>set_ci_db);
+   if (cq->set_ci_db_index < 0)
+   goto err_out_icm;
+
+   cq->arm_db_index = mthca_alloc_db(dev, 
MTHCA_DB_TYPE_CQ_ARM,
+ cq->cqn, >arm_db);
+   if (cq->arm_db_index < 0)
+   goto err_out_ci;
+   }
}
 
mailbox = kmalloc(sizeof (struct mthca_cq_context) + 
MTHCA_CMD_MAILBOX_EXTRA,
@@ -787,12 +791,14 @@
 
cq_context = MAILBOX_ALIGN(mailbox);
 
-   err = mthca_alloc_cq_buf(dev, size, cq);
-   if (err)
-   goto err_out_mailbox;
+   if (cq->is_kernel) {
+   err = mthca_alloc_cq_buf(dev, size, cq);
+   if (err)
+   goto err_out_mailbox;
 
-   for (i = 0; i < nent; ++i)
-   set_cqe_hw(get_cqe(cq, i));
+   for (i = 0; i < nent; ++i)
+   set_cqe_hw(get_cqe(cq, i));
+   }
 
spin_lock_init(>lock);
atomic_set(>refcount, 1);
@@ -803,11 +809,14 @@
  MTHCA_CQ_STATE_DISARMED |
  MTHCA_CQ_FLAG_TR);
cq_context->start   = cpu_to_be64(0);
-   cq_context->logsize_usrpage = cpu_to_be32((ffs(nent) - 1) << 24 |
- dev->driver_uar.index);
+   cq_context->logsize_usrpage = cpu_to_be32((ffs(nent) - 1) << 24);
+   if (ctx)
+   cq_context->logsize_usrpage |= cpu_to_be32(ctx->uar.index);
+   else
+   cq_context->logsize_usrpage |= 
cpu_to_be32(dev->driver_uar.index);
cq_context->error_eqn   = 
cpu_to_be32(dev->eq_table.eq[MTHCA_EQ_ASYNC].eqn);
cq_context->comp_eqn= 
cpu_to_be32(dev->eq_table.eq[MTHCA_EQ_COMP].eqn);
-   cq_context->pd  = cpu_to_be32(dev->driver_pd.pd_num);
+   cq_context->pd  = cpu_to_be32(pdn);
cq_context->lkey= cpu_to_be32(cq->mr.ibmr.lkey);
cq_context->cqn = cpu_to_be32(cq->cqn);
 
@@ -845,17 +854,19 @@
return 0;
 
 err_out_free_mr:
-   mthca_free_mr(dev, >mr);
-   mthca_free_cq_buf(dev, cq);
+   if (cq->is_kernel) {
+   mthca_free_mr(dev, >mr);
+   mthca_free_cq_buf(dev, cq);
+   }
 
 err_out_mailbox:
kfree(mailbox);
 
-   if (mthca_is_memfree(dev))
+   if (cq->is_kernel && mthca_is_memfree(dev))
mthca_free_db(dev, MTHCA_DB_TYPE_CQ_ARM, cq->arm_db_index);
 
 err_out_ci:
-   if (mthca_is_memfree(dev))
+   if (cq->is_kernel)
mthca_free_db(dev, MTHCA_DB_TYPE_CQ_SET_CI, 
cq->set_ci_db_index);
 
 err_out_icm:
@@ -895,7 +906,8 @@
int j;
 
printk(KERN_ERR "context for CQN %x (cons index %x, next sw 
%d)\n",
-  cq->cqn, cq->cons_index, !!next_cqe_sw(cq));
+  cq->cqn, cq->cons_index,
+  cq->is_kernel ? !!next_cqe_sw(cq) : 0);
for (j = 0; j < 16; ++j)
printk(KERN_ERR "[%2x] %08x\n", j * 4, 

[PATCH][RFC][2/4] IB: userspace verbs main module

[Roland Dreier]

Add device-independent userspace verbs support (ib_uverbs module).

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-export/drivers/infiniband/core/uverbs.h   2005-04-04 
14:55:10.496227053 -0700
@@ -0,0 +1,124 @@
+/*
+ * Copyright (c) 2005 Topspin Communications.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id: uverbs.h 2001 2005-03-16 04:15:41Z roland $
+ */
+
+#ifndef UVERBS_H
+#define UVERBS_H
+
+/* Include device.h and fs.h until cdev.h is self-sufficient */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct ib_uverbs_device {
+   int devnum;
+   struct cdev dev;
+   struct class_device class_dev;
+   struct ib_device   *ib_dev;
+   int num_comp;
+};
+
+struct ib_uverbs_event_file {
+   struct ib_uverbs_file *uverbs_file;
+   spinlock_t lock;
+   intfd;
+   intis_async;
+   wait_queue_head_t  poll_wait;
+   struct list_head   event_list;
+};
+
+struct ib_uverbs_file {
+   struct kref ref;
+   struct ib_uverbs_device*device;
+   struct ib_ucontext *ucontext;
+   struct ib_event_handler event_handler;
+   struct ib_uverbs_event_file async_file; 
+   struct ib_uverbs_event_file comp_file[1]; 
+};
+
+struct ib_uverbs_async_event {
+   struct ib_uverbs_async_event_desc desc;
+   struct list_head  list;
+};
+
+struct ib_uverbs_comp_event {
+   struct ib_uverbs_comp_event_desc desc;
+   struct list_head list;
+};
+
+struct ib_uobject_mr {
+   struct ib_uobject   uobj;
+   struct page*page_list;
+   struct scatterlist *sg_list;
+};
+
+extern struct semaphore ib_uverbs_idr_mutex;
+extern struct idr ib_uverbs_pd_idr;
+extern struct idr ib_uverbs_mr_idr;
+extern struct idr ib_uverbs_mw_idr;
+extern struct idr ib_uverbs_ah_idr;
+extern struct idr ib_uverbs_cq_idr;
+extern struct idr ib_uverbs_qp_idr;
+
+void ib_uverbs_comp_handler(struct ib_cq *cq, void *cq_context);
+void ib_uverbs_cq_event_handler(struct ib_event *event, void *context_ptr);
+void ib_uverbs_qp_event_handler(struct ib_event *event, void *context_ptr);
+
+int ib_umem_get(struct ib_device *dev, struct ib_umem *mem,
+   void *addr, size_t size);
+void ib_umem_release(struct ib_device *dev, struct ib_umem *umem);
+
+#define IB_UVERBS_DECLARE_CMD(name)\
+   ssize_t ib_uverbs_##name(struct ib_uverbs_file *file,   \
+const char __user *buf, int in_len,\
+int out_len)
+
+IB_UVERBS_DECLARE_CMD(query_params);
+IB_UVERBS_DECLARE_CMD(get_context);
+IB_UVERBS_DECLARE_CMD(query_port);
+IB_UVERBS_DECLARE_CMD(alloc_pd);
+IB_UVERBS_DECLARE_CMD(dealloc_pd);
+IB_UVERBS_DECLARE_CMD(reg_mr);
+IB_UVERBS_DECLARE_CMD(dereg_mr);
+IB_UVERBS_DECLARE_CMD(create_cq);
+IB_UVERBS_DECLARE_CMD(destroy_cq);
+IB_UVERBS_DECLARE_CMD(create_qp);
+IB_UVERBS_DECLARE_CMD(modify_qp);
+IB_UVERBS_DECLARE_CMD(destroy_qp);
+
+#endif /* UVERBS_H */
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-export/drivers/infiniband/core/uverbs_cmd.c   2005-04-04 
14:53:12.136965074 -0700
@@ -0,0 +1,790 @@
+/*
+ * Copyright (c) 2005 Topspin Communications.  All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) 

[PATCH][RFC][1/4] IB: core changes for userspace verbs

[Roland Dreier]

Add new structs and struct members required by userspace verbs to IB core.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- linux-export.orig/drivers/infiniband/core/verbs.c   2005-01-11 
09:35:27.046388000 -0800
+++ linux-export/drivers/infiniband/core/verbs.c2005-04-04 
14:50:59.579791210 -0700
@@ -47,10 +47,11 @@
 {
struct ib_pd *pd;
 
-   pd = device->alloc_pd(device);
+   pd = device->alloc_pd(device, NULL, NULL, 0);
 
if (!IS_ERR(pd)) {
-   pd->device = device;
+   pd->device  = device;
+   pd->uobject = NULL;
atomic_set(>usecnt, 0);
}
 
@@ -76,8 +77,9 @@
ah = pd->device->create_ah(pd, ah_attr);
 
if (!IS_ERR(ah)) {
-   ah->device = pd->device;
-   ah->pd = pd;
+   ah->device  = pd->device;
+   ah->pd  = pd;
+   ah->uobject = NULL;
atomic_inc(>usecnt);
}
 
@@ -122,7 +124,7 @@
 {
struct ib_qp *qp;
 
-   qp = pd->device->create_qp(pd, qp_init_attr);
+   qp = pd->device->create_qp(pd, qp_init_attr, NULL, 0);
 
if (!IS_ERR(qp)) {
qp->device= pd->device;
@@ -130,6 +132,7 @@
qp->send_cq   = qp_init_attr->send_cq;
qp->recv_cq   = qp_init_attr->recv_cq;
qp->srq   = qp_init_attr->srq;
+   qp->uobject   = NULL;
qp->event_handler = qp_init_attr->event_handler;
qp->qp_context= qp_init_attr->qp_context;
qp->qp_type   = qp_init_attr->qp_type;
@@ -197,10 +200,11 @@
 {
struct ib_cq *cq;
 
-   cq = device->create_cq(device, cqe);
+   cq = device->create_cq(device, cqe, NULL, NULL, 0);
 
if (!IS_ERR(cq)) {
cq->device= device;
+   cq->uobject   = NULL;
cq->comp_handler  = comp_handler;
cq->event_handler = event_handler;
cq->cq_context= cq_context;
@@ -245,8 +249,9 @@
mr = pd->device->get_dma_mr(pd, mr_access_flags);
 
if (!IS_ERR(mr)) {
-   mr->device = pd->device;
-   mr->pd = pd;
+   mr->device  = pd->device;
+   mr->pd  = pd;
+   mr->uobject = NULL;
atomic_inc(>usecnt);
atomic_set(>usecnt, 0);
}
@@ -267,8 +272,9 @@
 mr_access_flags, iova_start);
 
if (!IS_ERR(mr)) {
-   mr->device = pd->device;
-   mr->pd = pd;
+   mr->device  = pd->device;
+   mr->pd  = pd;
+   mr->uobject = NULL;
atomic_inc(>usecnt);
atomic_set(>usecnt, 0);
}
@@ -344,8 +350,9 @@
 
mw = pd->device->alloc_mw(pd);
if (!IS_ERR(mw)) {
-   mw->device = pd->device;
-   mw->pd = pd;
+   mw->device  = pd->device;
+   mw->pd  = pd;
+   mw->uobject = NULL;
atomic_inc(>usecnt);
}
 
--- linux-export.orig/drivers/infiniband/include/ib_verbs.h 2005-02-22 
10:14:06.623746000 -0800
+++ linux-export/drivers/infiniband/include/ib_verbs.h  2005-04-04 
14:50:42.054602327 -0700
@@ -41,7 +41,9 @@
 
 #include 
 #include 
+
 #include 
+#include 
 
 union ib_gid {
u8  raw[16];
@@ -618,29 +620,78 @@
u8  page_size;
 };
 
+struct ib_ucontext {
+   struct ib_device   *device;
+   struct list_headpd_list;
+   struct list_headmr_list;
+   struct list_headmw_list;
+   struct list_headcq_list;
+   struct list_headqp_list;
+   struct list_headsrq_list;
+   struct list_headah_list;
+   spinlock_t  lock;
+};
+
+struct ib_uobject {
+   u64 user_handle;/* handle given to us by 
userspace */
+   struct ib_ucontext *context;/* associated user context */
+   struct list_headlist;   /* link to context's list */
+   u32 id; /* index into kernel idr */
+};
+
+struct ib_umem {
+   unsigned long   user_base;
+   unsigned long   virt_base;
+   size_t  length;
+   int offset;
+   int page_size;
+   struct list_headchunk_list;
+};
+
+struct ib_umem_chunk {
+   struct list_headlist;
+   int nents;
+   int nmap;
+   struct scatterlist  page_list[0];
+};
+
+#define IB_UMEM_MAX_PAGE_CHUNK \
+   ((PAGE_SIZE - offsetof(struct ib_umem_chunk, page_list)) /  \
+((void *) &((struct ib_umem_chunk *) 0)->page_list[1] -\
+ (void *) &((struct ib_umem_chunk *) 

[PATCH][RFC][4/4] IB: userspace verbs Kconfig/Makefile changes

[Roland Dreier]

Hook userspace verbs up to Kconfig and Makefile.

Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

--- linux-export.orig/drivers/infiniband/Kconfig2005-04-04 
14:58:53.397756926 -0700
+++ linux-export/drivers/infiniband/Kconfig 2005-04-04 15:01:08.716332258 
-0700
@@ -7,6 +7,14 @@
  any protocols you wish to use as well as drivers for your
  InfiniBand hardware.
 
+config INFINIBAND_USER_VERBS
+   tristate "InfiniBand userspace verbs support"
+   depends on INFINIBAND
+   ---help---
+ Userspace InfiniBand verbs support.  This is the kernel side
+ of userspace verbs.  You will also need libibverbs and a
+ hardware driver library from .
+
 source "drivers/infiniband/hw/mthca/Kconfig"
 
 source "drivers/infiniband/ulp/ipoib/Kconfig"
--- linux-export.orig/drivers/infiniband/core/Makefile  2005-04-04 
14:58:53.398756709 -0700
+++ linux-export/drivers/infiniband/core/Makefile   2005-04-04 
15:00:44.933503748 -0700
@@ -1,7 +1,8 @@
 EXTRA_CFLAGS += -Idrivers/infiniband/include
 
-obj-$(CONFIG_INFINIBAND) +=ib_core.o ib_mad.o ib_ping.o \
-   ib_cm.o ib_sa.o ib_umad.o ib_ucm.o
+obj-$(CONFIG_INFINIBAND) +=ib_core.o ib_mad.o ib_ping.o \
+   ib_cm.o ib_sa.o ib_umad.o ib_ucm.o
+obj-$(CONFIG_INFINIBAND_USER_VERBS) += ib_uverbs.o
 
 ib_core-y :=   packer.o ud_header.o verbs.o sysfs.o \
device.o fmr_pool.o cache.o
@@ -16,4 +17,6 @@
 
 ib_umad-y :=   user_mad.o
 
+ib_uverbs-y := uverbs_main.o uverbs_cmd.o uverbs_mem.o
+
 ib_ucm-y :=ucm.o

-
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: [RFC] spinlock_t & rwlock_t break_lock member initialization (patch seeking comments included)

[Zwane Mwaikambo]

On Mon, 28 Mar 2005, Jesper Juhl wrote:

> On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:
> 
> > On Sun, 27 Mar 2005, Jesper Juhl wrote:
> > 
> > > I've now been running kernels (both PREEMPT, SMP, both and without both) 
> > > with the patch below applied for a few days and I see no ill effects. I'm 
> > > still interrested in comments about wether or not something like this 
> > > makes sense and is acceptable ?
> > 
> > The concept seems fine to me, although i think you should be using named 
> > initialisers instead.
> > 
> I wrote it the way I did to keep it similar to how the other members were 
> initialized, I wouldn't mind a different approach, but doing it this way 
> seemed to be what would "fit in" best, and it did the trick for me 
> (silenced the annoying warnings) and seemed safe.
> 
> Thank you for taking the time to comment on this trivial issue.

Well your original patch would probably cause the least noise amongst the 
other patches changing code in that area, perhaps try pushing 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 2.4] PCI 2/2 update pci.ids (0/2)

[Grant Coady]

Hi Marcelo,

This patch updates pci.ids to latest snapshot, requires patch 1/2 
to compile.  gzip'd due to size.  Compile and run tested.

Sign-off-by: Grant Coady <[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 2.4] PCI 1/2 update pci.ids

[Grant Coady]

Hi Marcelo,

Found the size of pci.ids strings (MAX_NAME_SIZE) needed increasing 
to accommodate latest pci.ids snapshot, compile failed at 140, 
succeeded at 150, so I went 160. 

This patch is required for the update to latest pci.ids snapshot 
patch 2/2.

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>


--- linux-2.4.30/drivers/pci/gen-devlist.c  2002-08-03 10:39:44.0 
+1000
+++ linux-2.4.30c/drivers/pci/gen-devlist.c 2005-04-05 07:59:20.0 
+1000
@@ -7,7 +7,7 @@
 #include 
 #include 
 
-#define MAX_NAME_SIZE 79
+#define MAX_NAME_SIZE 160
 
 static void
 pq(FILE *f, const char *c)
-
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] inotify 0.22

[John McCutchan]

On Mon, 2005-04-04 at 16:50 -0400, Dale Blount wrote:
> Will inotify watch directories recursively?  A quick browse through the
> source doesn't look like it, but I very well could be wrong.  Last I
> checked, dnotify did not either.  I am looking for a way to synchronize
> files in as-real-as-possible-time when they are modified.  The ideal
> implementation would be a kernel "hook" like d/inotify and a client
> application that watches changes and copies them to a remote server for
> redundancy purposes.   A scheduled rsync works decently, but has a lag
> time of 2-3 (or more) hours on certain files on a large filesystem.
> Will inotify work for this, or does someone else have another
> recommended solution to the problem?

This problem is solved really well by inotify. But inotify will not
watch directories recursively for you. You can easily spider your way
down the path yourself adding a watch for each directory you encounter.
This is how beagle works, which has the same needs as your problem.

-- 
John McCutchan <[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: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

[Nigel Cunningham]

Hi.

On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
> > Yes, exactly. Someone who understand do_exit please help clean up the
> > code. I'd like to remove the idle thread, since the smpboot code will
> > create a new idle thread.
> 
> I'd say fix the smpboot code so that it doesn't create new idle tasks
> except during boot.

Would that mean that CPUs that were physically hotplugged wouldn't get
idle threads?

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

-
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 2/3] hd eliminate bad section references

[Randy.Dunlap]

maximilian attems wrote:
Fix hd section references:
make parse_hd_setup() __init
Error: ./drivers/ide/legacy/hd.o .text refers to 0943 R_386_PC32
.init.text
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-bk5/drivers/ide/legacy/hd.c.orig	2005-04-04 18:39:04.0 +0200
+++ linux-2.6.12-rc1-bk5/drivers/ide/legacy/hd.c	2005-04-04 19:02:57.908576221 +0200
@@ -851,7 +851,7 @@
 	goto out;
 }
 
-static int parse_hd_setup (char *line) {
+static int __init parse_hd_setup (char *line) {
 	int ints[6];
 
 	(void) get_options(line, ARRAY_SIZE(ints), ints);
This one is fairly interesting and needs some resolution by someone
who knows
On the surface, the patch is correct.
Rusty, can you explain when __setup functions are called relative
to in-kernel init functions?  or put another way, can a __setup
function safely call in __init function?
Here's the function in question:
static int parse_hd_setup (char *line) {
int ints[6];
(void) get_options(line, ARRAY_SIZE(ints), ints);
hd_setup(NULL, ints);
return 1;
}
__setup("hd=", parse_hd_setup);

Should we make parse_hd_setup() __init,
or make hd_setup() non-__init, or something else?
{time passes, he looks]
OK, I looked at include/linux/init.h.  From what I can see
there, __setup() causes an .init.setup section to be emitted,
so marking __setup() function as __init would make sense.
I think that this patch is good.
Thanks.
--
~Randy
-
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] meminfo: add Cached underflow check

[Andrew Morton]

Martin Hicks <[EMAIL PROTECTED]> wrote:
>
> Working on some code lately I've been getting huge values
> for "Cached".  The cause is that get_page_cache_size() is an
> approximate value, and for a sufficiently small returned value
> of get_page_cache_size() the value underflows.

OK..

I think I'd prefer to do it this way - it's simpler and the original patch
had a teeny race wrt changes in total_swapcache_pages.


diff -puN fs/proc/proc_misc.c~meminfo-add-cached-underflow-check 
fs/proc/proc_misc.c
--- 25/fs/proc/proc_misc.c~meminfo-add-cached-underflow-check   Mon Apr  4 
15:06:38 2005
+++ 25-akpm/fs/proc/proc_misc.c Mon Apr  4 15:10:24 2005
@@ -126,6 +126,7 @@ static int meminfo_read_proc(char *page,
unsigned long committed;
unsigned long allowed;
struct vmalloc_info vmi;
+   long cached;
 
get_page_state();
get_zone_counts(, , );
@@ -140,6 +141,10 @@ static int meminfo_read_proc(char *page,
allowed = ((totalram_pages - hugetlb_total_pages())
* sysctl_overcommit_ratio / 100) + total_swap_pages;
 
+   cached = get_page_cache_size() - total_swapcache_pages - i.bufferram;
+   if (cached < 0)
+   cached = 0;
+
get_vmalloc_info();
 
/*
@@ -172,7 +177,7 @@ static int meminfo_read_proc(char *page,
K(i.totalram),
K(i.freeram),
K(i.bufferram),
-   K(get_page_cache_size()-total_swapcache_pages-i.bufferram),
+   K(cached),
K(total_swapcache_pages),
K(active),
K(inactive),
_

-
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] crypto: don't check for NULL before kfree(), it's redundant.

[Jesper Juhl]

Checking a pointer for NULL before calling kfree() on it is redundant. 
This patch removes such checks from crypto/

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

diff -up linux-2.6.12-rc1-mm4-orig/crypto/cipher.c 
linux-2.6.12-rc1-mm4/crypto/cipher.c
--- linux-2.6.12-rc1-mm4-orig/crypto/cipher.c   2005-03-31 21:19:49.0 
+0200
+++ linux-2.6.12-rc1-mm4/crypto/cipher.c2005-04-04 23:58:58.0 
+0200
@@ -336,6 +336,5 @@ out:
 
 void crypto_exit_cipher_ops(struct crypto_tfm *tfm)
 {
-   if (tfm->crt_cipher.cit_iv)
-   kfree(tfm->crt_cipher.cit_iv);
+   kfree(tfm->crt_cipher.cit_iv);
 }
diff -up linux-2.6.12-rc1-mm4-orig/crypto/hmac.c 
linux-2.6.12-rc1-mm4/crypto/hmac.c
--- linux-2.6.12-rc1-mm4-orig/crypto/hmac.c 2005-03-02 08:38:09.0 
+0100
+++ linux-2.6.12-rc1-mm4/crypto/hmac.c  2005-04-04 23:59:22.0 +0200
@@ -49,8 +49,7 @@ int crypto_alloc_hmac_block(struct crypt
 
 void crypto_free_hmac_block(struct crypto_tfm *tfm)
 {
-   if (tfm->crt_digest.dit_hmac_block)
-   kfree(tfm->crt_digest.dit_hmac_block);
+   kfree(tfm->crt_digest.dit_hmac_block);
 }
 
 void crypto_hmac_init(struct crypto_tfm *tfm, u8 *key, unsigned int *keylen)



-
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 performance counters for a processor in a multi-processor environment

[Abhinkar, Sameer]

Hi there,

I'm a newbie in Linux kernel development and hopefully my question has
some quick solution..

I'm trying to access performance counters on a dual Xeon processor
machine (both processors are 32-bit and HT enabled). Since each
processor (logical/physical) has their own performance counter, I'd like
to get the numbers for a processor. Is there a way I can do some
pre-work before executing rdpmc instruction to set up the context to
access counter information of a certain processor? Or, what is the best
way to do get the counter information for a certain processor in a
multi-processor environment.

If anybody has some information, I'd really grateful..

Thanks in advance,

Regards,
Sameer
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 11:24:05PM +0200, Sven Luther wrote:
> It assuredly can't hurt to add a few lines of comments to tg3.c, and since it
> is probably (well, 1/3 chance here) you who added said firmware to the tg3.c
> file, i guess you are even well placed to at least exclude it from being
> GPLed. Is this not a reasonable request ? Which should get a reasonable
> answer, and not claims of being a pain in the ass, and other wild fanatical
> accusations ? 

Jeff, please ignore this last sentence, i should not have said it.

Friendly,

Sven Luther

-
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.org replaced

[Fao, Sean]

H. Peter Anvin wrote:
HP has most graciously donated a pair of DL585 quad Opteron servers
with 24 GB of RAM and 10 TB of disk using a pair of MSA-30 arrays for
each server.
If you don't mind me asking, what all does this server do/host?
Just curious,
--
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/3] efi eliminate bad section references

[Randy.Dunlap]

(adding Matt Domsch to cc:)
maximilian attems wrote:
Randy please double check especially this one.
there may be a better solution.
Fix efi section references:
 remove __initdata for struct efi efi_phys 
 and struct efi_memory_map memmap
'memmap' can be used after init, so remove __initdata from it
certainly looks correct to me.
Regarding efi_phys:
'efi_get_time' can be called after init (that "inline ... _init"
on it is confusing to me), and it calls phys_efi_get_time(),
which uses 'efi_phys', so efi_phys should not be marked
as __initdata.
OTOH, phys_efi_set_virtual_address_map() can be marked as __init.
You could add that as an efficiency measure.
so
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Error: ./arch/i386/kernel/efi.o .text refers to 00d3 R_386_32
.init.data
Error: ./arch/i386/kernel/efi.o .text refers to 00ff R_386_32
.init.data
efi_memmap_walk (which is not __init nor static) 
accesses both efi_phys and memmap.

Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-bk5/arch/i386/kernel/efi.c.orig	2005-04-04 19:41:13.109877906 +0200
+++ linux-2.6.12-rc1-bk5/arch/i386/kernel/efi.c	2005-04-04 19:34:23.886343763 +0200
@@ -46,8 +46,8 @@
 
 struct efi efi;
 EXPORT_SYMBOL(efi);
-static struct efi efi_phys __initdata;
-struct efi_memory_map memmap __initdata;
+static struct efi efi_phys;
+struct efi_memory_map memmap;
 
 /*
  * We require an early boot_ioremap mapping mechanism initially

--
~Randy
-
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: i8042 controller on Toshiba Satellite P10 notebook - patch

[Jaco Kroon]

Dmitry Torokhov wrote:
> On Apr 4, 2005 3:35 PM, Jaco Kroon <[EMAIL PROTECTED]> wrote:
> 
>>As for loading the modules i8042, atkbd and psmouse (in that order):
>>black void of death.
>>
> Hmm.. remind me, if you boot with usb-handoff does it switch the i8042
> into active multiplexing mode (you get 4 AUX serio ports)?
> 
Checking my logs it actually looks like usb-handoff did get 4 ports.
With my patch, however, I only get:

serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 AUX port at 0x60,0x64 irq 1

>From the code I understand that this means that i8042_nomux != 0 or
i8042_check_mux() return != 0.  So I assume that with the patch that
check_mux returns non-zero (and reversed logic means that 0 implies the
check succeeds, ie, it _fails_ with my patch installed).  I don't know
which is the prefered mode of operation though (I guess MUX with 4 AUX
ports?).

With my patch I do get the ALPS support though - something which I
didn't get with usb-handoff, nor with acpi=off, nor with simply hacking
out the AUX_LOOP and AUX_TEST tests and just assuming the hardware is
there (I saw ALPS yesterday for the first time in my life for that matter).

OT:  I think I prefer synaptics multi-finger tapping to the tapping in
specific locations to get right and middle clicking, but that is another
story that probably has nothing to do with the kernel, and quite likely
something that is configurable in the synaptics xorg driver.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] network configs: disconnect network options from drivers

[Sam Ravnborg]

 
> >- Move submenu to the top
> >- Rename top menu to "Networking" and located it just before
> > "File systems"
> 
> I still prefer Networking to come before Device Drivers FWIW.
> Just makes some kind of hierarchical sense to me.
Moved up as suggested.

> I propose that the new file net/atm/Kconfig be sourced somewhere.
Thanks, I have missed that one - added just before wanrouter.
 
> I'll look at it more to see if I have any other comments.
OK. I will await and post an updated patch if you do not beat me.

Sam
-
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/