Re: [PATCH] highres: Do not run the TIMER_SOFTIRQ after switching to highres mode
Ingo Molnar wrote: > * Andres Salomon <[EMAIL PROTECTED]> wrote: > >> Thomas Gleixner wrote: > The question is, how the tick timer gets enqueued in the softirq queue. > Can you isolate the codepath, where this happens ? >>> The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable >>> clocksource and clock event sources are registered. The switch to high >>> resolution mode happens inside of the TIMER_SOFTIRQ, but runs the >>> softirq afterwards. That way the tick emulation timer, which was set up >>> in the switch to highres might be executed in the softirq context, which >>> is a BUG. The rbtree has not to be touched by the softirq after the >>> highres switch. >>> >> And an additional request, just to make it explicit that we should not >> have any NO_SOFTIRQ callbacks in the tree; BUG out if we encounter >> such a thing. > > please change it to WARN_ON_ONCE()... > > 'bug out' might mean: 'dead box'/'no resume'/'no bootup'. > > Ingo Certainly; note that hrtimers.c has quite a few BUG calls which could render a box dead, though. Patch to follow.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Fixes and cleanups for earlyprintk aka boot console.
Paul Mackerras wrote: > Gerd Hoffmann writes: > >> This patch fixes the console selection code to *not* consider a boot >> console a full-featured one, so the first non-boot console registering >> will become the default console instead. This way the unregister call >> for the boot console in the register_console() function actually >> triggers and the handover from the boot console to the real console >> device works smoothly. Added a printk for the handover, so you know >> which console device the output goes to when the boot console stops >> printing messages. > > You have removed functionality that is useful for debugging, that 3 > architectures had, namely a way to keep using the early boot console > and not replace it with a console that comes later, using a kernel > command line option. Perhaps you could provide a way to do that in > your patch. --verbose please. I don't think I broke that. I've seen code for that in i386/x86_64 and one of the other archs (via earlyprintk=foo,keep). The code clears now the CON_BOOT flag in case keep is present, which has the wanted effect: The earlyprintk console will not be replaced. cheers, Gerd -- Gerd Hoffmann <[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: [PATCH -mm 1/5] Blackfin: blackfin architecture patch update
On Sat, 2007-03-03 at 17:30 -0500, Arnd Bergmann wrote: > On Thursday 01 March 2007 05:14:40 Wu, Bryan wrote: > > Here is the update version of blackfin-arch.patch in -mm tree. > > simply add support to utrace and it was tested on blackfin STAMP > board > > as well as other following patches. > > Wow, this has come a long way since I looked at the patches last > year, good work! Yeah, old friend comes back. Thanks a lot for your review. We fixed lots of things according to your review since last year. > > I've gone through the complete patch again now, and these are the > issues I've found in it. None of these are show-stoppers and I'd > like to see it all go in during the next merge window. There should > be enough time until then to address these points: Lots of valuable comments got from you, we will get things done soon. So could please give us some information about the merge window schedule, we may try to catch this. > + > > +/* Clock and System Control (0xFFC0 0400-0xFFC0 07FF) */ > > +#define bfin_read_PLL_CTL() bfin_read16(PLL_CTL) > > +#define bfin_write_PLL_CTL(val) > bfin_write16(PLL_CTL,val) > > +#define bfin_read_PLL_STAT() bfin_read16(PLL_STAT) > > +#define bfin_write_PLL_STAT(val) > bfin_write16(PLL_STAT,val) > > +#define bfin_read_PLL_LOCKCNT() > bfin_read16(PLL_LOCKCNT) > > +#define bfin_write_PLL_LOCKCNT(val) > bfin_write16(PLL_LOCKCNT,val) > > +#define bfin_read_CHIPID() bfin_read32(CHIPID) > > +#define bfin_read_SWRST()bfin_read16(SWRST) > > +#define bfin_write_SWRST(val) > bfin_write16(SWRST,val) > > I remember that we have discussed these macro abstractions before, but > don't > recall the result of the discussion. You have around 5000 such macros, > and I still think it's not a helpful abstraction. It is much more > common > for device drivers to just use the read/write accessors directly. IIRC > the objections that were raised (and my replies to them) were roughly: > > > the driver writer doesn't want to know the size of the variable, and > > if it changes, they need to change every instance in the code, not > > just the macro. > > A driver writer should better know the type of variable he is > changing, > e.g. because of the type he passes in and out. Also, hardware > registers > don't suddenly change in size. > > > These macros allow us to work around hardware bugs when accessing > the > > registers by simply redefining the accessor to do something more > > complex. > > If there is a bug in the hardware, the workaround belongs into the > driver. You can then still define a special inline function to > access that particular register. > Oh, if we should fix this issue, there are lots of work to do because tons of drivers rely on this. Maybe after some team internal discussion, we will give a solution to this. Thanks again Best Regards, -Bryan Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] highres: Do not run the TIMER_SOFTIRQ after switching to highres mode
* Andres Salomon <[EMAIL PROTECTED]> wrote: > Thomas Gleixner wrote: > >>> The question is, how the tick timer gets enqueued in the softirq queue. > >>> Can you isolate the codepath, where this happens ? > > > > The TIMER_SOFTIRQ runs the hrtimers during bootup until a usable > > clocksource and clock event sources are registered. The switch to high > > resolution mode happens inside of the TIMER_SOFTIRQ, but runs the > > softirq afterwards. That way the tick emulation timer, which was set up > > in the switch to highres might be executed in the softirq context, which > > is a BUG. The rbtree has not to be touched by the softirq after the > > highres switch. > > > > And an additional request, just to make it explicit that we should not > have any NO_SOFTIRQ callbacks in the tree; BUG out if we encounter > such a thing. please change it to WARN_ON_ONCE()... 'bug out' might mean: 'dead box'/'no resume'/'no bootup'. 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] ext3: dirindex error pointer issues
Andreas Dilger <[EMAIL PROTECTED]> writes:
> On Mar 04, 2007 17:18 +0300, Dmitriy Monakhov wrote:
>> - ext3_dx_find_entry() exit with out setting proper error pointer
>> - do_split() exit with out setting proper error pointer
>>it is realy painful because many callers contain folowing code:
>>de = do_split(handle,dir, , frame, , );
>>if (!(de))
>> return retval;
>><<< WOW retval wasn't changed by do_split(), so caller failed
>><<< but return SUCCESS :)
>> - Rearrange do_split() error path. Current error path is realy ugly, all
>>this up and down jump stuff doesn't make code easy to understand.
>>
>> Signed-off-by: Monakhov Dmitriy <[EMAIL PROTECTED]>
>> ---
>> fs/ext3/namei.c | 26 +++---
>> fs/ext4/namei.c | 26 +++---
>> 2 files changed, 30 insertions(+), 22 deletions(-)
>>
>> diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
>> index 49159f1..1a52586 100644
>> --- a/fs/ext3/namei.c
>> +++ b/fs/ext3/namei.c
>> @@ -969,6 +969,7 @@ static struct buffer_head * ext3_dx_find_entry(struct
>> dentry *dentry,
>>(block<>+((char *)de - bh->b_data))) {
>> brelse (bh);
>> +*err = ERR_BAD_DX_DIR;
>> goto errout;
>> }
>> *res_dir = de;
>
> I have no objection to this change (by principle of least surprise) but
> I don't know if it fixes a real problem. The one caller of this function
> treats ERR_BAD_DX_DIR the same as bh == NULL.
Execly ERR_BAD_DX_DIR treats the same as bh == NULL and let's look at
callers code:
struct buffer_head * ext3_find_entry(..)
{
...
bh = ext3_dx_find_entry(dentry, res_dir, );
/*
* On success, or if the error was file not found,
* return. Otherwise, fall back to doing a search the
* old fashioned way.
*/
if (bh || (err != ERR_BAD_DX_DIR))
< after ext3_dx_find_entry() has failed , but don't set err pointer
< we get (bh == NULL, err == 0) , and then just return NULL.
return bh;
...
}
>
>> @@ -1134,9 +1135,9 @@ static struct ext3_dir_entry_2 *do_split(handle_t
>> *handle, struct inode *dir,
>> char *data1 = (*bh)->b_data, *data2;
>> unsigned split;
>> struct ext3_dir_entry_2 *de = NULL, *de2;
>> -int err;
>> +int err = 0;
>>
>> -bh2 = ext3_append (handle, dir, , error);
>> +bh2 = ext3_append (handle, dir, , );
>
> Why don't we just remove "err" entirely and use *error to avoid any risk
> of setting err and not returning it in error? Also reduces stack usage
> that tiny little bit.
I've chosen this approuch becouse of:
1) this approuch was used in block allocation code.
2) this approuch prevent folowing errors:
*error = do_some_function(.)
/* some code*/
if(error)
we do this checking as we do it thousands times before, but forget
what error it pointer here. And compiler can't warn us here because
it is absolutely legal operation. At least it is better to rename
error to errorp.
Btw: I've thought about adding assertations to error path witch may check
what errp pointer was properly initialized after error happends.
folowing code is draft only:
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -63,6 +63,7 @@ static struct buffer_head *ext3_append(handle_t *handle,
EXT3_I(inode)->i_disksize = inode->i_size;
ext3_journal_get_write_access(handle,bh);
}
+ assert(bh || *err);
return bh;
}
@@ -433,6 +434,7 @@ fail2:
frame--;
}
fail:
+ assert(*err != 0);
return NULL;
}
>
>
> In ext3_dx_add_entry() it appears like we should "goto journal_error"
> to report an error after the failed call to do_split(), instead of just
> "goto cleanup" so that we report an error in the filesystem. Not 100%
> sure of this.
do_split() already invoked ext3_std_error() on it's "journal_error" path.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/
[DOC] The documentation for HID Simple Driver Interface 0.5.0
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do not confuse with the
"simple" in this name.
Version
This is used for the version 0.5.0
--
Overview
--
Under standard HID device driver development means, we need to write
one interrupt handler for each new HID device to report event to
input subsystem. However, although the most of they can not merge into
mainstream kernel tree, they have only some extended keys, e.g. many
remote controllers. I think it seem break a fly on the wheel, which
write one new interrupt handler for this reason.
The basic idea is reuse the interrupt handler in hid-core.c. so writing
driver for new simple HID device will be more easier, quickly, and do not
need touch hid core.
In essence, this interface just is some hooks in HID core.
The hid-simple.h include this API. But, defore use this interface, you must
include hid.h first.
What's you will get from this interface.
Use me, you can:
1. Write the driver of USB input device without write code take care of
details of setup and clear usage.
2. A driver use this interface can be as a HID device input filter.
This interface can not support the more drivers handle one device at same time
yet. I can not sure if we really need this feature.
-
Prepare
-
Before use this interface, you must turn on these kernel configuration
items:
CONFIG_HID_SIMPLE : HID simple driver interface
--
Register and unregister
--
1. Register a simple driver.
int hidinput_register_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it register your driver to kernel,
when the chance that match device come, your driver can probe it. At least, you
must fill the member of parameter simple : name.
Return 0 mean register successfully. elsewise mean there have some
failures in register process.
So far, this function only can return 0 and -EINVAL.
When you driver matched one device, it will reregister it into input
subsystem (see the function hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
2. Unregister a simple driver.
void hidinput_unregister_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it clean your driver from kernel, and
in this process, your driver will disconnect any device which it matched.
However,
it do not free your memory of driver structure, that's your task.
This may reregister the device into input subsystem (see the function
hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
3. USB device driver.
You should use follow functions for USB device. the usage of these functions
is
same with aboves.
int hidinput_register_simple_usb_driver(struct hidinput_simple_driver *simple)
void hidinput_unregister_simple_usb_driver(struct hidinput_simple_driver
*simple)
Both functions is used in driver.
--
Usage
--
Each simple driver have one data structure hidinput_simple_driver:
struct hidinput_simple_driver {
/*
* The members for implement only are ignored here,
* please do not depend on them
*/
/* public for HID sublayer. */
int (*match_device)(struct hidinput_simple_driver *drv,
struct matched_device *dev);
/* public for drivers */
struct module *owner;
char *name;
int (*connect)(struct hid_device *, struct hid_input *);
void (*disconnect)(struct hid_device *, struct hid_input *);
void (*setup_usage)(struct hid_field *, struct hid_usage *);
void (*clear_usage)(struct hid_field *, struct hid_usage *);
int (*pre_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*post_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*open)(struct input_dev *dev);
void (*close)(struct input_dev *dev);
void *private;
struct usb_device_id *id_table;
struct usage_page_block *usage_page_table;
};
The data member description:
struct module *owner;
In most cases, set this member to THIS_MODULE is your want to.
char *name;
The name of your driver. you must fill this member before register it.
void *private;
You can save the data that your driver use only here. HID simple driver
core do not take care of this.
struct usb_device_id *id_table;
As same with other USB device driver, this is used by
[PATCH] usb/hid:The HID Simple Driver Interface 0.5.0 (core)
Changelogs (since 0.4.1):
1. port to 2.6.21.
2. One bugfix.
The code base is 2.6.21-rc2.
Signed-off-by: Liyu <[EMAIL PROTECTED]>
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid.h
linux-2.6.21-rc2/include/linux/hid.h
--- linux-2.6.21-rc2.orig/include/linux/hid.h 2007-03-05 09:09:35.0
+0800
+++ linux-2.6.21-rc2/include/linux/hid.h2007-03-05 11:17:22.0
+0800
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/*
* USB HID (Human Interface Device) interface class code
@@ -397,8 +398,15 @@ struct hid_input {
struct list_head list;
struct hid_report *report;
struct input_dev *input;
+ unsigned long input_lock; /* To protect accessing input_dev from
+* hid-input processing. But it not
+* necessary for accessing this
input_dev
+* instance from input subsystem. */
+ void *private;
};
+struct hidinput_simple_driver;
+
struct hid_device {/*
device report descriptor */
__u8 *rdesc;
unsigned rsize;
@@ -429,6 +437,8 @@ struct hid_device {
/* device repo
char phys[64]; /*
Device physical location */
char uniq[64]; /*
Device unique identifier (serial #) */
+ struct hidinput_simple_driver *simple;
+
void *driver_data;
/* device-specific function pointers */
@@ -483,6 +493,8 @@ extern void hidinput_hid_event(struct hi
extern void hidinput_report_event(struct hid_device *hid, struct hid_report
*report);
extern int hidinput_connect(struct hid_device *);
extern void hidinput_disconnect(struct hid_device *);
+extern void hidinput_reconnect_core(struct hid_device *);
+extern int hidinput_disconnect_core(struct hid_device *);
int hid_set_field(struct hid_field *, unsigned, __s32);
int hid_input_report(struct hid_device *, int type, u8 *, int, int);
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid-simple.h
linux-2.6.21-rc2/include/linux/hid-simple.h
--- linux-2.6.21-rc2.orig/include/linux/hid-simple.h1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21-rc2/include/linux/hid-simple.h 2007-03-05 13:37:42.0
+0800
@@ -0,0 +1,260 @@
+/*
+ * NOTE:
+ * For use me , you must include hid.h in your source first.
+ */
+#ifndef __HID_SIMPLE_H
+#define __HID_SIMPLE_H
+
+#ifdef __KERNEL__
+
+#include
+/* The public interface for simple device driver */
+struct usage_block {
+ int usage; /* usage code */
+ int value; /* not used, for F_EVENT_BY_VALUE in future */
+ int event; /* input event type, e.g. EV_KEY. */
+ int code; /* input subsystem code, e.g. KEY_F1. */
+ int flags; /* not used */
+};
+
+struct usage_page_block {
+ int page; /* usage page code */
+ int flags; /* not used */
+ struct usage_block *usage_blockes;
+};
+
+extern struct mutex matched_devices_lock;
+extern struct mutex simple_drivers_lock;
+extern struct list_head simple_drivers_list;
+extern struct list_head matched_devices_list;
+
+/* usage_block flags list */
+#define F_EVENT_BY_VALUE (0x1) /* submit input event by usage_block.value,
+ not implement yet */
+
+#define USAGE_BLOCK(i_usage, i_value, i_event, i_code, i_flags) \
+ {\
+ .usage = (i_usage),\
+ .value = (i_value),\
+ .event = (i_event),\
+ .code = (i_code),\
+ .flags = (i_flags),\
+ }
+
+#define USAGE_BLOCK_NULL {}
+
+#define USAGE_PAGE_BLOCK(i_page, i_usage_blockes) \
+ {\
+ .page = (i_page),\
+ .usage_blockes = (i_usage_blockes),\
+ }
+
+#define USAGE_PAGE_BLOCK_NULL {}
+
+#define __SIMPLE_DRIVER_INIT \
+ .owner = THIS_MODULE,
+
+struct matched_device;
+
+struct hidinput_simple_driver {
+/* private */
+ struct list_head node; /* link with simple_drivers_list */
+ struct list_head raw_devices;
+ unsigned long flags;
+/* public for hid sub-layer, for example, USB. */
+ int (*match_device)(struct hidinput_simple_driver *drv,
+ struct matched_device *dev);
+/* public for drivers. */
+ struct module *owner;
+ char *name;
+ int (*connect)(struct hid_device *, struct hid_input *);
+ void (*disconnect)(struct hid_device *, struct hid_input *);
+ void (*setup_usage)(struct hid_field *, struct hid_usage *);
+ void (*clear_usage)(struct hid_field *, struct hid_usage *);
+ int (*pre_event)(const struct hid_device *, const struct hid_field *,
+ const struct hid_usage *, const __s32);
+ int (*post_event)(const struct hid_device *, const
[PATCH] usb/hid:The HID Simple Driver Patches 0.5.0 (all-in-one)
This patch set include follow patches:
1. [PATCH] usb/hid: The HID Simple Driver Interface 0.5.0 (core)
2. [PATCH] usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver
0.5.0
3. Some related kbuild changes.
The code base is 2.6.21-rc2
Signed-off-by: Liyu <[EMAIL PROTECTED]>
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid.h
linux-2.6.21-rc2/include/linux/hid.h
--- linux-2.6.21-rc2.orig/include/linux/hid.h 2007-03-05 09:09:35.0
+0800
+++ linux-2.6.21-rc2/include/linux/hid.h2007-03-05 11:17:22.0
+0800
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/*
* USB HID (Human Interface Device) interface class code
@@ -397,8 +398,15 @@ struct hid_input {
struct list_head list;
struct hid_report *report;
struct input_dev *input;
+ unsigned long input_lock; /* To protect accessing input_dev from
+* hid-input processing. But it not
+* necessary for accessing this
input_dev
+* instance from input subsystem. */
+ void *private;
};
+struct hidinput_simple_driver;
+
struct hid_device {/*
device report descriptor */
__u8 *rdesc;
unsigned rsize;
@@ -429,6 +437,8 @@ struct hid_device {
/* device repo
char phys[64]; /*
Device physical location */
char uniq[64]; /*
Device unique identifier (serial #) */
+ struct hidinput_simple_driver *simple;
+
void *driver_data;
/* device-specific function pointers */
@@ -483,6 +493,8 @@ extern void hidinput_hid_event(struct hi
extern void hidinput_report_event(struct hid_device *hid, struct hid_report
*report);
extern int hidinput_connect(struct hid_device *);
extern void hidinput_disconnect(struct hid_device *);
+extern void hidinput_reconnect_core(struct hid_device *);
+extern int hidinput_disconnect_core(struct hid_device *);
int hid_set_field(struct hid_field *, unsigned, __s32);
int hid_input_report(struct hid_device *, int type, u8 *, int, int);
diff -Naurp linux-2.6.21-rc2.orig/include/linux/hid-simple.h
linux-2.6.21-rc2/include/linux/hid-simple.h
--- linux-2.6.21-rc2.orig/include/linux/hid-simple.h1970-01-01
08:00:00.0 +0800
+++ linux-2.6.21-rc2/include/linux/hid-simple.h 2007-03-05 13:37:42.0
+0800
@@ -0,0 +1,260 @@
+/*
+ * NOTE:
+ * For use me , you must include hid.h in your source first.
+ */
+#ifndef __HID_SIMPLE_H
+#define __HID_SIMPLE_H
+
+#ifdef __KERNEL__
+
+#include
+/* The public interface for simple device driver */
+struct usage_block {
+ int usage; /* usage code */
+ int value; /* not used, for F_EVENT_BY_VALUE in future */
+ int event; /* input event type, e.g. EV_KEY. */
+ int code; /* input subsystem code, e.g. KEY_F1. */
+ int flags; /* not used */
+};
+
+struct usage_page_block {
+ int page; /* usage page code */
+ int flags; /* not used */
+ struct usage_block *usage_blockes;
+};
+
+extern struct mutex matched_devices_lock;
+extern struct mutex simple_drivers_lock;
+extern struct list_head simple_drivers_list;
+extern struct list_head matched_devices_list;
+
+/* usage_block flags list */
+#define F_EVENT_BY_VALUE (0x1) /* submit input event by usage_block.value,
+ not implement yet */
+
+#define USAGE_BLOCK(i_usage, i_value, i_event, i_code, i_flags) \
+ {\
+ .usage = (i_usage),\
+ .value = (i_value),\
+ .event = (i_event),\
+ .code = (i_code),\
+ .flags = (i_flags),\
+ }
+
+#define USAGE_BLOCK_NULL {}
+
+#define USAGE_PAGE_BLOCK(i_page, i_usage_blockes) \
+ {\
+ .page = (i_page),\
+ .usage_blockes = (i_usage_blockes),\
+ }
+
+#define USAGE_PAGE_BLOCK_NULL {}
+
+#define __SIMPLE_DRIVER_INIT \
+ .owner = THIS_MODULE,
+
+struct matched_device;
+
+struct hidinput_simple_driver {
+/* private */
+ struct list_head node; /* link with simple_drivers_list */
+ struct list_head raw_devices;
+ unsigned long flags;
+/* public for hid sub-layer, for example, USB. */
+ int (*match_device)(struct hidinput_simple_driver *drv,
+ struct matched_device *dev);
+/* public for drivers. */
+ struct module *owner;
+ char *name;
+ int (*connect)(struct hid_device *, struct hid_input *);
+ void (*disconnect)(struct hid_device *, struct hid_input *);
+ void (*setup_usage)(struct hid_field *, struct hid_usage *);
+ void (*clear_usage)(struct hid_field *, struct hid_usage *);
+ int (*pre_event)(const struct hid_device *,
[PATCH] usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver 0.5.0
Changelogs:
1. Port to HID simple driver layer 0.5.0.
It can be applied on 2.6.21 at least.
Signed-off-by: Liyu <[EMAIL PROTECTED]>
--- linux-2.6.18/drivers/usb/input.orig/usbnek4k.c 1970-01-01
08:00:00.0 +0800
+++ linux-2.6.18/drivers/usb/input/usbnek4k.c 2006-10-12 13:29:28.0
+0800
@@ -0,0 +1,252 @@
+/*
+ * Microsoft Natural Ergonomic Keyboard 4000 Driver
+ *
+ * Version: 0.4.0
+ *
+ * Copyright (c) 2006 Li Yu <[EMAIL PROTECTED]>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include "hid.h"
+#include "hid-simple.h"
+
+static int ascii_keycode;
+module_param(ascii_keycode, bool, 0444);
+MODULE_PARM_DESC(ascii_keycode, "Only yield ASCII keycodes when turn on this,
default=n");
+
+#define USAGE_ZOOM_IN 0x22d
+#define USAGE_ZOOM_OUT 0x22e
+#define USAGE_HOME 0x223
+#define USAGE_SEARCH 0x221
+#define USAGE_EMAIL0x18a
+#define USAGE_FAVORITES0x182
+#define USAGE_MUTE 0xe2
+#define USAGE_VOLUME_DOWN 0xea
+#define USAGE_VOLUME_UP0xe9
+#define USAGE_PLAY_PAUSE 0xcd
+#define USAGE_CALCULATOR 0x192
+#define USAGE_BACK 0x224
+#define USAGE_FORWARD 0x225
+#define USAGE_CUSTOM 0xff05
+
+#define USAGE_CUSTOM_RELEASE 0x0
+#define USAGE_CUSTOM_1 0x1
+#define USAGE_CUSTOM_2 0x2
+#define USAGE_CUSTOM_3 0x4
+#define USAGE_CUSTOM_4 0x8
+#define USAGE_CUSTOM_5 0x10
+
+#define USAGE_HELP 0x95
+#define USAGE_UNDO 0x21a
+#define USAGE_REDO 0x279
+#define USAGE_NEW 0x201
+#define USAGE_OPEN 0x202
+#define USAGE_CLOSE0x203
+
+#define USAGE_REPLY0x289
+#define USAGE_FWD 0x28b
+#define USAGE_SEND 0x28c
+#define USAGE_SPELL0x1ab
+#define USAGE_SAVE 0x207
+#define USAGE_PRINT0x208
+
+#define USAGE_KEYPAD_EQUAL 0x67
+#define USAGE_KEYPAD_LEFT_PAREN0xb6
+#define USAGE_KEYPAD_RIGHT_PAREN 0xb7
+
+#define MSNEK4K_ID_VENDOR 0x045e
+#define MSNEK4K_ID_PRODUCT 0x00db
+
+#define map_key(c) do { usage->code = c; usage->type = EV_KEY;
set_bit(c,input->keybit); } while (0)
+#define clear_key(c) do { usage->code = 0; usage->type = 0;
clear_bit(c,input->keybit); } while (0)
+
+static struct usb_device_id nek4k_id_table[] = {
+ { USB_DEVICE(MSNEK4K_ID_VENDOR, MSNEK4K_ID_PRODUCT) },
+ {}
+};
+
+MODULE_DEVICE_TABLE(usb, nek4k_id_table);
+MODULE_DESCRIPTION("Microsoft Natural Ergonomic Keyboard 4000 Driver");
+MODULE_VERSION("0.4.0");
+
+struct usage_block consumer_usage_block[] = {
+ USAGE_BLOCK(USAGE_ZOOM_IN, 0, EV_KEY, KEY_F13, 0),
+ USAGE_BLOCK(USAGE_ZOOM_OUT, 0, EV_KEY, KEY_F14, 0),
+ USAGE_BLOCK(USAGE_HOME, 0, EV_KEY, KEY_HOMEPAGE, 0),
+ USAGE_BLOCK(USAGE_SEARCH, 0, EV_KEY, KEY_SEARCH, 0),
+ USAGE_BLOCK(USAGE_EMAIL, 0, EV_KEY, KEY_EMAIL, 0),
+ USAGE_BLOCK(USAGE_MUTE, 0, EV_KEY, KEY_MUTE, 0),
+ USAGE_BLOCK(USAGE_VOLUME_DOWN, 0, EV_KEY, KEY_VOLUMEDOWN, 0),
+ USAGE_BLOCK(USAGE_VOLUME_UP, 0, EV_KEY, KEY_VOLUMEUP, 0),
+ USAGE_BLOCK(USAGE_PLAY_PAUSE, 0, EV_KEY, KEY_PLAYPAUSE, 0),
+ USAGE_BLOCK(USAGE_CALCULATOR, 0, EV_KEY, KEY_CALC, 0),
+ USAGE_BLOCK(USAGE_BACK, 0, EV_KEY, KEY_BACK, 0),
+ USAGE_BLOCK(USAGE_FORWARD, 0, EV_KEY, KEY_FORWARD, 0),
+ USAGE_BLOCK(USAGE_HELP, 0, EV_KEY, KEY_HELP, 0),
+ USAGE_BLOCK(USAGE_UNDO, 0, EV_KEY, KEY_UNDO, 0),
+ USAGE_BLOCK(USAGE_REDO, 0, EV_KEY, KEY_REDO, 0),
+ USAGE_BLOCK(USAGE_NEW, 0, EV_KEY, KEY_NEW, 0),
+ USAGE_BLOCK(USAGE_OPEN, 0, EV_KEY, KEY_OPEN, 0),
+ USAGE_BLOCK(USAGE_CLOSE, 0, EV_KEY, KEY_CLOSE, 0),
+ USAGE_BLOCK(USAGE_REPLY, 0, EV_KEY, KEY_REPLY, 0),
+ USAGE_BLOCK(USAGE_FWD, 0, EV_KEY, KEY_FORWARDMAIL, 0),
+ USAGE_BLOCK(USAGE_SEND, 0, EV_KEY, KEY_SEND, 0),
+ USAGE_BLOCK(USAGE_SPELL, 0, EV_KEY, KEY_F15, 0),
+ USAGE_BLOCK(USAGE_SAVE, 0, EV_KEY, KEY_SAVE, 0),
+ USAGE_BLOCK(USAGE_PRINT, 0, EV_KEY, KEY_PRINT, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_block msvendor_usage_block[] = {
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_1, EV_KEY, KEY_FN_F1, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_2, EV_KEY, KEY_FN_F2, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_3, EV_KEY, KEY_FN_F3, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_4, EV_KEY, KEY_FN_F4, 0),
+ USAGE_BLOCK(USAGE_CUSTOM, USAGE_CUSTOM_5, EV_KEY, KEY_FN_F5, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_block keyboard_usage_block[] = {
+ USAGE_BLOCK(USAGE_KEYPAD_EQUAL, 0, EV_KEY, KEY_KPEQUAL, 0),
+ USAGE_BLOCK(USAGE_KEYPAD_LEFT_PAREN, 0, EV_KEY, KEY_KPLEFTPAREN, 0),
+ USAGE_BLOCK(USAGE_KEYPAD_RIGHT_PAREN, 0, EV_KEY, KEY_KPRIGHTPAREN, 0),
+ USAGE_BLOCK_NULL
+};
+
+struct usage_page_block nek4k_usage_page_blockes[]
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 11:02:48PM -0800, Greg KH wrote: > On Mon, Mar 05, 2007 at 12:42:29AM -0600, Matt Mackall wrote: > > On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: > > > On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: > > > > Recent kernels are having troubles with wireless for me. Two seemingly > > > > related problems: > > > > > > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > > > b) Manual iwconfig waits for 60s and then reports: > > > > > > > > Error for wireless request "Set Encode" (8B2A) : > > > > SET failed on device eth1 ; Operation not supported. > > > > > > Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that > > > will keep you from having to change any userspace code. > > > > No, it's disabled. Will test once I'm done tracking down the iwconfig > > problem. From the help text for SYSFS_DEPRECATED: > > > > If you are using a distro that was released in 2006 or > > later, it should be safe to say N here. > > > > If we need an as-yet-unreleased HAL without it, I would say the above > > should be changed to 2008 or so. If Debian actually cuts a release in > > the next few months, you might make that 2010. > > Well, just because Debian has such a slow release cycle, should the rest > of the world be forced to follow suit? :) > > When I originally wrote that, I thought Debian would have already done > their release, my mistake... That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here. If it is indeed the case that HAL needs to be upgraded here, the clock on deprecating these features can't even start counting until a usable HAL version is released. And then you need to give it at least a year after that before you can start recommending people disable it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 -mm] Blackfin: blackfin utrace patch
Hi folks,
As utrace is very promising in the -mm tree, a simple support is added
to blackfin architecture. I send this patch out just for review and it
is only a start point, we will make it fully work in the future.
Now after applying this patch, the blackfin-arch can be compile in the
2.6.21-rc2-mm1 with utrace enabled and ptrace disabled.
[PATCH -mm] Blackfin: blackfin utrace patch
This patch adds support utrace in blackfin architecture.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/asm-offsets.c |2
arch/blackfin/kernel/ptrace.c |8 +++
include/asm-blackfin/thread_info.h |2
include/asm-blackfin/tracehook.h | 79 +
4 files changed, 91 insertions(+)
diff -uprN linux-2.6-orig/arch/blackfin/kernel/asm-offsets.c
linux-2.6/arch/blackfin/kernel/asm-offsets.c
--- linux-2.6-orig/arch/blackfin/kernel/asm-offsets.c 2007-03-05
11:50:21.0 +0800
+++ linux-2.6/arch/blackfin/kernel/asm-offsets.c2007-03-05
11:57:23.0 +0800
@@ -45,7 +45,9 @@ int main(void)
/* offsets into the task struct */
DEFINE(TASK_STATE, offsetof(struct task_struct, state));
DEFINE(TASK_FLAGS, offsetof(struct task_struct, flags));
+#if 0
DEFINE(TASK_PTRACE, offsetof(struct task_struct, ptrace));
+#endif
DEFINE(TASK_BLOCKED, offsetof(struct task_struct, blocked));
DEFINE(TASK_THREAD, offsetof(struct task_struct, thread));
DEFINE(TASK_THREAD_INFO, offsetof(struct task_struct, thread_info));
diff -uprN linux-2.6-orig/arch/blackfin/kernel/ptrace.c
linux-2.6/arch/blackfin/kernel/ptrace.c
--- linux-2.6-orig/arch/blackfin/kernel/ptrace.c2007-03-05
11:50:21.0 +0800
+++ linux-2.6/arch/blackfin/kernel/ptrace.c 2007-03-05 11:57:23.0
+0800
@@ -34,12 +34,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -173,6 +175,8 @@ static inline int is_user_addr_valid(str
return -EIO;
}
+#ifdef CONFIG_PTRACE
+
/*
* Called by kernel/ptrace.c when detaching..
*
@@ -386,12 +390,15 @@ long arch_ptrace(struct task_struct *chi
return ret;
}
+#endif /* CONFIG_PTRACE */
+
asmlinkage void syscall_trace(void)
{
if (!test_thread_flag(TIF_SYSCALL_TRACE))
return;
+#if 0
if (!(current->ptrace & PT_PTRACED))
return;
@@ -400,6 +407,7 @@ asmlinkage void syscall_trace(void)
*/
ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
? 0x80 : 0));
+#endif
/*
* this isn't the same as continuing with a signal, but it will do
diff -uprN linux-2.6-orig/include/asm-blackfin/thread_info.h
linux-2.6/include/asm-blackfin/thread_info.h
--- linux-2.6-orig/include/asm-blackfin/thread_info.h 2007-03-05
11:50:22.0 +0800
+++ linux-2.6/include/asm-blackfin/thread_info.h2007-03-05
11:57:23.0 +0800
@@ -127,6 +127,7 @@ static inline struct thread_info *curren
#define TIF_MEMDIE 5
#define TIF_RESTORE_SIGMASK6 /* restore signal mask in do_signal() */
#define TIF_FREEZE 7 /* is freezing for suspend */
+#define TIF_SINGLESTEP 8 /* restore singlestep on return to user
mode */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<
+#include
+
+/*
+ * See linux/tracehook.h for the descriptions of what these need to do.
+ */
+
+#define ARCH_HAS_SINGLE_STEP (1)
+
+static inline void tracehook_enable_single_step(struct task_struct *task)
+{
+ /* TODO */
+#if 0
+ struct pt_regs *regs = task->thread.regs;
+
+ if (regs != NULL) {
+ }
+#endif
+ set_tsk_thread_flag(task, TIF_SINGLESTEP);
+}
+
+static inline void tracehook_disable_single_step(struct task_struct *task)
+{
+ /* TODO */
+#if 0
+ struct pt_regs *regs = task->thread.regs;
+
+ if (regs != NULL) {
+ }
+#endif
+ clear_tsk_thread_flag(task, TIF_SINGLESTEP);
+}
+
+
+static inline int tracehook_single_step_enabled(struct task_struct *tsk)
+{
+ return test_tsk_thread_flag(tsk, TIF_SINGLESTEP);
+}
+
+static inline void tracehook_enable_syscall_trace(struct task_struct *tsk)
+{
+ set_tsk_thread_flag(tsk, TIF_SYSCALL_TRACE);
+}
+
+static inline void tracehook_disable_syscall_trace(struct task_struct *tsk)
+{
+ clear_tsk_thread_flag(tsk, TIF_SYSCALL_TRACE);
+}
+
+static inline void tracehook_abort_syscall(struct pt_regs *regs)
+{
+ regs->orig_r0 = -1;
+}
+
+extern const struct utrace_regset_view utrace_bfin_native;
+static inline const struct utrace_regset_view *
+utrace_native_view(struct task_struct *tsk)
+{
+ return _bfin_native;
+}
+
+#endif
_
Thanks
-Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [v4l-dvb-maintainer] [-mm patch] drivers/media/video/ivtv/: possible cleanups
On Monday 05 March 2007 02:49, Adrian Bunk wrote:
> On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.20-mm2:
> >...
> > git-dvb.patch
> >...
> > git trees
> >...
>
> This patch contains the following possible cleanups:
> - every file should #include the headers containing the prototypes
> for it's global functions
> - make the following needlessly global variables static:
> - ivtv-driver.c: newi2c
> - ivtv-streams.c: struct ivtv_stream_info[]
> - make the following needlessly global functions static:
> - ivtv-fileops.c: ivtv_stop_decoding()
> - ivtv-i2c.c: ivtv_i2c_id_addr()
> - #if 0 the following unused global functions:
> - ivtv-i2c.c: ivtv_msp34xx()
> - ivtv-udma.c: ivtv_udma_setup()
> - ivtv-video.c: ivtv_encoder_enable()
> - ivtv-driver.c: remove the unused EXPORT_SYMBOL's
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
NACK.
A patch to fix the needlessly global functions is already in v4l-dvb,
and the 'unused EXPORT_SYMBOLs' ARE in fact used by the ivtv-fb
framebuffer. This module is not yet in the kernel, although I hope to
do that for 2.6.22.
Regards,
Hans
>
> ---
>
> drivers/media/video/ivtv/ivtv-driver.c | 16 +---
> drivers/media/video/ivtv/ivtv-fileops.c |2 +-
> drivers/media/video/ivtv/ivtv-fileops.h |1 -
> drivers/media/video/ivtv/ivtv-i2c.c |5 -
> drivers/media/video/ivtv/ivtv-i2c.h |2 --
> drivers/media/video/ivtv/ivtv-streams.c |2 +-
> drivers/media/video/ivtv/ivtv-udma.c|2 ++
> drivers/media/video/ivtv/ivtv-udma.h|2 --
> drivers/media/video/ivtv/ivtv-video.c |2 ++
> drivers/media/video/ivtv/ivtv-video.h |1 -
> drivers/media/video/ivtv/ivtv-yuv.c |1 +
> 11 files changed, 12 insertions(+), 24 deletions(-)
>
> ---
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c.old 2007-
>03-04 21:00:12.0 +0100 +++
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c 2007-03-0
>4 21:04:50.0 +0100 @@ -121,7 +121,7 @@
>
> int ivtv_debug = 0;
>
> -int newi2c = -1;
> +static int newi2c = -1;
>
> module_param_array(tuner, int, _c, 0644);
> module_param_array(radio, bool, _c, 0644);
> @@ -1367,19 +1367,5 @@
> pci_unregister_driver(_pci_driver);
> }
>
> -EXPORT_SYMBOL(ivtv_set_irq_mask);
> -EXPORT_SYMBOL(ivtv_cards_active);
> -EXPORT_SYMBOL(ivtv_cards);
> -EXPORT_SYMBOL(ivtv_api);
> -EXPORT_SYMBOL(ivtv_vapi);
> -EXPORT_SYMBOL(ivtv_vapi_result);
> -EXPORT_SYMBOL(ivtv_clear_irq_mask);
> -EXPORT_SYMBOL(ivtv_debug);
> -EXPORT_SYMBOL(ivtv_reset_ir_gpio);
> -EXPORT_SYMBOL(ivtv_udma_setup);
> -EXPORT_SYMBOL(ivtv_udma_unmap);
> -EXPORT_SYMBOL(ivtv_udma_alloc);
> -EXPORT_SYMBOL(ivtv_udma_prepare);
> -
> module_init(module_start);
> module_exit(module_cleanup);
> ---
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h.old 2007
>-03-04 21:00:35.0 +0100 +++
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h 2007-03-
>04 21:00:41.0 +0100 @@ -30,7 +30,6 @@
> int ivtv_start_capture(struct ivtv_open_id *id);
> void ivtv_stop_capture(struct ivtv_open_id *id, int gop_end);
> int ivtv_start_decoding(struct ivtv_open_id *id, int speed);
> -void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64
> pts); void ivtv_mute(struct ivtv *itv);
> void ivtv_unmute(struct ivtv *itv);
>
> ---
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c.old 2007
>-03-04 21:00:50.0 +0100 +++
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c 2007-03-
>04 21:01:01.0 +0100 @@ -730,7 +730,7 @@
> ivtv_release_stream(s);
> }
>
> -void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64 pts)
> +static void ivtv_stop_decoding(struct ivtv_open_id *id, int flags,
> u64 pts) {
> struct ivtv *itv = id->itv;
> struct ivtv_stream *s = >streams[id->type];
> ---
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h.old 2007-03-
>04 21:01:31.0 +0100 +++
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h 2007-03-04
> 21:02:07.0 +0100 @@ -22,11 +22,9 @@
> int ivtv_saa7115(struct ivtv *itv, unsigned int cmd, void *arg);
> int ivtv_saa7127(struct ivtv *itv, unsigned int cmd, void *arg);
> int ivtv_saa717x(struct ivtv *itv, unsigned int cmd, void *arg);
> -int ivtv_msp34xx(struct ivtv *itv, unsigned int cmd, void *arg);
> int ivtv_upd64031a(struct ivtv *itv, unsigned int cmd, void *arg);
> int ivtv_upd64083(struct ivtv *itv, unsigned int cmd, void *arg);
>
> -int ivtv_i2c_id_addr(struct ivtv *itv, u32 id);
> int ivtv_i2c_hw_addr(struct ivtv *itv, u32 hw);
> int ivtv_i2c_hw(struct ivtv *itv, u32 hw, unsigned int cmd, void
> *arg); int ivtv_i2c_id(struct ivtv *itv, u32 id, unsigned int cmd,
> void *arg); ---
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c.old 2007-03-
>04 21:01:43.0 +0100 +++
> linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 12:42:29AM -0600, Matt Mackall wrote: > On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: > > On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: > > > Recent kernels are having troubles with wireless for me. Two seemingly > > > related problems: > > > > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > > b) Manual iwconfig waits for 60s and then reports: > > > > > > Error for wireless request "Set Encode" (8B2A) : > > > SET failed on device eth1 ; Operation not supported. > > > > Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that > > will keep you from having to change any userspace code. > > No, it's disabled. Will test once I'm done tracking down the iwconfig > problem. From the help text for SYSFS_DEPRECATED: > > If you are using a distro that was released in 2006 or > later, it should be safe to say N here. > > If we need an as-yet-unreleased HAL without it, I would say the above > should be changed to 2008 or so. If Debian actually cuts a release in > the next few months, you might make that 2010. Well, just because Debian has such a slow release cycle, should the rest of the world be forced to follow suit? :) When I originally wrote that, I thought Debian would have already done their release, my mistake... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] hwbkpt: Hardware breakpoints (was Kwatch)
Thanks, Alan. Great work. I have some suggestions for changes.
> I pretty much copied the existing code for handling vm86 mode
> and single-step exceptions, without fully understanding it.
>
> The code doesn't virtualize the BS (single-step) flag in DR6
> for userspace. It could be added, but I wonder whether it is
> really needed.
There is only one TF flag, it and the DR_STEP bit in dr6 are part of the
unitary thread state. You should not be doing anything at all on
single-step exceptions.
> Setting user breakpoints on I/O ports should require permissions
> checking. I haven't tried to figure out how that works or
> how to implement it yet.
I would just leave the I/O breakpoint feature out for the first cut.
See if there is demand for it.
It requires setting CR4.DE, which we don't do. The validation is
relatively simple, comparing against the io_bitmap_ptr data (if any).
You can check at insertion time (requiring doing ioperm before inserting
an I/O breakpoint), and then check again at exception time if the hit
was in kernel mode and ignore it for a user-only breakpoint, or perhaps
check again and eject the breakpoint if it's been cleared from the
ioperm bitmap.
> It seems likely that some of the new routines should be marked
> "__kprobes", but I don't know which, or even what that annotation
> is supposed to mean.
That annotation is for code that is in the kprobes maintenance code path
(where you cannot insert kprobes). do_debug has it for the notify_die
path that might lead to kprobes. The only thing in your code that
should need it is your notifier function, which might get called for an
exception that turns out to be a kprobes single-step. There shouldn't
be any problem inserting kprobes into the other hwbkpt code.
> The parts relating to kernel breakpoints could be made conditional
> on a Kconfig option. The amount of code space saved would be
> relatively small; I'm not sure that it would be worthwhile.
In a utrace merge, the user parts can be made conditional on CONFIG_UTRACE.
Then with both turned off, the code goes away completely. It's unlikely it
will ever be turned off, but it is a clean way to go about things in case
someone wants the smallest possible config for a limited-use installation.
> + void(*installed)(struct hwbkpt *);
> + void(*uninstalled)(struct hwbkpt *);
Save space in the struct by having just one function for both installed
and uninstalled, taking an argument. Probably a caller should be able to
pass a null function here to say that the registration call should fail if
it can't be installed due to higher-priority or no-callback registrations
existing, and that its registration cannot be ejected by another (i.e., an
ill-behaved user).
> + void*data;
Leave this out. Let the caller embed struct hwbkpt in his larger struct
and use container_of.
> +/*
> + * The tsk argument in the following three routines will usually be a
> + * process being PTRACEd by the current task, normally a debugger.
> + * It is also legal for tsk to be the current task. In either case we
> + * can guarantee that tsk will not start running on another CPU while
> + * its breakpoints are being modified. If that happened it could cause
> + * a crash.
> + */
> +int register_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp);
> +void unregister_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp);
> +int modify_user_hwbkpt(struct task_struct *tsk, struct hwbkpt *bp,
> + void *address, u8 len, u8 type);
These are the kinds of constraints utrace is there to make doable.
(I'm assuming that guarantee is really "will not start running in
user mode", since SIGKILL is always possible.) In a utrace merge,
I think we want the only entry points for this to be a utrace-based
interface that explicitly requires utrace's notion of quiescence
(as its accessors for thread register data do).
> +/*
> + * Kernel breakpoints are not associated with any particular thread.
> + */
> +int register_kernel_hwbkpt(struct hwbkpt *bp);
> +void unregister_kernel_hwbkpt(struct hwbkpt *bp);
Potentially kernel users might want per-thread installations, if
it's simple to provide the option. e.g., a probe at some syscall
entry that installs a watchpoint while calling into complex
subsystems, and then removes it before returning.
> @@ -379,15 +381,15 @@ void exit_thread(void)
> tss->io_bitmap_base = INVALID_IO_BITMAP_OFFSET;
> put_cpu();
> }
> + flush_thread_hwbkpt(tsk);
I'd make this do if (unlikely(test_tsk_thread_flag(tsk, TIF_DEBUG))),
or make it an inline doing that test before calling out to the guts.
Most of the time the hwbkpt code need not be on a hot path, and the
exit path will be one.
> +struct thread_hwbkpt { /* HW breakpoint info for a thread */
> +
> + /* utrace support */
> +
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: > On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: > > Recent kernels are having troubles with wireless for me. Two seemingly > > related problems: > > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > b) Manual iwconfig waits for 60s and then reports: > > > > Error for wireless request "Set Encode" (8B2A) : > > SET failed on device eth1 ; Operation not supported. > > Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that > will keep you from having to change any userspace code. No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED: If you are using a distro that was released in 2006 or later, it should be safe to say N here. If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 -mm 1/5] Blackfin: blackfin architecture patch update
On 3/4/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Thursday 01 March 2007 05:14:40 Wu, Bryan wrote:
> Here is the update version of blackfin-arch.patch in -mm tree.
> simply add support to utrace and it was tested on blackfin STAMP board
> as well as other following patches.
Wow, this has come a long way since I looked at the patches last
year, good work!
I've gone through the complete patch again now, and these are the
issues I've found in it. None of these are show-stoppers and I'd
like to see it all go in during the next merge window. There should
be enough time until then to address these points:
> +EXPORT_SYMBOL(__ioremap);
> +EXPORT_SYMBOL(strcmp);
> +EXPORT_SYMBOL(strncmp);
> +EXPORT_SYMBOL(dump_thread);
> +
> +EXPORT_SYMBOL(ip_fast_csum);
> +
> +EXPORT_SYMBOL(kernel_thread);
> +
> +EXPORT_SYMBOL(__up);
> +EXPORT_SYMBOL(__down);
> +EXPORT_SYMBOL(__down_trylock);
> +EXPORT_SYMBOL(__down_interruptible);
> +
> +EXPORT_SYMBOL(is_in_rom);
In general, please put EXPORT_SYMBOL lines below the definition
of the symbol itself. This list of exports should only be used
for symbols that come from assembly files.
What is the right way to export symbol coming from c files?
You should probably also think about whether some of them are
better done as EXPORT_SYMBOL_GPL.
It is probably not. We need code using those symbols, no matter it's
non-GPLd or GPLd.
> + pending = bfin_read_IPEND() & ~0x8000;
> + other_ints = pending & (pending - 1);
> + if (other_ints == 0)
> + lower_to_irq14();
> + irq_exit();
> +
The last line here has trailing whitespace. While this gets automatically
removed by akpm's scripts, you're normally better off not adding it
in the first place, because it may cause your follow-on patches not
to apply, aside from being wrong to start with.
> +void machine_halt(void)
> +{
> + for (;;)
> + /* nothing */ ;
> +}
> +
> +void machine_power_off(void)
> +{
> + for (;;)
> + /* nothing */ ;
> +}
It might be nicer to make this
for (;;)
asm volatile ("idle");
Otherwise you end up burning CPU cycles after a halt without
any particular need.
Good suggestion, thanks.
> +#if defined(CONFIG_MTD_UCLINUX)
> + /* generic memory mapped MTD driver */
> + memory_mtd_end = memory_end;
> +
> + mtd_phys = _ramstart;
> + mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 8)));
> +
> +# if defined(CONFIG_EXT2_FS) || defined(CONFIG_EXT3_FS)
> + if (*((unsigned short *)(mtd_phys + 0x438)) == EXT2_SUPER_MAGIC)
> + mtd_size =
> + PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x404)) << 10);
> +# endif
> +
> +# if defined(CONFIG_CRAMFS)
> + if (*((unsigned long *)(mtd_phys)) == CRAMFS_MAGIC)
> + mtd_size = PAGE_ALIGN(*((unsigned long *)(mtd_phys + 0x4)));
> +# endif
> +
> +# if defined(CONFIG_ROMFS_FS)
> + if (((unsigned long *)mtd_phys)[0] == ROMSB_WORD0
> + && ((unsigned long *)mtd_phys)[1] == ROMSB_WORD1)
> + mtd_size =
> + PAGE_ALIGN(be32_to_cpu(((unsigned long *)mtd_phys)[2]));
This detection seems to me like a strange thing to do in setup_arch().
It should be possible to do this much later, at a point where the system
is much less fragile and e.g. printk works. It could even be moved into
some place in the mtd code itself, since other architectures might want
to do the same thing.
After download the rootfs image from host to the target ram, we need
to move the image to the right place, so we need to know the size of
the image at this time.
> +#if defined(CONFIG_BF561)
> +static struct cpu cpu[2];
> +#else
> +static struct cpu cpu[1];
> +#endif
> +static int __init topology_init(void)
> +{
> +#if defined (CONFIG_BF561)
> + register_cpu([0], 0);
> + register_cpu([1], 1);
> + return 0;
> +#else
> + return register_cpu(cpu, 0);
> +#endif
> +}
I think you should try to avoid the special-case stuff here. You can
have CONFIG_NR_CPUS in Kconfig set dependent on CONFIG_BF561 and change
the code here (and similarly in other places) to
static struct cpu cpu[NR_CPUS];
static int __init topology_init(void)
{
int i;
for (i=0; i< NR_CPUS; i++) {
register_cpu([i], i);
return 0;
}
Good suggestions, thanks.
> + for (i = ZERO_P; i <= L2_MEM; i++) {
> +
> + if (cplb_data[i].valid) {
> +
> + as_1m = cplb_data[i].start % SIZE_1M;
> +
> + /* We need to make sure all sections are properly 1M
aligned
> + * However between Kernel Memory and the Kernel mtd
section, depending
on the
> + * rootfs size, there can be overlapping memory areas.
> + */
> +
> + if (as_1m) {
> +#ifdef CONFIG_MTD_UCLINUX
> + if (i == SDRAM_RAM_MTD) {
> + if ((cplb_data[SDRAM_KERN].end + 1) >
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
We (Sun, AMD, Nvidia and Red Hat) have been testing a patch that seems
to solve the problem. AMD and Nvidia analyzed an HDT trace that
seemed to indicate that CPU updates of the GATT were still in cache
when a subsequent table walk caused by a device load used a stale GATT
PTE. That analysis inspired this patch, submitted to this list as an
RFC. It is not obvious (to me, at least) why this problem has only
shown up on Nvidia SATA controllers.
We are continuing to investigate.
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 030eb37..1dd461a 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -69,6 +69,8 @@ static u32 gart_unmapped_entry;
#define AGPEXTERN
#endif
+#define GATT_CLFLUSH(i) asm volatile ("clflush (%0)" :: "r" (iommu_gatt_base + (i)))
+
/* backdoor interface to AGP driver */
AGPEXTERN int agp_memory_reserved;
AGPEXTERN __u32 *agp_gatt_table;
@@ -221,6 +223,7 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
for (i = 0; i < npages; i++) {
iommu_gatt_base[iommu_page + i] = GPTE_ENCODE(phys_mem);
SET_LEAK(iommu_page + i);
+ GATT_CLFLUSH(iommu_page + i);
phys_mem += PAGE_SIZE;
}
return iommu_bus_base + iommu_page*PAGE_SIZE + (phys_mem & ~PAGE_MASK);
@@ -348,6 +351,7 @@ static int __dma_map_cont(struct scatterlist *sg, int
start, int stopat,
while (pages--) {
iommu_gatt_base[iommu_page] = GPTE_ENCODE(addr);
SET_LEAK(iommu_page);
+ GATT_CLFLUSH(iommu_page);
addr += PAGE_SIZE;
iommu_page++;
}
Andi, have you had a look at this? I'm a bit surprised at the lack of
reaction to this find..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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: 2.6.21-rc1: framebuffer/console boot failure
On Sun, 2007-03-04 at 14:52 +, Andrew Nelless wrote: > On Mon, February 26, 2007 11:09 pm, Antonino A. Daplas wrote: > > > > Not sure if the timer override workaround for nvidia chipsets is the > > culprit, but if you want, you can choose to revert that to the previous > > behavior (which is > > ignoring ACPI timer override). Open > > arch/x86_64/kernel/earlyquirk.c:nvidia_bugs() and change > > this line: > > > > if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) return; into this: > > > > acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check); /* return; */ > > > > > > Tony > > > > This fixes the problem. After a lot of rebooting > and testing the problem is definitely gone when this > check is patched out and the ACPI timer override is > ignored. It looks like there should be a cleaner > patch than just obliterating the condition and return > though. > > Perhaps the code should remain as is and > "acpi_use_timer_override" could be complimented > by exposing the "acpi_skip_timer_override" option to > the kernel command line? acpi_skip_timer_override is still documented in Documentation/kernel-parameters.txt. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] sdhci regression in 2.6.21-rc2
Mark Lord wrote: > Another regression, for Pierre Ossman this time. > > My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles. > Worked fine, without all of the noise, in all previous kernels up to > 2.6.20+. > This looks like a PCI configuration issue. Can you bisect which commit caused the issue? And what's the PCI address of the device? Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.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 00/13] Syslets, "Threadlets", generic AIO support, v3
On 3/4/07, Kyle Moffett <[EMAIL PROTECTED]> wrote: Well, even this far into 2.6, Linus' patch from 2003 still (mostly) applies; the maintenance cost for this kind of code is virtually zilch. If it matters that much to you clean it up and make it apply; add an alarmfd() syscall (another 100 lines of code at most?) and make a "read" return an architecture-independent siginfo-like structure and submit it for inclusion. Adding epoll() support for random objects is as simple as a 75-line object-filesystem and a 25- line syscall to return an FD to a new inode. Have fun! Go wild! Something this trivially simple could probably spend a week in -mm and go to linus for 2.6.22. Or, if you want to do slightly more work and produce something a great deal more useful, you could implement additional netlink address families for additional "event" sources. The socket - setsockopt - bind - sendmsg/recvmsg sequence is a well understood and well documented UNIX paradigm for multiplexing non-blocking I/O to many destinations over one socket. Everyone who has read Stevens is familiar with the basic UDP and "fd open server" techniques, and if you look at Linux's IP_PKTINFO and NETLINK_W1 (bravo, Evgeniy!) you'll see how easily they could be extended to file AIO and other kinds of event sources. For file AIO, you might have the application open one AIO socket per mount point, open files indirectly via the SCM_RIGHTS mechanism, and submit/retire read/write requests via sendmsg/recvmsg with ancillary data consisting of an lseek64 tuple and a user-provided cookie. Although the process still has to have one fd open per actual open file (because trying to authenticate file accesses without opening fds is madness), the only fds it has to manipulate directly are those representing entire pools of outstanding requests. This is usually a small enough set that select() will do just fine, if you're careful with fd allocation. (You can simply punt indirectly opened fds up to a high numerical range, where they can't be accessed directly from userspace but still make fine cookies for use in lseek64 tuples within cmsg headers). The same basic approach will work for timers, signals, and just about any other event source. Userspace is of course still stuck doing its own state machines / thread scheduling / however you choose to think of it. But all the important activity goes through socketcall(), and the data and control parameters are all packaged up into a struct msghdr instead of the bare buffer pointers of read/write. So if someone else does come along later and design an ultralight threading mechanism that isn't a total botch, the actual data paths won't need much rework; the exception handling will just get a lot simpler. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [git patches] libata fixes
Hello,
Paul Rolland wrote:
> Hello,
>
> Applied this on top of 2.6.21-rc1 and your previous patch (see my previous
> mail).
> Still booting, no more the weird error I've reported minutes ago.
>
> pata_jmicron still unable to detect my DVD-RW :
> scsi8 : pata_jmicron
> ata9.00: ATAPI, max UDMA/66
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: limiting speed to UDMA/44
> ata9: failed to recover some devices, retrying in 5 secs
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: limiting speed to PIO0
> ata9: failed to recover some devices, retrying in 5 secs
> ata9.00: qc timeout (cmd 0xef)
> ata9.00: failed to set xfermode (err_mask=0x4)
> ata9.00: disabled
> scsi9 : pata_jmicron
> ATA: abnormal status 0x7F on port 0x00019807
1. Has it ever worked with the previous kernels?
2. If you connect a harddisk to pata_jmicron, does it work?
3. Does applying the attached patch fix your problem?
--
tejun
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 43763c9..8a95a56 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -196,7 +196,8 @@ static int jmicron_init_one (struct pci_dev *pdev, const struct pci_device_id *i
{
static struct ata_port_info info = {
.sht = _sht,
- .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
+ .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
+ ATA_FLAG_SETXFER_POLLING,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
Re: [git patches] libata fixes
[cc'ing Eric D. Mudama. Hi!] Paul Rolland wrote: > ata1.00: exception Emask 0x2 SAct 0xffe0 SErr 0x0 action 0x2 frozen > ata1.00: (spurious completions during NCQ issue=0x0 SAct=0xffe0 > FIS=004040a1:0010) > ata1.00: cmd 60/02:28:52:ec:c4/00:00:0e:00:00/40 tag 5 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:30:54:ec:c4/00:00:0e:00:00/40 tag 6 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:38:56:ec:c4/00:00:0e:00:00/40 tag 7 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:40:58:ec:c4/00:00:0e:00:00/40 tag 8 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:48:5a:ec:c4/00:00:0e:00:00/40 tag 9 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:50:5c:ec:c4/00:00:0e:00:00/40 tag 10 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:58:5e:ec:c4/00:00:0e:00:00/40 tag 11 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:60:60:ec:c4/00:00:0e:00:00/40 tag 12 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:68:62:ec:c4/00:00:0e:00:00/40 tag 13 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:70:64:ec:c4/00:00:0e:00:00/40 tag 14 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1.00: cmd 60/02:78:66:ec:c4/00:00:0e:00:00/40 tag 15 cdb 0x0 data 1024 in > res 40/00:78:66:ec:c4/00:00:0e:00:00/40 Emask 0x2 (HSM violation) > ata1: soft resetting port > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata1.00: configured for UDMA/133 > ata1: EH complete > SCSI device sda: 490234752 512-byte hdwr sectors (251000 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > > This last part was not present when booting stock 2.6.21-rc1 Your drive has some issues with NCQ and is scheduled to be blacklisted such that it isn't enabled. libata used to ignore the condition but now considers it NCQ protocol violation and fails all pending commands. libata EH should turn NCQ off automatically after a few of the above errors. I'd love to see how that actually works in the field (full dmesg please). If it doesn't, it needs fixing. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/13] Syslets, "Threadlets", generic AIO support, v3
Kirk Kuchov wrote: [snip] This is a stupid comparaison. By your logic we should also have /dev/stdin, /dev/stdout and /dev/stderr. Well, as a matter of fact (on my system): # ls -l /dev/std* lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stderr -> fd/2 lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stdin -> fd/0 lrwxrwxrwx 1 root root 4 Feb 1 2006 /dev/stdout -> fd/1 Please don't bother to respond to this mail, I just saw that you apparently needed the info. Magnus P.S.: *PLONK* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: optimize siblings status check logic in wake_idle()
On Mon, Mar 05, 2007 at 05:58:31AM +0100, Nick Piggin wrote: > On Sun, Mar 04, 2007 at 08:13:09PM -0800, Suresh B wrote: > > On a 16 node system, we have seen ~1.25% perf improvement on a database > > workload > > when we completely short circuited wake_idle(). This patch is trying to > > comeup > > with a best compromise to avoid the cache misses and also minimize the > > latenices, > > perf impact. > > Hmm, I wonder what if we only wake_idle if the wakeup comes from this > CPU or a sibling? That's probably going to have downsides in some > workloads as well, though. yep. I thought about it and thought this patch is a decent solution. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: optimize siblings status check logic in wake_idle()
On Sun, Mar 04, 2007 at 08:13:09PM -0800, Suresh B wrote: > On Mon, Mar 05, 2007 at 03:35:34AM +0100, Nick Piggin wrote: > > On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote: > > > When a logical cpu 'x' already has more than one process running, then > > > most likely > > > the siblings of that cpu 'x' must be busy. Otherwise the idle siblings > > > would have likely(in most of the scenarios) picked up the extra load > > > making > > > the load on 'x' atmost one. > > > > Do you have any stats on this? > > Its more of a theory. There will be some conditions that this won't be true > but > IMO those won't be common cases. > > > > Use this logic to eliminate the siblings status check and minimize the > > > cache > > > misses encountered on a heavily loaded system. > > > > Well it does increase the cacheline footprint a bit, but all cachelines > > should be local to our L1 cache, presuming you don't have any CPUs where > > threads have seperate caches. > > These wakeup's can happen across SMP and NUMA domains. In those cases, most > likely > the sibling runqueue lines won't be in the caches. This has nothing to do with > siblings sharing caches or not. Oh that's true. > > > > What sort of numbers do you have? > > On a 16 node system, we have seen ~1.25% perf improvement on a database > workload > when we completely short circuited wake_idle(). This patch is trying to comeup > with a best compromise to avoid the cache misses and also minimize the > latenices, > perf impact. Hmm, I wonder what if we only wake_idle if the wakeup comes from this CPU or a sibling? That's probably going to have downsides in some workloads as well, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/6] 2.6.21-rc2: known regressions
On Sun, Mar 04, 2007 at 11:01:33PM -0500, Mark Lord wrote: > Adrian Bunk wrote: > > > >Subject: Bluetooth RFComm locks up the machine (device_move() related) > >References : http://lkml.org/lkml/2007/3/4/64 > >Submitter : Mark Lord <[EMAIL PROTECTED]> > >Caused-By : Marcel Holtmann <[EMAIL PROTECTED]> > > commit c1a3313698895d8ad4760f98642007bf236af2e8 > >Status : unknown > > A 2-line patch exists for fs/sysfs/dir.c to address this. > Waiting on Greg to apply it or substitute something prettier. ;) I want to see if Marcel agrees with it, as he did the original patch in that area. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: optimize siblings status check logic in wake_idle()
On Mon, Mar 05, 2007 at 03:35:34AM +0100, Nick Piggin wrote: > On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote: > > When a logical cpu 'x' already has more than one process running, then most > > likely > > the siblings of that cpu 'x' must be busy. Otherwise the idle siblings > > would have likely(in most of the scenarios) picked up the extra load making > > the load on 'x' atmost one. > > Do you have any stats on this? Its more of a theory. There will be some conditions that this won't be true but IMO those won't be common cases. > > Use this logic to eliminate the siblings status check and minimize the cache > > misses encountered on a heavily loaded system. > > Well it does increase the cacheline footprint a bit, but all cachelines > should be local to our L1 cache, presuming you don't have any CPUs where > threads have seperate caches. These wakeup's can happen across SMP and NUMA domains. In those cases, most likely the sibling runqueue lines won't be in the caches. This has nothing to do with siblings sharing caches or not. > > What sort of numbers do you have? On a 16 node system, we have seen ~1.25% perf improvement on a database workload when we completely short circuited wake_idle(). This patch is trying to comeup with a best compromise to avoid the cache misses and also minimize the latenices, perf impact. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG} usb regression in 2.6.21-rc2-git3
Mark Lord wrote: Here's another one for Greg: I have a Targus USB 1.1 "dock", basically a hub with built-in serial, parallel, PS/2 KB, PS/2 Mouse, and extra USB ports. Simply connecting, and then disconnecting it causes an oops with 2.6.21-rc2: .. Same behaviour with a second, different USB 1.1 "dock" here as well: Mar 4 23:40:16 silvy kernel: usb 5-8: new high speed USB device using ehci_hcd and address 5 Mar 4 23:40:16 silvy kernel: usb 5-8: configuration #1 chosen from 1 choice Mar 4 23:40:16 silvy kernel: hub 5-8:1.0: USB hub found Mar 4 23:40:16 silvy kernel: hub 5-8:1.0: 4 ports detected Mar 4 23:40:16 silvy kernel: usb 5-8.4: new full speed USB device using ehci_hcd and address 6 Mar 4 23:40:17 silvy kernel: usb 5-8.4: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: hub 5-8.4:1.0: USB hub found Mar 4 23:40:17 silvy kernel: hub 5-8.4:1.0: 4 ports detected Mar 4 23:40:17 silvy kernel: usb 5-8.4.1: new full speed USB device using ehci_hcd and address 7 Mar 4 23:40:17 silvy kernel: usb 5-8.4.1: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: usb 5-8.4.3: new low speed USB device using ehci_hcd and address 8 Mar 4 23:40:17 silvy kernel: usb 5-8.4.3: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.12 as /class/input/input8 Mar 4 23:40:17 silvy kernel: input: USB HID v1.10 Keyboard [Composite USB PS2 Converter USB to PS2 Adaptor v1.12] on usb-:00:1d.7-8.4.3 Mar 4 23:40:17 silvy kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.12 as /class/input/input9 Mar 4 23:40:17 silvy kernel: input: USB HID v1.10 Mouse [Composite USB PS2 Converter USB to PS2 Adaptor v1.12] on usb-:00:1d.7-8.4.3 Mar 4 23:40:17 silvy kernel: usb 5-8.4.4: new full speed USB device using ehci_hcd and address 9 Mar 4 23:40:17 silvy kernel: usb 5-8.4.4: configuration #1 chosen from 1 choice Mar 4 23:40:17 silvy kernel: pl2303 5-8.4.4:1.0: pl2303 converter detected Mar 4 23:40:17 silvy kernel: usb-serial ttyUSB0: Error registering port device, continuing Mar 4 23:40:17 silvy kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 7 if 0 alt 1 proto 2 vid 0x0B39 pid 0x0801 Mar 4 23:40:17 silvy kernel: usbcore: registered new interface driver usblp Mar 4 23:40:17 silvy kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Mar 4 23:41:05 silvy kernel: usb 5-8: USB disconnect, address 5 Mar 4 23:41:05 silvy kernel: usb 5-8.4: USB disconnect, address 6 Mar 4 23:41:05 silvy kernel: usb 5-8.4.1: USB disconnect, address 7 Mar 4 23:41:05 silvy kernel: drivers/usb/class/usblp.c: usblp0: removed Mar 4 23:41:05 silvy kernel: usb 5-8.4.3: USB disconnect, address 8 Mar 4 23:41:05 silvy kernel: usb 5-8.4.4: USB disconnect, address 9 Mar 4 23:41:05 silvy kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000c Mar 4 23:41:05 silvy kernel: printing eip: Mar 4 23:41:05 silvy kernel: c027c251 Mar 4 23:41:05 silvy kernel: *pde = Mar 4 23:41:05 silvy kernel: Oops: [#1] Mar 4 23:41:05 silvy kernel: PREEMPT Mar 4 23:41:05 silvy kernel: Modules linked in: usblp radeon drm nfsd exportfs lockd nfs_acl sunrpc acpi_cpufreq cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_stats freq_table cpufreq_conservative ac fan button thermal video battery container processor rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null af_key af_packet sbp2 usbhid hid pl2303 usbserial mousedev pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore ipw2200 ahci psmouse serio_raw pcspkr ieee80211 ieee80211_crypt sdhci mmc_core snd_page_alloc yenta_socket rsrc_nonstatic firmware_class ohci1394 ieee1394 b44 mii pcmcia_core intel_agp ehci_hcd uhci_hcd usbcore agpgart sg sr_mod cdrom unix Mar 4 23:41:05 silvy kernel: CPU:0 Mar 4 23:41:05 silvy kernel: EIP:0060:[klist_del+6/69]Not tainted VLI Mar 4 23:41:05 silvy kernel: EFLAGS: 00010286 (2.6.21-rc2-git3 #5) Mar 4 23:41:05 silvy kernel: EIP is at klist_del+0x6/0x45 Mar 4 23:41:05 silvy kernel: eax: ebx: f6730a78 ecx: 0001 edx: f63f5248 Mar 4 23:41:05 silvy kernel: esi: f6730a88 edi: f63f5240 ebp: f6706618 esp: f7ba7e00 Mar 4 23:41:05 silvy kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Mar 4 23:41:05 silvy kernel: Process khubd (pid: 1925, ti=f7ba6000 task=f7c275e0 task.ti=f7ba6000) Mar 4 23:41:05 silvy kernel: Stack: f6730a78 0001 c01fb571 f6730a78 0001 f63f5240 c01fb6f2 Mar 4 23:41:05 silvy kernel:f63f5240 f89ffd0e fffe f6c62a40 f63f5240 f63f5240 f63f5274 f89ffc8e Mar 4 23:41:05 silvy kernel:f63f5240 f6706618 c01aafd5 0202 f6730a00 f63f5240 f6730a00 Mar 4 23:41:05 silvy kernel: Call Trace:
Re: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Mon, 5 Mar 2007 03:26:02 +0100
> On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote:
> > From: Adrian Bunk <[EMAIL PROTECTED]>
> > Date: Mon, 5 Mar 2007 02:50:45 +0100
> >
> > > Subject: sparc64 compile error due to GENERIC_ISA_DMA removal
> > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8097
> > > Submitter : Horst H. von Brand <[EMAIL PROTECTED]>
> > > Caused-By : David S. Miller <[EMAIL PROTECTED]>
> > > commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44
> > > Status : unknown
> >
> > Fixed in current GIT.
> >
> > commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10
> > Author: David S. Miller <[EMAIL PROTECTED]>
> > Date: Wed Feb 28 13:09:34 2007 -0800
> >
> > [SPARC64]: Fix parport_pc build.
> >
> > Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
>
> Horst's problem is with the floppy driver and
> claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h .
Here is the fix I will send to Linus for this, thanks:
commit 08414aa2516da65ae7a522c6834b8ea576f38c4b
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sun Mar 4 20:36:18 2007 -0800
[SPARC64]: Fix floppy build failure.
Just define a local {claim,release}_dma_lock() implementation
for the floppy driver to use so we don't need to define and
export to modules the silly dma_spin_lock.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/asm-sparc64/dma.h b/include/asm-sparc64/dma.h
index 1bf4f7a..a9fd061 100644
--- a/include/asm-sparc64/dma.h
+++ b/include/asm-sparc64/dma.h
@@ -15,17 +15,6 @@
#include
#include
-extern spinlock_t dma_spin_lock;
-
-#define claim_dma_lock() \
-({ unsigned long flags; \
- spin_lock_irqsave(_spin_lock, flags); \
- flags; \
-})
-
-#define release_dma_lock(__flags) \
- spin_unlock_irqrestore(_spin_lock, __flags);
-
/* These are irrelevant for Sparc DMA, but we leave it in so that
* things can compile.
*/
diff --git a/include/asm-sparc64/floppy.h b/include/asm-sparc64/floppy.h
index dbe033e..331013a 100644
--- a/include/asm-sparc64/floppy.h
+++ b/include/asm-sparc64/floppy.h
@@ -854,4 +854,15 @@ static unsigned long __init sun_floppy_init(void)
#define EXTRA_FLOPPY_PARAMS
+static DEFINE_SPINLOCK(dma_spin_lock);
+
+#define claim_dma_lock() \
+({ unsigned long flags; \
+ spin_lock_irqsave(_spin_lock, flags); \
+ flags; \
+})
+
+#define release_dma_lock(__flags) \
+ spin_unlock_irqrestore(_spin_lock, __flags);
+
#endif /* !(__ASM_SPARC64_FLOPPY_H) */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][patch] dynamic resizing dentry hash using RCU
On Mon, Mar 05, 2007 at 05:27:24AM +0100, Nick Piggin wrote:
> On Sun, Mar 04, 2007 at 08:11:42PM -0800, David Miller wrote:
> > One minor nit:
> >
> > > +struct dentry_hash {
> > > + unsigned int shift;
> > > + unsigned long mask;
> > > + struct hlist_head *table;
> > > +};
> >
> > I don't see any reason to make 'mask' an unsigned long
> > and this makes this structure take up 8 bytes more than
> > necessary on 64-bit.
>
> You're right, the mask is currently just an int, so my patch should
> not be messing with that. Thanks.
>
> The other thing you'll have to be careful of when looking at doing
> an implementation, is that I think I forgot to use the RCU accessors
> (rcu_assign_pointer, rcu_dereference) when assigning and loading
> the new/old hash table pointers.
Also, now that I think of it, if resize performance is far far less
important than read-side performance, then you should be able to get
away without the additional smp_rmb() that I add to the read-side
in the algorithm I described.
All you have to do is introduce an additional RCU grace period between
assigning the old pointer to the current table, and the current pointer
to the new table. This will still ensure that an (old_table == NULL &&
cur_table == new_table) condition is impossible (that condition would
mean that one of our active tables is invisible to the reader).
This should truely reduce read-side fastpath overhead to just a single,
predictable branch, an extra read_mostly load or two and the rcu_blah()
bits.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][patch] dynamic resizing dentry hash using RCU
From: Nick Piggin <[EMAIL PROTECTED]> Date: Mon, 5 Mar 2007 05:27:24 +0100 > Sounds great, I would be happy to help review it. If we can create a > bit of common infrastructure, the dcache conversion might become a bit > more palatable and we could look at other things like the inode hash > as well. Absolutely, I'll run my patch by you once I have it ready. > The other thing you'll have to be careful of when looking at doing > an implementation, is that I think I forgot to use the RCU accessors > (rcu_assign_pointer, rcu_dereference) when assigning and loading > the new/old hash table pointers. Thanks for the heads-up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] sdhci regression in 2.6.21-rc2
Another regression, for Pierre Ossman this time. My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles. Worked fine, without all of the noise, in all previous kernels up to 2.6.20+. Mar 4 23:28:45 silvy logger: suspending Mar 4 23:29:09 silvy kernel: Stopping tasks ... done. Mar 4 23:29:09 silvy kernel: Suspending console(s) Mar 4 23:29:09 silvy kernel: pl2303 5-1.3:1.0: no suspend for driver pl2303? Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :03:01.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :03:00.0 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1f.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1e.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.7 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.3 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.2 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.1 disabled Mar 4 23:29:09 silvy kernel: ACPI: PCI interrupt for device :00:1d.0 disabled Mar 4 23:29:09 silvy kernel: Intel machine check architecture supported. Mar 4 23:29:09 silvy kernel: Intel machine check reporting enabled on CPU#0. Mar 4 23:29:09 silvy kernel: Back to C! Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:01.0 at offset 7 (was 2000d0d0, writing d0d0) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:01.0 at offset 3 (was 1, writing 10010) Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:01.0 to 64 Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.0 to 64 Mar 4 23:29:09 silvy kernel: usb usb1: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.1 ( -> 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.1[B] -> GSI 17 (level, low) -> IRQ 18 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.1 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.1 at offset f (was 200, writing 20a) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.1 at offset 8 (was 1, writing bf61) Mar 4 23:29:09 silvy kernel: usb usb2: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.2 ( -> 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.2[C] -> GSI 18 (level, low) -> IRQ 19 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.2 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.2 at offset f (was 300, writing 309) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.2 at offset 8 (was 1, writing bf41) Mar 4 23:29:09 silvy kernel: usb usb3: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: PCI: Enabling device :00:1d.3 ( -> 0001) Mar 4 23:29:09 silvy kernel: ACPI: PCI Interrupt :00:1d.3[D] -> GSI 19 (level, low) -> IRQ 17 Mar 4 23:29:09 silvy kernel: PCI: Setting latency timer of device :00:1d.3 to 64 Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.3 at offset f (was 400, writing 407) Mar 4 23:29:09 silvy kernel: PM: Writing back config space on device :00:1d.3 at offset 8 (was 1, writing bf21) Mar 4 23:29:09 silvy kernel: usb usb4: root hub lost power or was reset Mar 4 23:29:09 silvy kernel: mmc0: Got command interrupt even though no command operation was in progress. Mar 4 23:29:09 silvy kernel: sdhci: == REGISTER DUMP == Mar 4 23:29:09 silvy kernel: sdhci: Sys addr: 0x | Version: 0x Mar 4 23:29:09 silvy kernel: sdhci: Blk size: 0x | Blk cnt: 0x Mar 4 23:29:09 silvy kernel: sdhci: Argument: 0x | Trn mode: 0x Mar 4 23:29:09 silvy kernel: sdhci: Present: 0x | Host ctl: 0x00ff Mar 4 23:29:09 silvy kernel: sdhci: Power:0x00ff | Blk gap: 0x00ff Mar 4 23:29:09 silvy kernel: sdhci: Wake-up: 0x00ff | Clock:0x Mar 4 23:29:09 silvy kernel: sdhci: Timeout: 0x00ff | Int stat: 0x Mar 4 23:29:09 silvy kernel: sdhci: Int enab: 0x | Sig enab: 0x Mar 4 23:29:09 silvy kernel: sdhci: AC12 err: 0x | Slot int: 0x Mar 4 23:29:09 silvy kernel: sdhci: Caps: 0x | Max curr: 0x Mar 4 23:29:09 silvy kernel: sdhci: === Mar 4 23:29:09 silvy kernel: mmc0: Card is consuming too much power! Mar 4 23:29:09 silvy kernel: mmc0: Unexpected interrupt 0x0080. Mar 4 23:29:09 silvy kernel: sdhci: == REGISTER DUMP
[BUG} usb regression in 2.6.21-rc2-git3
Adrian Bunk wrote: This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. Here's another one for Greg: I have a Targus USB 1.1 "dock", basically a hub with built-in serial, parallel, PS/2 KB, PS/2 Mouse, and extra USB ports. Simply connecting, and then disconnecting it causes an oops with 2.6.21-rc2: Mar 4 23:29:51 silvy kernel: usb 4-2: new full speed USB device using uhci_hcd and address 2 Mar 4 23:29:51 silvy kernel: usb 4-2: configuration #1 chosen from 1 choice Mar 4 23:29:51 silvy kernel: hub 4-2:1.0: USB hub found Mar 4 23:29:51 silvy kernel: hub 4-2:1.0: 5 ports detected Mar 4 23:29:52 silvy kernel: usb 4-2.3: new full speed USB device using uhci_hcd and address 3 Mar 4 23:29:52 silvy kernel: usb 4-2.3: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: input: MTC PS/2 to USB converter as /class/input/input9 Mar 4 23:29:52 silvy kernel: input: USB HID v1.10 Keyboard [MTC PS/2 to USB converter] on usb-:00:1d.3-2.3 Mar 4 23:29:52 silvy kernel: input: MTC PS/2 to USB converter as /class/input/input10 Mar 4 23:29:52 silvy kernel: input: USB HID v1.10 Mouse [MTC PS/2 to USB converter] on usb-:00:1d.3-2.3 Mar 4 23:29:52 silvy kernel: usb 4-2.5: new full speed USB device using uhci_hcd and address 4 Mar 4 23:29:52 silvy kernel: usb 4-2.5: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: usb 4-2.4: new full speed USB device using uhci_hcd and address 5 Mar 4 23:29:52 silvy kernel: usb 4-2.4: configuration #1 chosen from 1 choice Mar 4 23:29:52 silvy kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4 if 0 alt 1 proto 2 vid 0x0711 pid 0x0300 Mar 4 23:29:52 silvy kernel: usbcore: registered new interface driver usblp Mar 4 23:29:52 silvy kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Mar 4 23:29:52 silvy kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for MCT U232 Mar 4 23:29:52 silvy kernel: mct_u232 4-2.4:1.0: MCT U232 converter detected Mar 4 23:29:52 silvy kernel: usb-serial ttyUSB0: Error registering port device, continuing Mar 4 23:29:52 silvy kernel: usbcore: registered new interface driver mct_u232 Mar 4 23:29:52 silvy kernel: drivers/usb/serial/mct_u232.c: Magic Control Technology USB-RS232 converter driver z2.0 Mar 4 23:29:57 silvy kernel: usb 4-2: USB disconnect, address 2 Mar 4 23:29:57 silvy kernel: usb 4-2.3: USB disconnect, address 3 Mar 4 23:29:57 silvy kernel: usb 4-2.4: USB disconnect, address 5 Mar 4 23:29:57 silvy kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 000c Mar 4 23:29:57 silvy kernel: printing eip: Mar 4 23:29:57 silvy kernel: c027c251 Mar 4 23:29:57 silvy kernel: *pde = Mar 4 23:29:57 silvy kernel: Oops: [#1] Mar 4 23:29:57 silvy kernel: PREEMPT Mar 4 23:29:57 silvy kernel: Modules linked in: mct_u232 usblp radeon drm nfsd exportfs lockd nfs_acl sunrpc acpi_cpufreq cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_stats freq_table cpufreq_conservative ac fan button thermal video battery container processor rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null af_key af_packet sbp2 usbhid hid pl2303 usbserial mousedev snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss pcmcia snd_pcm snd_timer snd ipw2200 soundcore ieee80211 ieee80211_crypt pcspkr psmouse serio_raw b44 ahci ohci1394 ieee1394 snd_page_alloc sdhci mmc_core firmware_class yenta_socket rsrc_nonstatic pcmcia_core mii intel_agp ehci_hcd uhci_hcd usbcore agpgart sg sr_mod cdrom unix Mar 4 23:29:57 silvy kernel: CPU:0 Mar 4 23:29:57 silvy kernel: EIP:0060:[klist_del+6/69]Not tainted VLI Mar 4 23:29:57 silvy kernel: EFLAGS: 00010286 (2.6.21-rc2-git3 #5) Mar 4 23:29:57 silvy kernel: EIP is at klist_del+0x6/0x45 Mar 4 23:29:57 silvy kernel: eax: ebx: f619f278 ecx: 0001 edx: f66873c8 Mar 4 23:29:57 silvy kernel: esi: f619f288 edi: f66873c0 ebp: f619f618 esp: f742fe24 Mar 4 23:29:57 silvy kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Mar 4 23:29:57 silvy kernel: Process khubd (pid: 1970, ti=f742e000 task=f7c20070 task.ti=f742e000) Mar 4 23:29:57 silvy kernel: Stack: f619f278 0001 c01fb571 f619f278 0001 f66873c0 c01fb6f2 Mar 4 23:29:57 silvy kernel:f66873c0 f8a05d0e fffe f6146340 f66873c0 f66873c0 f66873f4 f8a05c8e Mar 4 23:29:57 silvy kernel:f66873c0 f619f618 c01aafd5 0202 f619f200 f66873c0 f619f200 Mar 4 23:29:57 silvy kernel: Call Trace: Mar 4 23:29:57 silvy kernel: [device_del+21/398] device_del+0x15/0x18e Mar 4 23:29:57 silvy kernel: [device_unregister+8/16] device_unregister+0x8/0x10 Mar 4 23:29:57 silvy kernel: [] destroy_serial+0x80/0xcc [usbserial] Mar 4 23:29:57 silvy kernel: []
Re: [IPW3945] Can't load microcode
On 3/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote: ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.0d ipw3945: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt :05:00.0[A] -> GSI 18 (level, low) -> IRQ 22 PCI: Setting latency timer of device :05:00.0 to 64 ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: ipw3945.ucode load failed: Reason -2 ipw3945: Could not read microcode: -2 ipw3945: probe of :05:00.0 failed with error -2 Error -2 is "No such file or directory". Maybe it expects the firmware to be somewhere other than /lib/firmware or your driver and firmware versions don't match. Try adding some debug printk()s around the request_firmware() call in the driver. If you're using out of tree drivers the error should be reported to Intel rather than this list. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][patch] dynamic resizing dentry hash using RCU
On Sun, Mar 04, 2007 at 08:11:42PM -0800, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Fri, 23 Feb 2007 16:37:43 +0100
>
> > So I introduce a new method for resizing hash tables with RCU, and apply
> > that to the dentry hash.
>
> Thanks for doing this work Nick. I'm going to take your ideas
> and apply them to an ipv4 routing cache dynamic growth patch I
> worked on a while ago.
Sounds great, I would be happy to help review it. If we can create a
bit of common infrastructure, the dcache conversion might become a bit
more palatable and we could look at other things like the inode hash
as well.
> One minor nit:
>
> > +struct dentry_hash {
> > + unsigned int shift;
> > + unsigned long mask;
> > + struct hlist_head *table;
> > +};
>
> I don't see any reason to make 'mask' an unsigned long
> and this makes this structure take up 8 bytes more than
> necessary on 64-bit.
You're right, the mask is currently just an int, so my patch should
not be messing with that. Thanks.
The other thing you'll have to be careful of when looking at doing
an implementation, is that I think I forgot to use the RCU accessors
(rcu_assign_pointer, rcu_dereference) when assigning and loading
the new/old hash table pointers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fixes and cleanups for earlyprintk aka boot console.
Gerd Hoffmann writes: > This patch fixes the console selection code to *not* consider a boot > console a full-featured one, so the first non-boot console registering > will become the default console instead. This way the unregister call > for the boot console in the register_console() function actually > triggers and the handover from the boot console to the real console > device works smoothly. Added a printk for the handover, so you know > which console device the output goes to when the boot console stops > printing messages. You have removed functionality that is useful for debugging, that 3 architectures had, namely a way to keep using the early boot console and not replace it with a console that comes later, using a kernel command line option. Perhaps you could provide a way to do that in your patch. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Heads up on sys_fallocate()
On Sun, Mar 04, 2007 at 08:11:17PM +, Anton Altaparmakov wrote: > glibc cannot ever be smart enough because a file system driver will > always know better and be able to do things in a much more optimized > way. Please read the thread again. That is not what anyone proposed. The issues we're discussing is whether fallback for a filesystem that does not support preallocation natively should be done in kernelspace or in userspace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc2-mm1 -- WARNING: "pcmcia_access_configuration_register" [drivers/ssb/ssb.ko] undefined!
WARNING: "pcmcia_access_configuration_register" [drivers/ssb/ssb.ko] undefined! WARNING: "pccard_parse_tuple" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_register_driver" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pccard_get_tuple_data" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_request_configuration" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_request_window" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pccard_get_first_tuple" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_release_window" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_map_mem_page" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_unregister_driver" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! WARNING: "pcmcia_disable_device" [drivers/net/wireless/mac80211/bcm43xx/bcm43xx-mac80211.ko] undefined! make[1]: *** [__modpost] Error 1 # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set CONFIG_BCM43XX_MAC80211=m CONFIG_BCM43XX_MAC80211_PCI=y CONFIG_BCM43XX_MAC80211_PCMCIA=y CONFIG_BCM43XX_MAC80211_DEBUG=y CONFIG_BCM43XX_MAC80211_DMA=y CONFIG_BCM43XX_MAC80211_PIO=y CONFIG_BCM43XX_MAC80211_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_MAC80211_DMA_MODE is not set # CONFIG_BCM43XX_MAC80211_PIO_MODE is not set # CONFIG_RT2X00 is not set # CONFIG_ADM8211 is not set # CONFIG_P54_COMMON is not set # CONFIG_ZD1211RW_MAC80211 is not set # CONFIG_RTL818X is not set # CONFIG_RTL8187 is not set CONFIG_NET_WIRELESS=y CONFIG_MAC80211=m CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUG=y CONFIG_MAC80211_VERBOSE_DEBUG=y CONFIG_MAC80211_LOWTX_FRAME_DUMP=y CONFIG_TKIP_DEBUG=y CONFIG_MAC80211_DEBUG_COUNTERS=y CONFIG_HOSTAPD_WPA_TESTING=y CONFIG_MAC80211_IBSS_DEBUG=y CONFIG_MAC80211_VERBOSE_PS_DEBUG=y # CONFIG_IEEE80211 is not set CONFIG_WIRELESS_EXT=y CONFIG_CFG80211=y CONFIG_CFG80211_WEXT_COMPAT=y CONFIG_NL80211=y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sata_sil problems with recent kernels
Dale Blount wrote: > On Tue, 2007-02-27 at 13:54 -0500, Dale Blount wrote: >> On Fri, 2007-02-23 at 12:00 -0500, Dale Blount wrote: >>> Hi, >>> >>> Excuse me if this has been covered or fixed, I couldn't find anything in >>> the archives. >>> >>> I upgraded from 2.6.11.7 to 2.6.20.1 today and found all the drives >>> connected to 2 brands of sata_sil sata controllers not working. The >>> drives are also (now) of various brands, Maxtor 300GB and 500GB >>> Seagates. > > For the archives, the fix is documented here: > > http://article.gmane.org/gmane.linux.ide/16304 Yeap, that's the correct fix and the problem is introduced in 2.6.20 by using polling IDENTIFY by default. Well, the bug has always been there but no one was issuing polling command to sata_sil upto 2.6.19. This will probably included in the next -stable iteration. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][patch] dynamic resizing dentry hash using RCU
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Fri, 23 Feb 2007 16:37:43 +0100
> So I introduce a new method for resizing hash tables with RCU, and apply
> that to the dentry hash.
Thanks for doing this work Nick. I'm going to take your ideas
and apply them to an ipv4 routing cache dynamic growth patch I
worked on a while ago.
One minor nit:
> +struct dentry_hash {
> + unsigned int shift;
> + unsigned long mask;
> + struct hlist_head *table;
> +};
I don't see any reason to make 'mask' an unsigned long
and this makes this structure take up 8 bytes more than
necessary on 64-bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [PATA] Failed to set xfermode on LITE-ON LTR-48246S
Philipp Matthias Hahn wrote:
> Hello!
>
> As reported by John Williams and others like in
> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
> I too have a problem with 2.6.20.1 using ata_piix not detecting the
> CD-ROM any more. Applying the patch from
> http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
> applying
> http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
> made it work. Here's the relevant extra debugging output:
* Did it work with previous kernels?
* Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
--
tejun
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index dc42ba1..78e6ac5 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -105,8 +105,10 @@ enum {
PIIX_FLAG_AHCI = (1 << 27), /* AHCI possible */
PIIX_FLAG_CHECKINTR = (1 << 28), /* make sure PCI INTx enabled */
- PIIX_PATA_FLAGS = ATA_FLAG_SLAVE_POSS,
- PIIX_SATA_FLAGS = ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR,
+ PIIX_PATA_FLAGS = ATA_FLAG_SLAVE_POSS |
+ ATA_FLAG_SETXFER_POLLING,
+ PIIX_SATA_FLAGS = ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR |
+ ATA_FLAG_SETXFER_POLLING,
/* combined mode. if set, PATA is channel 0.
* if clear, PATA is channel 1.
Re: 2.6.21-rc2-mm1 -- kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
Ah, I see this was already reported. Sorry. My query at marc.theaimsgroup.com didn't find the previous report. I just stumbled onto it while browsing for other information. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [3/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:36AM +0100, Adrian Bunk wrote: > This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 > that are not yet fixed in Linus' tree. > Subject: kernels fail to boot with drives on ATIIXP controller > References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 > Submitter : Michal Jaegermann <[EMAIL PROTECTED]> > Status : unknown Alan added comment to my posting that my problems are caused by messed up IRQ routing on that box I tried. Indeed, I can boot kernel 2.6.20-1.2962.fc7, which really is 2.6.21-rc2, provided I will use 'acpi=off irqpoll'. Anything else and a boot silently dies if 'acpi=off' is skipped or is not finding disk if 'irqpoll' is missing. Somehow 2.6.19 is booting on the same hardware without "valliant efforts"; OTOH 'ahci' driver was not used there. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/6] 2.6.21-rc2: known regressions
Adrian Bunk wrote: Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord <[EMAIL PROTECTED]> Caused-By : Marcel Holtmann <[EMAIL PROTECTED]> commit c1a3313698895d8ad4760f98642007bf236af2e8 Status : unknown A 2-line patch exists for fs/sysfs/dir.c to address this. Waiting on Greg to apply it or substitute something prettier. ;) Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: CK804 SATA Errors (still got them)
On Sunday 04 March 2007 23:25, Robert Hancock wrote: > Alistair John Strachan wrote: > >> Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a > >> (link below) and see what effect that has? > >> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > >>t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a > > > > Obviously, I'll let you know if it happens again, but I've reverted this > > commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on > > an NVIDIA sata controller, and this error hasn't appeared. > > > > So I'm inclined to (very unscientifically) say that this brings it back > > to 2.6.20's level of stability. > > Interesting. Can you try un-reverting that patch, and applying this one? > > The reading of the status register is something that was part of the > original NVidia code, which I'm not really sure why is there. Given that > reading the status register clears the drive's interrupt status, that might > be causing some wierd interaction with the ADMA controller. Also, I added > in a printk for cases where notifiers are triggered but the command doesn't > indicate completion - if you still get problems, let me know if you see > that message. Didn't take long to observe the problem again, so I'm guessing that this isn't it. I was definitely using a kernel compiled with your patch: [EMAIL PROTECTED]:~$ uname -v #1 SMP Sun Mar 4 23:39:56 GMT 2007 I got the following in dmesg: ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:37:77:61/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Your debugging message did not appear in dmesg, however. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [6/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:45AM +0100, Adrian Bunk wrote: > > Subject: usb-serial broken > (ftdi serial device shows up as ttyUSB140 instead of ttyUSB0) > Submitter : Craig Schlenter <[EMAIL PROTECTED]> > Caused-By : Oliver Neukum <[EMAIL PROTECTED]> > commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c > Handled-By : Oliver Neukum <[EMAIL PROTECTED]> > Status : patch available Patch is queued up in my tree and will go to Linus in a few days. But I think there is another usb-serial patch that Oliver needs to send me to fix another problem with the usb-serial core... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/6] 2.6.21-rc2: known regressions
On Mon, Mar 05, 2007 at 02:50:31AM +0100, Adrian Bunk wrote: > Subject: kref refcounting breakage > References : http://lkml.org/lkml/2007/3/2/67 > Submitter : Andrew Morton <[EMAIL PROTECTED]> > Handled-By : Greg KH <[EMAIL PROTECTED]> > Status : unknown I'm working on tracking this down still... > Subject: wireless breakage (ipw2200, iwconfig, NetworkManager) > References : http://lkml.org/lkml/2007/3/4/135 > Submitter : Matt Mackall <[EMAIL PROTECTED]> > Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> (?) > commit 43cb76d91ee85f579a69d42bc8efc08bac560278 (?) > Handled-By : Johannes Berg <[EMAIL PROTECTED]> > Status : unknown I really think this is a CONFIG_SYSFS_DEPRECATED issue (not being set), but want to get Matt confirm either way before saying this is a real issue or not. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] implement __attribute_discard_text/data__ and use it to leave out PM functions if !CONFIG_PM
Hello, all.
This patch is the result from the following discussion.
http://thread.gmane.org/gmane.linux.ide/16475
The problem is that CONFIG_PM affects a lot of low level drivers and
scattering CONFIG_PM all over the place is too ugly. This patch...
* implements __attribute_discard_text__ and __attribute_discard_data__
(not implemented for modules yet, only for built-ins)
* uses them to implement __pm and __pmdata markers
* convert libata midlayer and ahci to use it instead of CONFIG_PM
__attribute_discard_text/data__ puts the marked symbols in separate
sections which are located from VMA 0 and discarded when generating
the final image. It's similar to putting those into /DISCARD/ section
but won't complain even if the discarded symbols are referenced by
active sections. As the discard sections are located from VMA 0,
actually dereferencing such symbols will result in OOPS.
This trick certainly makes LLDs cleaner but there are also some
downsides, so here are the cons.
* Cannot depend on the compiler to detect illegal dereferences to
discarded symbols. We probably can do this using sparse.
* Cannot use the compiler to detect unused but unmarked symbols. This
also probably can be done with sparse.
* EXPORT_SYMBOL() is nullified, so it will take extra bytes for
each symbol marked with __pm. (insignificant)
* Implementation involves modifying kernel image, module build process
and possibly sparse. It might be too expensive to achieve device
driver prettiness, but there are a lot of device drivers out there
and a lot of CONFIG_PM's to be added. Also, discard attributes can
be used for other purposes too.
Any better ideas? Comments?
DO NOT APPLY.
diff --git a/arch/i386/Makefile b/arch/i386/Makefile
index bd28f9f..2806dfe 100644
--- a/arch/i386/Makefile
+++ b/arch/i386/Makefile
@@ -25,7 +25,7 @@ CC := $(CC) -m32
endif
LDFLAGS:= -m elf_i386
-OBJCOPYFLAGS := -O binary -R .note -R .comment -S
+OBJCOPYFLAGS := -O binary -R .note -R .comment -R .discard -S
ifdef CONFIG_RELOCATABLE
LDFLAGS_vmlinux := --emit-relocs
endif
diff --git a/arch/i386/kernel/vmlinux.lds.S b/arch/i386/kernel/vmlinux.lds.S
index ca51610..69b18c6 100644
--- a/arch/i386/kernel/vmlinux.lds.S
+++ b/arch/i386/kernel/vmlinux.lds.S
@@ -32,6 +32,7 @@ PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(7); /* RWE */
note PT_NOTE FLAGS(4); /* R__ */
+ QUIET_DISCARD_PHDR
}
SECTIONS
{
@@ -217,6 +218,8 @@ SECTIONS
}
/* Sections to be discarded */
+ QUIET_DISCARD
+
/DISCARD/ : {
*(.exitcall.exit)
}
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 43cc43d..bfb0135 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -219,12 +219,10 @@ static void ahci_thaw(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
static void ahci_vt8251_error_handler(struct ata_port *ap);
static void ahci_post_internal_cmd(struct ata_queued_cmd *qc);
-#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
static int ahci_port_resume(struct ata_port *ap);
static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
static int ahci_pci_device_resume(struct pci_dev *pdev);
-#endif
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
@@ -243,10 +241,8 @@ static struct scsi_host_template ahci_sht = {
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
-#ifdef CONFIG_PM
.suspend= ata_scsi_device_suspend,
.resume = ata_scsi_device_resume,
-#endif
};
static const struct ata_port_operations ahci_ops = {
@@ -275,10 +271,8 @@ static const struct ata_port_operations ahci_ops = {
.error_handler = ahci_error_handler,
.post_internal_cmd = ahci_post_internal_cmd,
-#ifdef CONFIG_PM
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
-#endif
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -310,10 +304,8 @@ static const struct ata_port_operations ahci_vt8251_ops = {
.error_handler = ahci_vt8251_error_handler,
.post_internal_cmd = ahci_post_internal_cmd,
-#ifdef CONFIG_PM
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
-#endif
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -444,10 +436,8 @@ static struct pci_driver ahci_pci_driver = {
.id_table = ahci_pci_tbl,
.probe = ahci_init_one,
.remove = ata_pci_remove_one,
-#ifdef CONFIG_PM
.suspend= ahci_pci_device_suspend,
Re: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 19:17, Marc Perkel wrote: > >Thanks - because of your suggestion I had found the > >instructions. But you have some interesting options > >set. > > > >-N nicearray -b internal -e 1.0 > > > >Are these important? > > -N? What's in a name? I suppose, it's not so > important. > (Arrays are identified by their UUID anyway. But > maybe > udev can do something with the name someday as it > does > today with /dev/disk/*.) Not worth starting over for. > > -b internal -- seems like a good idea to speed up > resynchronization. I'm trying to figure out what the default is. > > -e 1.0 -- I wonder why the new superblock format > is > not default in mdadm (0.90 is still used). > Looks interesting for big arrays but not sure it's worth starting over for. Trying to get through a 2 hour sync using 4 500gb sata 2 drives. > > >pci=nommconf iommu=soft > > The nvidia chipset corruption problem? > Yep - that's the one. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Raid 10 Problems?
On Mar 4 2007 19:17, Marc Perkel wrote: >Thanks - because of your suggestion I had found the >instructions. But you have some interesting options >set. > >-N nicearray -b internal -e 1.0 > >Are these important? -N? What's in a name? I suppose, it's not so important. (Arrays are identified by their UUID anyway. But maybe udev can do something with the name someday as it does today with /dev/disk/*.) -b internal -- seems like a good idea to speed up resynchronization. -e 1.0 -- I wonder why the new superblock format is not default in mdadm (0.90 is still used). >pci=nommconf iommu=soft The nvidia chipset corruption problem? 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: The performance and behaviour of the anti-fragmentation related patches
On Fri, Mar 02, 2007 at 11:05:15AM -0600, Joel Schopp wrote: > Linus Torvalds wrote: > > > >On Thu, 1 Mar 2007, Andrew Morton wrote: > >>So some urgent questions are: how are we going to do mem hotunplug and > >>per-container RSS? > > The people who were trying to do memory hot-unplug basically all stopped > waiting for these patches, or something similar, to solve the fragmentation > problem. Our last working set of patches built on top of an earlier > version of Mel's list based solution. > > > > >Also: how are we going to do this in virtualized environments? Usually the > >people who care abotu memory hotunplug are exactly the same people who > >also care (or claim to care, or _will_ care) about virtualization. > > Yes, we are. And we are very much in favor of these patches. At last > year's OLS developers from IBM, HP, Xen coauthored a paper titled "Resizing > Memory with Balloons and Hotplug". > http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf Our > conclusion was that ballooning is simply not good enough and we need memory > hot-unplug. Here is a quote from the article I find relevant to today's > discussion: But if you don't require a lot of higher order allocations anyway, then guest fragmentation caused by ballooning doesn't seem like much problem. If you need higher order allocations, then ballooning is bad because of fragmentation, so you need memory unplug, so you need higher order allocations. Goto 1. Balooning probably does skew memory management stats and watermarks, but that's just because it is implemented as a module. A couple of hooks should be enough to allow things to be adjusted? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 15:10, Marc Perkel wrote: > >> On Mar 4 2007 08:25, Marc Perkel wrote: > >> >I'm running the latest OpenVZ kernel 2.6.18. I'm > >> not > >> >sure if this is a factor or not as the problem > >> occurs > >> >without starting any VEs. > >> > > >> >I've never used raid 10 before (stripes on top > of 2 > >> >mirrors) so I don't have anything to compare > this > >> >with. I'm just wondering if I'm doing something > >> wrong. > >> > >> Are you using raid1+0 (3 md devices) or raid10 (1 > >> raid device)? > >> Depending on which, you might want to try the > other. > > > > > >I'm using 3 devices. Can you use just one? If so - > >how? > >How do I create a raid 10 using mdadm? > > mdadm -C /dev/md0 -N nicearray -b internal -e 1.0 -l > 10 -n 4 /dev/sd[abcd]1 > > for example. (See the manpage for details.) > Thanks - because of your suggestion I had found the instructions. But you have some interesting options set. -N nicearray -b internal -e 1.0 Are these important? I can restart the process. I think that I found my original problem. I forgot to use: pci=nommconf iommu=soft We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] GIT 1.5.0.3
The latest maintenance release GIT 1.5.0.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.0.3-1.$arch.rpm (RPM)
GIT v1.5.0.3 Release Notes
==
Fixes since v1.5.0.2
* Bugfixes
- 'git.el' honors the commit coding system from the configuration.
- 'blameview' in contrib/ correctly digs deeper when a line is
clicked.
- 'http-push' correctly makes sure the remote side has leading
path. Earlier it started in the middle of the path, and
incorrectly.
- 'git-merge' did not exit with non-zero status when the
working tree was dirty and cannot fast forward. It does
now.
- 'cvsexportcommit' does not lose yet-to-be-used message file.
- int-vs-size_t typefix when running combined diff on files
over 2GB long.
- 'git apply --whitespace=strip' should not touch unmodified
lines.
- 'git-mailinfo' choke when a logical header line was too long.
- 'git show A..B' did not error out. Negative ref ("not A" in
this example) does not make sense for the purpose of the
command, so now it errors out.
- 'git fmt-merge-msg --file' without file parameter did not
correctly error out.
- 'git archimport' barfed upon encountering a commit without
summary.
- 'git index-pack' did not protect itself from getting a short
read out of pread(2).
- 'git http-push' had a few buffer overruns.
- Build dependency fixes to rebuild fetch.o when other headers
change.
* Documentation updates
- user-manual updates.
- Options to 'git remote add' were described insufficiently.
- Configuration format.suffix was not documented.
- Other formatting and spelling fixes.
Shortlog since v1.5.0.2
---
Alexandre Julliard (1):
git.el: Set the default commit coding system from the repository config.
Aneesh Kumar K.V (1):
blameview: Fix the browse behavior in blameview
Christian Schlotter (1):
Documentation: Correct minor typo in git-add documentation.
Eygene Ryabinkin (2):
http-push.c::lock_remote(): validate all remote refs.
Another memory overrun in http-push.c
Gerrit Pape (2):
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
Fix quoting in update hook template
J. Bruce Fields (6):
Documentation: mention module option to git-cvsimport
user-manual: reset to ORIG_HEAD not HEAD to undo merge
user-manual: ensure generated manual references stylesheet
user-manual: insert earlier of mention content-addressable architecture
user-manual: how to replace commits older than most recent
user-manual: more detailed merge discussion
Jim Meyering (1):
diff --cc: integer overflow given a 2GB-or-larger file
Johannes Schindelin (3):
fetch.o depends on the headers, too.
builtin-archive: use RUN_SETUP
Document the config variable format.suffix
Junio C Hamano (5):
git-apply: do not fix whitespaces on context lines.
Documentation: git-remote add [-t ] [-m ] [-f] name url
Start preparing Release Notes for 1.5.0.3
git-merge: fail correctly when we cannot fast forward.
GIT 1.5.0.3
Linus Torvalds (2):
mailinfo: do not get confused with logical lines that are too long.
git-show: Reject native ref
Matthias Kestenholz (1):
Fix git-gc usage note
Michael Coleman (2):
Fix minor typos/grammar in user-manual.txt
builtin-fmt-merge-msg: fix bugs in --file option
Michael Poole (1):
Correct ordering in git-cvsimport's option documentation
Paolo Bonzini (1):
git-archimport: support empty summaries, put summary on a single line.
Ramsay Allan Jones (5):
Fix a "label defined but unreferenced" warning.
Fix an "implicit function definition" warning.
Fix some "comparison is always true/false" warnings.
Fix a "pointer type missmatch" warning.
Unset NO_C99_FORMAT on Cygwin.
Sergey Vlasov (3):
Documentation/build-docdep.perl: Fix dependencies for included asciidoc
files
Documentation/git-quiltimport.txt: Fix labeled list formatting
Documentation/git-send-email.txt: Fix labeled list formatting
Shawn O. Pearce (1):
index-pack: Loop over pread until data loading is complete.
Theodore Ts'o (1):
Fix git-show man page formatting in the EXAMPLES section
Uwe Kleine-König (1):
Include config.mak in doc/Makefile
Yasushi SHOJI (1):
glossary: Add definitions for dangling and unreachable objects
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
On Sunday 04 March 2007, Zwane Mwaikambo wrote: >On Sun, 4 Mar 2007, Gene Heskett wrote: >> >There will be times when the mainline scheduler feels more >> > interactive than this scheduler, and that is because it has >> > significant unfairness granted towards interactive tasks. This >> > degree of unfairness in an effort to maintain interactivity has been >> > criticised and causes problems in certain environments with both >> > loss of fairness, relative starvation and is not entirely >> > predictable. >> >> Well, in 20 minutes of playing, I am so far VERY impressed, the kmail >> composer is typing to the screen in unison to my keystrokes, where >> with the older version it often went away for 10 or more seconds at a >> time, then displayed the last sentence I had typed in one (or 2 >> sometimes) swell foop. Now I can back up and correct a typo in real >> time whereas before, it was often faster if the typo was half a line >> back, and the key repeat so darned slow it was often over a second per >> character cell moved, to go grab the mouse, position the cursor on the >> typo, click, wait for the indicator to move, and then fix it. Typing >> is now pleasurable again. Key repeats seem to remain at the set in >> the bios key repeat speed. Amazing. I do believe you have given me >> back my machine. > >What are the specs on your hardware? XP-2800 Athlon on a biostar board whose model number I've forgotten. 1 GB of dual channel 400 mhz ram running at 333 because this athlon falls over at 400mhz fsb settings. 480GB of drives in 3 pieces. Running a jaton 3dForce 6200-256 video card with nvidia driver, which does the opengl stuff better than the ati 9200se I took out a week ago, but this nvidia card is several times harder on the cpu when tvtime is running than the ati was. There are other cards in this box, 1394, nic, usb expander, but that is the main list of power burners. Its dmesg clock is just short of 2100. and: Calibrating delay using timer specific routine.. 4177.82 BogoMIPS (lpj=2088910) In comparison to an XP-1400 I had before, this is nowhere near 2x faster. -- 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make arch/i386/kernel/vmi.c:vmi_pmd_clear() static
Adrian Bunk wrote:
This patch makes the needlessly global vmi_pmd_clear() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c.old 2007-03-04
20:32:08.0 +0100
+++ linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c 2007-03-04 20:33:51.0
+0100
@@ -517,7 +517,7 @@
vmi_ops.set_pte(pte, ptep, vmi_flags_addr(mm, addr, VMI_PAGE_PT, 0));
}
-void vmi_pmd_clear(pmd_t *pmd)
+static void vmi_pmd_clear(pmd_t *pmd)
{
const pte_t pte = { 0 };
vmi_check_page_type(__pa(pmd) >> PAGE_SHIFT, VMI_PAGE_PMD);
Acked-by: Zachary Amsden <[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: [-mm patch] remove arch/i386/kernel/tsc.c:custom_sched_clock
Adrian Bunk wrote: On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote: ... Changes since 2.6.20-mm2: ... +vmi-sched-clock-paravirt-op-fix.patch ... 2.6.21 queue ... This patch removes the no longer used custom_sched_clock. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc2-mm1/arch/i386/kernel/tsc.c.old 2007-03-04 19:02:54.0 +0100 +++ linux-2.6.21-rc2-mm1/arch/i386/kernel/tsc.c 2007-03-04 19:03:00.0 +0100 @@ -24,7 +24,6 @@ * an extra value to store the TSC freq */ unsigned int tsc_khz; -unsigned long long (*custom_sched_clock)(void); int tsc_disable; Acked-by: Zachary Amsden <[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: [-mm patch] arch/i386/kernel/vmi.c must #include
Adrian Bunk wrote: On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote: ... Changes since 2.6.20-mm2: ... +vmi-fix-highpte.patch ... 2.6.21 queue ... This patch fixes the following compile error: Includes changed, perhaps? No idea why this broke, but fix looks good. Acked-by: Zachary Amsden <[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: [PATCH] ieee1394: ohci1394: add reg_flush, remove bogus barriers
I wrote:
> @@ -1521,7 +1513,7 @@ static int ohci_iso_recv_start(struct hp
>
> if (sync != -1) {
> /* set sync flag on first DMA descriptor */
> - struct dma_cmd *cmd = >block[recv->block_dma];
> + struct dma_cmd *cmd = >block[recv->block_dma];
> cmd->control |= cpu_to_le32(DMA_CTL_WAIT);
>
> /* match sync field */
Ignore this hunk.
--
Stefan Richter
-=-=-=== --== --=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ieee1394: ohci1394: add reg_flush, remove bogus barriers
Add a utility function to flush MMIO writes.
Remove some mb()s which didn't do anything.
There are still a few wmb()s in ohci1394 which look suspicious.
Shouldn't there be dma_sync_*() calls instead?
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/ohci1394.c | 47 +---
drivers/ieee1394/ohci1394.h | 14 ++
2 files changed, 21 insertions(+), 40 deletions(-)
Index: linux/drivers/ieee1394/ohci1394.h
===
--- linux.orig/drivers/ieee1394/ohci1394.h
+++ linux/drivers/ieee1394/ohci1394.h
@@ -248,17 +248,19 @@ static inline int cross_bound(unsigned l
return 0;
}
-/*
- * Register read and write helper functions.
- */
+/* Register read and write helper functions */
static inline void reg_write(const struct ti_ohci *ohci, int offset, u32 data)
{
-writel(data, ohci->registers + offset);
+ writel(data, ohci->registers + offset);
}
-
static inline u32 reg_read(const struct ti_ohci *ohci, int offset)
{
-return readl(ohci->registers + offset);
+ return readl(ohci->registers + offset);
+}
+/* A dummy read to force all PCI writes to be posted immediately */
+static inline void reg_flush(const struct ti_ohci *ohci)
+{
+ readl(ohci->registers);
}
Index: linux/drivers/ieee1394/ohci1394.c
===
--- linux.orig/drivers/ieee1394/ohci1394.c
+++ linux/drivers/ieee1394/ohci1394.c
@@ -1438,12 +1438,8 @@ static void ohci_iso_recv_change_channel
reg = listen ? OHCI1394_IRMultiChanMaskHiSet :
OHCI1394_IRMultiChanMaskHiClear;
i = channel - 32;
}
-
reg_write(recv->ohci, reg, (1 << i));
-
- /* issue a dummy read to force all PCI writes to be posted immediately
*/
- mb();
- reg_read(recv->ohci, OHCI1394_IsochronousCycleTimer);
+ reg_flush(recv->ohci);
}
static void ohci_iso_recv_set_channel_mask(struct hpsb_iso *iso, u64 mask)
@@ -1464,10 +1460,7 @@ static void ohci_iso_recv_set_channel_ma
reg_write(recv->ohci,
OHCI1394_IRMultiChanMaskHiClear, (1 << (i-32)));
}
}
-
- /* issue a dummy read to force all PCI writes to be posted immediately
*/
- mb();
- reg_read(recv->ohci, OHCI1394_IsochronousCycleTimer);
+ reg_flush(recv->ohci);
}
static int ohci_iso_recv_start(struct hpsb_iso *iso, int cycle, int tag_mask,
int sync)
@@ -1477,7 +1470,6 @@ static int ohci_iso_recv_start(struct hp
u32 command, contextMatch;
reg_write(recv->ohci, recv->ContextControlClear, 0x);
- wmb();
/* always keep ISO headers */
command = (1 << 30);
@@ -1521,7 +1513,7 @@ static int ohci_iso_recv_start(struct hp
if (sync != -1) {
/* set sync flag on first DMA descriptor */
- struct dma_cmd *cmd = >block[recv->block_dma];
+ struct dma_cmd *cmd = >block[recv->block_dma];
cmd->control |= cpu_to_le32(DMA_CTL_WAIT);
/* match sync field */
@@ -1545,11 +1537,6 @@ static int ohci_iso_recv_start(struct hp
/* run */
reg_write(recv->ohci, recv->ContextControlSet, 0x8000);
- /* issue a dummy read of the cycle timer register to force
- all PCI writes to be posted immediately */
- mb();
- reg_read(recv->ohci, OHCI1394_IsochronousCycleTimer);
-
/* check RUN */
if (!(reg_read(recv->ohci, recv->ContextControlSet) & 0x8000)) {
PRINT(KERN_ERR,
@@ -2116,13 +2103,8 @@ static int ohci_iso_xmit_queue(struct hp
wmb();
/* wake DMA in case it is sleeping */
- reg_write(xmit->ohci, xmit->ContextControlSet, 1 << 12);
-
- /* issue a dummy read of the cycle timer to force all PCI
- writes to be posted immediately */
- mb();
- reg_read(xmit->ohci, OHCI1394_IsochronousCycleTimer);
-
+ reg_write(ohci, xmit->ContextControlSet, 1 << 12);
+ reg_flush(ohci);
return 0;
}
@@ -2132,11 +2114,10 @@ static int ohci_iso_xmit_start(struct hp
struct ti_ohci *ohci = xmit->ohci;
/* clear out the control register */
- reg_write(xmit->ohci, xmit->ContextControlClear, 0x);
- wmb();
+ reg_write(ohci, xmit->ContextControlClear, 0x);
/* address and length of first descriptor block (Z=3) */
- reg_write(xmit->ohci, xmit->CommandPtr,
+ reg_write(ohci, xmit->CommandPtr,
dma_prog_region_offset_to_bus(>prog, iso->pkt_dma *
sizeof(struct iso_xmit_cmd)) | 3);
/* cycle match */
@@ -2145,28 +2126,28 @@ static int ohci_iso_xmit_start(struct hp
/* 'cycle' is only mod 8000, but we also need two 'seconds'
bits -
just snarf them from the current time */
- u32 seconds = reg_read(xmit->ohci,
Re: [patch] sched: optimize siblings status check logic in wake_idle()
On Fri, Mar 02, 2007 at 08:23:32PM -0800, Suresh B wrote:
> When a logical cpu 'x' already has more than one process running, then most
> likely
> the siblings of that cpu 'x' must be busy. Otherwise the idle siblings
> would have likely(in most of the scenarios) picked up the extra load making
> the load on 'x' atmost one.
Do you have any stats on this?
> Use this logic to eliminate the siblings status check and minimize the cache
> misses encountered on a heavily loaded system.
Well it does increase the cacheline footprint a bit, but all cachelines
should be local to our L1 cache, presuming you don't have any CPUs where
threads have seperate caches.
What sort of numbers do you have?
>
> Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
> ---
>
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 0dc7572..d1ecc56 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -1368,7 +1368,16 @@ static int wake_idle(int cpu, struct task_struct *p)
> struct sched_domain *sd;
> int i;
>
> - if (idle_cpu(cpu))
> + /*
> + * If it is idle, then it is the best cpu to run this task.
> + *
> + * This cpu is also the best, if it has more than one task already.
> + * Siblings must be also busy(in most cases) as they didn't already
> + * pickup the extra load from this cpu and hence we need not check
> + * sibling runqueue info. This will avoid the checks and cache miss
> + * penalities associated with that.
> + */
> + if (idle_cpu(cpu) || cpu_rq(cpu)->nr_running > 1)
> return cpu;
>
> for_each_domain(cpu, sd) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler
On Sun, 4 Mar 2007, Gene Heskett wrote: > >There will be times when the mainline scheduler feels more interactive > > than this scheduler, and that is because it has significant unfairness > > granted towards interactive tasks. This degree of unfairness in an > > effort to maintain interactivity has been criticised and causes > > problems in certain environments with both loss of fairness, relative > > starvation and is not entirely predictable. > > Well, in 20 minutes of playing, I am so far VERY impressed, the kmail > composer is typing to the screen in unison to my keystrokes, where with > the older version it often went away for 10 or more seconds at a time, > then displayed the last sentence I had typed in one (or 2 sometimes) > swell foop. Now I can back up and correct a typo in real time whereas > before, it was often faster if the typo was half a line back, and the key > repeat so darned slow it was often over a second per character cell > moved, to go grab the mouse, position the cursor on the typo, click, wait > for the indicator to move, and then fix it. Typing is now pleasurable > again. Key repeats seem to remain at the set in the bios key repeat > speed. Amazing. I do believe you have given me back my machine. What are the specs on your hardware? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/6] 2.6.21-rc2: known regressions
On Mon, 5 Mar 2007 02:50:31 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 > that are not yet fixed in Linus' tree. We seem to have broken an unusually large amount of stuff this time. partial post-mortem: - The ACPICA merge landed in -mm super-late: basically it was in mainline a week afterwards and saw only a single -mm release. Part of the reason for this short period in -mm was that ACPICA had its paws all over x86_64 code and conflicted badly with significant changes in the x86_64 tree. That happens sometimes. But when it does, the mess lands in my lap rather than in the laps of the perpetrators. Lesson: keep the code well-factored so that different subsystems don't soil each others' kennels. - The hrtimers/dynticks stuff is simply hard: timekeeping, low-level x86, even APICs. These are areas in which things break a lot, so churning it was inevitably going to cause problems. Lesson: none, I think. Low-level x86 support is just hard, and changing it breaks things. So that accounts for _some_ of the damage, but I wonder if there's more to it than that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Mon, 5 Mar 2007 03:26:02 +0100 > On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote: > > From: Adrian Bunk <[EMAIL PROTECTED]> > > Date: Mon, 5 Mar 2007 02:50:45 +0100 > > > > > Subject: sparc64 compile error due to GENERIC_ISA_DMA removal > > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 > > > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > > > Caused-By : David S. Miller <[EMAIL PROTECTED]> > > > commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 > > > Status : unknown > > > > Fixed in current GIT. > > > > commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 > > Author: David S. Miller <[EMAIL PROTECTED]> > > Date: Wed Feb 28 13:09:34 2007 -0800 > > > > [SPARC64]: Fix parport_pc build. > > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > Horst's problem is with the floppy driver and > claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h . Thanks for the clarification, I was thinking of the parport problem reported by Meelis Roos. I'll look into this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc2-mm1
On Sunday March 4, [EMAIL PROTECTED] wrote: > On Mon, 5 Mar 2007 01:11:33 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > On Fri, 2 Mar 2007 03:00:26 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/ > > > > > > > nfs blocks shutdown and reboot. > > If I try to do 'service nfs stop', the box hangs, no login, no SysRQ-T or P, > > S-U-B works at least. > > > > The bug was added by > knfsd-use-recv_msg-to-get-peer-address-for-nfsd-instead-of-code-copying.patch. Bother... Looks like a need a MSG_DONTWAIT in there, don't I. I'll resend. Thanks, NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [6/6] 2.6.21-rc2: known regressions
On Sun, Mar 04, 2007 at 06:07:25PM -0800, David Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Mon, 5 Mar 2007 02:50:45 +0100 > > > Subject: sparc64 compile error due to GENERIC_ISA_DMA removal > > References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 > > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > > Caused-By : David S. Miller <[EMAIL PROTECTED]> > > commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 > > Status : unknown > > Fixed in current GIT. > > commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 > Author: David S. Miller <[EMAIL PROTECTED]> > Date: Wed Feb 28 13:09:34 2007 -0800 > > [SPARC64]: Fix parport_pc build. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Horst's problem is with the floppy driver and claim_dma_lock/release_dma_lock in include/asm-sparc64/dma.h . cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc2-mm1 -- kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently'
I ran "make oldconfig" and picked various options and then make hit: CC kernel/sched.o kernel/sched.c: In function 'trigger_load_balance': kernel/sched.c:3384: error: 'struct rq' has no member named 'in_nohz_recently' kernel/sched.c:3384: error: 'struct rq' has no member named 'idle_at_tick' kernel/sched.c:3385: error: 'struct rq' has no member named 'in_nohz_recently' kernel/sched.c:3387: error: 'nohz' undeclared (first use in this function) kernel/sched.c:3387: error: (Each undeclared identifier is reported only once kernel/sched.c:3387: error: for each function it appears in.) kernel/sched.c:3404: warning: implicit declaration of function 'resched_cpu' kernel/sched.c:3412: error: 'struct rq' has no member named 'idle_at_tick' kernel/sched.c:3422: error: 'struct rq' has no member named 'idle_at_tick' make[1]: *** [kernel/sched.o] Error 1 # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 8/9] mtd: Allow mtd block device drivers to have a custom ioctl function
To make a modules, we have to export "get_mtd_blktrans_gendisk".
"get_mtd_blktrans_gendisk" is used at mtdswap.
>
> +struct gendisk *get_mtd_blktrans_gendisk(struct
> mtd_blktrans_dev *dev)
> +{
> + return dev->blkcore_priv;
> +}
> +
@@ -469,6 +480,7 @@ EXPORT_SYMBOL_GPL(register_mtd_blktrans);
EXPORT_SYMBOL_GPL(deregister_mtd_blktrans);
EXPORT_SYMBOL_GPL(add_mtd_blktrans_dev);
EXPORT_SYMBOL_GPL(del_mtd_blktrans_dev);
+EXPORT_SYMBOL_GPL(get_mtd_blktrans_gendisk);
MODULE_AUTHOR("David Woodhouse <[EMAIL PROTECTED]>");
MODULE_LICENSE("GPL");
Thank you,
Kyungmin Park
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ext3: dirindex error pointer issues
On Mar 04, 2007 17:18 +0300, Dmitriy Monakhov wrote:
> - ext3_dx_find_entry() exit with out setting proper error pointer
> - do_split() exit with out setting proper error pointer
>it is realy painful because many callers contain folowing code:
>de = do_split(handle,dir, , frame, , );
>if (!(de))
> return retval;
><<< WOW retval wasn't changed by do_split(), so caller failed
><<< but return SUCCESS :)
> - Rearrange do_split() error path. Current error path is realy ugly, all
>this up and down jump stuff doesn't make code easy to understand.
>
> Signed-off-by: Monakhov Dmitriy <[EMAIL PROTECTED]>
> ---
> fs/ext3/namei.c | 26 +++---
> fs/ext4/namei.c | 26 +++---
> 2 files changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
> index 49159f1..1a52586 100644
> --- a/fs/ext3/namei.c
> +++ b/fs/ext3/namei.c
> @@ -969,6 +969,7 @@ static struct buffer_head * ext3_dx_find_entry(struct
> dentry *dentry,
> (block< +((char *)de - bh->b_data))) {
> brelse (bh);
> + *err = ERR_BAD_DX_DIR;
> goto errout;
> }
> *res_dir = de;
I have no objection to this change (by principle of least surprise) but
I don't know if it fixes a real problem. The one caller of this function
treats ERR_BAD_DX_DIR the same as bh == NULL.
> @@ -1134,9 +1135,9 @@ static struct ext3_dir_entry_2 *do_split(handle_t
> *handle, struct inode *dir,
> char *data1 = (*bh)->b_data, *data2;
> unsigned split;
> struct ext3_dir_entry_2 *de = NULL, *de2;
> - int err;
> + int err = 0;
>
> - bh2 = ext3_append (handle, dir, , error);
> + bh2 = ext3_append (handle, dir, , );
Why don't we just remove "err" entirely and use *error to avoid any risk
of setting err and not returning it in error? Also reduces stack usage
that tiny little bit.
In ext3_dx_add_entry() it appears like we should "goto journal_error"
to report an error after the failed call to do_split(), instead of just
"goto cleanup" so that we report an error in the filesystem. Not 100%
sure of this.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Raid 10 Problems?
On Mar 4 2007 15:10, Marc Perkel wrote: >> On Mar 4 2007 08:25, Marc Perkel wrote: >> >I'm running the latest OpenVZ kernel 2.6.18. I'm >> not >> >sure if this is a factor or not as the problem >> occurs >> >without starting any VEs. >> > >> >I've never used raid 10 before (stripes on top of 2 >> >mirrors) so I don't have anything to compare this >> >with. I'm just wondering if I'm doing something >> wrong. >> >> Are you using raid1+0 (3 md devices) or raid10 (1 >> raid device)? >> Depending on which, you might want to try the other. > > >I'm using 3 devices. Can you use just one? If so - >how? >How do I create a raid 10 using mdadm? mdadm -C /dev/md0 -N nicearray -b internal -e 1.0 -l 10 -n 4 /dev/sd[abcd]1 for example. (See the manpage for details.) 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: [6/6] 2.6.21-rc2: known regressions
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Mon, 5 Mar 2007 02:50:45 +0100 > Subject: sparc64 compile error due to GENERIC_ISA_DMA removal > References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > Caused-By : David S. Miller <[EMAIL PROTECTED]> > commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 > Status : unknown Fixed in current GIT. commit 74bd7d093b8e87f35eaf3b14459b96a0e20d1d10 Author: David S. Miller <[EMAIL PROTECTED]> Date: Wed Feb 28 13:09:34 2007 -0800 [SPARC64]: Fix parport_pc build. Signed-off-by: David S. Miller <[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/
Discussing LKML community [OT from the Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3]
> From: "Michael K. Edwards" <[EMAIL PROTECTED]> > Newsgroups: gmane.linux.kernel > Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3 > Date: Wed, 28 Feb 2007 09:01:07 -0800 Michael, [] > In this instance, there didn't seem to be any harm in sending my > thoughts to LKML as I wrote them, on the off chance that Ingo or > Davide would get some value out of them in this design cycle (which > any code I eventually get around to producing will miss). So far, > I've gotten some rather dismissive pushback from Ingo and Alan (who > seem to have no interest outside x86 and less understanding than I > would have thought of what real userspace code looks like), a "why > preach to people who know more than you do" from Davide, this may be sad, unless you've spent time and effort to make a Patch, i.e. read source, understand why it's written so, why it's being used now that way, and why it has to be updated on new cycle of kernel development. > a brief aside on the dominance of x86 from Oleg, I didn't have a chance, and probably i will not have one, to communicate with people like you to learn from your wisdom personally. That's why i've replied to your, after you've mentioned transputers. And i've got rather different opinion, than i expected. That shows my test-tube being, little experience etc. As discussion was about CPUs, it was technical, thus on-topic for LKML. > and one off-list "keep up the good work". Not a very rich harvest from > (IMHO) pretty good seeds. Offlist message was my share of view about things, that were offtopic, and clarifying about lkml thing, and it wasn't on-topic for LKML. I'm pretty sure, that there libraries of books, written on every single bit of things Linux currently *implements* in asm/C. (1) Thus, `return -ENOPATCH', man, regardless what you are saying in lkml. That's why prominent people, you've joined me with (:, replied in go-to-kernelnewbie style. > In short, so far the "Linux kernel community" is upholding its > reputation for insularity, arrogance, coding without prior design, > lack of interest in userspace problems, and inability to learn from > the mistakes of others. (None of these characterizations depends on > there being any real insight in anything I have written.) You, as a person, who have right to be personally wrong, may think that way. But do not forget, as i've wrote you offlist and in (1), this is development community, sometimes development of development one, etc; educated, enthusiastic, wise, Open Source, poor on time (and money :). > Happy hacking, > - Michael And you too. LKML *can* (sometimes may) show how useful this hacking is. > P. S. I do think "threadlets" are brilliant, though, and reading > Ingo's patches gave me a much better idea of what would be involved in > prototyping Asynchronously Executed I/O Unit opcodes. You are discussing on-topic thing in the P.S. And this is IMHO wrong approach. Also, note, that i've changed subject, stripped cc list, please note, that i can be young and naive boy barking up the wrong tree. Kind regards. -- -o--=O`C /. .\ #oo'L O o <___=E M^-- (Wuuf) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] arch/i386/kernel/vmi.c must #include
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-mm2: >... > +vmi-fix-highpte.patch >... > 2.6.21 queue >... This patch fixes the following compile error: <-- snip --> ... CC arch/i386/kernel/vmi.o /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c: In function 'vmi_map_pt_hook': /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: 'KM_PTE0' undeclared (first use in this function) /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: (Each undeclared identifier is reported only once /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: for each function it appears in.) /home/bunk/linux/kernel-2.6/linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c:387: error: 'KM_PTE1' undeclared (first use in this function) make[2]: *** [arch/i386/kernel/vmi.o] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c.old 2007-03-04 16:44:14.0 +0100 +++ linux-2.6.21-rc2-mm1/arch/i386/kernel/vmi.c 2007-03-04 16:44:27.0 +0100 @@ -35,6 +35,7 @@ #include #include #include +#include /* Convenient for calling VMI functions indirectly in the ROM */ typedef u32 __attribute__((regparm(1))) (VROMFUNC)(void); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make fb_deferred_io_mkwrite() static
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm2:
>...
> +fbdev-mm-deferred-io-support.patch
>...
> fbdev updates
>...
This patch makes the needlessly global fb_deferred_io_mkwrite() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-mm1/drivers/video/fb_defio.c.old 2007-03-04
21:55:57.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/video/fb_defio.c 2007-03-04
21:56:07.0 +0100
@@ -48,8 +48,8 @@
}
/* vm_ops->page_mkwrite handler */
-int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
- struct page *page)
+static int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
+ struct page *page)
{
struct fb_info *info = vma->vm_private_data;
struct fb_deferred_io *fbdefio = info->fbdefio;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] remove arch/i386/kernel/tsc.c:custom_sched_clock
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-mm2: >... > +vmi-sched-clock-paravirt-op-fix.patch >... > 2.6.21 queue >... This patch removes the no longer used custom_sched_clock. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc2-mm1/arch/i386/kernel/tsc.c.old 2007-03-04 19:02:54.0 +0100 +++ linux-2.6.21-rc2-mm1/arch/i386/kernel/tsc.c 2007-03-04 19:03:00.0 +0100 @@ -24,7 +24,6 @@ * an extra value to store the TSC freq */ unsigned int tsc_khz; -unsigned long long (*custom_sched_clock)(void); int tsc_disable; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Regression between 2.6.20 and 2.6.21-rc1: NCQ problem with ahci and Hitachi drive
Hello, Mathieu. Mathieu Bérard wrote: > Hello, > I have and laptop with an ICH6M SATA Controller and an Hitachi hard drive. > While it worked well using the ahci module and with NCQ enabled using > Linux 2.6.20, it does not work anymore (hang at boot) with 2.6.21-rc* > > My drive is among those that were recently blacklisted (see lkml post > "[PATCH] libata: > add NCQ blacklist entries from Silicon Image Windowsdriver) > (Model Number: HTS541010G9SA00 and Firmware Revision: MBZOC60D) > This blacklisting patch is in -mm now. > So there is probably a drive related issue here, I'm just wondering why > it just work > flawlessly with a 2.6.20... > > Relevant part of kernel log: > [ 16.044663] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > [ 16.089475] ata1.00: ATA-7: HTS541010G9SA00, MBZOC60D, max UDMA/100 > [ 16.089525] ata1.00: 195371568 sectors, multi 0: LBA48 NCQ (depth 31/32) No, your drive isn't blacklisted yet. NCQ is still being enabled. > [ 16.091804] ata1.00: configured for UDMA/100 > [ 18.151756] SCSI device sda: write cache: enabled, read cache: > enabled, doesn't support DPO or FUA [--snip--] > [ 18.151856] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) > [ 18.151911] sda: Write Protect is off > [ 18.151977] SCSI device sda: write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [] > [ 48.143940] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 > frozen > [ 48.143999] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 > cdb 0x0 data 4096 in > [ 48.144000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) It looks like IRQ isn't getting through. Does giving "acpi=off" kernel parameter make any difference? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Heads up on sys_fallocate()
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote: > > When you do it like this, who can the kernel/filesystem *guarantee* that > when the data is written there actually is room on the harddrive? > > What you described seems like using truncate/ftruncate to increase the > file's size. That is not at all what posix_fallocate is for. > posix_fallocate must make sure that the requested blocks on the disk are > reserved (allocated) for the file's use and that at no point in the > future will, say, a msync() fail because a mmap(MAP_SHARED) page has > been written to. That actually causes an interesting problem for compressing filesystems. The space consumed by blocks depends on their contents and how well it compresses. At the moment, the only option I see to support posix_fallocate for LogFS is to set an inode flag disabling compression, then allocate the blocks. But if the file already contains large amounts of compressed data, I have a problem. Disabling compression for a range within a file is not supported, so I can only return an error. But which one? Jörn -- A surrounded army must be given a way out. -- Sun Tzu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 09/13] fs/unionfs/: Miscellaneous coding style fixes
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/super.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 176cfb6..571b589 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -320,9 +320,8 @@ static int unionfs_show_options(struct seq_file *m, struct
vfsmount *mnt)
seq_printf(m, "%s=%s", path,
perms & MAY_WRITE ? "rw" : "ro");
- if (bindex != bend) {
+ if (bindex != bend)
seq_printf(m, ":");
- }
}
out:
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/13] fs/unionfs/: Use SEEK_{SET,CUR} instead of hardcoded values
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/dirfops.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/dirfops.c b/fs/unionfs/dirfops.c
index 2b77fa9..8f568c7 100644
--- a/fs/unionfs/dirfops.c
+++ b/fs/unionfs/dirfops.c
@@ -135,15 +135,15 @@ static int unionfs_readdir(struct file *file, void
*dirent, filldir_t filldir)
buf.sb = inode->i_sb;
/* Read starting from where we last left off. */
- offset = vfs_llseek(hidden_file, uds->dirpos, 0);
+ offset = vfs_llseek(hidden_file, uds->dirpos, SEEK_SET);
if (offset < 0) {
err = offset;
goto out;
}
err = vfs_readdir(hidden_file, unionfs_filldir, );
- /* Save the position for when we continue. */
- offset = vfs_llseek(hidden_file, 0, 1);
+ /* Save the position for when we continue. */
+ offset = vfs_llseek(hidden_file, 0, SEEK_CUR);
if (offset < 0) {
err = offset;
goto out;
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/13] fs/unionfs/: Fix copyup_deleted_file dentry leak
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 2664be9..aa7c75d 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -41,6 +41,15 @@ static int copyup_deleted_file(struct file *file, struct
dentry *dentry,
sprintf(name, ".unionfs%*.*lx",
i_inosize, i_inosize, hidden_dentry->d_inode->i_ino);
+ /*
+* Loop, looking for an unused temp name to copyup to.
+*
+* It's somewhat silly that we look for a free temp tmp name in the
+* source branch (bstart) instead of the dest branch (bindex), where
+* the final name will be created. We _will_ catch it if somehow
+* the name exists in the dest branch, but it'd be nice to catch it
+* sooner than later.
+*/
tmp_dentry = NULL;
do {
char *suffix = name + nlen - countersize;
@@ -58,7 +67,9 @@ static int copyup_deleted_file(struct file *file, struct
dentry *dentry,
err = PTR_ERR(tmp_dentry);
goto out;
}
+ /* don't dput here because of do-while condition eval order */
} while (tmp_dentry->d_inode != NULL); /* need negative dentry */
+ dput(tmp_dentry);
err = copyup_named_file(dentry->d_parent->d_inode, file, name, bstart,
bindex, file->f_dentry->d_inode->i_size);
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/13] fs/unionfs: Fix a memory leak & null pointer dereference
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 379c525..66d6ce9 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -230,7 +230,7 @@ int unionfs_file_revalidate(struct file *file, int
willwrite)
unionfs_read_lock(sb);
if (!unionfs_d_revalidate(dentry, NULL) && !d_deleted(dentry)) {
err = -ESTALE;
- goto out;
+ goto out_nofree;
}
sbgen = atomic_read(_SB(sb)->generation);
@@ -286,6 +286,9 @@ int unionfs_file_revalidate(struct file *file, int
willwrite)
}
out:
+ if (err)
+ kfree(UNIONFS_F(file)->lower_files);
+out_nofree:
unionfs_unlock_dentry(dentry);
unionfs_read_unlock(dentry->d_sb);
return err;
@@ -391,7 +394,7 @@ int unionfs_open(struct inode *inode, struct file *file)
file->private_data = kzalloc(sizeof(struct unionfs_file_info),
GFP_KERNEL);
if (!UNIONFS_F(file)) {
err = -ENOMEM;
- goto out;
+ goto out_nofree;
}
fbstart(file) = -1;
fbend(file) = -1;
@@ -444,7 +447,7 @@ out:
kfree(UNIONFS_F(file)->lower_files);
kfree(UNIONFS_F(file));
}
-
+out_nofree:
return err;
}
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/13] fs/unionfs/: Fix dentry leak in copyup_named_dentry
From: Erez Zadok <[EMAIL PROTECTED]>
When we chmod a directory on a readonly branch, and have to copy it up, we
forget to dput(). If this was a file, it gets dput indirectly through other
functions we call, but not if it was a directory.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/copyup.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/unionfs/copyup.c b/fs/unionfs/copyup.c
index e0075ca..e24d940 100644
--- a/fs/unionfs/copyup.c
+++ b/fs/unionfs/copyup.c
@@ -352,20 +352,18 @@ static int copyup_named_dentry(struct inode *dir, struct
dentry *dentry,
unionfs_read_lock(sb);
- if ((err = is_robranch_super(sb, new_bindex))) {
- dput(old_hidden_dentry);
+ if ((err = is_robranch_super(sb, new_bindex)))
goto out;
- }
/* Create the directory structure above this dentry. */
new_hidden_dentry = create_parents_named(dir, dentry, name, new_bindex);
if (IS_ERR(new_hidden_dentry)) {
- dput(old_hidden_dentry);
err = PTR_ERR(new_hidden_dentry);
goto out;
}
old_hidden_dentry = unionfs_lower_dentry_idx(dentry, old_bindex);
+ /* we conditionally dput this old_hidden_dentry at end of function */
dget(old_hidden_dentry);
/* For symlinks, we must read the link before we lock the directory. */
@@ -460,6 +458,14 @@ out_unlock:
unlock_dir(new_hidden_parent_dentry);
out_free:
+ /*
+* If old_hidden_dentry was a directory, we need to dput it. If it
+* was a file, then it was already dput indirectly by other
+* functions we call ablve which operate on regular files.
+*/
+ if (old_hidden_dentry && old_hidden_dentry->d_inode &&
+ S_ISDIR(old_hidden_dentry->d_inode->i_mode))
+ dput(old_hidden_dentry);
kfree(symbuf);
out:
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL -mm] Unionfs updates
The following patches (also available though the git tree) address a number
of code cleanliness issues with Unionfs.
You can pull from 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git
to receive the following:
Erez Zadok (6):
fs/unionfs: Fix a memory leak & null pointer dereference
fs/unionfs/: Fix a memory leak in unionfs_read_super
fs/unionfs/: Fix copyup_deleted_file dentry leak
fs/unionfs/: mntput in __cleanup_dentry
fs/unionfs/: Fix dentry leak in copyup_named_dentry
fs/unionfs/: Fix unlocking in error paths
Josef 'Jeff' Sipek (7):
fs/unionfs/: Don't grab dentry private data mutex in unionfs_d_release
fs/unionfs/: Several small cleanups in unionfs_interpose
fs/unionfs/: Rename unionfs_d_revalidate_wrap
fs/unionfs/: Remove alloc_filldir_node
fs/unionfs/: Use SEEK_{SET,CUR} instead of hardcoded values
fs/unionfs/: Check return value of d_path
fs/unionfs/: Miscellaneous coding style fixes
fs/unionfs/commonfops.c | 22 ++
fs/unionfs/copyup.c | 17 +
fs/unionfs/dentry.c | 15 ---
fs/unionfs/dirfops.c|6 +++---
fs/unionfs/lookup.c | 11 +--
fs/unionfs/main.c | 18 ++
fs/unionfs/rdstate.c|8 +---
fs/unionfs/super.c |8 ++--
fs/unionfs/union.h |2 +-
9 files changed, 61 insertions(+), 46 deletions(-)
Josef 'Jeff' Sipek.
[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 11/13] fs/unionfs/: mntput in __cleanup_dentry
From: Erez Zadok <[EMAIL PROTECTED]>
This fixes a mnt refleak which occured during copyup when directory
hierarchy was recreated on a writable branch.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/copyup.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/copyup.c b/fs/unionfs/copyup.c
index 998cc69..e0075ca 100644
--- a/fs/unionfs/copyup.c
+++ b/fs/unionfs/copyup.c
@@ -548,6 +548,9 @@ static void __cleanup_dentry(struct dentry * dentry, int
bindex,
if (!unionfs_lower_dentry_idx(dentry, i)->d_inode) {
dput(unionfs_lower_dentry_idx(dentry, i));
unionfs_set_lower_dentry_idx(dentry, i, NULL);
+
+ mntput(unionfs_lower_mnt_idx(dentry, i));
+ unionfs_set_lower_mnt_idx(dentry, i, NULL);
} else {
if (new_bstart < 0)
new_bstart = i;
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 03/13] fs/unionfs/: Don't grab dentry private data mutex in unionfs_d_release
Grabbing the UNIONFS_D(dentry)->lock is completely unnecessary and there are
no other references; we are about to free the object anyway. Additionally,
grabbing the mutex produces warning when the slab object is reused - as it
was freed while there still was a reference to it.
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/dentry.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 3721409..ac4bf0e 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -190,12 +190,6 @@ static void unionfs_d_release(struct dentry *dentry)
{
int bindex, bstart, bend;
- /* There is no reason to lock the dentry, because we have the only
-* reference, but the printing functions verify that we have a lock
-* on the dentry before calling dbstart, etc.
-*/
- unionfs_lock_dentry(dentry);
-
/* this could be a negative dentry, so check first */
if (!UNIONFS_D(dentry)) {
printk(KERN_DEBUG "dentry without private data: %.*s",
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/13] fs/unionfs/: Check return value of d_path
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/super.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 38443c7..176cfb6 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -311,6 +311,11 @@ static int unionfs_show_options(struct seq_file *m, struct
vfsmount *mnt)
path = d_path(unionfs_lower_dentry_idx(sb->s_root, bindex),
unionfs_lower_mnt_idx(sb->s_root, bindex), tmp_page,
PAGE_SIZE);
+ if (IS_ERR(path)) {
+ ret = PTR_ERR(path);
+ goto out;
+ }
+
perms = branchperms(sb, bindex);
seq_printf(m, "%s=%s", path,
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/13] fs/unionfs/: Remove alloc_filldir_node
alloc_filldir_node was used only once. Additionally, all the arguments
passed to it were ignored wasting stack space for no reason whatsoever.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/rdstate.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/fs/unionfs/rdstate.c b/fs/unionfs/rdstate.c
index e240285..b67a86a 100644
--- a/fs/unionfs/rdstate.c
+++ b/fs/unionfs/rdstate.c
@@ -225,12 +225,6 @@ struct filldir_node *find_filldir_node(struct
unionfs_dir_state *rdstate,
return cursor;
}
-static struct filldir_node *alloc_filldir_node(const char *name, int namelen,
- unsigned int hash, int bindex)
-{
- return kmem_cache_alloc(unionfs_filldir_cachep, GFP_KERNEL);
-}
-
int add_filldir_node(struct unionfs_dir_state *rdstate, const char *name,
int namelen, int bindex, int whiteout)
{
@@ -246,7 +240,7 @@ int add_filldir_node(struct unionfs_dir_state *rdstate,
const char *name,
index = hash % rdstate->size;
head = &(rdstate->list[index]);
- new = alloc_filldir_node(name, namelen, hash, bindex);
+ new = kmem_cache_alloc(unionfs_filldir_cachep, GFP_KERNEL);
if (!new) {
err = -ENOMEM;
goto out;
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/13] fs/unionfs/: Rename unionfs_d_revalidate_wrap
Follow the convention of "foo" calling "__foo".
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c |2 +-
fs/unionfs/dentry.c |9 -
fs/unionfs/union.h |2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 66d6ce9..2664be9 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -228,7 +228,7 @@ int unionfs_file_revalidate(struct file *file, int
willwrite)
unionfs_lock_dentry(dentry);
sb = dentry->d_sb;
unionfs_read_lock(sb);
- if (!unionfs_d_revalidate(dentry, NULL) && !d_deleted(dentry)) {
+ if (!__unionfs_d_revalidate(dentry, NULL) && !d_deleted(dentry)) {
err = -ESTALE;
goto out_nofree;
}
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index ac4bf0e..cae4897 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -21,7 +21,7 @@
/*
* returns 1 if valid, 0 otherwise.
*/
-int unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd)
+int __unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd)
{
int valid = 1; /* default is valid (1); invalid is 0. */
struct dentry *hidden_dentry;
@@ -174,13 +174,12 @@ out:
return valid;
}
-static int unionfs_d_revalidate_wrap(struct dentry *dentry,
-struct nameidata *nd)
+static int unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd)
{
int err;
unionfs_lock_dentry(dentry);
- err = unionfs_d_revalidate(dentry, nd);
+ err = __unionfs_d_revalidate(dentry, nd);
unionfs_unlock_dentry(dentry);
return err;
@@ -226,7 +225,7 @@ out:
}
struct dentry_operations unionfs_dops = {
- .d_revalidate = unionfs_d_revalidate_wrap,
+ .d_revalidate = unionfs_d_revalidate,
.d_release = unionfs_d_release,
};
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 60276c7..bae3c76 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -296,7 +296,7 @@ extern int unionfs_rename(struct inode *old_dir, struct
dentry *old_dentry,
int unionfs_unlink(struct inode *dir, struct dentry *dentry);
int unionfs_rmdir(struct inode *dir, struct dentry *dentry);
-int unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd);
+int __unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd);
/* The values for unionfs_interpose's flag. */
#define INTERPOSE_DEFAULT 0
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/13] fs/unionfs/: Fix a memory leak in unionfs_read_super
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/main.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index ca7ee26..bd64242 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -584,10 +584,11 @@ static int unionfs_read_super(struct super_block *sb,
void *raw_data,
atomic_set(_D(sb->s_root)->generation, 1);
/* call interpose to create the upper level inode */
- if ((err = unionfs_interpose(sb->s_root, sb, 0)))
- goto out_freedpd;
+ err = unionfs_interpose(sb->s_root, sb, 0);
unionfs_unlock_dentry(sb->s_root);
- goto out;
+ if (!err)
+ goto out;
+ /* else fall through */
out_freedpd:
if (UNIONFS_D(sb->s_root)) {
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/13] fs/unionfs/: Several small cleanups in unionfs_interpose
1) No need to lock the inode - lockdep was complaining about potential
circular dependency
2) No need to use temporary variable for iunique() inode number
3) Removed unneeded comment
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/main.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index bd64242..a37916d 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -66,19 +66,14 @@ int unionfs_interpose(struct dentry *dentry, struct
super_block *sb, int flag)
err = -ENOMEM;
goto out;
}
- mutex_lock(>i_mutex);
} else {
- ino_t ino;
/* get unique inode number for unionfs */
- ino = iunique(sb, UNIONFS_ROOT_INO);
-
- inode = iget(sb, ino);
+ inode = iget(sb, iunique(sb, UNIONFS_ROOT_INO));
if (!inode) {
- err = -EACCES; /* should be impossible??? */
+ err = -EACCES;
goto out;
}
- mutex_lock(>i_mutex);
if (atomic_read(>i_count) > 1)
goto skip;
}
@@ -147,8 +142,6 @@ skip:
BUG();
}
- mutex_unlock(>i_mutex);
-
out:
return err;
}
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/13] fs/unionfs/: Fix unlocking in error paths
From: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/lookup.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/lookup.c b/fs/unionfs/lookup.c
index df929e9..967bb5b 100644
--- a/fs/unionfs/lookup.c
+++ b/fs/unionfs/lookup.c
@@ -84,6 +84,7 @@ struct dentry *unionfs_lookup_backend(struct dentry *dentry,
struct nameidata *n
struct vfsmount *first_hidden_mnt = NULL;
int locked_parent = 0;
int locked_child = 0;
+ int allocated_new_info = 0;
int opaque;
char *whname = NULL;
@@ -101,9 +102,11 @@ struct dentry *unionfs_lookup_backend(struct dentry
*dentry, struct nameidata *n
BUG_ON(UNIONFS_D(dentry) != NULL);
locked_child = 1;
}
- if (lookupmode != INTERPOSE_PARTIAL)
+ if (lookupmode != INTERPOSE_PARTIAL) {
if ((err = new_dentry_private_data(dentry)))
goto out;
+ allocated_new_info = 1;
+ }
/* must initialize dentry operations */
dentry->d_op = _dops;
@@ -380,7 +383,7 @@ out:
if (locked_parent)
unionfs_unlock_dentry(parent_dentry);
dput(parent_dentry);
- if (locked_child)
+ if (locked_child || (err && allocated_new_info))
unionfs_unlock_dentry(dentry);
return ERR_PTR(err);
}
@@ -431,6 +434,7 @@ int new_dentry_private_data(struct dentry *dentry)
int newsize;
int oldsize = 0;
struct unionfs_dentry_info *info = UNIONFS_D(dentry);
+ int unlock_on_err = 0;
spin_lock(>d_lock);
if (!info) {
@@ -443,6 +447,7 @@ int new_dentry_private_data(struct dentry *dentry)
mutex_init(>lock);
mutex_lock(>lock);
+ unlock_on_err = 1;
info->lower_paths = NULL;
} else
@@ -482,6 +487,8 @@ int new_dentry_private_data(struct dentry *dentry)
out_free:
kfree(info->lower_paths);
+ if (unlock_on_err)
+ mutex_unlock(>lock);
out:
free_dentry_private_data(info);
--
1.5.0.2.260.g2eb065
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make struct v9fs_cached_file_operations static
This patch makes te needlessly global struct v9fs_cached_file_operations
static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/9p/v9fs_vfs.h |1 -
fs/9p/vfs_file.c |4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.21-rc2-mm1/fs/9p/v9fs_vfs.h.old 2007-03-04 22:02:54.0
+0100
+++ linux-2.6.21-rc2-mm1/fs/9p/v9fs_vfs.h 2007-03-04 22:03:00.0
+0100
@@ -40,7 +40,6 @@
extern struct file_system_type v9fs_fs_type;
extern const struct address_space_operations v9fs_addr_operations;
extern const struct file_operations v9fs_file_operations;
-extern const struct file_operations v9fs_cached_file_operations;
extern const struct file_operations v9fs_dir_operations;
extern struct dentry_operations v9fs_dentry_operations;
extern struct dentry_operations v9fs_cached_dentry_operations;
--- linux-2.6.21-rc2-mm1/fs/9p/vfs_file.c.old 2007-03-04 22:03:07.0
+0100
+++ linux-2.6.21-rc2-mm1/fs/9p/vfs_file.c 2007-03-04 22:03:57.0
+0100
@@ -42,6 +42,8 @@
#include "v9fs_vfs.h"
#include "fid.h"
+static const struct file_operations v9fs_cached_file_operations;
+
/**
* v9fs_file_open - open a file (or directory)
* @inode: inode to be opened
@@ -245,7 +247,7 @@
return total;
}
-const struct file_operations v9fs_cached_file_operations = {
+static const struct file_operations v9fs_cached_file_operations = {
.llseek = generic_file_llseek,
.read = do_sync_read,
.aio_read = generic_file_aio_read,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make drivers/video/display/display-sysfs.c:display_class static
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote: >... > Changes since 2.6.20-mm2: >... > +fbdev-display-class.patch > +fbdev-display-class-update.patch >... > fbdev updates >... This patch makes the needlessly global struct display_class static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc2-mm1/drivers/video/display/display-sysfs.c.old 2007-03-04 21:49:31.0 +0100 +++ linux-2.6.21-rc2-mm1/drivers/video/display/display-sysfs.c 2007-03-04 21:49:38.0 +0100 @@ -127,7 +127,7 @@ static struct mutex allocated_dsp_lock; static DEFINE_IDR(allocated_dsp); -struct class *display_class; +static struct class *display_class; struct display_device *display_device_register(struct display_driver *driver, struct device *parent, void *devdata) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/net/qla3xxx.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc2-mm1/drivers/net/qla3xxx.c.old 2007-03-04
21:41:27.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/net/qla3xxx.c 2007-03-04 21:41:39.0
+0100
@@ -1797,14 +1797,14 @@
atomic_inc(>tx_count);
}
-void ql_get_sbuf(struct ql3_adapter *qdev)
+static void ql_get_sbuf(struct ql3_adapter *qdev)
{
if (++qdev->small_buf_index == NUM_SMALL_BUFFERS)
qdev->small_buf_index = 0;
qdev->small_buf_release_cnt++;
}
-struct ql_rcv_buf_cb *ql_get_lbuf(struct ql3_adapter *qdev)
+static struct ql_rcv_buf_cb *ql_get_lbuf(struct ql3_adapter *qdev)
{
struct ql_rcv_buf_cb *lrg_buf_cb = NULL;
lrg_buf_cb = >lrg_buf[qdev->lrg_buf_index];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Status : unknown Subject: beeps get longer after suspend References : http://lkml.org/lkml/2007/2/26/276 Submitter : Pavel Machek <[EMAIL PROTECTED]> Status : unknown Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> Status : unknown Subject: ThinkPad Z60m: usb mouse stops working after suspend to ram References : http://lkml.org/lkml/2007/2/21/413 http://lkml.org/lkml/2007/2/28/172 Submitter : Arkadiusz Miskiewicz <[EMAIL PROTECTED]> Caused-By : Konstantin Karasyov <[EMAIL PROTECTED]> commit 0a6139027f3986162233adc17285151e78b39cac Handled-By : Konstantin Karasyov <[EMAIL PROTECTED]> Status : problem is being debugged Subject: AE_NOT_FOUND ACPI messages References : http://bugzilla.kernel.org/show_bug.cgi?id=8066 http://lkml.org/lkml/2007/2/27/263 Submitter : Thomas Meyer <[EMAIL PROTECTED]> Meelis Roos <[EMAIL PROTECTED]> Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8066 Status : patch available Subject: Asus M6Ne notebook: ACPI: First battery is not detected References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 Submitter : Janosch Machowinski <[EMAIL PROTECTED]> Status : unknown Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted <[EMAIL PROTECTED]> Status : unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22 patch] the scheduled removal of OBSOLETE_OSS options
This patch contains the scheduled removal of the OBSOLETE_OSS options for 2.6.22. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- sound/oss/Kconfig | 27 --- sound/oss/dmasound/Kconfig | 14 -- 2 files changed, 41 deletions(-) --- linux-2.6.21-rc2-mm1/sound/oss/Kconfig.old 2007-03-05 01:22:21.0 +0100 +++ linux-2.6.21-rc2-mm1/sound/oss/Kconfig 2007-03-05 01:22:36.0 +0100 @@ -5,20 +5,6 @@ # # Prompt user for primary drivers. -config OBSOLETE_OSS - bool "Obsolete OSS drivers" - depends on SOUND_PRIME - help - This option enables support for obsolete OSS drivers that - are scheduled for removal in the near future since there - are ALSA drivers for the same hardware. - - Please contact Adrian Bunk <[EMAIL PROTECTED]> if you had to - say Y here because your soundcard is not properly supported - by ALSA. - - If unsure, say N. - config SOUND_BT878 tristate "BT878 audio dma" depends on SOUND_PRIME && PCI @@ -45,19 +31,6 @@ note that CONFIG_KGDB should not be enabled at the same time, since it also attempts to use this UART port. -config SOUND_ES1371 - tristate "Creative Ensoniq AudioPCI 97 (ES1371)" - depends on SOUND_PRIME && PCI && OBSOLETE_OSS - help - Say Y or M if you have a PCI sound card utilizing the Ensoniq - ES1371 chipset, such as Ensoniq's AudioPCI97. To find out if - your sound card uses an ES1371 without removing your computer's - cover, use lspci -n and look for the PCI ID 1274:1371. Since - Ensoniq was bought by Creative Labs, Sound Blaster 64/PCI - models are either ES1370 or ES1371 based. This driver differs - slightly from OSS/Free, so PLEASE READ - . - config SOUND_ICH tristate "Intel ICH (i8xx) audio support" depends on SOUND_PRIME && PCI --- linux-2.6.21-rc2-mm1/sound/oss/dmasound/Kconfig.old 2007-03-05 01:22:44.0 +0100 +++ linux-2.6.21-rc2-mm1/sound/oss/dmasound/Kconfig 2007-03-05 01:22:56.0 +0100 @@ -12,20 +12,6 @@ want). If you want to compile it as a module, say M here and read . -config DMASOUND_PMAC - tristate "PowerMac DMA sound support" - depends on PPC32 && PPC_PMAC && SOUND && I2C && OBSOLETE_OSS - select DMASOUND - help - If you want to use the internal audio of your PowerMac in Linux, - answer Y to this question. This will provide a Sun-like /dev/audio, - compatible with the Linux/i386 sound system. Otherwise, say N. - - This driver is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you - want). If you want to compile it as a module, say M here and read - . - config DMASOUND_PAULA tristate "Amiga DMA sound support" depends on (AMIGA || APUS) && SOUND - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: kwin dies silently References : http://lkml.org/lkml/2007/2/28/112 Submitter : Sid Boyce <[EMAIL PROTECTED]> Status : unknown Subject: resume: slab error in verify_redzone_free(): cache `size-512': memory outside object was overwritten References : http://lkml.org/lkml/2007/2/24/41 Submitter : Pavel Machek <[EMAIL PROTECTED]> Handled-By : Marcel Holtmann <[EMAIL PROTECTED]> Status : unknown Subject: bluetooth hardlocks References : http://lkml.org/lkml/2007/3/2/85 Submitter : Pavel Machek <[EMAIL PROTECTED]> Status : unknown Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord <[EMAIL PROTECTED]> Caused-By : Marcel Holtmann <[EMAIL PROTECTED]> commit c1a3313698895d8ad4760f98642007bf236af2e8 Status : unknown Subject: kref refcounting breakage References : http://lkml.org/lkml/2007/3/2/67 Submitter : Andrew Morton <[EMAIL PROTECTED]> Handled-By : Greg KH <[EMAIL PROTECTED]> Status : unknown Subject: wireless breakage (ipw2200, iwconfig, NetworkManager) References : http://lkml.org/lkml/2007/3/4/135 Submitter : Matt Mackall <[EMAIL PROTECTED]> Caused-By : Greg Kroah-Hartman <[EMAIL PROTECTED]> (?) commit 43cb76d91ee85f579a69d42bc8efc08bac560278 (?) Handled-By : Johannes Berg <[EMAIL PROTECTED]> Status : unknown Subject: forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins <[EMAIL PROTECTED]> Status : unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make drivers/net/s2io.c:vlan_strip_flag static
This patch makes the needlessly global vlan_strip_flag static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.21-rc2-mm1/drivers/net/s2io.c.old 2007-03-04 21:37:59.0 +0100 +++ linux-2.6.21-rc2-mm1/drivers/net/s2io.c 2007-03-04 21:38:14.0 +0100 @@ -316,7 +316,7 @@ } /* A flag indicating whether 'RX_PA_CFG_STRIP_VLAN_TAG' bit is set or not */ -int vlan_strip_flag; +static int vlan_strip_flag; /* Unregister the vlan */ static void s2io_vlan_rx_kill_vid(struct net_device *dev, unsigned long vid) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/media/video/ivtv/: possible cleanups
On Fri, Mar 02, 2007 at 03:00:26AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm2:
>...
> git-dvb.patch
>...
> git trees
>...
This patch contains the following possible cleanups:
- every file should #include the headers containing the prototypes for
it's global functions
- make the following needlessly global variables static:
- ivtv-driver.c: newi2c
- ivtv-streams.c: struct ivtv_stream_info[]
- make the following needlessly global functions static:
- ivtv-fileops.c: ivtv_stop_decoding()
- ivtv-i2c.c: ivtv_i2c_id_addr()
- #if 0 the following unused global functions:
- ivtv-i2c.c: ivtv_msp34xx()
- ivtv-udma.c: ivtv_udma_setup()
- ivtv-video.c: ivtv_encoder_enable()
- ivtv-driver.c: remove the unused EXPORT_SYMBOL's
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/ivtv/ivtv-driver.c | 16 +---
drivers/media/video/ivtv/ivtv-fileops.c |2 +-
drivers/media/video/ivtv/ivtv-fileops.h |1 -
drivers/media/video/ivtv/ivtv-i2c.c |5 -
drivers/media/video/ivtv/ivtv-i2c.h |2 --
drivers/media/video/ivtv/ivtv-streams.c |2 +-
drivers/media/video/ivtv/ivtv-udma.c|2 ++
drivers/media/video/ivtv/ivtv-udma.h|2 --
drivers/media/video/ivtv/ivtv-video.c |2 ++
drivers/media/video/ivtv/ivtv-video.h |1 -
drivers/media/video/ivtv/ivtv-yuv.c |1 +
11 files changed, 12 insertions(+), 24 deletions(-)
--- linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c.old
2007-03-04 21:00:12.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-driver.c 2007-03-04
21:04:50.0 +0100
@@ -121,7 +121,7 @@
int ivtv_debug = 0;
-int newi2c = -1;
+static int newi2c = -1;
module_param_array(tuner, int, _c, 0644);
module_param_array(radio, bool, _c, 0644);
@@ -1367,19 +1367,5 @@
pci_unregister_driver(_pci_driver);
}
-EXPORT_SYMBOL(ivtv_set_irq_mask);
-EXPORT_SYMBOL(ivtv_cards_active);
-EXPORT_SYMBOL(ivtv_cards);
-EXPORT_SYMBOL(ivtv_api);
-EXPORT_SYMBOL(ivtv_vapi);
-EXPORT_SYMBOL(ivtv_vapi_result);
-EXPORT_SYMBOL(ivtv_clear_irq_mask);
-EXPORT_SYMBOL(ivtv_debug);
-EXPORT_SYMBOL(ivtv_reset_ir_gpio);
-EXPORT_SYMBOL(ivtv_udma_setup);
-EXPORT_SYMBOL(ivtv_udma_unmap);
-EXPORT_SYMBOL(ivtv_udma_alloc);
-EXPORT_SYMBOL(ivtv_udma_prepare);
-
module_init(module_start);
module_exit(module_cleanup);
--- linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h.old
2007-03-04 21:00:35.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.h
2007-03-04 21:00:41.0 +0100
@@ -30,7 +30,6 @@
int ivtv_start_capture(struct ivtv_open_id *id);
void ivtv_stop_capture(struct ivtv_open_id *id, int gop_end);
int ivtv_start_decoding(struct ivtv_open_id *id, int speed);
-void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64 pts);
void ivtv_mute(struct ivtv *itv);
void ivtv_unmute(struct ivtv *itv);
--- linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c.old
2007-03-04 21:00:50.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-fileops.c
2007-03-04 21:01:01.0 +0100
@@ -730,7 +730,7 @@
ivtv_release_stream(s);
}
-void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64 pts)
+static void ivtv_stop_decoding(struct ivtv_open_id *id, int flags, u64 pts)
{
struct ivtv *itv = id->itv;
struct ivtv_stream *s = >streams[id->type];
--- linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h.old
2007-03-04 21:01:31.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.h2007-03-04
21:02:07.0 +0100
@@ -22,11 +22,9 @@
int ivtv_saa7115(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_saa7127(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_saa717x(struct ivtv *itv, unsigned int cmd, void *arg);
-int ivtv_msp34xx(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_upd64031a(struct ivtv *itv, unsigned int cmd, void *arg);
int ivtv_upd64083(struct ivtv *itv, unsigned int cmd, void *arg);
-int ivtv_i2c_id_addr(struct ivtv *itv, u32 id);
int ivtv_i2c_hw_addr(struct ivtv *itv, u32 hw);
int ivtv_i2c_hw(struct ivtv *itv, u32 hw, unsigned int cmd, void *arg);
int ivtv_i2c_id(struct ivtv *itv, u32 id, unsigned int cmd, void *arg);
--- linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c.old
2007-03-04 21:01:43.0 +0100
+++ linux-2.6.21-rc2-mm1/drivers/media/video/ivtv/ivtv-i2c.c2007-03-04
21:27:22.0 +0100
@@ -62,6 +62,7 @@
#include "ivtv-driver.h"
#include "ivtv-cards.h"
#include "ivtv-gpio.h"
+#include "ivtv-i2c.h"
#include
@@ -574,7 +575,7 @@
/* Find the i2c device based on the driver ID and return
its i2c address or -ENODEV if no matching device was found. */
-int ivtv_i2c_id_addr(struct ivtv *itv, u32 id)
+static int ivtv_i2c_id_addr(struct ivtv *itv, u32 id)
{
struct i2c_client *client;
int retval = -ENODEV;
@@ -681,10 +682,12
[6/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: sparc64 compile error due to GENERIC_ISA_DMA removal References : http://bugzilla.kernel.org/show_bug.cgi?id=8097 Submitter : Horst H. von Brand <[EMAIL PROTECTED]> Caused-By : David S. Miller <[EMAIL PROTECTED]> commit 1b51d3a08b6c80a1e47d4c579c41abbe56cd3c44 Status : unknown Subject: mmc reader no longer works References : http://lkml.org/lkml/2007/2/27/91 Submitter : Pavel Machek <[EMAIL PROTECTED]> Caused-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: usb-serial broken (ftdi serial device shows up as ttyUSB140 instead of ttyUSB0) Submitter : Craig Schlenter <[EMAIL PROTECTED]> Caused-By : Oliver Neukum <[EMAIL PROTECTED]> commit 34ef50e5b1f96c2d8c0f3d28b7d407743806256c Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : patch available Subject: Oops in rtc_cmos References : http://lkml.org/lkml/2007/3/4/112 http://lkml.org/lkml/2007/2/18/172 Submitter : Paul Rolland <[EMAIL PROTECTED]> Rafael J. Wysocki <[EMAIL PROTECTED]> Caused-By : David Brownell <[EMAIL PROTECTED]> commit 7be2c7c96aff2871240d61fef508c41176c688b5 Patch : http://lkml.org/lkml/2007/2/23/184 Status : patch available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3/6] 2.6.21-rc2: known regressions
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: NCQ problem with ahci and Hitachi drive References : http://lkml.org/lkml/2007/3/4/178 Submitter : Mathieu Bérard <[EMAIL PROTECTED]> Status : unknown Subject: kernels fail to boot with drives on ATIIXP controller References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621 Submitter : Michal Jaegermann <[EMAIL PROTECTED]> Status : unknown Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html Submitter : Fabio Comolli <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Status : problem is being discussed Subject: SATA_ACPI errors during kernel boot References : http://bugzilla.kernel.org/show_bug.cgi?id=8080 http://bugzilla.kernel.org/show_bug.cgi?id=8046 http://bugzilla.kernel.org/show_bug.cgi?id=8095 http://lkml.org/lkml/2007/2/22/159 Submitter : Janosch Machowinski <[EMAIL PROTECTED]> Lukas Hejtmanek <[EMAIL PROTECTED]> Meelis Roos <[EMAIL PROTECTED]> Olivier Mondoloni <[EMAIL PROTECTED]> Handled-By : Thomas Renninger <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Robert Moore <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
