Re: 2.6.22-rc3-mm1
"Michael Ellerman" <[EMAIL PROTECTED]> writes: > On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote: >> > ... >> +msi-fix-the-ordering-of-msix-irqs.patch >> +msi-mask-the-msix-vector-before-we-unmap-it.patch > ... >> 2.6.22 probable-queue > > I think these two should be in the 2.6.22 definite-queue, unless Eric > disagrees. They are simple bug fixes for regression in 2.6.22 so I don't see a reason to delay them. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sparsemem: Shut up unused symbol compiler warnings.
> On Fri, Jun 01, 2007 at 02:26:17PM +0900, Yasunori Goto wrote: > > I think this issue is fixed by > > move-three-functions-that-are-only-needed-for.patch in current -mm tree. > > Is it not enough? > > > That's possible, I hadn't checked -mm. This was simply against current > git. If there's already a fix in -mm, then this can simply be ignored. Okay. Thanks for your report. -- Yasunori Goto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
On Fri, 1 Jun 2007, Tejun Heo wrote: but one thing we should bear in mind is that harddisks don't have humongous caches or very smart controller / instruction set. No matter how relaxed interface the block layer provides, in the end, it just has to issue whole-sale FLUSH CACHE on the device to guarantee data ordering on the media. if you are talking about individual drives you may be right for the moment (but 16M cache on drives is a _lot_ larger then people imagined would be there a few years ago) but when you consider the self-contained disk arrays it's an entirely different story. you can easily have a few gig of cache and a complete OS pretending to be a single drive as far as you are concerned. and the price of such devices is plummeting (in large part thanks to Linux moving into this space), you can now readily buy a 10TB array for $10k that looks like a single drive. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sendfile removal
Jens Axboe wrote: >>> >> I would personally argue that sendfile() blocking on an O_NONBLOCK >> desriptor, as opposed to returning EAGAIN, is a bug, and a fairly >> serious such. > > I agree, but it's still a change in behaviour. Even if we consider the > app buggy (it is), can we potentially break it? > It depends on which app it is, of course. However, I think we have to smoke that out the hard way. I don't think we should retain a bug in the kernel just because some unknown app might depend on that bug -- taking that to the extreme we could never fix bugs at all... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sendfile removal (nfsd update)
On Fri, Jun 01 2007, Neil Brown wrote: > > Ok, here is a patch that makes nfsd use splice instead of sendfile. > It appears to both compile and work. > > Some observations: > - __splice_from_pipe wants a "struct file*" and I wanted to pass a > "struct svcrqst *". Maybe it should take a void * ? > - It also wants a *ppos which I had no use for.. It that really > need? Cannot >f_pos be used? See: http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=c73a9509ef7877d31e0c97c684ee8b7ed13ecbbe;hp=07f0e716250d4a3a550b2f39bd0a7e4e6566b3c2 I'll rebase the conversion on top of this one, loop will need the same change. > - I copied do_splice_to from splice.c as it wasn't exported, and > then found I couldn't compile because rw_verify_area wasn't > exported. As nfsd doesn't need that (we never export > mandatory-locking files) I just remove it and some other cruft > that I didn't need Not sure if that was the best approach. > - I needed to export alloc_pipe_info. Maybe there should be a > get_current_pipe instead which does the alloc if needed. > - I would much rather have something like free_pipe_info exported > than open code it in do_splice_read (which is based heavily on > do_splice_direct). I need the same thing for loop. I think I'll add do_splice_foo() to fs/splice.c in a way that loop can use instead of do_splice_direct(), then nfsd should be able to do the same. Thanks for this Neil! -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sendfile removal
On Thu, May 31 2007, H. Peter Anvin wrote: > Jens Axboe wrote: > >> > >>> - retval = in_file->f_op->sendfile(in_file, ppos, count, file_send_actor, > >>> out_file); > >>> + fl = 0; > >>> + if (in_file->f_flags & O_NONBLOCK) > >>> + fl = SPLICE_F_NONBLOCK; > >>> + > >>> + retval = do_splice_direct(in_file, ppos, out_file, count, fl); > >> I like this, but are you sure it wont break user land ? > >> > >> Some applications might react badly if sendfile() returns EAGAIN ? > > > > Yeah, I didn't actually intend for that to sneak in. I'd think that > > userspace should handle it if they opened the file O_NONBLOCK (or used > > fcntl()), but it's a change in behaviour none the less and probably not > > a good idea. > > > > I would personally argue that sendfile() blocking on an O_NONBLOCK > desriptor, as opposed to returning EAGAIN, is a bug, and a fairly > serious such. I agree, but it's still a change in behaviour. Even if we consider the app buggy (it is), can we potentially break it? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sparsemem: Shut up unused symbol compiler warnings.
On Fri, Jun 01, 2007 at 02:26:17PM +0900, Yasunori Goto wrote: > I think this issue is fixed by > move-three-functions-that-are-only-needed-for.patch in current -mm tree. > Is it not enough? > That's possible, I hadn't checked -mm. This was simply against current git. If there's already a fix in -mm, then this can simply be ignored. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] document Acked-by:
On Thu, 31 May 2007 19:09:10 PDT, [EMAIL PROTECTED] said: > +If a person was not directly involved in the preparation or handling of a > +patch but wishes to signify and record their approval of it then they can > +arrange to have an Acked-by: line added to the patch's changelog. > + > +Acked-by: is often used by the maintainer of the affected code when that > +maintainer neither wrote, merged nor forwarded the patch themselves. Do we want to add verbiage saying that an Acked-By: is also useful when it comes from somebody (likely the original reporter) who has actually tested the patch? pgpUdMcDDUvOr.pgp Description: PGP signature
Re: [PATCH] sparsemem: Shut up unused symbol compiler warnings.
I think this issue is fixed by
move-three-functions-that-are-only-needed-for.patch in current -mm tree.
Is it not enough?
Thanks.
> __kmalloc_section_memmap()/__kfree_section_memmap() and friends are only
> used by the memory hotplug code. Move these in to the existing
> CONFIG_MEMORY_HOTPLUG block.
>
> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
>
> --
>
> mm/sparse.c | 42 +-
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 1302f83..35f739a 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -229,6 +229,7 @@ static struct page __init
> *sparse_early_mem_map_alloc(unsigned long pnum)
> return NULL;
> }
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> static struct page *__kmalloc_section_memmap(unsigned long nr_pages)
> {
> struct page *page, *ret;
> @@ -269,27 +270,6 @@ static void __kfree_section_memmap(struct page *memmap,
> unsigned long nr_pages)
> }
>
> /*
> - * Allocate the accumulated non-linear sections, allocate a mem_map
> - * for each and record the physical to section mapping.
> - */
> -void __init sparse_init(void)
> -{
> - unsigned long pnum;
> - struct page *map;
> -
> - for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> - if (!valid_section_nr(pnum))
> - continue;
> -
> - map = sparse_early_mem_map_alloc(pnum);
> - if (!map)
> - continue;
> - sparse_init_one_section(__nr_to_section(pnum), pnum, map);
> - }
> -}
> -
> -#ifdef CONFIG_MEMORY_HOTPLUG
> -/*
> * returns the number of sections whose mem_maps were properly
> * set. If this is <=0, then that means that the passed-in
> * map was not consumed and must be freed.
> @@ -329,3 +309,23 @@ out:
> return ret;
> }
> #endif
> +
> +/*
> + * Allocate the accumulated non-linear sections, allocate a mem_map
> + * for each and record the physical to section mapping.
> + */
> +void __init sparse_init(void)
> +{
> + unsigned long pnum;
> + struct page *map;
> +
> + for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> + if (!valid_section_nr(pnum))
> + continue;
> +
> + map = sparse_early_mem_map_alloc(pnum);
> + if (!map)
> + continue;
> + sparse_init_one_section(__nr_to_section(pnum), pnum, map);
> + }
> +}
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [EMAIL PROTECTED] For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"[EMAIL PROTECTED]"> [EMAIL PROTECTED]
--
Yasunori Goto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Make prepare_namespace() wait for devices
Andrew Morton wrote:
> On Thu, 31 May 2007 13:20:48 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> What was the verdict here? Were you satisfied with this or do you need a
>> change?
>>
>
>
> I was kinda hoing to see version #2 with that funny loop cleaned up a bit?
>
>
New patch with the layout you suggested. It may be fewer lines, but I
still say my version was more readable.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 6354cb955ce1602b7b259f525edac7c8f585574b
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the
background, causing a race between them and prepare_namespace().
In order to be able to use these buses without an initrd, we now
wait for the device specified in root= to actually show up.
If the device never shows up than we will hang in an infinite loop.
In order to not mess with setups that reboot on panic, the feature
must be turned on via the command line option "rootwait".
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 46fe407..4e5ef6a 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -25,6 +25,7 @@ int __initdata rd_doload; /* 1 = load RAM disk, 0 = don't load */
int root_mountflags = MS_RDONLY | MS_SILENT;
char * __initdata root_device_name;
static char __initdata saved_root_name[64];
+int __initdata root_wait;
dev_t ROOT_DEV;
@@ -216,6 +217,14 @@ static int __init root_dev_setup(char *line)
__setup("root=", root_dev_setup);
+static int __init rootwait_setup(char *line)
+{
+ root_wait = simple_strtol(line,NULL,0);
+ return 1;
+}
+
+__setup("rootwait=", rootwait_setup);
+
static char * __initdata root_mount_data;
static int __init root_data_setup(char *str)
{
@@ -438,11 +447,20 @@ void __init prepare_namespace(void)
root_device_name += 5;
}
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
-
if (initrd_load())
goto out;
+ /* wait for any asynchronous scanning to complete */
+ if ((ROOT_DEV == 0) && root_wait) {
+ printk(KERN_INFO "Waiting for root device %s...\n",
+ saved_root_name);
+ while (driver_probe_done() != 0 ||
+ (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
+ msleep(100);
+ }
+
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage
On Fri, Jun 01, 2007 at 03:53:49AM +0200, Nick Piggin wrote:
> On Thu, May 31, 2007 at 06:45:17PM -0700, Mark Fasheh wrote:
> > On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote:
> > > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock
> > > > the
> > > > page, so long as it's returned in a locked state? Though, do we even
> > > > need
> > > > the page lock that early? It seemed to me that you were adding it for
> > > > consistency reasons (I could be wrong though).
> > >
> > > You could do that, but you'd have to probably check that it is
> > > within i_size after you relock it, I think... yeah, that might
> > > be the best thing for ocfs to do for now.
Ok. So how about the attached patch? It's a bit different than discussed,
but I think it's much cleaner because it preserves the current behavior of
the callback and keeps that bit of page locking inside core code. Not tested
as of yet, but I can run it tommorrow.
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
[EMAIL PROTECTED]
From: Mark Fasheh <[EMAIL PROTECTED]>
[PATCH] Release page lock before calling ->page_mkwrite
__do_fault() was calling ->page_mkwrite() with the page lock held, which
violates the locking rules for that callback. Release and retake the page
lock around the callback to avoid deadlocking file systems which manually
take it.
Signed-off-by: Mark Fasheh <[EMAIL PROTECTED]>
---
mm/memory.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 7221618..491cc27 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2378,11 +2378,14 @@ static int __do_fault(struct mm_struct *
* address space wants to know that the page is about
* to become writable
*/
- if (vma->vm_ops->page_mkwrite &&
- vma->vm_ops->page_mkwrite(vma, page) < 0) {
- fdata.type = VM_FAULT_SIGBUS;
- anon = 1; /* no anon but release faulted_page */
- goto out;
+ if (vma->vm_ops->page_mkwrite) {
+ unlock_page(page);
+ if (vma->vm_ops->page_mkwrite(vma, page) < 0) {
+ fdata.type = VM_FAULT_SIGBUS;
+ anon = 1; /* no anon but release
faulted_page */
+ goto out_unlocked;
+ }
+ lock_page(page);
}
}
@@ -2434,6 +2437,7 @@ static int __do_fault(struct mm_struct *
out:
unlock_page(faulted_page);
+out_unlocked:
if (anon)
page_cache_release(faulted_page);
else if (dirty_page) {
--
1.4.2.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: sleeping function called from invalid context at kernel/fork.c:385
On Fri, 1 Jun 2007, Sam Ravnborg wrote: > On Thu, May 31, 2007 at 09:05:54PM -0700, Christoph Lameter wrote: > > On Thu, 31 May 2007, Prarit Bhargava wrote: > > > > > I used the sn2_defconfig in the tree :) > > > > That is a static kernel build. Ideal for that kind of bug. > Quite the opposite. I thought that a static kernel build would throw out the __exit sections? So it should trigger the bug? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Friday 01 June 2007 00:08, Matthew Garrett wrote: > On Thu, May 31, 2007 at 11:33:10PM -0400, Dmitry Torokhov wrote: > > On Thursday 31 May 2007 21:44, Matthew Garrett wrote: > > > It's not trivial at all. You need to introduce a mechanism for noting a > > > KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably > > > the best layer for this), but you need to ensure that you only signal > > > the user who is currently at the keyboard. This needs to be presented to > > > the user via some sort of UI, which will then need to signal some sort > > > of privileged process to actually change the keymap. > > > > Not necessarily priveleged - you most likely already change ownership > > of event devices to user who is logged at console (so your force feedback > > joysticks work). > > If you let users alter the kernel keymap, then you need to implement > support for resetting the kernel keymap on exit. Otherwise it's a > trivial DoS. > You already do - do you let your users play games with force-feedback joysticks? To load force feedback effect you need write permissions for corresponding event device. And we are talking about console owner here - with current desktop-oriented distributions they already get access to host of otherwise restricted devices. > > > When the user logs > > > out, you'll then need to unmap the key again and repeat as necessary for > > > any new user who logs in. > > > > I think we should aim at the most common case - when there are no multiple > > users on the box. Then the utility that detects KEY_UNKNOWN just saves the > > mapping user chose and automatically reload keymap upon next reboot. > > The standard setup for home machines tends to be an account per family > member. That could be... Although it is desktops that are usually shared. Hmm, I am trying to remember setup of the people I know... I think the most common setup is a desktop in an easily accessible place (kitchen) with a single account. Older kids/parents may have their own desktop/laptops that are not shared. > The standard setup in an office environment is likely to be > multiuser. Huh? In my limited experience everyone in the office gets its own box. And I am not talking about software shop. > > > Note that KEY_UNKNOWN solution does not preculde futher customization on > > per-user base once default action is established. > > No, but it makes it significantly more confusing. User 1 chooses a > setup. This gets saved. User 2 remaps keys based on User 1's settings > (which have been restored at bootup). User 1 alters key mapping. User 2 > suddenly becomes hugely confused. One user is an administrator. He can alter the global keymap. If there are multiple users he may need to be cautious. > > > > > > Alternatively, we could generate a keycode and then let the user map > > > that to an X keysym. We've even already got code to do this. > > > > > > > There is world outside of X. > > On machines like we're discussing (laptops, basically) it's a tiny > world. Optimise for the common case, not the rare one. > > > > That's a ridiculously niche case, and can be handled in userspace. Just > > > have udev do remapping when it detects multiple keyboards that both have > > > KEY_PROG* layers, or let X have different keymaps for different input > > > devices. We shouldn't make the (by far) common case significantly more > > > difficult to deal with this one. > > > > > > > No, it is not a niche case. I think it is much more common than the case > > where > > you have multiple users for the same box using different keymaps. Even if > > box > > is shared there most likely will be one person setting it up in the > > beginning > > and the rest will follow his/her setup. > > How many users plug external keyboards with unlabelled keys into a > laptop? No, I really don't think that's a common case at all. I think quite a few people use external keyboards. I know that in my office everyone with a laptop has a docking station and uses full keyboard with it. I use external AT keyboard at home... As far as unlabeled goes - they may be labeled but we may not know their labels. > The solution that satisfies the largest number of users with the > smallest amount of work is the one where pressing a key on the keyboard > results in X events being generated. Right now, that requires that the > key generate a real keycode. > Again, it is not only about X. What if X is not running (or running but nobody is logged in)? There are number of events (SUSPEND, WLAN switch, undock request, etc) that should be handled by daemons not depending on X. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix comparisons of unsigned < 0
From: Bill Nottingham <[EMAIL PROTECTED]> Date: Wed, 30 May 2007 03:56:13 -0400 > Recent gcc versions emit warnings when unsigned variables are compared < 0 or > >= 0. > > Signed-off-by: Bill Nottingham <[EMAIL PROTECTED]> Patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] Make net watchdog timers 1 sec jiffy aligned
From: Venki Pallipadi <[EMAIL PROTECTED]> Date: Tue, 29 May 2007 11:01:13 -0700 > > round_jiffies for net dev watchdog timer. > > Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparsemem: Shut up unused symbol compiler warnings.
__kmalloc_section_memmap()/__kfree_section_memmap() and friends are only
used by the memory hotplug code. Move these in to the existing
CONFIG_MEMORY_HOTPLUG block.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
mm/sparse.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 1302f83..35f739a 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -229,6 +229,7 @@ static struct page __init
*sparse_early_mem_map_alloc(unsigned long pnum)
return NULL;
}
+#ifdef CONFIG_MEMORY_HOTPLUG
static struct page *__kmalloc_section_memmap(unsigned long nr_pages)
{
struct page *page, *ret;
@@ -269,27 +270,6 @@ static void __kfree_section_memmap(struct page *memmap,
unsigned long nr_pages)
}
/*
- * Allocate the accumulated non-linear sections, allocate a mem_map
- * for each and record the physical to section mapping.
- */
-void __init sparse_init(void)
-{
- unsigned long pnum;
- struct page *map;
-
- for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
- if (!valid_section_nr(pnum))
- continue;
-
- map = sparse_early_mem_map_alloc(pnum);
- if (!map)
- continue;
- sparse_init_one_section(__nr_to_section(pnum), pnum, map);
- }
-}
-
-#ifdef CONFIG_MEMORY_HOTPLUG
-/*
* returns the number of sections whose mem_maps were properly
* set. If this is <=0, then that means that the passed-in
* map was not consumed and must be freed.
@@ -329,3 +309,23 @@ out:
return ret;
}
#endif
+
+/*
+ * Allocate the accumulated non-linear sections, allocate a mem_map
+ * for each and record the physical to section mapping.
+ */
+void __init sparse_init(void)
+{
+ unsigned long pnum;
+ struct page *map;
+
+ for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+ if (!valid_section_nr(pnum))
+ continue;
+
+ map = sparse_early_mem_map_alloc(pnum);
+ if (!map)
+ continue;
+ sparse_init_one_section(__nr_to_section(pnum), pnum, map);
+ }
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: sleeping function called from invalid context at kernel/fork.c:385
On Thu, May 31, 2007 at 09:05:54PM -0700, Christoph Lameter wrote: > On Thu, 31 May 2007, Prarit Bhargava wrote: > > > I used the sn2_defconfig in the tree :) > > That is a static kernel build. Ideal for that kind of bug. Quite the opposite. If modpost cannot resolve symbols you are jsut told what top-level file it is in. A allmodconfig should be more useful and give you warnings in all normal cases. Let me know if I shall look over some of the warnings. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] slab: Fix slab debug for non alien caches.
Currently when slab debugging is enabled, the WARN_ON() nodeid checks
trigger if we boot with 'noaliencache'. In the noaliencache case the
WARN_ON()'s seem to be superfluous, so only bother doing the nodeid
comparison if use_alien_caches is set.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
mm/slab.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 2e71a32..88db26b 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2663,7 +2663,7 @@ static void *slab_get_obj(struct kmem_cache *cachep,
struct slab *slabp,
next = slab_bufctl(slabp)[slabp->free];
#if DEBUG
slab_bufctl(slabp)[slabp->free] = BUFCTL_FREE;
- WARN_ON(slabp->nodeid != nodeid);
+ WARN_ON(use_alien_caches && slabp->nodeid != nodeid);
#endif
slabp->free = next;
@@ -2677,7 +2677,7 @@ static void slab_put_obj(struct kmem_cache *cachep,
struct slab *slabp,
#if DEBUG
/* Verify that the slab belongs to the intended node */
- WARN_ON(slabp->nodeid != nodeid);
+ WARN_ON(use_alien_caches && slabp->nodeid != nodeid);
if (slab_bufctl(slabp)[objnr] + 1 <= SLAB_LIMIT + 1) {
printk(KERN_ERR "slab: double free detected in cache "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sendfile removal
Jens Axboe wrote: >> >>> - retval = in_file->f_op->sendfile(in_file, ppos, count, file_send_actor, >>> out_file); >>> + fl = 0; >>> + if (in_file->f_flags & O_NONBLOCK) >>> + fl = SPLICE_F_NONBLOCK; >>> + >>> + retval = do_splice_direct(in_file, ppos, out_file, count, fl); >> I like this, but are you sure it wont break user land ? >> >> Some applications might react badly if sendfile() returns EAGAIN ? > > Yeah, I didn't actually intend for that to sneak in. I'd think that > userspace should handle it if they opened the file O_NONBLOCK (or used > fcntl()), but it's a change in behaviour none the less and probably not > a good idea. > I would personally argue that sendfile() blocking on an O_NONBLOCK desriptor, as opposed to returning EAGAIN, is a bug, and a fairly serious such. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Thu, May 31, 2007 at 11:33:10PM -0400, Dmitry Torokhov wrote: > On Thursday 31 May 2007 21:44, Matthew Garrett wrote: > > It's not trivial at all. You need to introduce a mechanism for noting a > > KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably > > the best layer for this), but you need to ensure that you only signal > > the user who is currently at the keyboard. This needs to be presented to > > the user via some sort of UI, which will then need to signal some sort > > of privileged process to actually change the keymap. > > Not necessarily priveleged - you most likely already change ownership > of event devices to user who is logged at console (so your force feedback > joysticks work). If you let users alter the kernel keymap, then you need to implement support for resetting the kernel keymap on exit. Otherwise it's a trivial DoS. > > When the user logs > > out, you'll then need to unmap the key again and repeat as necessary for > > any new user who logs in. > > I think we should aim at the most common case - when there are no multiple > users on the box. Then the utility that detects KEY_UNKNOWN just saves the > mapping user chose and automatically reload keymap upon next reboot. The standard setup for home machines tends to be an account per family member. The standard setup in an office environment is likely to be multiuser. > Note that KEY_UNKNOWN solution does not preculde futher customization on > per-user base once default action is established. No, but it makes it significantly more confusing. User 1 chooses a setup. This gets saved. User 2 remaps keys based on User 1's settings (which have been restored at bootup). User 1 alters key mapping. User 2 suddenly becomes hugely confused. > > > > Alternatively, we could generate a keycode and then let the user map > > that to an X keysym. We've even already got code to do this. > > > > There is world outside of X. On machines like we're discussing (laptops, basically) it's a tiny world. Optimise for the common case, not the rare one. > > That's a ridiculously niche case, and can be handled in userspace. Just > > have udev do remapping when it detects multiple keyboards that both have > > KEY_PROG* layers, or let X have different keymaps for different input > > devices. We shouldn't make the (by far) common case significantly more > > difficult to deal with this one. > > > > No, it is not a niche case. I think it is much more common than the case where > you have multiple users for the same box using different keymaps. Even if box > is shared there most likely will be one person setting it up in the beginning > and the rest will follow his/her setup. How many users plug external keyboards with unlabelled keys into a laptop? No, I really don't think that's a common case at all. The solution that satisfies the largest number of users with the smallest amount of work is the one where pressing a key on the keyboard results in X events being generated. Right now, that requires that the key generate a real keycode. -- Matthew Garrett | [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: BUG: sleeping function called from invalid context at kernel/fork.c:385
On Thu, 31 May 2007, Prarit Bhargava wrote: > I used the sn2_defconfig in the tree :) That is a static kernel build. Ideal for that kind of bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc3-mm1
On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote: ... +msi-fix-the-ordering-of-msix-irqs.patch +msi-mask-the-msix-vector-before-we-unmap-it.patch ... 2.6.22 probable-queue I think these two should be in the 2.6.22 definite-queue, unless Eric disagrees. 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: MCP55 NCQ problem?
Hi,
Peer Chen írta:
Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci
-xxx'? Thanks.
BRs
Peer Chen
-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 10:31 PM
To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?
CCing Peer Chen and Kuan Luo from NVIDIA..
Looks like there were some unrecognized FIS errors from the controller
in there?
Zoltan Boszormenyi wrote:
Hi,
I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:
ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data
12288 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data
12288 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
At the time I was creating a DVD ISO image (reads and writes went to the
disk
that was resetted), browsing mail in thunderbird which also exercised
the same
disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:
scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD160JJ WU10 PQ: 0
ANSI: 5
scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0
ANSI: 5
I got almost the same yesterday with 2.6.22-rc2-mm1:
May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6
SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus
113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors =
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors =
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion,
repeating EH (cnt=4)
May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte
hardware sectors (320073 MB)
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache:
enabled, read cache: enabled, doesn't support DPO or FUA
..
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7
SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus
113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors =
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors =
625142448, hpa_sectors = 625142448
May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion,
repeating EH (cnt=4)
May 29 12:47:47 localhost kernel:
Re: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Thursday 31 May 2007 21:44, Matthew Garrett wrote: > On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 01 Jun 2007, Matthew Garrett wrote: > > > Given existing userspace, it's never useful to generate KEY_UNKNOWN. > > > Adding extra information to the event doesn't alter that. > > > > It will not break anything, and it is trivial to write an application to > > intelligently handle KEY_UNKNOWN+scancode events. This really is not a > > reason to not do it, at all. > > It's not trivial at all. You need to introduce a mechanism for noting a > KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably > the best layer for this), but you need to ensure that you only signal > the user who is currently at the keyboard. This needs to be presented to > the user via some sort of UI, which will then need to signal some sort > of privileged process to actually change the keymap. Not necessarily priveleged - you most likely already change ownership of event devices to user who is logged at console (so your force feedback joysticks work). > When the user logs > out, you'll then need to unmap the key again and repeat as necessary for > any new user who logs in. I think we should aim at the most common case - when there are no multiple users on the box. Then the utility that detects KEY_UNKNOWN just saves the mapping user chose and automatically reload keymap upon next reboot. Note that KEY_UNKNOWN solution does not preculde futher customization on per-user base once default action is established. > > Alternatively, we could generate a keycode and then let the user map > that to an X keysym. We've even already got code to do this. > There is world outside of X. > > > I think using positional keycodes would also be a mistake. We just need > > > a slightly larger set of keycodes representing user-definable keys. > > > There's 4 of them already - I really can't imagine there being many > > > keyboards with a significantly larger set of unlabelled keys. > > > > I had this exact PoV, too, until Dmitry reminded me that keycodes are > > *global* to the system in practice, and that different keys (as in keys that > > have no correlation between their position, labels or lack thereof, and > > function) in different input devices would end up mapped to KEY_PROGx by > > default. > > That's a ridiculously niche case, and can be handled in userspace. Just > have udev do remapping when it detects multiple keyboards that both have > KEY_PROG* layers, or let X have different keymaps for different input > devices. We shouldn't make the (by far) common case significantly more > difficult to deal with this one. > No, it is not a niche case. I think it is much more common than the case where you have multiple users for the same box using different keymaps. Even if box is shared there most likely will be one person setting it up in the beginning and the rest will follow his/her setup. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: sleeping function called from invalid context at kernel/fork.c:385
Luck, Tony wrote: Tony, the ia64 section mismatch "whack-a-mole" is far from over :( Can you post the .config file that you are using when you see all those warnings ... I'll start bopping them on their cute little heads. Hi Tony, I used the sn2_defconfig in the tree :) P. -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: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Stefan Bader wrote: > 2007/5/30, Phillip Susi <[EMAIL PROTECTED]>: >> Stefan Bader wrote: >> > >> > Since drive a supports barrier request we don't get -EOPNOTSUPP but >> > the request with block y might get written before block x since the >> > disk are independent. I guess the chances of this are quite low since >> > at some point a barrier request will also hit drive b but for the time >> > being it might be better to indicate -EOPNOTSUPP right from >> > device-mapper. >> >> The device mapper needs to ensure that ALL underlying devices get a >> barrier request when one comes down from above, even if it has to >> construct zero length barriers to send to most of them. >> > > And somehow also make sure all of the barriers have been processed > before returning the barrier that came in. Plus it would have to queue > all mapping requests until the barrier is done (if strictly acting > according to barrier.txt). > > But I am wondering a bit whether the requirements to barriers are > really that tight as described in Tejun's document (barrier request is > only started if everything before is safe, the barrier itself isn't > returned until it is safe, too, and all requests after the barrier > aren't started before the barrier is done). Is it really necessary to > defer any further requests until the barrier has been written to save > storage? Or would it be sufficient to guarantee that, if a barrier > request returns, everything up to (including the barrier) is on safe > storage? Well, what's described in barrier.txt is the current implemented semantics and what filesystems expect, so we can't change it underneath them but we definitely can introduce new more relaxed variants, but one thing we should bear in mind is that harddisks don't have humongous caches or very smart controller / instruction set. No matter how relaxed interface the block layer provides, in the end, it just has to issue whole-sale FLUSH CACHE on the device to guarantee data ordering on the media. IMHO, we can do better by paying more attention to how we do things in the request queue which can be deeper and more intelligent than the device queue. 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: BUG: sleeping function called from invalid context at kernel/fork.c:385
> Tony, the ia64 section mismatch "whack-a-mole" is far from over :( Can you post the .config file that you are using when you see all those warnings ... I'll start bopping them on their cute little heads. -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: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Jens Axboe wrote: > On Thu, May 31 2007, David Chinner wrote: >> On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote: >>> On Thu, May 31 2007, David Chinner wrote: IOWs, there are two parts to the problem: 1 - guaranteeing I/O ordering 2 - guaranteeing blocks are on persistent storage. Right now, a single barrier I/O is used to provide both of these guarantees. In most cases, all we really need to provide is 1); the need for 2) is a much rarer condition but still needs to be provided. > if I am understanding it correctly, the big win for barriers is that you > do NOT have to stop and wait until the data is on persistant media before > you can continue. Yes, if we define a barrier to only guarantee 1), then yes this would be a big win (esp. for XFS). But that requires all filesystems to handle sync writes differently, and sync_blockdev() needs to call blkdev_issue_flush() as well So, what do we do here? Do we define a barrier I/O to only provide ordering, or do we define it to also provide persistent storage writeback? Whatever we decide, it needs to be documented >>> The block layer already has a notion of the two types of barriers, with >>> a very small amount of tweaking we could expose that. There's absolutely >>> zero reason we can't easily support both types of barriers. >> That sounds like a good idea - we can leave the existing >> WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED >> behaviour that only guarantees ordering. The filesystem can then >> choose which to use where appropriate > > Precisely. The current definition of barriers are what Chris and I came > up with many years ago, when solving the problem for reiserfs > originally. It is by no means the only feasible approach. > > I'll add a WRITE_ORDERED command to the #barrier branch, it already > contains the empty-bio barrier support I posted yesterday (well a > slightly modified and cleaned up version). Would that be very different from issuing barrier and not waiting for its completion? For ATA and SCSI, we'll have to flush write back cache anyway, so I don't see how we can get performance advantage by implementing separate WRITE_ORDERED. I think zero-length barrier (haven't looked at the code yet, still recovering from jet lag :-) can serve as genuine barrier without the extra write tho. 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] Introduce O_CLOEXEC (take >2)
On Fri, Jun 01, 2007 at 11:38:40AM +1000, Stephen Rothwell wrote: > This also breaks Alpha (which uses 0200 for O_DIRECT) and parisc > (which uses 0200 for O_RSYNC). So you ether need to choose a > different value or define O_CLOEXEC for those two architectures. > That's easy enough to fix... Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> diff --git a/include/asm-parisc/fcntl.h b/include/asm-parisc/fcntl.h index 317851f..4ca0fb0 100644 --- a/include/asm-parisc/fcntl.h +++ b/include/asm-parisc/fcntl.h @@ -14,6 +14,7 @@ #define O_DSYNC0100 /* HPUX only */ #define O_RSYNC0200 /* HPUX only */ #define O_NOATIME 0400 +#define O_CLOEXEC 0800 /* set close_on_exec */ #define O_DIRECTORY0001 /* must be a directory */ #define O_NOFOLLOW 0200 /* don't follow links */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)
On Wednesday 30 May 2007 19:02:28 Mark Adler wrote:
> On May 30, 2007, at 6:30 AM, Satyam Sharma wrote:
> > [1] For your reference, here is the user code in question:
>
> ...
>
> >if (srclen > 2 && !(data_in[1] & PRESET_DICT) &&
> > ((data_in[0] & 0x0f) == Z_DEFLATED) &&
> > !(((data_in[0]<<8) + data_in[1]) % 31)) {
>
> The funny thing here is that the author felt compelled to use a
> #defined constant for the dictionary bit (PRESET_DICT), but had no
> problem with a numeric constant to isolate the compression method
> (0x0f), or for that matter extracting the window bits from the
> header. The easy way to avoid the use of an internal zlib header
> file here is to simply replace PRESET_DICT with 0x20. That constant
> will never change -- it is part of the definition of the zlib header
> in RFC 1950.
If there is no objection, I'll put together a patch that changes the use in
JFFS2 into a "magic number", complete with documentation on it, and also
moves all of the zlib stuff into a single directory.
> The slightly more involved patch to avoid the problem is to let
> inflate() do all that work for you, including the integrity check on
> the zlib header (% 31). Also this corrects an error in the original
> code, which is that it continues to try to decompress after finding
> that a dictionary is needed or that the zlib header is invalid. In
> this version, a bad header simply returns an error:
>
Does anyone know if doing as Mark suggests would negatively impact the
performance of JFFS2 to such a degree that it could be considered a
regression? I, unfortunately, don't have the hardware to properly test the
code. And, at this point in time, I also don't have enough familiarity with
the JFFS2 code to make such a change myself.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SELECT() returns 1 But FIONREAD says (Input/output error)
Uncle George wrote: David Schwartz wrote: Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to do anything about it. The select() returns because i pulled the USB cable from hub. Seems reasonable. The next select() found what? to be interesting in order to prematurely terminate the select-wait? As far as I can tell, nothing interesting has happened since the previous select(). In this case the select() is only looking at read()'s. It's because you haven't done anything to handle the error which is still persisting. Likely the only thing sane you can do in this case is close the fd and try to reopen it later. -- 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.22-rc1-mm1 [cannot change thermal trip points]
On Monday 21 May 2007 08:11, Pavel Machek wrote: > On Thu 2007-05-17 18:42:43, Len Brown wrote: > > > Something similar happened to me on XE3, yes. > > > > > > (Actual values were different; BIOS specified critical temperature at > > > cca 95C, but hw killed the power at cca 83C. Setting critical trip > > > point at 80C made the problem go away.) > > > > Great, please file a bug and include the acpidump from the XE3 > > and we'll fix it, rather than supporting a bogus (manual) workaround for it. > > It is few years since I do not have that XE3 machine. > > > Of course if your system is running at 80*C and the hardware shuts > > off at 83*C, you may have a broken fan, or one clogged with dust... > > It _did_ have broken fan. It also had broken trip points. Thanks for clarifying this, Pavel. If you come upon an XE3 where Linux-2.6.22 doesn't work as well as Windows, please let me know. Given that the justification for this ill-conceived workaround seems to have diminished to the memory of broken hardware, it is clear that we should stay the course of removing it so that it doesn't further confuse future users. If SuSE violently disagrees with me, you are certainly empowered to restore the workaround in your distribution staring at 2.6.22 as part of your value add. However, given its history of confusing users, it seems that it might increase your support burden rather than decrease it. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sendfile removal (nfsd update)
Ok, here is a patch that makes nfsd use splice instead of sendfile.
It appears to both compile and work.
Some observations:
- __splice_from_pipe wants a "struct file*" and I wanted to pass a
"struct svcrqst *". Maybe it should take a void * ?
- It also wants a *ppos which I had no use for.. It that really
need? Cannot >f_pos be used?
- I copied do_splice_to from splice.c as it wasn't exported, and
then found I couldn't compile because rw_verify_area wasn't
exported. As nfsd doesn't need that (we never export
mandatory-locking files) I just remove it and some other cruft
that I didn't need Not sure if that was the best approach.
- I needed to export alloc_pipe_info. Maybe there should be a
get_current_pipe instead which does the alloc if needed.
- I would much rather have something like free_pipe_info exported
than open code it in do_splice_read (which is based heavily on
do_splice_direct).
NeilBrown
---
Replace ->sendfile with ->splice_read
Apparently ->sendfile is going away, so change nfsd to use ->splice_read
to get pages for a file.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/vfs.c | 125
./fs/pipe.c |1
2 files changed, 109 insertions(+), 17 deletions(-)
diff .prev/fs/nfsd/vfs.c ./fs/nfsd/vfs.c
--- .prev/fs/nfsd/vfs.c 2007-06-01 10:41:27.0 +1000
+++ ./fs/nfsd/vfs.c 2007-06-01 12:32:51.0 +1000
@@ -23,7 +23,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -801,26 +801,32 @@ found:
}
/*
- * Grab and keep cached pages assosiated with a file in the svc_rqst
- * so that they can be passed to the netowork sendmsg/sendpage routines
- * directrly. They will be released after the sending has completed.
+ * Grab and keep cached pages associated with a file in the svc_rqst
+ * so that they can be passed to the network sendmsg/sendpage routines
+ * directly. They will be released after the sending has completed.
*/
static int
-nfsd_read_actor(read_descriptor_t *desc, struct page *page, unsigned long
offset , unsigned long size)
+nfsd_splice_actor(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
+ struct splice_desc *sd)
{
- unsigned long count = desc->count;
- struct svc_rqst *rqstp = desc->arg.data;
+ struct svc_rqst *rqstp = (struct svc_rqst *)sd->file;
struct page **pp = rqstp->rq_respages + rqstp->rq_resused;
+ struct page *page = buf->page;
+ size_t size;
+ int ret;
+
+ ret = buf->ops->pin(pipe, buf);
+ if (unlikely(ret))
+ return ret;
- if (size > count)
- size = count;
+ size = sd->len;
if (rqstp->rq_res.page_len == 0) {
get_page(page);
put_page(*pp);
*pp = page;
rqstp->rq_resused++;
- rqstp->rq_res.page_base = offset;
+ rqstp->rq_res.page_base = buf->offset;
rqstp->rq_res.page_len = size;
} else if (page != pp[-1]) {
get_page(page);
@@ -832,11 +838,98 @@ nfsd_read_actor(read_descriptor_t *desc,
} else
rqstp->rq_res.page_len += size;
- desc->count = count - size;
- desc->written += size;
return size;
}
+static long do_splice_to(struct file *in, loff_t *ppos,
+struct pipe_inode_info *pipe, size_t len,
+unsigned int flags)
+{
+ loff_t isize, left;
+
+ isize = i_size_read(in->f_mapping->host);
+ if (unlikely(*ppos >= isize))
+ return 0;
+
+ left = isize - *ppos;
+ if (unlikely(left < len))
+ len = left;
+
+ return in->f_op->splice_read(in, ppos, pipe, len, flags);
+}
+
+static int do_splice_read(struct file *in, loff_t *ppos, size_t count,
+ struct svc_rqst *rqstp)
+{
+ struct pipe_inode_info *pipe;
+ long ret, bytes;
+ int i;
+
+ rqstp->rq_resused = 1;
+
+ pipe = current->splice_pipe;
+ if (unlikely(!pipe)) {
+ pipe = alloc_pipe_info(NULL);
+ if (!pipe)
+ return -ENOMEM;
+
+ pipe->readers = 1;
+ current->splice_pipe = pipe;
+ }
+
+ ret = 0;
+ bytes = 0;
+
+ while (count) {
+ loff_t unused = 0;
+ size_t read_len, max_read_len;
+
+ max_read_len = min(count, (size_t)(PIPE_BUFFERS*PAGE_SIZE));
+
+ ret = do_splice_to(in, ppos, pipe, max_read_len, 0);
+ if (unlikely(ret < 0))
+ goto out_release;
+
+ read_len = ret;
+
+ ret = __splice_from_pipe(pipe, (struct file *)rqstp,
+, read_len, 0,
+
Re: [patch -mm] alsa mixer_oss kfree fix
Hi, Just append to my email. The reason I read mixer_oss.c is that I see oops in 2.6.22-rc1-mm1, seems oops in mixer_oss.c, but the oops rised only once, I found rc3-mm1 have no change in this file, so I read the source , then post this patch. please find the oops message below: BUG: unable to handle kernel NULL pointer dereference at virtual address 0088 printing eip: c0162bc2 *pde = Oops: [#1] PREEMPT Modules linked in: snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd_page_alloc snd soundcore ipv6 capability commoncap e100 mi i agpgart pcspkr psmouse CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010087 (2.6.22-rc1-mm1 #7) EIP is at kfree+0x42/0x90 eax: ebx: c10568e0 ecx: c2b47000 edx: c01588d2 esi: 0287 edi: ebp: c2864000 esp: c2865f58 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process modprobe (pid: 2963, ti=c2864000 task=c1ede540 task.ti=c2864000) Stack: 0011 f8855000 c0520cb4 0001 0001 c1e524a0 c1051bc0 c01588d2 0805c348 0001 c2864000 f885502b f8840a00 0001 c013caf1 4b79 000b7f68 b7f44840 08065f88 0805c348 c01040bc Call Trace: [] alsa_mixer_oss_init+0x0/0x37 [snd_mixer_oss] [] __vunmap+0xb2/0xe0 [] alsa_mixer_oss_init+0x2b/0x37 [snd_mixer_oss] [] sys_init_module+0xa1/0x140 [] syscall_call+0x7/0xb [] packet_seq_start+0x30/0x60 === Code: 00 00 00 40 a1 40 6a 59 c0 c1 ea 0c c1 e2 05 01 c2 8b 02 89 d3 25 00 40 02 00 3d 00 40 02 00 74 45 8b 7b 10 8b 54 24 1c 9 c 5e fa <39> 9f 88 00 00 00 75 25 8b 03 a8 02 75 1f 0f b7 53 0a 8b 43 0c EIP: [] kfree+0x42/0x90 SS:ESP 0068:c2865f58 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc3-mm1
Andrew Morton wrote: On Thu, 31 May 2007 23:01:15 -0300 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/ - Merged the convert-cpusets-to-container-infrastructure patches. These will probably be dropped and redone. x86 things +add-select-phylib-to-the-ucc_geth-kconfig-option.patch +m68k-parenthesis-balance.patch +msi-fix-the-ordering-of-msix-irqs.patch +msi-mask-the-msix-vector-before-we-unmap-it.patch +potential-parse-error-in-ifdef.patch +potential-parse-error-in-ifdef-fix.patch +potential-parse-error-in-ifdef-update.patch +pci_ids-update-patch-for-intel-ich9m.patch +x86-fix-oprofile-double-free-was-re-multiple-free.patch http://lkml.org/lkml/2007/5/30/565 fixes the above patch :-) I don't know what you mean. The code is already using for_each_possible_cpu() and x86-fix-oprofile-double-free-was-re-multiple-free.patch doesn't change that. Yes, the code, i.e. nmi_setup already uses for_each_possible_cpu(), that is not the problem. The problem is allocate_msr doing a for_each_online_cpu(), i.e. not allocating for each_possible_cpu. Chris tested and acked the patch: http://lkml.org/lkml/2007/5/31/36 - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] alsa mixer_oss kfree fix
Hi, kfree(NULL) is legal, and is often used. Really? I don't know this before. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
Hello, Linus Torvalds wrote: > On Fri, 1 Jun 2007, Tejun Heo wrote: >> Gregor's cdrom has broken SRST support which is extremely rare and >> broken. > > Well, the concept is neither rare nor arguably all that broken. > > The paper standards floating around in the industry are so much toilet > paper. The only standard that seems to really matter is what Windows has > traditionally done. We may not like it, but there it is... > > This bites us more when it comes to the real el-cheapo stuff, notably when > it comes to various USB mass storage things (which have some random > USB->flash controller cobbled together by a senile llama on crack), and is > almost unheard of for anythign that is "server-grade", but when it comes > to no-brand random devices, it really does tend to be the case that the > only testing they ever had was using Windows. > > And hardware is seldom any different from software: if it wasn't tested, > it probably doesn't work. Yeap, agreed. SRST on PATA works on most devices tho. This device is the first reported one which genuinely doesn't like SRST itself but we also had a case where a device doesn't report proper diagnostic code and another one which reports incorrect device class code. Hardreset on SATA works better because it's much more integral part of the protocol. SRST also seems to work better but there is an emulated PMP device which craps itself if SRST is issued to it. > So it would be good if somebody knew what the Windows ID/startup sequence > was/is. I think we figured it out by trial-and-error for the USB mass > storage stuff. But it tends to boil down to: don't do things that aren't > absolutely required (for SCSI, it was things like not asking for mode > pages that weren't absolutely required, because some devices wouldn't > support it, and would simply lock up if you did so!) Most BIOSen, Windows and old IDE driver don't reset at all during probing. They first issue IDENTIFY unconditionally, if that fails, IDENTIFY_PACKET. From the beginning, libata has issued reset during probing. We've had a few problems regarding this but they have been worked around successfully till now. One of the upsides of doing reset during probing is that the reset code path gets tested a lot and libata is more likely to recover properly after error conditions. With SATA, this is getting more important because errors are much more common and happen occasionally even on perfectly healthy machines. As libata gets much wider userbase including old/weird PATA devices, we seem to be facing more of these broken devices. We may be reaching the point where the benefit of doing reset during probing isn't worth the price we have to pay, at least on PATA. Jeff, what do you think? -- 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: MCP55 NCQ problem?
Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci
-xxx'? Thanks.
BRs
Peer Chen
-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 10:31 PM
To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?
CCing Peer Chen and Kuan Luo from NVIDIA..
Looks like there were some unrecognized FIS errors from the controller
in there?
Zoltan Boszormenyi wrote:
> Hi,
>
> I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:
>
> ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
> ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data
> 12288 out
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data
> 12288 out
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata2: hard resetting port
> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
> ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
> ata2.00: configured for UDMA/133
> ata2: EH pending after completion, repeating EH (cnt=4)
> ata2: EH complete
> sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>
> At the time I was creating a DVD ISO image (reads and writes went to the
> disk
> that was resetted), browsing mail in thunderbird which also exercised
> the same
> disk and I was downloading another ISO with about 400-450 kB/sec to
> another disk. Here are the disks in question:
>
> scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD160JJ WU10 PQ: 0
> ANSI: 5
> scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0
> ANSI: 5
>
> I got almost the same yesterday with 2.6.22-rc2-mm1:
>
> May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6
> SErr 0x0 action 0x2 frozen
> May 29 12:44:20 localhost kernel: ata2.00: cmd
> 61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
> May 29 12:44:20 localhost kernel: res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:44:20 localhost kernel: ata2.00: cmd
> 61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
> May 29 12:44:20 localhost kernel: res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:44:20 localhost kernel: ata2: hard resetting port
> May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus
> 113 SControl 300)
> May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors =
> 625142448, hpa_sectors = 625142448
> May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors =
> 625142448, hpa_sectors = 625142448
> May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
> May 29 12:44:21 localhost kernel: ata2: EH pending after completion,
> repeating EH (cnt=4)
> May 29 12:44:21 localhost kernel: ata2: EH complete
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte
> hardware sectors (320073 MB)
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache:
> enabled, read cache: enabled, doesn't support DPO or FUA
> ..
> May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7
> SErr 0x0 action 0x2 frozen
> May 29 12:47:46 localhost kernel: ata2.00: cmd
> 61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
> May 29 12:47:46 localhost kernel: res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2.00: cmd
> 61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
> May 29 12:47:46 localhost kernel: res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2.00: cmd
> 61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
> May 29 12:47:46 localhost kernel: res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2: hard resetting port
> May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus
> 113 SControl 300)
> May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors =
> 625142448, hpa_sectors = 625142448
> May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors =
> 625142448, hpa_sectors = 625142448
> May 29 12:47:47 localhost kernel: ata2.00: configured
Re: 2.6.22-rc3-mm1
On Thu, 31 May 2007 23:01:15 -0300 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/ > > > > - Merged the convert-cpusets-to-container-infrastructure patches. These > > will probably be dropped and redone. > > > > > > > > > > > x86 things > > > > +add-select-phylib-to-the-ucc_geth-kconfig-option.patch > > +m68k-parenthesis-balance.patch > > +msi-fix-the-ordering-of-msix-irqs.patch > > +msi-mask-the-msix-vector-before-we-unmap-it.patch > > +potential-parse-error-in-ifdef.patch > > +potential-parse-error-in-ifdef-fix.patch > > +potential-parse-error-in-ifdef-update.patch > > +pci_ids-update-patch-for-intel-ich9m.patch > > +x86-fix-oprofile-double-free-was-re-multiple-free.patch > > > http://lkml.org/lkml/2007/5/30/565 fixes the above patch :-) > I don't know what you mean. The code is already using for_each_possible_cpu() and x86-fix-oprofile-double-free-was-re-multiple-free.patch doesn't change 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: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Fri, 01 Jun 2007, Matthew Garrett wrote: > On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 01 Jun 2007, Matthew Garrett wrote: > > > Given existing userspace, it's never useful to generate KEY_UNKNOWN. > > > Adding extra information to the event doesn't alter that. > > > > It will not break anything, and it is trivial to write an application to > > intelligently handle KEY_UNKNOWN+scancode events. This really is not a > > reason to not do it, at all. > > It's not trivial at all. You need to introduce a mechanism for noting a > KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably That would be trivial, but... > the best layer for this), but you need to ensure that you only signal > the user who is currently at the keyboard. This needs to be presented to > the user via some sort of UI, which will then need to signal some sort > of privileged process to actually change the keymap. When the user logs > out, you'll then need to unmap the key again and repeat as necessary for > any new user who logs in. ... this is not. You're correct. So using KEY_UNKNOWN should not be the preferred way, then. > Alternatively, we could generate a keycode and then let the user map > that to an X keysym. We've even already got code to do this. Well, I also would appreciate bumping up KEY_MAX and a nice shiny set of KEY_FN that covered all the missing ones for ThinkPads. It is Dmitry you have to convince about it. That still doesn't make KEY_UNKNOWN without a scan code useful, so either way, I think KEY_UNKNOWN should be limited to drivers that can remap keycodes *and* which send MSC_SCAN events along with KEY_UNKNOWN, so that you know what key to remap. I don't care if it is easy or not to be nice to the user and ask for a key remap, at least it will not be *impossible* like it currently is. Otherwise, we would be better off removing KEY_UNKNOWN altogether (which I wouldn't mind much, either). > > > I think using positional keycodes would also be a mistake. We just need > > > a slightly larger set of keycodes representing user-definable keys. > > > There's 4 of them already - I really can't imagine there being many > > > keyboards with a significantly larger set of unlabelled keys. > > > > I had this exact PoV, too, until Dmitry reminded me that keycodes are > > *global* to the system in practice, and that different keys (as in keys that > > have no correlation between their position, labels or lack thereof, and > > function) in different input devices would end up mapped to KEY_PROGx by > > default. > > That's a ridiculously niche case, and can be handled in userspace. Just > have udev do remapping when it detects multiple keyboards that both have > KEY_PROG* layers, or let X have different keymaps for different input > devices. We shouldn't make the (by far) common case significantly more > difficult to deal with this one. Dmitry? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] alsa mixer_oss kfree fix
On Fri, 1 Jun 2007 01:53:39 + "young dave" <[EMAIL PROTECTED]> wrote: > Fix possible null pointer kfree. kfree(NULL) is legal, and is often used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc3-mm1 - works-for-me and a meta-question...
Hi, On Fri, Jun 01, 2007 at 12:27:02AM +0200, Michal Piotrowski wrote: > On 01/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said: > >> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/ > > > >Builds, boots, seems to be behaving on my laptop (Dell D820, X86_64). > > > >Meta-question: Is there a useful address/mailbox/webpage to toss *working* > >reports at? > > > > There was a klive > http://klive.cpushare.com/ > > Actually it doesn't work. Andrea, what is happening with klive? Don't worry, everything is going fine at klive.cpushare.com. You only clicked it at the wrong time ;). (by the time I read your message it was back up already) Uptime has generally been very good... KLive current problem is that 512M of shm for the db, isn't enough to get good performance with the current data size anymore. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/1] document Acked-by:
From: Andrew Morton <[EMAIL PROTECTED]> Explain what we use Acked-by: for, and how it differs from Signed-off-by: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- Documentation/SubmittingPatches | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff -puN Documentation/SubmittingPatches~document-acked-by Documentation/SubmittingPatches --- a/Documentation/SubmittingPatches~document-acked-by +++ a/Documentation/SubmittingPatches @@ -328,7 +328,20 @@ now, but you can do this to mark interna point out some special detail about the sign-off. -12) The canonical patch format +12) When to use Acked-by: + +The Signed-off-by: tag implies that the signer was involved in the development +of the patch, or that he/she was in the patch's delivery path. + +If a person was not directly involved in the preparation or handling of a +patch but wishes to signify and record their approval of it then they can +arrange to have an Acked-by: line added to the patch's changelog. + +Acked-by: is often used by the maintainer of the affected code when that +maintainer neither wrote, merged nor forwarded the patch themselves. + + +13) The canonical patch format The canonical patch subject line is: _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc3-mm1
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/ - Merged the convert-cpusets-to-container-infrastructure patches. These will probably be dropped and redone. x86 things +add-select-phylib-to-the-ucc_geth-kconfig-option.patch +m68k-parenthesis-balance.patch +msi-fix-the-ordering-of-msix-irqs.patch +msi-mask-the-msix-vector-before-we-unmap-it.patch +potential-parse-error-in-ifdef.patch +potential-parse-error-in-ifdef-fix.patch +potential-parse-error-in-ifdef-update.patch +pci_ids-update-patch-for-intel-ich9m.patch +x86-fix-oprofile-double-free-was-re-multiple-free.patch http://lkml.org/lkml/2007/5/30/565 fixes the above patch :-) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SELECT() returns 1 But FIONREAD says (Input/output error)
David Schwartz wrote: Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to do anything about it. The select() returns because i pulled the USB cable from hub. Seems reasonable. The next select() found what? to be interesting in order to prematurely terminate the select-wait? As far as I can tell, nothing interesting has happened since the previous select(). In this case the select() is only looking at read()'s. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] alsa mixer_oss kfree fix
Hi,
Fix possible null pointer kfree.
Signed-off-by: dave young <[EMAIL PROTECTED]>
mixer_oss.c |120 +-
1 file changed, 74 insertions(+), 46 deletions(-)
diff -purN linux/sound/core/oss/mixer_oss.c linux.new/sound/core/oss/mixer_oss.c
--- linux/sound/core/oss/mixer_oss.c2007-06-01 09:00:12.0 +
+++ linux.new/sound/core/oss/mixer_oss.c2007-06-01 09:36:10.0
+
@@ -512,23 +512,27 @@ static void snd_mixer_oss_get_volume1_vo
return;
}
uinfo = kzalloc(sizeof(*uinfo), GFP_KERNEL);
+ if (uinfo == NULL)
+ goto out_uinfo;
uctl = kzalloc(sizeof(*uctl), GFP_KERNEL);
- if (uinfo == NULL || uctl == NULL)
- goto __unalloc;
+ if (uctl == NULL)
+ goto out_uctl;
if (kctl->info(kctl, uinfo))
- goto __unalloc;
+ goto out;
if (kctl->get(kctl, uctl))
- goto __unalloc;
+ goto out;
if (uinfo->type == SNDRV_CTL_ELEM_TYPE_BOOLEAN &&
uinfo->value.integer.min == 0 && uinfo->value.integer.max == 1)
- goto __unalloc;
+ goto out;
*left = snd_mixer_oss_conv1(uctl->value.integer.value[0],
uinfo->value.integer.min, uinfo->value.integer.max,
>volume[0]);
if (uinfo->count > 1)
*right = snd_mixer_oss_conv1(uctl->value.integer.value[1],
uinfo->value.integer.min, uinfo->value.integer.max,
>volume[1]);
- __unalloc:
+out:
+ kfree(uctl);
+out_uctl:
+ kfree(uinfo);
+out_uinfo:
up_read(>controls_rwsem);
- kfree(uctl);
- kfree(uinfo);
}
static void snd_mixer_oss_get_volume1_sw(struct snd_mixer_oss_file *fmixer,
@@ -550,13 +554,15 @@ static void snd_mixer_oss_get_volume1_sw
return;
}
uinfo = kzalloc(sizeof(*uinfo), GFP_KERNEL);
+ if (uinfo == NULL)
+ goto out_uinfo;
uctl = kzalloc(sizeof(*uctl), GFP_KERNEL);
- if (uinfo == NULL || uctl == NULL)
- goto __unalloc;
+ if (uctl == NULL)
+ goto out_uctl;
if (kctl->info(kctl, uinfo))
- goto __unalloc;
+ goto out;
if (kctl->get(kctl, uctl))
- goto __unalloc;
+ goto out;
if (!uctl->value.integer.value[0]) {
*left = 0;
if (uinfo->count == 1)
@@ -564,10 +570,12 @@ static void snd_mixer_oss_get_volume1_sw
}
if (uinfo->count > 1 && !uctl->value.integer.value[route ? 3 : 1])
*right = 0;
- __unalloc:
- up_read(>controls_rwsem);
- kfree(uctl);
+out:
+ kfree(uctl);
+out_uctl:
kfree(uinfo);
+out_uinfo:
+ up_read(>controls_rwsem);
}
static int snd_mixer_oss_get_volume1(struct snd_mixer_oss_file *fmixer,
@@ -613,25 +621,29 @@ static void snd_mixer_oss_put_volume1_vo
if ((kctl = snd_ctl_find_numid(card, numid)) == NULL)
return;
uinfo = kzalloc(sizeof(*uinfo), GFP_KERNEL);
+ if (uinfo == NULL)
+ goto out_uinfo;
uctl = kzalloc(sizeof(*uctl), GFP_KERNEL);
- if (uinfo == NULL || uctl == NULL)
- goto __unalloc;
+ if (uctl == NULL)
+ goto out_uctl;
if (kctl->info(kctl, uinfo))
- goto __unalloc;
+ goto out;
if (uinfo->type == SNDRV_CTL_ELEM_TYPE_BOOLEAN &&
uinfo->value.integer.min == 0 && uinfo->value.integer.max == 1)
- goto __unalloc;
+ goto out;
uctl->value.integer.value[0] = snd_mixer_oss_conv2(left,
uinfo->value.integer.min, uinfo->value.integer.max);
if (uinfo->count > 1)
uctl->value.integer.value[1] = snd_mixer_oss_conv2(right,
uinfo->value.integer.min, uinfo->value.integer.max);
if ((res = kctl->put(kctl, uctl)) < 0)
- goto __unalloc;
+ goto out;
if (res > 0)
snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, >id);
- __unalloc:
- up_read(>controls_rwsem);
- kfree(uctl);
+out:
+ kfree(uctl);
+out_uctl:
kfree(uinfo);
+out_uinfo:
+ up_read(>controls_rwsem);
}
static void snd_mixer_oss_put_volume1_sw(struct snd_mixer_oss_file *fmixer,
@@ -654,11 +666,13 @@ static void snd_mixer_oss_put_volume1_sw
return;
}
uinfo = kzalloc(sizeof(*uinfo), GFP_KERNEL);
+ if (uinfo == NULL)
+ goto out_uinfo;
uctl = kzalloc(sizeof(*uctl), GFP_KERNEL);
- if (uinfo == NULL || uctl == NULL)
- goto __unalloc;
+ if (uctl == NULL)
+ goto out_uctl;
if (kctl->info(kctl, uinfo))
- goto __unalloc;
+ goto out;
if (uinfo->count > 1) {
uctl->value.integer.value[0] = left > 0 ? 1 : 0;
uctl->value.integer.value[route ? 3 : 1] = right > 0 ? 1 : 0;
@@ -670,13 +684,15 @@ static
Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage
On Thu, May 31, 2007 at 06:45:17PM -0700, Mark Fasheh wrote: > On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote: > > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the > > > page, so long as it's returned in a locked state? Though, do we even need > > > the page lock that early? It seemed to me that you were adding it for > > > consistency reasons (I could be wrong though). > > > > You could do that, but you'd have to probably check that it is > > within i_size after you relock it, I think... yeah, that might > > be the best thing for ocfs to do for now. > > Well, ocfs2 already does i_size checks in page_mkwrite, so we're covered > with respect to truncate races. > > I'm still not clear though - what was the reason for adding the page locking > there in the 1st place? Yeah, its to cover page invalidation races. There is a description in an earlier patch's changelog. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc3-mm1 - page_mkwrite() breakage
On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote: > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the > > page, so long as it's returned in a locked state? Though, do we even need > > the page lock that early? It seemed to me that you were adding it for > > consistency reasons (I could be wrong though). > > You could do that, but you'd have to probably check that it is > within i_size after you relock it, I think... yeah, that might > be the best thing for ocfs to do for now. Well, ocfs2 already does i_size checks in page_mkwrite, so we're covered with respect to truncate races. I'm still not clear though - what was the reason for adding the page locking there in the 1st place? --Mark -- Mark Fasheh Senior Software Developer, Oracle [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 01 Jun 2007, Matthew Garrett wrote: > > Given existing userspace, it's never useful to generate KEY_UNKNOWN. > > Adding extra information to the event doesn't alter that. > > It will not break anything, and it is trivial to write an application to > intelligently handle KEY_UNKNOWN+scancode events. This really is not a > reason to not do it, at all. It's not trivial at all. You need to introduce a mechanism for noting a KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably the best layer for this), but you need to ensure that you only signal the user who is currently at the keyboard. This needs to be presented to the user via some sort of UI, which will then need to signal some sort of privileged process to actually change the keymap. When the user logs out, you'll then need to unmap the key again and repeat as necessary for any new user who logs in. Alternatively, we could generate a keycode and then let the user map that to an X keysym. We've even already got code to do this. > > I think using positional keycodes would also be a mistake. We just need > > a slightly larger set of keycodes representing user-definable keys. > > There's 4 of them already - I really can't imagine there being many > > keyboards with a significantly larger set of unlabelled keys. > > I had this exact PoV, too, until Dmitry reminded me that keycodes are > *global* to the system in practice, and that different keys (as in keys that > have no correlation between their position, labels or lack thereof, and > function) in different input devices would end up mapped to KEY_PROGx by > default. That's a ridiculously niche case, and can be handled in userspace. Just have udev do remapping when it detects multiple keyboards that both have KEY_PROG* layers, or let X have different keymaps for different input devices. We shouldn't make the (by far) common case significantly more difficult to deal with this one. -- Matthew Garrett | [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] Introduce O_CLOEXEC (take >2)
On Thu, 31 May 2007 16:20:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h > > index c154b9d..b847741 100644 > > --- a/include/asm-generic/fcntl.h > > +++ b/include/asm-generic/fcntl.h > > @@ -48,6 +48,9 @@ > > #ifndef O_NOATIME > > #define O_NOATIME 0100 > > #endif > > +#ifndef O_CLOEXEC > > +#define O_CLOEXEC 0200/* set close_on_exec */ > > +#endif > > #ifndef O_NDELAY > > #define O_NDELAY O_NONBLOCK > > #endif > > This will break xtensa, because that architecture (and only that > architecture) doesn't include asm-generic/fcntl.h from asm/fcntl.h. This also breaks Alpha (which uses 0200 for O_DIRECT) and parisc (which uses 0200 for O_RSYNC). So you ether need to choose a different value or define O_CLOEXEC for those two architectures. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpirD2kzbvsR.pgp Description: PGP signature
Re: Linux v2.6.22-rc3
On Fri, 1 Jun 2007, Tejun Heo wrote: > > Gregor's cdrom has broken SRST support which is extremely rare and > broken. Well, the concept is neither rare nor arguably all that broken. The paper standards floating around in the industry are so much toilet paper. The only standard that seems to really matter is what Windows has traditionally done. We may not like it, but there it is... This bites us more when it comes to the real el-cheapo stuff, notably when it comes to various USB mass storage things (which have some random USB->flash controller cobbled together by a senile llama on crack), and is almost unheard of for anythign that is "server-grade", but when it comes to no-brand random devices, it really does tend to be the case that the only testing they ever had was using Windows. And hardware is seldom any different from software: if it wasn't tested, it probably doesn't work. So it would be good if somebody knew what the Windows ID/startup sequence was/is. I think we figured it out by trial-and-error for the USB mass storage stuff. But it tends to boil down to: don't do things that aren't absolutely required (for SCSI, it was things like not asking for mode pages that weren't absolutely required, because some devices wouldn't support it, and would simply lock up if you did so!) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22-rc3-mm1 - page_mkwrite() breakage
On Thu, May 31, 2007 at 06:24:40PM -0700, Mark Fasheh wrote: > On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote: > > Ah, I didn't realise you were using that yet. I expect ocfs2 is using > > VM_CAN_INVALIDATE there anyway. > > > > Hmm, this becomes easier to deal with after page_mkwrite is merged with > > ->fault. But for now, can we just lock the page at the do_wp_page site > > as well, and change the API? All users I have seen want the page locked > > there anyway... > > Unfortunately that doesn't work for ocfs2 for exactly the same reasons page > lock doesn't work during a write either - there's a cluster lock inversion > and we might have to zero adjacent pages for an allocating write. I guess you could just fail the page_mkwrite and have it try again? .. that would require changing it not to always go SIGBUS though. > What's involved in merging it with ->fault? Just I have't sent the patch (because at the time there were no page_mkwrite users to look at). It is nicer too, because the nopage path only has to call into the filesystem once, to return the page (the filesystem can check whether it is for write, and do the page_mkwrite thing at that time). do_wp_page obviously still involves the extra call, and that will be with a flag telling the fs that it isn't a "nopage" fault, but a write fault on an existing page. > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the > page, so long as it's returned in a locked state? Though, do we even need > the page lock that early? It seemed to me that you were adding it for > consistency reasons (I could be wrong though). You could do that, but you'd have to probably check that it is within i_size after you relock it, I think... yeah, that might be the best thing for ocfs to do for now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Fri, 01 Jun 2007, Matthew Garrett wrote: > On Thu, May 31, 2007 at 09:13:04PM -0300, Henrique de Moraes Holschuh wrote: > > Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above > > just makes KEY_UNKNOWN useful for something instead of keeping it as an > > useless notice to the user that some key (which one? who knows!) was > > pressed. > > Given existing userspace, it's never useful to generate KEY_UNKNOWN. > Adding extra information to the event doesn't alter that. It will not break anything, and it is trivial to write an application to intelligently handle KEY_UNKNOWN+scancode events. This really is not a reason to not do it, at all. > > Perhaps what you dislike re. KEY_UNKNOWN is the part where KEY_UNKNOWN+scan > > code is declared to be the prefered way to report keys that do not have a > > specific function? Your reply seems to indicate this, but I am not sure I > > really understood what you meant. > > Yes. That could easily be removed or switched around but... > > I am not exactly in love with the idea of using KEY_UNKNOWN in place of > > stuff like KEY_FN_F1 either (I'd prefer to just bump up KEY_MAX and have > > more posicional keycodes), but Dmitry is being quite clear that he does not > > want to increase KEY_MAX to add more positional keycodes. > > I think using positional keycodes would also be a mistake. We just need > a slightly larger set of keycodes representing user-definable keys. > There's 4 of them already - I really can't imagine there being many > keyboards with a significantly larger set of unlabelled keys. I had this exact PoV, too, until Dmitry reminded me that keycodes are *global* to the system in practice, and that different keys (as in keys that have no correlation between their position, labels or lack thereof, and function) in different input devices would end up mapped to KEY_PROGx by default. And in that scenario, KEY_UNKNOWN (i.e. "please remap me to what you want this key to do for real") makes a lot more sense, given that we don't have all the positional keycodes we need, and more are not being added. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Documentation: /proc/$pid/stat files
I'd like to see the "stat" file documented (I always have to go looking for it). Thanks to Bharadwaj Yadavalli[1] and fs/proc/array.c, I've got most of it, but I'm not an expert in this area. :) I've included my "pending" patch below for reference. Can someone give me a short description of the following fields? wchan exit_signal policy blkio_ticks Thanks, -Kees [1] http://www.red-hat.com/archives/axp-list/2001-January/msg00355.html --- --- linux-2.6.22-rc3-git4/Documentation/filesystems/proc.txt.pre 2007-05-31 17:17:20.0 -0700 +++ linux-2.6.22-rc3-git4/Documentation/filesystems/proc.txt2007-05-31 17:40:06.0 -0700 @@ -171,7 +171,9 @@ read the file /proc/PID/status: This shows you nearly the same information you would get if you viewed it with the ps command. In fact, ps uses the proc file system to obtain its information. The statm file contains more detailed information about the -process memory usage. Its seven fields are explained in Table 1-2. +process memory usage. Its seven fields are explained in Table 1-2. The stat +file contains details information about the process itself. Its fields are +explained in Table 1-3. Table 1-2: Contents of the statm files (as of 2.6.8-rc3) @@ -188,16 +190,64 @@ Table 1-2: Contents of the statm files ( dt number of dirty pages(always 0 on 2.6) .. + +Table 1-3: Contents of the stat files (as of 2.6.22-rc3) +.. + Field Content + pid process id + tcomm filename of the executable + state state (R is running, S is sleeping, D is sleeping in an +uninterruptible wait, Z is zombie, T is traced or stopped) + ppid process id of the parent process + pgrp pgrp of the process + sid session id + tty_nrtty the process uses + tty_pgrp pgrp of the tty + flags task flags + min_flt number of minor faults + cmin_flt number of minor faults with child's + maj_flt number of major faults + cmaj_flt number of major faults with child's + utime user mode jiffies + stime kernel mode jiffies + cutimeuser mode jiffies with child's + cstimekernel mode jiffies with child's + priority priority level + nice nice level + num_threads number of threads + start_timetime the process started after system boot + vsize virtual memory size + rss resident set memory size + rsslimcurrent limit in bytes on the rss + start_codeaddress above which program text can run + end_code address below which program text can run + start_stack address of the start of the stack + esp current value of ESP + eip current value of EIP + pending bitmap of pending signals (obsolete) + blocked bitmap of blocked signals (obsolete) + sigignbitmap of ignored signals (obsolete) + sigcatch bitmap of catched signals (obsolete) + wchan ? + 0 (place holder) + 0 (place holder) + exit_signal ? + task_cpu which CPU the task is scheduled on + rt_priority realtime priority + policy? + blkio_ticks ? +.. + 1.2 Kernel data --- Similar to the process entries, the kernel data files give information about the running kernel. The files used to obtain this information are contained in -/proc and are listed in Table 1-3. Not all of these will be present in your +/proc and are listed in Table 1-4. Not all of these will be present in your system. It depends on the kernel configuration and the loaded modules, which files are there, and which are missing. -Table 1-3: Kernel info in /proc +Table 1-4: Kernel info in /proc .. FileContent apm Advanced power management info @@ -473,10 +523,10 @@ IDE devices: More detailed information can be found in the controller specific subdirectories. These are named ide0, ide1 and so on. Each of these -directories contains the files shown in table 1-4. +directories contains the files shown in table 1-5. -Table 1-4: IDE controller info in /proc/ide/ide? +Table 1-5: IDE controller info in /proc/ide/ide? .. FileContent channel IDE channel (0 or 1) @@ -486,11 +536,11 @@ Table 1-4: IDE controller info in /proc .. Each
Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage
On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote: > Ah, I didn't realise you were using that yet. I expect ocfs2 is using > VM_CAN_INVALIDATE there anyway. > > Hmm, this becomes easier to deal with after page_mkwrite is merged with > ->fault. But for now, can we just lock the page at the do_wp_page site > as well, and change the API? All users I have seen want the page locked > there anyway... Unfortunately that doesn't work for ocfs2 for exactly the same reasons page lock doesn't work during a write either - there's a cluster lock inversion and we might have to zero adjacent pages for an allocating write. What's involved in merging it with ->fault? Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the page, so long as it's returned in a locked state? Though, do we even need the page lock that early? It seemed to me that you were adding it for consistency reasons (I could be wrong though). --Mark -- Mark Fasheh Senior Software Developer, Oracle [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: [RFC][PATCH 0/3] A Dynticks Aware Processor Idle PM Governor
Applied this series to acpi-test in anticipation that Venki is about to send some incremental patches to address the feedback on it. thanks, -Len On Saturday 24 March 2007 03:46, Adam Belay wrote: > Hi All, > > Here is my first take at implementing an idle PM governor that takes > full advantage of NO_HZ. I call it the 'menu' governor because it > considers the full list of idle states before each entry. > > I've kept the implementation fairly simple. It attempts to guess the > next residency time and then chooses a state that would meet at least > the break-even point between power savings and entry cost. To this end, > it selects the deepest idle state that satisfies the following > constraints: > 1. If the idle time elapsed since bus master activity was detected > is below a threshold (currently 20 ms), then limit the selection > to C2-type or above. > 2. Do not choose a state with a break-even residency that exceeds > the expected time remaining until the next timer interrupt. > 3. Do not choose a state with a break-even residency that exceeds > the elapsed time between the last pair of break events, > excluding timer interrupts. > > This governor has an advantage over "ladder" governor because it > proactively checks how much time remains until the next timer interrupt > using the tick infrastructure. Also, it handles device interrupt > activity more intelligently by not including timer interrupts in break > event calculations. Finally, it doesn't make policy decisions using the > number of state entries, which can have variable residency times (NO_HZ > makes these potentially very large), and instead only considers sleep > time deltas. > > The menu governor can be selected during runtime using the cpuidle sysfs > interface like so: > "echo "menu" > /sys/devices/system/cpu/cpuidle/current_governor" > > This patchset applies against 2.6.21-rc4 plus the latest from the acpi > testing tree, which is available here: > ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.21/acpi-test-20070126-2.6.21-rc4.diff.bz2 > > I'd really appreciate any comments, benchmarks, or suggestions. > > Cheers, > Adam > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/5] msi: fix ARM compile
From: Dan Williams <[EMAIL PROTECTED]> In file included from drivers/pci/msi.c:22: include/asm/smp.h:17:26: asm/arch/smp.h: No such file or directory include/asm/smp.h:20:3: #error " included in non-SMP build" include/asm/smp.h:23:1: warning: "raw_smp_processor_id" redefined In file included from include/linux/sched.h:65, from include/linux/mm.h:4, from drivers/pci/msi.c:10: include/linux/smp.h:85:1: warning: this is the location of the previous definition Tested on powerpc, i386, and x86_64. Signed-off-by: Dan Williams <[EMAIL PROTECTED]> Acked-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/pci/msi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index d9cbd58..f7f7470 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -15,10 +15,10 @@ #include #include #include +#include #include #include -#include #include "pci.h" #include "msi.h" -- 1.5.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 5/5] PCI: quirk disable MSI on via vt3351
From: Jay Cliburn <[EMAIL PROTECTED]> The Via VT3351 APIC does not play well with MSI and unleashes a flood of APIC errors when MSI is used to deliver interrupts. The problem was recently exposed when the atl1 network device driver, which enables MSI by default, stimulated APIC errors on an Asus M2V mainboard, which employs the Via VT3351. See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional details on this bug. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|1 + include/linux/pci_ids.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 4937982..01d8f8a 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1640,6 +1640,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCN DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); /* Disable MSI on chipsets that are known to not support it */ static void __devinit quirk_disable_msi(struct pci_dev *dev) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index c4a14c6..02cf0cd 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1292,6 +1292,7 @@ #define PCI_DEVICE_ID_VIA_P4M890 0x0327 #define PCI_DEVICE_ID_VIA_VT3324 0x0324 #define PCI_DEVICE_ID_VIA_VT3336 0x0336 +#define PCI_DEVICE_ID_VIA_VT3351 0x0351 #define PCI_DEVICE_ID_VIA_8371_0 0x0391 #define PCI_DEVICE_ID_VIA_8501_0 0x0501 #define PCI_DEVICE_ID_VIA_82C561 0x0561 -- 1.5.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 3/5] PCI: Fix pci_find_present
From: Ben Gardner <[EMAIL PROTECTED]>
pci_find_present() is only matching the last item in the list of ids.
The break after the match is found only escapes the for loop, not the
while loop, so found gets reset to NULL on the next pass.
Signed-off-by: Ben Gardner <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/search.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index b137a27..c132324 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -403,10 +403,11 @@ const struct pci_device_id *pci_find_present(const struct
pci_device_id *ids)
while (ids->vendor || ids->subvendor || ids->class_mask) {
list_for_each_entry(dev, _devices, global_list) {
if ((found = pci_match_one_device(ids, dev)) != NULL)
- break;
+ goto exit;
}
ids++;
}
+exit:
up_read(_bus_sem);
return found;
}
--
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/5] PCI: i386: fixup for Siemens Nixdorf AG FSC Multiprocessor Interrupt Controllers
From: Ivan Kokshaysky <[EMAIL PROTECTED]>
Wolfgang gets:
PCI: Cannot allocate resource region 0 of device :00:04.0
PCI: Error while updating region :00:04.0/0 (a8008000 != fec08000)
Note that the BAR seems to have high address bits hardwired to fec0.
And device :00:04.0 is
00:04.0 System peripheral: Siemens Nixdorf AG FSC Multiprocessor Interrupt
Controller (rev 02)
I'd guess that when we try to reassign this resource, PCI interrupts might
just stop working. This could explain SCSI timeouts and other weird things.
Cc: Wolfgang Erig <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/i386/pci/fixup.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/i386/pci/fixup.c b/arch/i386/pci/fixup.c
index b62eafb..b95b429 100644
--- a/arch/i386/pci/fixup.c
+++ b/arch/i386/pci/fixup.c
@@ -436,3 +436,14 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_5530_LEGACY,
pci_early_fixup_cyrix_5530);
DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5530_LEGACY,
pci_early_fixup_cyrix_5530);
+
+/*
+ * Siemens Nixdorf AG FSC Multiprocessor Interrupt Controller:
+ * prevent update of the BAR0, which doesn't look like a normal BAR.
+ */
+static void __devinit pci_siemens_interrupt_controller(struct pci_dev *dev)
+{
+ dev->resource[0].flags |= IORESOURCE_PCI_FIXED;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SIEMENS, 0x0015,
+ pci_siemens_interrupt_controller);
--
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] PCI: disable MSI by default on systems with Serverworks HT1000 chips
From: Andy Gospodarek <[EMAIL PROTECTED]> I've been seeing lots of messages like these: eth0: No interrupt was generated using MSI, switching to INTx mode. Please report this failure to the PCI maintainer and include system chipset information. On several systems that use the following Severworks HT1000 (also sometimes labeled as a Broadcom chipset as well) bridge chips. It doesn't appear MSI works well (if at all) on these systems. Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|1 + include/linux/pci_ids.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 1cff65f..4937982 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1637,6 +1637,7 @@ static void __init quirk_disable_all_msi(struct pci_dev *dev) printk(KERN_WARNING "PCI: MSI quirk detected. MSI deactivated.\n"); } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 4712e26..c4a14c6 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1437,6 +1437,7 @@ #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017 #define PCI_DEVICE_ID_SERVERWORKS_EPB0x0103 +#define PCI_DEVICE_ID_SERVERWORKS_HT1000_PCIX 0x0104 #define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 #define PCI_DEVICE_ID_SERVERWORKS_CSB5 0x0201 -- 1.5.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Replacing the /proc//exe symlink code
On Wed, 2007-05-30 at 23:01 -0700, Chris Wright wrote: > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > > === > > > --- linux-2.6.22-rc2-mm1.orig/kernel/exit.c > > > +++ linux-2.6.22-rc2-mm1/kernel/exit.c > > > @@ -924,10 +924,12 @@ fastcall void do_exit(long code) > > > if (unlikely(tsk->audit_context)) > > > audit_free(tsk); > > > > > > taskstats_exit(tsk, group_dead); > > > > > > + if (tsk->exe_file) > > > + fput(tsk->exe_file); > > > > just taking a cursory look so I may be missing something, but doesn't > > this leave the possibility that right here, with tsk->exe_file being > > put, another task would try to look at tsk's /proc/tsk->pid/exe? > > And I hit this one, so there's at least one issue. > > [ 110.296952] Unable to handle kernel NULL pointer dereference at > 0088 RIP: > [ 110.299053] [] d_path+0x1a/0x117 > [ 110.301861] PGD 6d35a067 PUD 6d35e067 PMD 0 > [ 110.303509] Oops: [1] SMP > [ 110.304719] CPU 1 > [ 110.305493] Modules linked in: oprofile > [ 110.306969] Pid: 3983, comm: pidof Not tainted 2.6.22-rc3-g7f397dcd-dirty > #183 > [ 110.309733] RIP: 0010:[] [] > d_path+0x1a/0x117 > [ 110.312635] RSP: 0018:810142335e38 EFLAGS: 00010292 > [ 110.314667] RAX: 81006d58a000 RBX: RCX: > 1000 > [ 110.317397] RDX: 81006d58a000 RSI: RDI: > > [ 110.320127] RBP: 81006d58a000 R08: fff3 R09: > 0006be8b > [ 110.322857] R10: R11: 0001 R12: > > [ 110.325588] R13: 1000 R14: 81006d58a000 R15: > 0 > [ 110.328319] FS: 2b033d578260() GS:81000106e480() > knlGS: > [ 110.331415] CS: 0010 DS: ES: CR0: 8005003b > [ 110.333613] CR2: 0088 CR3: 6cf54000 CR4: > 06e0 > [ 110.336344] Process pidof (pid: 3983, threadinfo 810142334000, task > 8101421186c0) > [ 110.339472] Stack: 8101422a7268 81006d58a000 > fff4 > [ 110.342556] 1000 00678820 > 802b7a54 > [ 110.345404] > > [ 110.348180] Call Trace: > [ 110.349188] [] proc_pid_readlink+0x89/0xff > [ 110.351387] [] sys_readlinkat+0x87/0xa9 > [ 110.353487] [] remove_vma+0x5d/0x64 > [ 110.355455] [] error_exit+0x0/0x84 > [ 110.357389] [] system_call+0x7e/0x83 > [ 110.359388] > [ 110.359958] > [ 110.359958] Code: 48 8b 87 88 00 00 00 48 85 c0 74 20 48 8b 40 30 48 85 c0 > 74 > [ 110.363381] RIP [] d_path+0x1a/0x117 > [ 110.365386] RSP > [ 110.366720] CR2: 0088 Hmm, at first blush this does appear to be related to the bug Serge pointed out. I'm not certain though, so I'll see if I can spot/produce any other problems that could explain this. Thanks for testing my patch! Cheers, -Matt Helsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 PATCH] PCI patches for 2.6.22-rc3
Here are some bugfixes for PCI your 2.6.22-rc3 git tree. All of these have been in the -mm tree for a month or so. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/ The full patches will be sent to the linux-pci mailing list, if anyone wants to see it thanks, greg k-h arch/i386/pci/fixup.c | 11 +++ drivers/pci/msi.c |2 +- drivers/pci/quirks.c|2 ++ drivers/pci/search.c|3 ++- include/linux/pci_ids.h |2 ++ 5 files changed, 18 insertions(+), 2 deletions(-) --- Andy Gospodarek (1): PCI: disable MSI by default on systems with Serverworks HT1000 chips Ben Gardner (1): PCI: Fix pci_find_present Dan Williams (1): msi: fix ARM compile Ivan Kokshaysky (1): PCI: i386: fixup for Siemens Nixdorf AG FSC Multiprocessor Interrupt Controllers Jay Cliburn (1): PCI: quirk disable MSI on via vt3351 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Documentation: /proc/$pid/stat files
Documentation for the /proc/$pid/stat file. Signed-off-by: Kees Cook <[EMAIL PROTECTED]> --- proc.txt | 65 --- 1 file changed, 58 insertions(+), 7 deletions(-) --- linux-2.6.22-rc3-git4/Documentation/filesystems/proc.txt.pre 2007-05-31 17:17:20.0 -0700 +++ linux-2.6.22-rc3-git4/Documentation/filesystems/proc.txt2007-05-31 18:10:27.0 -0700 @@ -171,7 +171,9 @@ read the file /proc/PID/status: This shows you nearly the same information you would get if you viewed it with the ps command. In fact, ps uses the proc file system to obtain its information. The statm file contains more detailed information about the -process memory usage. Its seven fields are explained in Table 1-2. +process memory usage. Its seven fields are explained in Table 1-2. The stat +file contains details information about the process itself. Its fields are +explained in Table 1-3. Table 1-2: Contents of the statm files (as of 2.6.8-rc3) @@ -188,16 +190,65 @@ Table 1-2: Contents of the statm files ( dt number of dirty pages(always 0 on 2.6) .. + +Table 1-3: Contents of the stat files (as of 2.6.22-rc3) +.. + Field Content + pid process id + tcomm filename of the executable + state state (R is running, S is sleeping, D is sleeping in an +uninterruptible wait, Z is zombie, T is traced or stopped) + ppid process id of the parent process + pgrp pgrp of the process + sid session id + tty_nrtty the process uses + tty_pgrp pgrp of the tty + flags task flags + min_flt number of minor faults + cmin_flt number of minor faults with child's + maj_flt number of major faults + cmaj_flt number of major faults with child's + utime user mode jiffies + stime kernel mode jiffies + cutimeuser mode jiffies with child's + cstimekernel mode jiffies with child's + priority priority level + nice nice level + num_threads number of threads + start_timetime the process started after system boot + vsize virtual memory size + rss resident set memory size + rsslimcurrent limit in bytes on the rss + start_codeaddress above which program text can run + end_code address below which program text can run + start_stack address of the start of the stack + esp current value of ESP + eip current value of EIP + pending bitmap of pending signals (obsolete) + blocked bitmap of blocked signals (obsolete) + sigignbitmap of ignored signals (obsolete) + sigcatch bitmap of catched signals (obsolete) + wchan address where process went to sleep + 0 (place holder) + 0 (place holder) + exit_signal signal to send to parent thread on exit + task_cpu which CPU the task is scheduled on + rt_priority realtime priority + policyscheduling policy (man sched_setscheduler) + blkio_ticks time spent waiting for block IO +.. + + 1.2 Kernel data --- Similar to the process entries, the kernel data files give information about the running kernel. The files used to obtain this information are contained in -/proc and are listed in Table 1-3. Not all of these will be present in your +/proc and are listed in Table 1-4. Not all of these will be present in your system. It depends on the kernel configuration and the loaded modules, which files are there, and which are missing. -Table 1-3: Kernel info in /proc +Table 1-4: Kernel info in /proc .. FileContent apm Advanced power management info @@ -473,10 +524,10 @@ IDE devices: More detailed information can be found in the controller specific subdirectories. These are named ide0, ide1 and so on. Each of these -directories contains the files shown in table 1-4. +directories contains the files shown in table 1-5. -Table 1-4: IDE controller info in /proc/ide/ide? +Table 1-5: IDE controller info in /proc/ide/ide? .. FileContent channel IDE channel (0 or 1) @@ -486,11 +537,11 @@ Table 1-4: IDE controller info in /proc .. Each device connected to a controller has a separate subdirectory in the -controllers
Re: [patch 8/9] F00F bug fixup for i386 - use conditional calls
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Fri, 1 Jun 2007 02:14:53 +0200 (MEST) > Mikael Pettersson <[EMAIL PROTECTED]> wrote: > > > Andrew Morton wrote: > > > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > > > > > * Andrew Morton ([EMAIL PROTECTED]) wrote: > > > > > > > > > > Use the faster conditional calls for F00F bug handling in > > > > > > do_page_fault. > > > > > > > > > > > > > > > > I guess this means that CONDCALL will be enabled on pretty much all > > > > > i386, > > > > > in which case making the whole feature Kconfigurable is starting to > > > > > look > > > > > marginal. > > > > > > > > > > Perhaps a better approach would have to made this change dependent > > > > > upon > > > > > CONDCALL, rather than forcing it on. > > > > > > > > > > > > > Do you mean making X86_F00F_BUG depend on COND_CALL instead of selecting > > > > it ? > > > > > > yup > > > > X86_F00F_BUG needs to be enabled in all kernels capable of booting on > > P5 class machines, whether or not some obscure CONFIG_COND_CALL thingy > > is enabled or not. X86_F00F_BUG is not some optional optimisation, it's > > an essential workaround for a serious hardware bug. > > > > Therefore it seems select rather than depend is called for. > > Nope. > > CONFIG_COND_CALL=n-> do f00f handling the present way > CONFIG_COND_CALL=y-> do f00f handling the new, fast-n-fancy way > > > Because I don't think everyone will want to drag all this cond_call stuff > into their kernel just for slightly faster f00f handling. > Then I should probably leave the redundant if (boot_cpu_data.f00f_bug) test in do_f00f_workaround so that configuration where cond_calls are not enabled still behave the same way as before. The redundant test will make the case when cond calls are present a little slower, but we still have the improvement when the architecture does not need the workaround. I could also wrap this test in a #ifndef CONFIG_COND_CALL, but it seems ugly. Also, since the default is not to set the CF_STATIC_ENABLE flag, the workaround won't be compiled in the kernel if the conditional calls are configured out. The question that arises is : what should be the default behavior of a cond_call when the cond_calls are configured out? Active, active only if the CF_STATIC_ENABLE flags is set or inactive? -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Introduce O_CLOEXEC (take >2)
On Thu, 31 May 2007 16:20:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > This will break xtensa, because that architecture (and only that > architecture) doesn't include asm-generic/fcntl.h from asm/fcntl.h. It used to (for a whole 15 months). Consolidation and cleanup is hard enough to do once ... > But let's leave this patch as-is: it's xtensa which needs fixing. See my other patch ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpzAHgJaGQzC.pgp Description: PGP signature
RE: SELECT() returns 1 But FIONREAD says (Input/output error)
> i am using the GARMIN_GPS/usb driver to read a gps receiver. > In testing the ability of my software to recover from various errors, I > try this: unplug the gps/USB cable from the usb hub. > > Interestingly enough the thread spins. > the SELECT() waits for something to happen, and I get one channel that > something interesting happened. > Then i try to find out how many chars are in the read buff via FIONREAD. > That call errors out with an i/o error. > > Needless to day, the code resets the SELECT parameters, and SELECT is > called again. It again says that something interesting has happened on > that ( i/o errored ) channel. And we now repeat the FIONREAD. > > In this case what, will reset the "something interesting has happened" > report from the SELECT call? Will it ever be reset in this case? Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to do anything about it. At minimum, a detection of an error condition that could be persistent should be followed by a delay. A detection of an error condition that has in fact persisted and was previously detected should *never* be followed by an immediate return to 'select'. You need to *handle* the I/O error. Backoff might be one way, sleeping for an increasing amount of time after each fatal error, subject to some limit. And why are you calling FIONREAD? Just 'read' the data -- you're going to have to eventually anyway. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Let Xtense use asm-generic/fcntl.h
Commit fc4fb2adf944d45a7f3d4d38df991c79ffdb6a43 "fixed" the Xtensa
asm/fcntl.h and in doing so ignored asm-generic/fcntl.h completely.
It turns out that it is now exactly the same as asm-generic/fcntl.h.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
include/asm-xtensa/fcntl.h | 100 +---
1 files changed, 1 insertions(+), 99 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/include/asm-xtensa/fcntl.h b/include/asm-xtensa/fcntl.h
index 0609fc6..46ab12d 100644
--- a/include/asm-xtensa/fcntl.h
+++ b/include/asm-xtensa/fcntl.h
@@ -1,99 +1 @@
-/*
- * include/asm-xtensa/fcntl.h
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1995, 1996, 1997, 1998 by Ralf Baechle
- * Copyright (C) 2001 - 2005 Tensilica Inc.
- */
-
-#ifndef _XTENSA_FCNTL_H
-#define _XTENSA_FCNTL_H
-
-/* open/fcntl - O_SYNC is only implemented on blocks devices and on files
- located on an ext2 file system */
-#define O_ACCMODE 0003
-#define O_RDONLY00
-#define O_WRONLY01
-#define O_RDWR 02
-#define O_CREAT 0100 /* not fcntl */
-#define O_EXCL0200 /* not fcntl */
-#define O_NOCTTY 0400 /* not fcntl */
-#define O_TRUNC 01000 /* not fcntl */
-#define O_APPEND 02000
-#define O_NONBLOCK 04000
-#define O_NDELAY O_NONBLOCK
-#define O_SYNC 01
-#define FASYNC 02 /* fcntl, for BSD compatibility */
-#define O_DIRECT04 /* direct disk access hint */
-#define O_LARGEFILE010
-#define O_DIRECTORY020 /* must be a directory */
-#define O_NOFOLLOW 040 /* don't follow links */
-#define O_NOATIME 0100
-
-#define F_DUPFD0 /* dup */
-#define F_GETFD1 /* get close_on_exec */
-#define F_SETFD2 /* set/clear close_on_exec */
-#define F_GETFL3 /* get file->f_flags */
-#define F_SETFL4 /* set file->f_flags */
-#define F_GETLK5
-#define F_SETLK6
-#define F_SETLKW 7
-
-#define F_SETOWN 8 /* for sockets. */
-#define F_GETOWN 9 /* for sockets. */
-#define F_SETSIG 10 /* for sockets. */
-#define F_GETSIG 11 /* for sockets. */
-
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
-/* for F_[GET|SET]FL */
-#define FD_CLOEXEC 1 /* actually anything with low bit set goes */
-
-/* for posix fcntl() and lockf() */
-#define F_RDLCK0
-#define F_WRLCK1
-#define F_UNLCK2
-
-/* for old implementation of bsd flock () */
-#define F_EXLCK4 /* or 3 */
-#define F_SHLCK8 /* or 4 */
-
-/* for leases */
-#define F_INPROGRESS 16
-
-/* operations for bsd flock(), also used by the kernel implementation */
-#define LOCK_SH1 /* shared lock */
-#define LOCK_EX2 /* exclusive lock */
-#define LOCK_NB4 /* or'd with one of the above to prevent
- blocking */
-#define LOCK_UN8 /* remove lock */
-
-#define LOCK_MAND 32 /* This is a mandatory flock */
-#define LOCK_READ 64 /* ... Which allows concurrent read operations
*/
-#define LOCK_WRITE 128 /* ... Which allows concurrent write operations
*/
-#define LOCK_RW192 /* ... Which allows concurrent read &
write ops */
-
-struct flock {
- short l_type;
- short l_whence;
- off_t l_start;
- off_t l_len;
- pid_t l_pid;
-};
-
-struct flock64 {
- short l_type;
- short l_whence;
- loff_t l_start;
- loff_t l_len;
- pid_t l_pid;
-};
-
-#define F_LINUX_SPECIFIC_BASE 1024
-
-#endif /* _XTENSA_FCNTL_H */
+#include
--
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22-rc3-mm1 - page_mkwrite() breakage
On Thu, May 31, 2007 at 04:13:54PM -0700, Mark Fasheh wrote: > On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote: > > git-ocfs2.patch > > Andrew, thanks for getting that back in there. > > > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared > writable mmap. We hang on a page lock because ->page_mkwrite() is > being called with the page already locked: > > + /* > + * For consistency in subsequent calls, make the nopage_page always > + * locked. > + */ > + if (unlikely(!(vma->vm_flags & VM_CAN_INVALIDATE))) > + lock_page(nopage_page); > > It wasn't previously being called with the page lock held, intentionally. Ah, I didn't realise you were using that yet. I expect ocfs2 is using VM_CAN_INVALIDATE there anyway. Hmm, this becomes easier to deal with after page_mkwrite is merged with ->fault. But for now, can we just lock the page at the do_wp_page site as well, and change the API? All users I have seen want the page locked there anyway... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.22-rc3
Hello, Linus. Sorry about late response. I'm still recovering from jet
lag.
Linus Torvalds wrote:
> On Tue, 29 May 2007, Tejun Heo wrote:
>> Aieee, so the drive doesn't like the new SRST sequence.
>
> It would appear that the old code largely ignored the SRST error entirely,
> no?
Yes, we used to ignore some error conditions, which sometimes led to
very long timeout sequence after hotplugging under certain circumstances
- a few 30sec timeouts for the reset and another 30sec for the following
IDENTIFY (because reset didn't fail after the timeouts).
> If we *used* to do (in ata_bus_post_reset()):
>
> if (dev0)
> ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
>
> and you changed that to actually care about the return value:
>
> if (dev0) {
> rc = ata_wait_ready(ap, deadline);
> if (rc && rc != -ENODEV)
> return rc;
> }
>
> (in _two_ places). That change also changed the same "post_reset" handling
> in a totally _different_ way: it used to do ata_busy_sleep() twice, now it
> still does it twice, but it does it with the same "timeout" value, so if
> the first one times out, then the second one won't be given any timeout AT
> ALL!
>
> And to make matters worse: the first timeout seems to be for ANOTHER PORT
> ENTIRELY! So you seem to break port 1 even if the timeout happened on port
> 0, as far as I can read that sequence.
Yes, the whole operation uses single timeout. If the given time runs
out, it fails for both devices on the channel. This is because reset
timeout is channel wide. After SRST, both devices are required to
respond in certain time (30secs max per spec). If anyone of the device
doesn't respond, it isn't clear what we can or can't do with the bus -
reset protocol itself requires responding master, cable detection needs
both devices working, etc...
> So I think your ata_bus_post_reset() changes are rather suspect. The fact
> that you don't change the timeout, and use the same deadline for two
> different ports (and for multiple commands to the same port, afaik), seems
> rather suspect. The old code also didn't care about failures in certain
> phases of the reset sequence, and it appears that it did so for good
> reason.
Gregor's cdrom has broken SRST support which is extremely rare and
broken. The reason why it works flawlessly with the ide driver is
because the ide driver doesn't issue SRST during probing and libata
worked after 30sec timeout before reset-seq change because libata didn't
use to check reset failures in some cases and the device just worked
when issued commands even when it didn't report ready status after reset.
I'll try to add some code in the reset path and see where the device
fails reset protocol. Hopefully, we can work around it. If it doesn't,
maybe we'll need to issue IDENTIFY and see whether that works after
reset timeout. :-(
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 8/9] F00F bug fixup for i386 - use conditional calls
On Fri, 1 Jun 2007 02:14:53 +0200 (MEST) Mikael Pettersson <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > > > * Andrew Morton ([EMAIL PROTECTED]) wrote: > > > > > > > > Use the faster conditional calls for F00F bug handling in > > > > > do_page_fault. > > > > > > > > > > > > > I guess this means that CONDCALL will be enabled on pretty much all > > > > i386, > > > > in which case making the whole feature Kconfigurable is starting to look > > > > marginal. > > > > > > > > Perhaps a better approach would have to made this change dependent upon > > > > CONDCALL, rather than forcing it on. > > > > > > > > > > Do you mean making X86_F00F_BUG depend on COND_CALL instead of selecting > > > it ? > > > > yup > > X86_F00F_BUG needs to be enabled in all kernels capable of booting on > P5 class machines, whether or not some obscure CONFIG_COND_CALL thingy > is enabled or not. X86_F00F_BUG is not some optional optimisation, it's > an essential workaround for a serious hardware bug. > > Therefore it seems select rather than depend is called for. Nope. CONFIG_COND_CALL=n -> do f00f handling the present way CONFIG_COND_CALL=y -> do f00f handling the new, fast-n-fancy way Because I don't think everyone will want to drag all this cond_call stuff into their kernel just for slightly faster f00f handling. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device hang when offlining a CPU due to IRQ misrouting
Hi there, I'm seeing a driver hang with 2.6.22-rc3 while being slightly stupid about offlining CPUs. I suspect that this problem extends beyond a particular machine, as I've been able to replicate it with an IBM x3650 and an IBM x3755. This is what I'm doing: 1) I tie an IRQ to a particular CPU via /proc/irq/XXX/smp_affinity (IRQ 4341 is the network card and we're picking on CPU1 in this example): echo 2 > /proc/irq/4341/smp_affinity 2) I then take CPU1 offline: echo 0 > /sys/devices/system/cpu/cpu1/online 3) The kernel prints this: [ 1101.968040] Breaking affinity for irq 4341 [ 1102.074019] CPU 1 is now offline [ 1102.081593] lockdep: not fixing up alternatives. [ 1112.886919] nfs: server 9.47.66.169 not responding, still trying After step 2 the system never sees interrupts from the network card and remains hung like that until CPU1 is brought back up. It looks as though the kernel is trying to reroute the IRQ (or so I'm assuming from the "Breaking affinity" message), but this doesn't ever happen, so the the kernel stops seeing interrupts from the device. Granted, one should not be offlining the CPU that is currently designated to handle an IRQ, but I suspect that the kernel ought at a minimum to reject the offlining or route the IRQ to any online CPU instead of screwing things up. There exists a similar scenario. Set the IRQ affinity to a bunch of CPUs, watch /proc/interrupts to see which CPU is actually servicing the interrupts, then offline that CPU. The kernel does not reroute the IRQ to any of the other CPUs and the device also hangs. The furthest that I've dug is that it works on 2.6.17 and is broken in 2.6.22-rc3 and 2.6.21. Will git-bisect further, but I wanted to know if anyone else has seen this sort of problem. afaik, this seems to happen with both IOAPIC and MSI interrupts, possibly more. --D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Thu, May 31, 2007 at 09:13:04PM -0300, Henrique de Moraes Holschuh wrote: > Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above > just makes KEY_UNKNOWN useful for something instead of keeping it as an > useless notice to the user that some key (which one? who knows!) was > pressed. Given existing userspace, it's never useful to generate KEY_UNKNOWN. Adding extra information to the event doesn't alter that. > Perhaps what you dislike re. KEY_UNKNOWN is the part where KEY_UNKNOWN+scan > code is declared to be the prefered way to report keys that do not have a > specific function? Your reply seems to indicate this, but I am not sure I > really understood what you meant. Yes. > I am not exactly in love with the idea of using KEY_UNKNOWN in place of > stuff like KEY_FN_F1 either (I'd prefer to just bump up KEY_MAX and have > more posicional keycodes), but Dmitry is being quite clear that he does not > want to increase KEY_MAX to add more positional keycodes. I think using positional keycodes would also be a mistake. We just need a slightly larger set of keycodes representing user-definable keys. There's 4 of them already - I really can't imagine there being many keyboards with a significantly larger set of unlabelled keys. -- Matthew Garrett | [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 2/5] console: console handover to preferred console
Andrew Morton wrote:
On Thu, 31 May 2007 13:58:26 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
[PATCH 2/5] console: console handover to preferred console
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/kernel/printk.c b/kernel/printk.c
index 0bbdeac..7b96cae 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -985,12 +1007,15 @@ void register_console(struct console *console)
if (!(console->flags & CON_ENABLED))
return;
- if (bootconsole) {
+ if (bootconsole && (console->flags & CON_CONSDEV)) {
printk(KERN_INFO "console handover: boot [%s%d] -> real
[%s%d]\n",
bootconsole->name, bootconsole->index,
console->name, console->index);
unregister_console(bootconsole);
console->flags &= ~CON_PRINTBUFFER;
+ } else {
+ printk(KERN_INFO "console [%s%d] enabled\n",
+ console->name, console->index);
}
/*
What does this change do, and what is the reason for it??
for earlyprintk=ttyS0,9600 console=tty0 console=ttyS0,9600n8
the handover will happen from earlyser0 to tty0. but what we want is to ttyS0.
later with patch4,
console=tty0 console=uart8250,io,0x3f8,9600n8
will handover to ttyS0 instead of tty0.
Maybe can put above lines into commit log.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] F00F bug fixup for i386 - use conditional calls
Andrew Morton wrote: > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton ([EMAIL PROTECTED]) wrote: > > > > > > Use the faster conditional calls for F00F bug handling in do_page_fault. > > > > > > > > > > I guess this means that CONDCALL will be enabled on pretty much all i386, > > > in which case making the whole feature Kconfigurable is starting to look > > > marginal. > > > > > > Perhaps a better approach would have to made this change dependent upon > > > CONDCALL, rather than forcing it on. > > > > > > > Do you mean making X86_F00F_BUG depend on COND_CALL instead of selecting > > it ? > > yup X86_F00F_BUG needs to be enabled in all kernels capable of booting on P5 class machines, whether or not some obscure CONFIG_COND_CALL thingy is enabled or not. X86_F00F_BUG is not some optional optimisation, it's an essential workaround for a serious hardware bug. Therefore it seems select rather than depend is called for. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Fri, 01 Jun 2007, Matthew Garrett wrote: > On Thu, May 31, 2007 at 07:28:14PM -0300, Henrique de Moraes Holschuh wrote: > > We have all the pieces needed to have sane, generic userland keyboard > > handling > > in place for a while now, but it was not sufficiently documented (or used!). > > > > If EV_KEY input drivers always generate scan codes that can be used to > > reprogram their keycode maps, and always generate EV_MSC MSC_SCAN events > > when > > they output an EV_KEY KEY_UNKNOWN event, userspace can trap those and feed > > it > > to a generic helper that can ask the user to assign a key code and function > > to > > that key. > > I still disagree that this is the best approach. Userspace already has > the functionality to map keys if they produce a keycode. Producing > KEY_UNKNOWN would require the implementation of a stack of extra code. Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above just makes KEY_UNKNOWN useful for something instead of keeping it as an useless notice to the user that some key (which one? who knows!) was pressed. Drivers already have KEY_RESERVED to mark positions in the keycode map for keys that should generate no events, so we are not forcing anyone to always generate useless events, either. Perhaps what you dislike re. KEY_UNKNOWN is the part where KEY_UNKNOWN+scan code is declared to be the prefered way to report keys that do not have a specific function? Your reply seems to indicate this, but I am not sure I really understood what you meant. I am not exactly in love with the idea of using KEY_UNKNOWN in place of stuff like KEY_FN_F1 either (I'd prefer to just bump up KEY_MAX and have more posicional keycodes), but Dmitry is being quite clear that he does not want to increase KEY_MAX to add more positional keycodes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 4/5] serial: convert early_uart to earlycon for 8250
Andrew Morton wrote: On Thu, 31 May 2007 14:01:33 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: Andrew, Please don't drop others if there is problem with this one. YH [PATCH 4/5] serial: convert early_uart to earlycon for 8250 +config FIX_EARLYCON_MEM + bool + depends on X86 + default y + It might have been nicer to do this in arch/i386/Kconfig and arch/x86_64/Kconfig. That way we don't end up with a great string of arch selectors in non-arch Kconfig files (do "grep SPARC */Kconfig*") otoh, doing that means that FIX_EARLYCON_MEM doesn't get mentioned in drivers/serial/Kconfig and you need to go on a great hunting expedition to find out who sets it. we could extend that to others arch that is support fixmap like ./asm-i386/fixmap.h ./asm-mips/fixmap.h ./asm-parisc/fixmap.h ./asm-sh/fixmap.h ./asm-sparc/fixmap.h ./asm-um/fixmap.h ./asm-x86_64/fixmap.h so it will be >> +config FIX_EARLYCON_MEM >> + bool >> + depends on X86 || MIPS || PARISC || SH || SPARC || UM >> + default y >> + You you can provide another config like CONFIG_FIXMAP YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] console: console handover to preferred console
On Thu, 31 May 2007 13:58:26 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH 2/5] console: console handover to preferred console
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index 0bbdeac..7b96cae 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -985,12 +1007,15 @@ void register_console(struct console *console)
> if (!(console->flags & CON_ENABLED))
> return;
>
> - if (bootconsole) {
> + if (bootconsole && (console->flags & CON_CONSDEV)) {
> printk(KERN_INFO "console handover: boot [%s%d] -> real
> [%s%d]\n",
> bootconsole->name, bootconsole->index,
> console->name, console->index);
> unregister_console(bootconsole);
> console->flags &= ~CON_PRINTBUFFER;
> + } else {
> + printk(KERN_INFO "console [%s%d] enabled\n",
> +console->name, console->index);
> }
>
> /*
What does this change do, and what is the reason for it??
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Syslets - Fix cachemiss_thread return value
> the demos I sent out. Dunno about the existing ones, but I bet they do > the same. Hmm, they didn't when I ran them, but I'll give yours a try and take a closer look. Thanks for taking the time to bring it up. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compact Flash performance...
Jeff Garzik wrote: Mark Lord wrote: To maximize throughput, some kind of host-queuing would be needed, or just have the driver sit in a tight loop, starting the next I/O immediately when the previous one finishes. Linux isn't that quick (yet). I was talking on IRC with Tejun just recently. There are several controllers (and/or "situations") like this, where some amount of host queueing would permit greater throughput, even when NCQ is not supported. sata_sx4 is the most dramatic example, where host queueing could potentially increase speed by a factor of 10 or more, since it is penalized by an awful two-irq-per-command (w/ a per-host bottleneck to boot) setup. Silicon Image has a "command buffer". And overall, I designed ->qc_prep() hook separate from ->qc_issue() to enable the prepartion of multiple commands such that it only takes a simple "go" I/O to start a transaction, immediately after the previous one ends. Jeff Theoretically NVIDIA nForce4 ADMA could likely do this as well, as it seems to allow chaining up multiple commands to execute in succession (assuming they're not NCQ).. -- 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: [PATCH 4/5] serial: convert early_uart to earlycon for 8250
On Thu, 31 May 2007 14:01:33 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> Please don't drop others if there is problem with this one.
>
> YH
>
> [PATCH 4/5] serial: convert early_uart to earlycon for 8250
>
> Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and
> include/asm-x86_64/serial.h. the serial8250_ports need to be probed late
> in serial initializing stage. the console_init=>serial8250_console_init=>
> register_console=>serial8250_console_setup will return -ENDEV, and console
> ttyS0 can not be enabled at that time.
> need to wait till uart_add_one_port in drivers/serial/serial_core.c to call
> register_console to get console ttyS0. that is too late.
>
> Make early_uart to use early_param, so uart console can be used earlier.
> Make it to be bootconsole with CON_BOOT flag, so can use console handover
> feature. and it will switch to corresponding normal serial console
> automatically.
>
> new command line will be:
> console=uart8250,io,0x3f8,9600n8
> console=uart8250,mmio,0xff5e,115200n8
> or
> earlycon=uart8250,io,0x3f8,9600n8
> earlycon=uart8250,mmio,0xff5e,115200n8
>
> it will print in very early stage:
> Early serial console at I/O port 0x3f8 (options '9600n8')
> console [uart0] enabled
> later for console it will print:
> console handover: boot [uart0] -> real [ttyS0]
>
> ...
>
> --- a/drivers/serial/8250_early.c
> +++ b/drivers/serial/8250_early.c
> @@ -32,17 +30,21 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#ifdef CONFIG_FIX_EARLYCON_MEM
> +#include
> +#include
> +#endif
>
> ...
>
> @@ -143,12 +144,18 @@ static int __init parse_options(struct
> early_uart_device *device, char *options)
> if (!strncmp(options, "mmio,", 5)) {
> port->iotype = UPIO_MEM;
> port->mapbase = simple_strtoul(options + 5, , 0);
> - port->membase = ioremap(port->mapbase, mapsize);
> +#ifdef CONFIG_FIX_EARLYCON_MEM
> + set_fixmap_nocache(FIX_EARLYCON_MEM_BASE, port->mapbase &
> PAGE_MASK);
> + port->membase = (void __iomem
> *)__fix_to_virt(FIX_EARLYCON_MEM_BASE);
> + port->membase += port->mapbase & ~PAGE_MASK;
> +#else
> + port->membase = ioremap(port->mapbase, 64);
ug. OK, that'll work. Simple and direct ;)
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
>
> ...
>
> +config FIX_EARLYCON_MEM
> + bool
> + depends on X86
> + default y
> +
It might have been nicer to do this in arch/i386/Kconfig and
arch/x86_64/Kconfig. That way we don't end up with a great string of arch
selectors in non-arch Kconfig files (do "grep SPARC */Kconfig*")
otoh, doing that means that FIX_EARLYCON_MEM doesn't get mentioned in
drivers/serial/Kconfig and you need to go on a great hunting expedition to
find out who sets it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Something goes wrong with timer statistics.
On 2007.05.30 02:13:50 +0200, Stephane Casset wrote:
> Le Tue, May 29, 2007 at 11:38:48PM +0200, Ian Kumlien écrivait :
> > Hi,
> >
> > As the daystar sets, i try to play some with my new would be
> > firewall/server, but since this will be running for quite some time i
> > have been experimenting with powertop to find out what i can do to limit
> > it's power usage.
> >
> > But, if i run powertop for too long or a few times to many... this
> > happens:
> > http://pomac.netswarm.net/pics/kernel_panic.jpg
> >
> > If i don't run powertop, it is rock solid... Compiling for hours,
> > running memtest for hours etc etc...
>
> Same here, P4 HT, if I run powertop for 5-10 minutes the system crash :(
> It happens with 2.6.22-rc{2,3} at least :( I didn't try before.
>
> I don't have a oops since the last crash was in X, but next time I will
> try to catch it. If there is any patch around to fix this I am willing
> to test.
There is finally one that seems to work:
http://lkml.org/lkml/2007/5/31/394
I'd be glad if you could give it a try.
Thanks,
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Syslets - Fix cachemiss_thread return value
On Thu, May 31, 2007 at 03:07:16PM -0700, Zach Brown wrote: > Can you explain what motivated you to send out this patch? > > It used to return 0. It was changed because, unlike the syslet > syscalls, sys_io_submit() doesn't have a simple 0 value to indicate > success. The current implementation wants to return the number of iocbs > that were processed, including the one which blocked, from the cachemiss > thread. So before calling into an operation it sets task_ret_ret() so > that the cachemiss thread can return it if it takes over. > task_ret_reg() is holding a return value that is being returned by the > cachemiss thread on behalf of a sys_io_submit() which blocked. > > When I made the change I didn't really audit its effect on the other > paths. I suppose it's time to do that, and you could help by telling me > if you saw something bad happen :). The bad thing was sys_async_exec returning -NOSYS every time a new cachemiss thread was created. Without this patch, you'll see sys_async_exec failures with either of the demos I sent out. Dunno about the existing ones, but I bet they do the same. Jeff -- Work email - jdike at linux dot intel dot 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: Compact Flash performance...
Hi Mark, On 31/05/07, Mark Lord <[EMAIL PROTECTED]> wrote: Daniel J Blueman wrote: > On 31/05/07, Mark Lord <[EMAIL PROTECTED]> wrote: >> Daniel J Blueman wrote: >> > Whoops, yes. Here is the expected data: > [snip] >> >> Thanks. I'll use that data to update/validate future versions of hdparm. >> At UDMA66, it *should* be capable of the 40MByte/sec realm of readback >> perf, >> assuming the card itself is really that fast. > > hdparm in the other identify mode does list the UDMA3/4 modes twice > [1], which looks odd. > >> I don't know too much about the specifics, though, but perhaps the >> card is only capable of full speed in PIO6, which requires special >> cabling >> and is currently unsupported in libata (?). > > Seems less likely, as the Extreme IV reader (and another) supports > UDMA mode 4; in PIO mode 6, they apparently top out at 17MB/s [2], > which seems reasonable. > >> Another factor, is that hdparm performs discrete, non-overlapping, >> reads of 1MByte chunks for its timing test. Some drives cannot achieve >> full performance with such (relatively) large gaps between IO's. > > 100MB transfers still achieve 32MB/s: > > # dd if=/dev/sdb of=/dev/null bs=10k count=10 > 10+0 records in > 10+0 records out > 102400 bytes (1.0 GB) copied, 31.9328 seconds, 32.1 MB/s > >> Also, just for fun, you could try "hdparm --direct -t /dev/sdb" > > # hdparm --direct -t /dev/sdb > > /dev/sdb: > Timing O_DIRECT disk reads: 96 MB in 3.05 seconds = 31.47 MB/sec > > It is conceivable that the controller in the two particular readers > which get 40MB/s are doing some kind of prefetching, but seems seems > like an extreme gain. Okay, here's the new hdparm information for this: [snip] *CFA advanced modes: pio5 *pio6 So, udma4 and pio6 are the fastest supported speeds. According to the CFA specifications (v4.1), either of those modes requires SHORT cables and special handling. You probably have regular (16-18") cables, and libata doesn't support PIO6, and the motherboard chipset may not support the "special handling" requirements in other ways. Also, only one device on the cable. It makes sense for Linux to default to normal cable lengths in absence of some mechanism to detect or specify this; in this case my CF card is plugged directly into the motherboard with a CF adapter [1], so one device, short traces. Anyway, I'd imagine the "special handling" and other requirements have been introduced/influenced by vendors, so possibly more special-cased than possible here. I see from your earlier posting that libata selected UDMA/66 (udma4) for the device though, since libata doesn't know that your cable is too long. And that mode is working, so that's probably as good as it gets on that particular motherboard chipset. I couldn't find a kernel parameter to specify if I have a long/short cable. Is there a way? Some cards may perform better when their "memory" interface is used instead of the "I/O" interface, or vice-versa. I'm not sure which of the two methods was selected by libata (probably the "memory" interface). There is also a "PC-Card" style interface with shared-memory, which some USB readers *may* use as an alternative to the standard IDE/ATA style interface. Cheers Thanks for the detail in the other mails too; it's useful, Daniel --- [1] http://img.inkfrog.com/pix/kitty.wun/Female_CF_type3.jpg -- Daniel J Blueman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/9] Scheduler profiling - Use conditional calls
On Wed, May 30, 2007 at 10:00:34AM -0400, Mathieu Desnoyers wrote:
>>> + if (prof_on)
>>> + BUG_ON(cond_call_arm("profile_on"));
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
>> What's the point of this BUG_ON()? The condition is a priori impossible.
On Thu, May 31, 2007 at 05:12:58PM -0400, Mathieu Desnoyers wrote:
> Not impossible: hash_add_cond_call() can return -ENOMEM if kmalloc lacks
> memory.
Shouldn't it just propagate the errors like anything else instead of
going BUG(), then? One can easily live without profiling if the profile
buffers should fail to be allocated e.g. due to memory fragmentation.
These things all have to handle errors for hotplugging anyway AIUI.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote: > David Chinner wrote: > >That sounds like a good idea - we can leave the existing > >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED > >behaviour that only guarantees ordering. The filesystem can then > >choose which to use where appropriate > > So what if you want a synchronous write, but DON'T care about the order? submit_bio(WRITE_SYNC, bio); Already there, already used by XFS, JFS and direct I/O. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/4] 2.6.22-rc3: known regressions
On Thu, 31 May 2007 16:17:00 -0700 Roland Dreier <[EMAIL PROTECTED]> wrote: > What about the changes to fix the order that MSI-X irqs are returned > in (iirc, list_add had to be changed to list_add_tail in a couple of > places). Without that change, multiple MSI-X interrupts seem to be > broken: the kernel programs the MSI-X table in the opposite order that > it gives the irq numbers to the driver. The net effect is that if I > request, say, 3 MSI-X interrupts for a device, then when the device > generates the first interrupt, the driver thinks it generated the > third interrupt, and things go fairly haywire. > That's msi-fix-the-ordering-of-msix-irqs.patch, which is also queued for the next batch. "next batch" == around 40 patches atm. Some of these need maintainer acks so they will be further delayed, or more likely just merged without the appropriate ack. From: "Eric W. Biederman" <[EMAIL PROTECTED]> "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> writes: Found what seems the problem with our vectors being listed backward. In drivers/pci/msi.c we should be using list_add_tail rather than list_add to preserve the ordering across various kernels. Please consider this for inclusion. Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]> Screwed-up-by: Michael Ellerman <[EMAIL PROTECTED]> Cc: "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/pci/msi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/pci/msi.c~msi-fix-the-ordering-of-msix-irqs drivers/pci/msi.c --- a/drivers/pci/msi.c~msi-fix-the-ordering-of-msix-irqs +++ a/drivers/pci/msi.c @@ -333,7 +333,7 @@ static int msi_capability_init(struct pc msi_mask_bits_reg(pos, is_64bit_address(control)), maskbits); } - list_add(>list, >msi_list); + list_add_tail(>list, >msi_list); /* Configure MSI capability structure */ ret = arch_setup_msi_irqs(dev, 1, PCI_CAP_ID_MSI); @@ -404,7 +404,7 @@ static int msix_capability_init(struct p entry->dev = dev; entry->mask_base = base; - list_add(>list, >msi_list); + list_add_tail(>list, >msi_list); } ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
On Thu, May 31, 2007 at 07:28:14PM -0300, Henrique de Moraes Holschuh wrote: > We have all the pieces needed to have sane, generic userland keyboard handling > in place for a while now, but it was not sufficiently documented (or used!). > > If EV_KEY input drivers always generate scan codes that can be used to > reprogram their keycode maps, and always generate EV_MSC MSC_SCAN events when > they output an EV_KEY KEY_UNKNOWN event, userspace can trap those and feed it > to a generic helper that can ask the user to assign a key code and function to > that key. I still disagree that this is the best approach. Userspace already has the functionality to map keys if they produce a keycode. Producing KEY_UNKNOWN would require the implementation of a stack of extra code. -- Matthew Garrett | [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: Compact Flash performance...
Mark Lord wrote: To maximize throughput, some kind of host-queuing would be needed, or just have the driver sit in a tight loop, starting the next I/O immediately when the previous one finishes. Linux isn't that quick (yet). I was talking on IRC with Tejun just recently. There are several controllers (and/or "situations") like this, where some amount of host queueing would permit greater throughput, even when NCQ is not supported. sata_sx4 is the most dramatic example, where host queueing could potentially increase speed by a factor of 10 or more, since it is penalized by an awful two-irq-per-command (w/ a per-host bottleneck to boot) setup. Silicon Image has a "command buffer". And overall, I designed ->qc_prep() hook separate from ->qc_issue() to enable the prepartion of multiple commands such that it only takes a simple "go" I/O to start a transaction, immediately after the previous one ends. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] improved locking performance in rt_run_flush()
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 20 May 2007 15:11:48 +1000
> David Miller <[EMAIL PROTECTED]> wrote:
> > From: Dave Johnson <[EMAIL PROTECTED]>
> >>
> >> The below patch changes rt_run_flush() to only take each spinlock
> >> protecting the rt_hash_table once instead of taking a spinlock for
> >> every hash table bucket (and ending up taking the same small set
> >> of locks over and over).
>
> ...
>
> > I'm not ignoring it I'm just trying to brainstorm whether there
> > is a better way to resolve this inefficiency. :-)
>
> The main problem I see with this is having to walk and free each
> chain with the lock held. We could avoid this if we had a pointer
> in struct rtable to chain them up for freeing later.
>
> I just checked and struct rtable is 236 bytes long on 32-bit but
> the slab cache pads it to 256 bytes so we've got some free space.
> I suspect 64-bit should be similar.
SLUB I believe packs more aggressively and won't pad things out like
that. Therefore adding a member to rtable is much less attractive.
I've been considering various alternative ways to deal with this.
For 2.6.22 and -stable's sake we could allocate an array of pointers
of size N where N is the number of rtable hash slots per spinlock.
A big lock wraps around rt_run_flush() to protect these slots, and
then the loop is:
grap_lock();
for_each_hash_chain_for_lock(i) {
rth = rt_hash_table[i].chain;
if (rth) {
rt_hash_table[i].chain = NULL;
flush_chain[i % N] = rt;
}
}
drop_lock();
for (i = 0; i < N; i++) {
struct rtable *rth = flush_chain[i];
flush_chain[i] = NULL;
while (rth) {
struct rtable *next = rth->u.dst.rt_next;
rt_free(rth);
rth = next;
}
}
Holding a lock across the entire hash plucking has it's not nice
properties, but it's better than taking the same lock N times in
a row.
In the longer term, if I resurrect my dynamically sized rtable hash
patches (which I do intend to do), that code protected a lot of this
stuff with a seqlock and it might be possible to use that seqlock
solely to flush the lists in rt_run_flush().
Any better ideas?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
Am Freitag, den 01.06.2007, 00:03 +0200 schrieb Markus Rechberger: > On 5/31/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: > > > timecop wrote: > > > >> Guys, it's GPL code. Fork the project and stop your bitching. > > > >> If you do a better job, people will use and contribute to your > > version. > > > >> If you do a worse job, people will use and contribute to Manu's. > > > >> Some will use and contribute to both. Life's good, eh? > > > > > > > > This is exactly why Linux is shit. > > > > You have 100s of "forked projects" because some guy named Uwe thought > > > > he could do better than some guy named Manu and now you have two > > > > projects to contribute to, both suck in various ways, of course some > > > > idiot is going to be "backporting" from one to another, introducing > > > > weird bugs, etc etc etc. > > > > > > > > Make a fucking decision and stick with it. Stop wasting everyone's > > > > time. It's no secret that current Linux-DVB/V4L/whatever system is a > > > > pile of steaming feces. Every one of you admitted to it on this list > > > > at some point in the past. So get to it, make a fucking decision, > > > > "fire" (loool) retards who are slowing the project down, and get shit > > > > moving. I vote for Uwe as Linux-DVB maintainer. > > > > Regards, > > > > tc > > > > > > I nominate Timecop to be maintainer/top cop to figure out which version > > > sucks in which area > > > and do his best to get the best approach used. Sometimes a good strong > > > and outspoken > > > manager is more important than technical prowess (and I have no idea as > > > to your technical > > > abilities, just saying it looks like a management issue). > > > > I am not a fan of "strong men" or "strong managers" of whatever kind. We in > > Germany have very bad experiences concerning this kind of human desire / > > call > > regarding our history. > > Instead there should be one responsible code reviewer for v4l stuff, and at > > least one responsible code reviewer for DVB stuff. > > This is a minimum adequate demand to make things work. > > > > Inactivity on future projects in connection with Nacks of activities to > > optimize the stock kernel are no fair play or helpful behaviour at all, but > > they are just counterproductive. Who likes small kings? Well, I do not! > > > > > > > > For Uwe, it's not that I don't "want" to understand anything - I just > > > showed up 2 days ago and > > > simply want a workable driver for my machine, and instead had to switch > > > cards to something > > > else. Usually I assume if the code was forked the fork would be > > > somewhere else and you wouldn't > > > be complaining to this list, but I understand there are different ways. > > > (Samba did it this way for > > > quite some time). > > > > Forking may be OK for different Linux distros. But v4l-DVB is not a distro, > > it > > should be a common project instead. > > > > What you find is some 20 developers with a multiplicity of repositories. > > You do not even know who is maintainer and who is not. > > What you also find is the blocking gesture of that person who once threw his > > hat into the ring wanting to become maintainer. > > As the whole situation is one big mess you do not even know whether becoming > > a > > maintainer or not is product of a democtratic vote. > > > > Above that there is no team structure at all, but instead there is a big > > chaos, mess. > > And if some code, may it be humble or mature, is not even pulled into the > > mm-tree (its basic role has always been testing, nothing else) I would call > > that a catastrophe. > > > > Uwe writes alot insulting crap (which is a fact), YES. > even if the DVB > subsystem has no maintainer the code should be managed appropriately > and stopping the development is no way to do it. > At the moment we have __tonns of critical bugs__ in the drivers and > the video4linux and dvb framework; both frameworks are incomplete and > don't provide the necessary flexibility to support an infrastructure > for devices which could already be supported at the moment. > > We have several (technical) good people which which work on the > framework on different parts but who don't cooperate at all and who > cannot work together at all. > We have alot code which is managed in separated repositories where > different developers spent several years of development (including > reverse engineering, hacking and so on) it's a shame that the whole > project is stuck where it is. New developers who fundamentally want to > change something are not welcome at all, even if they have valuable > ideas. > > Some developers are also sick of contributing since the whole > community is flawed at the moment. I propose a few ways to go YES. > * stopping that signed off by madness that every driver developer has > to sign off changes which happened at the core which will definitelly > never happen because people _do not like each other_.
Re: [PATCH] Introduce O_CLOEXEC (take >2)
On Thu, 31 May 2007 14:09:15 -0400 Ulrich Drepper <[EMAIL PROTECTED]> wrote: > I've brought this topic up before but didn't provide a patch. Well, here > we go again, this time with a patch. I even throw in a test program. > > The problem is as follows: in multi-threaded code (or more correctly: all > code using clone() with CLONE_FILES) we have a race when exec'ing. > >thread #1 thread #2 > >fd=open() > >fork + exec > > fcntl(fd,F_SETFD,FD_CLOEXEC) > > In some applications this can happen frequently. Take a web browser. One > thread opens a file and another thread starts, say, an external PDF viewer. > The result can even be a security issue if that open file descriptor refers > to a sensitive file and the external program can somehow be tricked into > using that descriptor. > > Just adding O_CLOEXEC support to open() doesn't solve the whole set of > problems. There are other ways to create file descriptors (socket, > epoll_create, Unix domain socket transfer, etc). These can and should > be addressed separately though. open() is such an easy case that it makes > not much sense putting the fix off. > > ... > > diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h > index c154b9d..b847741 100644 > --- a/include/asm-generic/fcntl.h > +++ b/include/asm-generic/fcntl.h > @@ -48,6 +48,9 @@ > #ifndef O_NOATIME > #define O_NOATIME0100 > #endif > +#ifndef O_CLOEXEC > +#define O_CLOEXEC0200/* set close_on_exec */ > +#endif > #ifndef O_NDELAY > #define O_NDELAY O_NONBLOCK > #endif This will break xtensa, because that architecture (and only that architecture) doesn't include asm-generic/fcntl.h from asm/fcntl.h. But let's leave this patch as-is: it's xtensa which needs fixing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/4] 2.6.22-rc3: known regressions
What about the changes to fix the order that MSI-X irqs are returned in (iirc, list_add had to be changed to list_add_tail in a couple of places). Without that change, multiple MSI-X interrupts seem to be broken: the kernel programs the MSI-X table in the opposite order that it gives the irq numbers to the driver. The net effect is that if I request, say, 3 MSI-X interrupts for a device, then when the device generates the first interrupt, the driver thinks it generated the third interrupt, and things go fairly haywire. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage
On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote: > git-ocfs2.patch Andrew, thanks for getting that back in there. mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared writable mmap. We hang on a page lock because ->page_mkwrite() is being called with the page already locked: + /* +* For consistency in subsequent calls, make the nopage_page always +* locked. +*/ + if (unlikely(!(vma->vm_flags & VM_CAN_INVALIDATE))) + lock_page(nopage_page); It wasn't previously being called with the page lock held, intentionally. --Mark -- Mark Fasheh Senior Software Developer, Oracle [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: [2/4] 2.6.22-rc3: known regressions
On Thu, 31 May 2007, Andrew Morton wrote: > > The status is "sitting in my queue for 2.6.22". I'll be sending it up > today or tomorrow. Was hoping to get an ack from Greg &/| Andi on it, but > those are not easy to come by. Well, it looks "Obviously Correct(tm)", since clearly the iounmap() should be done _after_ the last use. So I don't think it needs any more acking. But tomorrow is fine.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Add INPUT support to toshiba_acpi
On Thu, 2007-05-31 at 18:46 +0200, Andreas Mohr wrote:
> HCI_EMPTY is *by far* the most frequent state to occur I think
> (users won't press keys all the time), thus it's probably better(?)
> for branch prediction to have this placed first, right?
> Not that it matters too much instruction-wise, but still...
Sure.
> Apart from that I'm very happy to see progress on this front
> (speaking as a "proud" owner of an old Toshiba notebook requiring
> this stuff).
Good - this stuff should just work :-)
> And I'd definitely move the multiple identical "Re-enabled hotkeys" parts
> into one single non-inlined(!) function for the same reason.
> Not to mention that it's BUTT UGLY to have the *same* fat
> multi-line comment duplicated bazillion times.
Agree. New patch (untested) attached.
Thanks for review,
Richard.
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..38835b6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
depends on X86
select BACKLIGHT_CLASS_DEVICE
+ select INPUT_POLLDEV
---help---
This driver adds support for access to certain system settings
on "legacy free" Toshiba laptops. These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..f802609 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
* engineering the Windows drivers
* Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
* Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
*
* TODO
*
*/
-#define TOSHIBA_ACPI_VERSION "0.18"
+#define TOSHIBA_ACPI_VERSION "0.19"
#define PROC_INTERFACE_VERSION 1
#include
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -99,6 +100,16 @@ MODULE_LICENSE("GPL");
#define HCI_VIDEO_OUT_CRT 0x2
#define HCI_VIDEO_OUT_TV 0x4
+/* key definitions */
+#define HCI_HKEY_MUTE 0x0101
+#define HCI_HKEY_LOCK 0x013b
+#define HCI_HKEY_SEARCH 0x013c
+#define HCI_HKEY_SUSPEND 0x013d
+#define HCI_HKEY_HIBERNATE 0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN 0x0140
+#define HCI_HKEY_BRIGHTNESSUP 0x0141
+#define HCI_HKEY_WLAN 0x0142
+
/* utility
*/
@@ -213,9 +224,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
static int force_fan;
static int last_key_event;
static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
typedef struct _ProcItem {
const char *name;
@@ -438,34 +455,60 @@ static unsigned long write_fan(const char *buffer, unsigned long count)
return count;
}
-static char *read_keys(char *p)
+/* returns zero if hci event is invalid */
+static u32 get_hci_system_event_value(void)
{
u32 hci_result;
u32 value;
+ u32 retval = 0;
+
+ /* read a system event from the queue */
+ hci_read1(HCI_SYSTEM_EVENT, , _result);
+
+ switch (hci_result) {
+ case HCI_EMPTY:
+ /* better luck next time */
+ break;
+ case HCI_SUCCESS:
+ /* value is the data in the queue */
+ retval = value;
+ break;
+ case HCI_NOT_SUPPORTED:
+ /* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+ hci_write1(HCI_SYSTEM_EVENT, 1, _result);
+ printk(MY_NOTICE "Re-enabled hotkeys\n");
+ break;
+ default:
+ /* there was an unknown error */
+ printk(MY_ERR "Error reading hotkey status\n");
+ }
+ return retval;
+}
- if (!key_event_valid) {
- hci_read1(HCI_SYSTEM_EVENT, , _result);
- if (hci_result == HCI_SUCCESS) {
- key_event_valid = 1;
- last_key_event = value;
- } else if (hci_result == HCI_EMPTY) {
- /* better luck next time */
- } else if (hci_result == HCI_NOT_SUPPORTED) {
- /* This is a workaround for an unresolved issue on
- * some machines where system events sporadically
- * become disabled. */
- hci_write1(HCI_SYSTEM_EVENT, 1, _result);
- printk(MY_NOTICE "Re-enabled hotkeys\n");
- } else {
- printk(MY_ERR "Error reading hotkey status\n");
- goto end;
+/* deprecate this interface... */
+static char *read_keys(char *p)
+{
+ u32 value;
+
+ if (hotkeys_over_input) {
+ key_event_valid = 0;
+ last_key_event = 0;
+ } else {
+ if (!key_event_valid) {
+ value = get_hci_system_event_value();
+ if (value != 0) {
+key_event_valid = 1;
+last_key_event = value;
+ }
}
}
p += sprintf(p, "hotkey_ready:%d\n", key_event_valid);
p += sprintf(p, "hotkey: 0x%04x\n", last_key_event);
+ p += sprintf(p, "hotkeys_via_input: %d\n", hotkeys_over_input);
- end:
return p;
}
@@ -534,15 +577,103 @@ static acpi_status
Re: [BUG] Something goes wrong with timer statistics.
On 2007.06.01 00:59:11 +0200, Ian Kumlien wrote:
> On tor, 2007-05-31 at 17:27 +0200, Björn Steinbrink wrote:
> > On 2007.05.31 17:10:07 +0200, Eric Dumazet wrote:
> > > Well... :) , there is still a memory barrier missing it seems.
> > >
> > > Another cpu might see a bad value if 'active=1' is set before
> > > tstat_hash_table is really cleared.
> >
> > Hm, that even makes the assumption in my first try valid ;-)
> > Just for the record, this time I thought that the barrier from the
> > spinlock in timer_stats_update_stats (right before the check for active)
> > would be enough, but that's obviously running on the wrong cpu if we
> > race... *sigh*
> >
>
> Fix the comment below and you can add:
> Signed-off-by: Ian Kumlien <[EMAIL PROTECTED]>
>
> It's currently been running for the longest period ever, ie, 11 minutes
> =)
Finally! :-)
> I'm gonna leave it running during the night and send a status update
> when the evil daystar reaches it's peak CET. (i haven't been able to
> stop since linus mentioned it... damn it... =))
>
> > @@ -360,6 +364,7 @@ static ssize_t tstats_write(struct file *file, const
> > char __user *buf,
> > if (!active) {
> > reset_entries();
> > time_start = ktime_get();
> > + smb_mb();
>
> smb? you mean smp =)
No idea how I managed to break that after test compiling it... :-/
Thanks for catching it :-)
So unless I messed up something again, here's the final patch.
Thanks,
Björn
Fix two races in the timer stats lookup code. One by ensuring that the
initialization of a new entry is finished upon insertion of that entry.
The other by cleaning up the hash table when the entries array is
cleared, so that we don't have any "pre-inserted" entries.
Thanks to Eric Dumazet for reminding me of the memory barriers.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
Signed-off-by: Ian Kumlien <[EMAIL PROTECTED]>
---
diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c
index 868f1bc..fa3d380 100644
--- a/kernel/time/timer_stats.c
+++ b/kernel/time/timer_stats.c
@@ -117,21 +117,6 @@ static struct entry entries[MAX_ENTRIES];
static atomic_t overflow_count;
-static void reset_entries(void)
-{
- nr_entries = 0;
- memset(entries, 0, sizeof(entries));
- atomic_set(_count, 0);
-}
-
-static struct entry *alloc_entry(void)
-{
- if (nr_entries >= MAX_ENTRIES)
- return NULL;
-
- return entries + nr_entries++;
-}
-
/*
* The entries are in a hash-table, for fast lookup:
*/
@@ -149,6 +134,22 @@ static struct entry *alloc_entry(void)
static struct entry *tstat_hash_table[TSTAT_HASH_SIZE] __read_mostly;
+static void reset_entries(void)
+{
+ nr_entries = 0;
+ memset(entries, 0, sizeof(entries));
+ memset(tstat_hash_table, 0, sizeof(tstat_hash_table));
+ atomic_set(_count, 0);
+}
+
+static struct entry *alloc_entry(void)
+{
+ if (nr_entries >= MAX_ENTRIES)
+ return NULL;
+
+ return entries + nr_entries++;
+}
+
static int match_entries(struct entry *entry1, struct entry *entry2)
{
return entry1->timer == entry2->timer &&
@@ -202,12 +203,15 @@ static struct entry *tstat_lookup(struct entry *entry,
char *comm)
if (curr) {
*curr = *entry;
curr->count = 0;
+ curr->next = NULL;
memcpy(curr->comm, comm, TASK_COMM_LEN);
+
+ smp_mb(); /* Ensure that curr is initialized before insert */
+
if (prev)
prev->next = curr;
else
*head = curr;
- curr->next = NULL;
}
out_unlock:
spin_unlock(_lock);
@@ -360,6 +364,7 @@ static ssize_t tstats_write(struct file *file, const char
__user *buf,
if (!active) {
reset_entries();
time_start = ktime_get();
+ smp_mb();
active = 1;
}
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] support larger cifs network reads
With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.
A patch for the cifs client to support larger reads follows. In this
patch, using very large reads is not the default behavior, since it
would require larger buffer allocations for the large cifs request
buffers, but in the future when cifs can demultiplex reads to a page
list in the cifs_demultiplex_thread (without having to copy to a large
temporary buffer) this will be even more useful.
diff --git a/fs/cifs/README b/fs/cifs/README
index 4d01697..6ad722b 100644
--- a/fs/cifs/README
+++ b/fs/cifs/README
@@ -301,8 +301,19 @@ A partial list of the supported mount op
during the local client kernel build will be used.
If server does not support Unicode, this parameter is
unused.
- rsizedefault read size (usually 16K)
- wsizedefault write size (usually 16K, 32K is often better
over GigE)
+ rsizedefault read size (usually 16K). The client currently
+ can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
+ defaults to 16K and may be changed (from 8K to the maximum
+ kmalloc size allowed by your kernel) at module install time
+ for cifs.ko. Setting CIFSMaxBufSize to a very large value
+ will cause cifs to use more memory and may reduce performance
+ in some cases. To use rsize greater than 127K (the original
+ cifs protocol maximum) also requires that the server support
+ a new Unix Capability flag (for very large read) which some
+ newer servers (e.g. Samba 3.0.26 or later) do. rsize can be
+ set from a minimum of 2048 to a maximum of 8388608 (depending
+ on the value of CIFSMaxBufSize)
+ wsizedefault write size (default 57344)
maximum wsize currently allowed by CIFS is 57344 (14 4096 byte
pages)
rwmount the network share read-write (note that the
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index d38c69b..8c4365d 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -732,10 +732,21 @@ cifs_init_request_bufs(void)
/* Buffer size can not be smaller than 2 * PATH_MAX since maximum
Unicode path name has to fit in any SMB/CIFS path based frames */
CIFSMaxBufSize = 8192;
- } else if (CIFSMaxBufSize > 1024*127) {
- CIFSMaxBufSize = 1024 * 127;
} else {
- CIFSMaxBufSize &= 0x1FE00; /* Round size to even 512 byte mult*/
+ if (CIFSMaxBufSize + MAX_CIFS_HDR_SIZE > KMALLOC_MAX_SIZE) {
+ CIFSMaxBufSize = KMALLOC_MAX_SIZE - MAX_CIFS_HDR_SIZE;
+ cERROR(1,("CIFSMaxBufSize too large, resetting to %ld",
+ KMALLOC_MAX_SIZE));
+ }
+
+ /* The length field is 3 bytes, but for time being we use only
+* 23 of the available 24 length bits */
+ if (CIFSMaxBufSize > 8388608) {
+ CIFSMaxBufSize = 8388608;
+ cERROR(1,
+ ("CIFSMaxBufSize set to protocol max 8388608"));
+ } else /* round buffer size to even 512 byte multiple */
+ CIFSMaxBufSize &= 0x7FFE00;
}
/* cERROR(1,("CIFSMaxBufSize %d 0x%x",CIFSMaxBufSize,CIFSMaxBufSize)); */
cifs_req_cachep = kmem_cache_create("cifs_request",
diff --git a/fs/cifs/cifspdu.h b/fs/cifs/cifspdu.h
index d619ca7..6e6cda0 100644
--- a/fs/cifs/cifspdu.h
+++ b/fs/cifs/cifspdu.h
@@ -1885,15 +1885,19 @@ typedef struct {
#define CIFS_UNIX_POSIX_PATHNAMES_CAP 0x0010 /* Allow POSIX
path chars */
#define CIFS_UNIX_POSIX_PATH_OPS_CAP0x0020 /* Allow new POSIX
path based
calls including posix open
- and posix unlink */
+ and posix unlink */
+#define CIFS_UNIX_LARGE_READ_CAP0x0040 /* support reads >128K (up
+ to 0x00 */
+#define CIFS_UNIX_LARGE_WRITE_CAP 0x0080
+
#ifdef CONFIG_CIFS_POSIX
/* Can not set pathnames cap yet until we send new posix create SMB since
otherwise server can treat such handles opened with older ntcreatex
(by a new client which knows how to send posix path ops)
as non-posix handles (can affect write behavior with byte range locks.
We can add back in POSIX_PATH_OPS cap when Posix Create/Mkdir finished */
-/* #define CIFS_UNIX_CAP_MASK 0x003b */
-#define CIFS_UNIX_CAP_MASK 0x001b
+/* #define CIFS_UNIX_CAP_MASK
Re: [BUG] Something goes wrong with timer statistics.
On tor, 2007-05-31 at 17:27 +0200, Björn Steinbrink wrote:
> On 2007.05.31 17:10:07 +0200, Eric Dumazet wrote:
> > Well... :) , there is still a memory barrier missing it seems.
> >
> > Another cpu might see a bad value if 'active=1' is set before
> > tstat_hash_table is really cleared.
>
> Hm, that even makes the assumption in my first try valid ;-)
> Just for the record, this time I thought that the barrier from the
> spinlock in timer_stats_update_stats (right before the check for active)
> would be enough, but that's obviously running on the wrong cpu if we
> race... *sigh*
>
> Thanks,
> Björn
>
>
>
> Fix two races in the timer stats lookup code. One by ensuring that the
> initialization of a new entry is finished upon insertion of that entry.
> The other by cleaning up the hash table when the entries array is
> cleared, so that we don't have "pre-inserted" entries.
>
> Thanks to Eric Dumazet for reminding me of the memory barriers.
Fix the comment below and you can add:
Signed-off-by: Ian Kumlien <[EMAIL PROTECTED]>
It's currently been running for the longest period ever, ie, 11 minutes
=)
I'm gonna leave it running during the night and send a status update
when the evil daystar reaches it's peak CET. (i haven't been able to
stop since linus mentioned it... damn it... =))
> Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
> ---
> @@ -360,6 +364,7 @@ static ssize_t tstats_write(struct file *file, const char
> __user *buf,
> if (!active) {
> reset_entries();
> time_start = ktime_get();
> + smb_mb();
smb? you mean smp =)
> active = 1;
> }
> break;
--
Ian Kumlien -- http://pomac.netswarm.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.22-rc3: known regressions
On Thu, 31 May 2007 17:39:08 -0500
"Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 03:22:07PM -0700, Linus Torvalds wrote:
> >
> >
> > On Thu, 31 May 2007, Mike Miller (OS Dev) wrote:
> >
> > > On Wed, May 30, 2007 at 07:22:14PM -0700, Linus Torvalds wrote:
> > > >
> > > >
> > > > On Tue, 29 May 2007, Michal Piotrowski wrote:
> > > > >
> > > > > Subject: Oops on 2.6.22-rc2 when unloading the cciss driver
> > > > > References : http://lkml.org/lkml/2007/5/24/172
> > > > > Submitter : Mike Miller (OS Dev) <[EMAIL PROTECTED]>
> > > > > Status : Unknown
> > > >
> > > > I thought this one should be fixed by commit e9ca75b53. Not so?
> > >
> > > I apologize for the slow response. I also apologize that I don't know
> > > enough
> > > about git to figure out what commit e9ca75b53 does.
> >
> > Even without git, you can use the kernel.org gitweb install:
> >
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e9ca75b53
> >
> > (where the "h=" is the magic part - pick any commit SHA1 you want,
> > including short-hand ones like the one I gave).
> >
> > With git, you just do
> >
> > git show e9ca75b53
> >
> > to see a particular named commit.
> >
> > > I submitted a fix that was blessed by Eric B. that fixed that Oops.
> >
> > Ok, I don't think I have anything like that. The one I pointed to is the
> > one by Gerald Britton, acked by you ..
> >
> > But I now realize that that commit was already in -rc2. In fact, it's just
> > before the -rc2 release. So while it claims to fix one oops on shutdown,
> > it may be the _cause_ of the oops on mudule unload.
> >
> > Linus
> Linus,
> The fix from Gerald was a different Oops and is not related to this problem.
> This is the patch I submitted for the rmmod Oops:
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index e01380b..6632150 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -558,12 +558,12 @@ static int msi_free_irqs(struct pci_dev* dev)
>
> list_for_each_entry_safe(entry, tmp, >msi_list, list) {
> if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
> - if (list_is_last(>list, >msi_list))
> - iounmap(entry->mask_base);
> -
> writel(1, entry->mask_base +
> entry->msi_attrib.entry_nr
> * PCI_MSIX_ENTRY_SIZE
> + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> +
> + if (list_is_last(>list, >msi_list))
> + iounmap(entry->mask_base);
> }
> list_del(>list);
> kfree(entry);
>
> Reference:
> http://groups.google.com/group/linux.kernel/browse_frm/thread/ed0949e9d42cfdef/5953daaa00ea5bf7?lnk=gst=cciss=3=en#5953daaa00ea5bf7
>
> I'm not sure what the status is right now.
>
The status is "sitting in my queue for 2.6.22". I'll be sending it up
today or tomorrow. Was hoping to get an ack from Greg &/| Andi on it, but
those are not easy to come by.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
