Re: HDIO_DRIVE_CMD and hdparm

[Alan Cox]

>   - SCSI doesn't handle HDIO_DRIVE_CMD(null), and returns EINVAL
> => fine for hdparm
>   - If a block device doesn't support the ioctl, blkdev_driver_ioctl() returns
> ENOTTY
> => hdparm error message

Those are both correct
-ENOTTY I don't know this ioctl
-EINVAL I know this ioctl, usage wrong
0   Hey it worked

ENOIOCTLCMD Internal (not user exposed)
for fallthrough

ENOSYS  CD-ROM being weird.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Current -git kernel kills X

[Andi Kleen]

Jeff Garzik <[EMAIL PROTECTED]> writes:

> Hardware: x86-64 dual core, Intel ICH7 platform (see lspci), ATI R580
> Software: Fedora Core 6/x86-64, VESA driver, GNOME desktop, with
> latest updates

Can you try with the latest git again please? There was a fix that fixed
a similar problem for some people.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: trivial MLX4_DEBUG dependency fix.

[Paul Mundt]

On Thu, May 10, 2007 at 04:42:37AM -0700, Roland Dreier wrote:
>  > CONFIG_MLX4_DEBUG works out to a def_bool y for those that
>  > have CONFIG_EMBEDDED set. Make it depend on MLX4_CORE..
> 
> Thanks, applied...  (by the way, this bug just results in an
> extraneous CONFIG variable being defined, right?  There's no further
> breakage -- or am I misunderstanding the situation?)
> 
Correct, there was no real breakage, just the extraneous variable.
SLUB_DEBUG had the same symptoms, which is why I referenced it ;-)

>  > I'll let someone else wonder why debugging output is default enabled,
>  > this seems to be a worrying trend as of late.
> 
> Actually this option just controls whether to build the debugging
> output at all.  The output is controlled at runtime with a module
> parameter (which can be changed via sysfs after the module is loaded),
> and the output defaults to off.
> 
> The reason why I want building the debugging stuff to default to y is
> so that distros automatically build modules with debugging enabled.
> Otherwise it's a pain to try and gather info from someone who has
> problems with a kernel they didn't build.
> 
That's more reasonable at least. Thanks for the clarification.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 07/10] Linux Kernel Markers - Documentation

[Pekka Enberg]

On 5/10/07, Alan Cox <[EMAIL PROTECTED]> wrote:

"blobs of crap" - in whose opinion. Yours. So you don't want the kernel
to mention things you personally don't approve of. Thats straight forward
censorship and has no place in free software.


Out of kernel code comes and goes, so why mention it in-tree? Besides,
what's wrong with the suggested "can be used for tracing or
performance accounting?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] Re: mm snapshot broken-out-2007-05-10-03-06.tar.gz uploaded

[Michal Piotrowski]

Hi Jeremy,

[EMAIL PROTECTED] napisał(a):
> The mm snapshot broken-out-2007-05-10-03-06.tar.gz has been uploaded to
> 
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-05-10-03-06.tar.gz
> 

Bug reported here http://lkml.org/lkml/2007/4/25/400 is back.

[0.00] 
[0.00] | Locking API testsuite:
[0.00] 

[0.00]  | spin |wlock |rlock |mutex | 
wsem | rsem |
[0.00]   
--
[0.00]  A-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.00]  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.01]  A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.01]  A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.02]  A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.03]  A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.04]  A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.06] double unlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.06]   initialize held:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.06]  bad unlock order:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[0.07]   
--
[0.07]   recursive read-lock: |  ok  |  
   |  ok  |
[0.07]recursive read-lock #2: |  ok  |  
   |  ok  |
[0.07] mixed read-write-lock: |  ok  |  
   |  ok  |
[0.07] mixed write-read-lock: |  ok  |  
   |  ok  |
[0.07]   
--
[0.07]  hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[0.07]  soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[0.07]  hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[0.07]  soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[0.07]sirq-safe-A => hirqs-on/12:  ok  |  ok  |irq event stamp: 
472
[0.08] hardirqs last  enabled at (472): [] 
irqsafe2A_rlock_12+0xb6/0xc7
[0.08] hardirqs last disabled at (471): [] 
native_sched_clock+0x70/0x118
[0.08] softirqs last  enabled at (468): [] 
irqsafe2A_rlock_12+0xa1/0xc7
[0.08] softirqs last disabled at (464): [] 
irqsafe2A_rlock_12+0xc/0xc7
[0.08] FAILED| [] dump_trace+0x63/0x1eb
[0.08]  [] show_trace_log_lvl+0x1a/0x30
[0.08]  [] show_trace+0x12/0x14
[0.08]  [] dump_stack+0x16/0x18
[0.08]  [] dotest+0x8d/0x3f4
[0.08]  [] locking_selftest+0x915/0x1a58
[0.08]  [] start_kernel+0x27d/0x34f
[0.08]  ===
[0.08]
[0.08]sirq-safe-A => hirqs-on/21:irq event stamp: 476
[0.08] hardirqs last  enabled at (476): [] 
irqsafe2A_spin_21+0x1c/0xc7
[0.08] hardirqs last disabled at (475): [] 
native_sched_clock+0x70/0x118
[0.08] softirqs last  enabled at (468): [] 
irqsafe2A_rlock_12+0xa1/0xc7
[0.08] softirqs last disabled at (464): [] 
irqsafe2A_rlock_12+0xc/0xc7
[0.08]   ok  |irq event stamp: 480
[0.08] hardirqs last  enabled at (480): [] 
irqsafe2A_wlock_21+0x1c/0xc7
[0.08] hardirqs last disabled at (479): [] 
native_sched_clock+0x70/0x118
[0.08] softirqs last  enabled at (468): [] 
irqsafe2A_rlock_12+0xa1/0xc7
[0.08] softirqs last disabled at (464): [] 
irqsafe2A_rlock_12+0xc/0xc7
[0.08]   ok  |irq event stamp: 484
[0.08] hardirqs last  enabled at (484): [] 
irqsafe2A_rlock_21+0x1c/0xc7
[0.08] hardirqs last disabled at (483): [] 
native_sched_clock+0x70/0x118
[0.08] softirqs last  enabled at (468): [] 
irqsafe2A_rlock_12+0xa1/0xc7
[0.08] softirqs last disabled at (464): [] 
irqsafe2A_rlock_12+0xc/0xc7
[0.08] FAILED| [] dump_trace+0x63/0x1eb
[0.08]  [] show_trace_log_lvl+0x1a/0x30
[0.08]  [] show_trace+0x12/0x14
[0.08]  [] dump_stack+0x16/0x18
[0.08]  [] dotest+0x8d/0x3f4
[0.08]  [] locking_selftest+0x96b/0x1a58
[0.08]  [] start_kernel+0x27d/0x34f
[0.08]  ===
[0.08]
[0.08]  hard-safe-A + irqs-on/12:  ok  |  ok  |irq event stamp: 
500
[0.08] hardirqs last  enabled at (500): [] 
irqsafe2B_hard_rlock_12+0xaf/0xc0
[0.08] hardirqs last disabled at (499): [] 
native_sched_clock+0x70/0x118
[0.08] softirqs last  enabled at (468): [] 
irqsafe2A_rlock_12+0xa1

Re: [PATCH 002 of 2] md: Improve the is_mddev_idle test

[Jan Engelhardt]

On May 10 2007 20:04, Neil Brown wrote:
>> >-   if ((curr_events - rdev->last_events + 4096) > 8192) {
>> >+   if ((long)curr_events - (long)rdev->last_events > 4096) {
>> >rdev->last_events = curr_events;
>> >idle = 0;
>> >}
>> 
>/* sync IO will cause sync_io to increase before the disk_stats
> * as sync_io is counted when a request starts, and 
> * disk_stats is counted when it completes.
> * So resync activity will cause curr_events to be smaller than
> * when there was no such activity.
> * non-sync IO will cause disk_stat to increase without
> * increasing sync_io so curr_events will (eventually)
> * be larger than it was before.  Once it becomes
> * substantially larger, the test below will cause
> * the array to appear non-idle, and resync will slow
> * down.
> * If there is a lot of outstanding resync activity when
> * we set last_event to curr_events, then all that activity
> * completing might cause the array to appear non-idle
> * and resync will be slowed down even though there might
> * not have been non-resync activity.  This will only
> * happen once though.  'last_events' will soon reflect
> * the state where there is little or no outstanding
> * resync requests, and further resync activity will
> * always make curr_events less than last_events.
> *
> */
>
>Does that read at all well?

It is a more verbose explanation of your patch description, yes.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ixp4xx compile error (was Re: 2.6.21-mm2)

[Dmitry Torokhov]

On 5/10/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote:


 static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, 
unsigned int code, int value)
 {
-   unsigned int pin = (unsigned int) input_get_drvdata(input_dev);
+   unsigned int pin = (unsigned int) input_get_drvdata(dev);
   unsigned int count = 0;



Yep, my fault. Please forward this to Linus.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] ext2: remove inode constructor

[Pekka Enberg]

On 5/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

ext2 has no truncate_mutex.


I think it does:

-   mutex_init(&ei->truncate_mutex);
-   inode_init_once(&ei->vfs_inode);
-   }
-}

And fs/ext2/super.c:init_once() from 2.6.21-mm2 says:

   mutex_init(&ei->truncate_mutex);
   inode_init_once(&ei->vfs_inode);
   }
}

Hmm?

On 5/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

These patches are rather tangled up with the unmerged __GFP_RECLAIMABLE
stuff.  I'll duck them for now.


Ok. I would appreciate any kind of heads-up when you're ready to eat
these patches again. ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix bug in mm/thrash.c function grab_swap_token()

[Mika Kukkonen]

Following bug was uncovered by compiling with '-W' flag:

  CC  mm/thrash.o
mm/thrash.c: In function ‘grab_swap_token’:
mm/thrash.c:52: warning: comparison of unsigned expression < 0 is always false

Field token_priority is unsigned, so decrementing first and the checking
is not a good plan. Attached patch (compile tested) reverses the order.

Btw, I'm not sure if likely() makes any sense in this new situation.

Signed-off-by: Mika Kukkonen <[EMAIL PROTECTED]>

diff --git a/mm/thrash.c b/mm/thrash.c
index 9ef9071..c4c5205 100644
--- a/mm/thrash.c
+++ b/mm/thrash.c
@@ -48,9 +48,8 @@ void grab_swap_token(void)
if (current_interval < current->mm->last_interval)
current->mm->token_priority++;
else {
-   current->mm->token_priority--;
-   if (unlikely(current->mm->token_priority < 0))
-   current->mm->token_priority = 0;
+   if (likely(current->mm->token_priority > 0))
+   current->mm->token_priority--;
}
/* Check if we deserve the token */
if (current->mm->token_priority >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add driver for Dallas DS1682 elapsed time recorder

[Alessandro Zummo]

On Thu, 10 May 2007 13:48:50 +0200
Jean Delvare <[EMAIL PROTECTED]> wrote:

> I know this isn't exactly a RTC chip, but this is still related with
> timekeeping, so wouldn't it be better placed under drivers/rtc?
> Alessandro, what do you think?

 Hi,

   I don't know if the rtc subsystem can offer help/framework
 for such a kind of driver. maybe it could be extended to 
 incorporate it. probably the alarms could be handled
 in some way.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.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 7/12] i386 sg: add support for chaining scatterlists

[Satyam Sharma]

Hi Jens,

On 5/10/07, Jens Axboe <[EMAIL PROTECTED]> wrote:

The core of the patch - allow the last sg element in a scatterlist
table to point to the start of a new table. We overload the LSB of
the page pointer to indicate whether this is a valid sg entry, or
merely a link to the next list.

Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
 include/asm-i386/scatterlist.h |2 +
 include/linux/scatterlist.h|   52 ++-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/asm-i386/scatterlist.h b/include/asm-i386/scatterlist.h
index d7e45a8..bd5164a 100644
--- a/include/asm-i386/scatterlist.h
+++ b/include/asm-i386/scatterlist.h
@@ -10,6 +10,8 @@ struct scatterlist {
 unsigned int   length;
 };

+#define ARCH_HAS_SG_CHAIN
+
 /* These macros should be used after a pci_map_sg call has been done
  * to get bus addresses of each of the SG entries and their lengths.
  * You should only work with the number of sg entries pci_map_sg
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index bed5ab4..fa2dc1c 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
[...]
+/*
+ * We could improve this by passing in the maximum size of an sglist, so
+ * we could jump directly to the last table. That would eliminate this
+ * (potentially) lengthy scan.
+ */
+static inline struct scatterlist *sg_last(struct scatterlist *sgl,
+ unsigned int nents)
+{
+#ifdef ARCH_HAS_SG_CHAIN
+   struct scatterlist *ret = &sgl[nents - 1];
+#else
+   struct scatterlist *sg, *ret = NULL;
+   int i;
+
+   for_each_sg(sgl, sg, nents, i)
+   ret = sg;
+
+#endif
+   return ret;
+}
+
+/*
+ * Chain previous sglist to this one
+ */
+static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
+   struct scatterlist *sgl)
+{
+#ifndef ARCH_HAS_SG_CHAIN
+   BUG();
+#endif
+   prv[prv_nents - 1].page = (struct page *) ((unsigned long) sgl | 0x01);
+}
+
 #endif /* _LINUX_SCATTERLIST_H */


(Style triviality)

In include/linux/scatterlist.h, why not simply:

#ifdef ARCH_HAS_SG_CHAIN


+/*
+ * We could improve this by passing in the maximum size of an sglist, so
+ * we could jump directly to the last table. That would eliminate this
+ * (potentially) lengthy scan.
+ */
+static inline struct scatterlist *sg_last(struct scatterlist *sgl,
+ unsigned int nents)
+{
+   struct scatterlist *ret = &sgl[nents - 1];
+   return ret;
+}
+
+/*
+ * Chain previous sglist to this one
+ */
+static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
+   struct scatterlist *sgl)
+{
+   prv[prv_nents - 1].page = (struct page *) ((unsigned long) sgl | 0x01);
+}


#else


+/*
+ * We could improve this by passing in the maximum size of an sglist, so
+ * we could jump directly to the last table. That would eliminate this
+ * (potentially) lengthy scan.
+ */
+static inline struct scatterlist *sg_last(struct scatterlist *sgl,
+ unsigned int nents)
+{
+   struct scatterlist *sg, *ret = NULL;
+   int i;
+
+   for_each_sg(sgl, sg, nents, i)
+   ret = sg;
+
+   return ret;
+}
+
+/*
+ * Chain previous sglist to this one
+ */
+static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
+   struct scatterlist *sgl)
+{
+   BUG();
+}


#endif /* ARCH_HAS_SG_CHAIN */

Similar to most of the other headers I've seen, and avoids multiple
usage if #ifdef / #ifndef.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 07/10] Linux Kernel Markers - Documentation

[Alan Cox]

On Thu, 10 May 2007 15:52:26 +0300
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:

> On 5/10/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > "blobs of crap" - in whose opinion. Yours. So you don't want the kernel
> > to mention things you personally don't approve of. Thats straight forward
> > censorship and has no place in free software.
> 
> Out of kernel code comes and goes, so why mention it in-tree? Besides,
> what's wrong with the suggested "can be used for tracing or
> performance accounting?"

Because people want to know what it is really for ? It's quite amazing
really at the same time as people are posting crypto keys everywhere in
defiance of USSA law, we've got free software people trying to remove
references to a piece of out of tree software, and one that is free
software. 

And as I keep saying the tree is full of references to out of tree stuff.
The documentation directory alone currently contains over a thousand http
URLS as of 2.6.21-rc6-mm1.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Andi, you broke my laptop :-)

[Andi Kleen]

On Wed, May 09, 2007 at 12:56:16PM -0700, Pete Zaitcev wrote:
> Hi, Andi:
> 
> The attached patch (actually, git show output) makes my Dell 1501 to hang
> on boot. Sorry, I have no clue why... The culprit is found with git bisect.
> But yes, it's an AMD MK-36. I use an x86_64 kernel. It is 100% reproducible.

MK-36? Does it have SVM? 

Anyways we previously had issues with this being miscompiled, but 
I thought the latest patch should have been ok. What compiler do you use?

Can you send me a disassembly listing of arch/x86_64/kernel/time.o?

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 02/10] Linux Kernel Markers, architecture independent code.

[Mathieu Desnoyers]

Hi Alexey,

* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
> On Wed, May 09, 2007 at 09:55:57PM -0400, Mathieu Desnoyers wrote:
> > --- /dev/null
> > +++ linux-2.6-lttng/include/linux/marker.h
> > @@ -0,0 +1,124 @@
> 
> > +#ifdef __KERNEL__
> 
> Just don't add this file to include/linux/Kbuild and remove __KERNEL__
> ifdef.
> 
> > --- linux-2.6-lttng.orig/include/linux/module.h
> > +++ linux-2.6-lttng/include/linux/module.h
> > @@ -356,6 +356,9 @@
> > /* The command line arguments (may be mangled).  People like
> >keeping pointers to this stuff */
> > char *args;
> > +
> > +   const struct __mark_marker *markers;
> > +   unsigned int num_markers;
> 
> #ifdef CONFIG_MARKERS, please.
> 

Ok, I merged the patch from SystemTAP to help them parse the markers
section, but seeing the violent objections it gets, I guess they will
have to figure out another way to parse it. Let's drop the
allow-userspace-applications-to-use-markerh-to-parse-the-markers-section-in-the-kernel-binary.patch
then.


> > --- linux-2.6-lttng.orig/kernel/module.c
> > +++ linux-2.6-lttng/kernel/module.c
> 
> > @@ -1659,6 +1884,9 @@
> > unsigned int unusedcrcindex;
> > unsigned int unusedgplindex;
> > unsigned int unusedgplcrcindex;
> > +   unsigned int markersindex;
> > +   unsigned int markersdataindex;
> > +   unsigned int markersstringsindex;
> 
> Bunch of underscores wouldn't hurt.
> 

Hrm, I used the exact same variable naming style already present in the
function. Do you suggest changing _every_ variable name to underscores ?

> > +void list_modules(void)
> > +{
> > +   /* Enumerate loaded modules */
> > +   struct list_head*i;
> > +   struct module   *mod;
> > +   unsigned long refcount = 0;
> > +
> > +   mutex_lock(&module_mutex);
> > +   list_for_each(i, &modules) {
> > +   mod = list_entry(i, struct module, list);
> > +#ifdef CONFIG_MODULE_UNLOAD
> > +   refcount = local_read(&mod->ref[0].count);
>   ^
> Buy second CPU, already. ;-)
>

Good catch, will fix. I do already have more than one, don't worry ;)

> > +#endif //CONFIG_MODULE_UNLOAD
> > +   trace_mark(list_module, "%s %d %lu",
> > +   mod->name, mod->state, refcount);
> > +   }
> > +   mutex_unlock(&module_mutex);
> > +}
> 

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

Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop

[Remi Colinet]

Hello,

My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch.
No problem noticed with 2.6.21.

The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21
and then removed git-input patch. It is ok since then.

>From what i can see, no interrupt is raised from the GlidePoint with git-input
applied. IRQ count 12 does not increase. It is when using the touchpad.

   CPU0
  0:160   IO-APIC-edge  timer
  1:935   IO-APIC-edge  i8042
  7:  0   IO-APIC-edge  parport0
  8:  1   IO-APIC-edge  rtc
  9:  2   IO-APIC-fasteoi   acpi
=> 12:114   IO-APIC-edge  i8042 <=
 14:   3223   IO-APIC-edge  libata
 15:  5   IO-APIC-edge  libata
 16:  0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6
 17:  1   IO-APIC-fasteoi   uhci_hcd:usb2, ipw2200, Intel ICH6 Modem
 18:  0   IO-APIC-fasteoi   uhci_hcd:usb3
 19:  1   IO-APIC-fasteoi   uhci_hcd:usb4, yenta
NMI:  0
LOC:   4051
ERR:  0
MIS:  0

I have also tried to disable the ALPS driver in the .config file. IRQ 12 are
then raised when using the Glide Point. X refuses to start.

Any idea?

Remi Colinet

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Allow compat_ioctl.c to compile without CONFIG_NET

[Andi Kleen]

On Thu, May 10, 2007 at 06:41:20PM +0900, Simon Horman wrote:
> A small regression appears to have been introduced in the recent patch
> "cleanup compat ioctl handling", which was included in Linus' tree after
> 2.6.20.
> 
> siocdevprivate_ioctl() is no longer defined if CONFIG_NET is undefined,
> whereas previously it was a dummy function in this case.
> 
> This causes compilation with CONFIG_COMPAT but without CONFIG_NET to fail.
> 
> fs/compat_ioctl.c: In function `compat_sys_ioctl':
> fs/compat_ioctl.c:3571: warning: implicit declaration of function 
> `siocdevprivate_ioctl'
> 

Thanks makes sense. I assume Andrew will just pass it on.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata reset-seq merge broke sata_sil on sh

[Tejun Heo]

Paul Mundt wrote:
> Yes, it's spun down at boot. I'll get the logs with the timestamps and
> the results of the mdelay() incrementing in the morning when I've got the
> board handy again.

I see.  That's where the expected initial prereset failure comes from.

> On Thu, May 10, 2007 at 01:53:48PM +0200, Tejun Heo wrote:
>> * According to the report, things still work till 27c78b37 - commit for
>> the actual merge and there's no related change till the current master
>> from there.  So, which commit actually breaks detection?  Or is
>> detection just flaky after b8cffc6a?
>>
> The detection is simply flaky after that point, however before the
> current master it never hit the 35 second point (and thus never implied
> that the link was down). I'll double check the bisect log to see if there
> was anything beyond that that may have caused it.
> 
> The -ENODEV at least implies that the SRST fails, so at least that's a
> starting point.

If prereset() fails to get the initial DRDY before 10secs, it assumes
something went wrong and escalates to hardreset.  sil family of
controllers report 0xff status while the link is broken and it seems
that your particular drive needs more than the current 150ms to recover
phy link.  It probably went unnoticed till now because the device was
never hardreset before.  If the diagnosis is correct, increasing the
delay in hardreset should fix the problem.  Well, let's see.  :-)

> One other curious thing is that it seems to misreport the IRQ. In this
> case the log indicates 0, whereas it's actually on IRQ 66. When the
> system is booted, /proc/interrupts reflects that sata_sil is on the
> proper IRQ (even when it's reported as 0 in the boot printk()).

That's somthing I've missed during init model conversion.  It's just
printk problem.  I'll fix it.

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 06/10] Linux Kernel Markers - Non optimized architectures

[Mathieu Desnoyers]

Linux Kernel Markers - Non Optimized Architectures fix 2

Fix comments in headers
- Remove Copyright notice in one-liner header
- Transfer generic header note "using asm to fix a gcc bug" to where it belongs
  now : in linux/marker.h.
- Fix optimisation -> optimization typo in powerpc and i386 headers.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
 include/asm-arm/marker.h   |   12 
 include/asm-cris/marker.h  |   12 
 include/asm-frv/marker.h   |   12 
 include/asm-generic/marker.h   |   12 
 include/asm-h8300/marker.h |   12 
 include/asm-i386/marker.h  |2 +-
 include/asm-ia64/marker.h  |   12 
 include/asm-m32r/marker.h  |   12 
 include/asm-m68k/marker.h  |   12 
 include/asm-m68knommu/marker.h |   12 
 include/asm-mips/marker.h  |   12 
 include/asm-parisc/marker.h|   12 
 include/asm-powerpc/marker.h   |2 +-
 include/asm-ppc/marker.h   |   12 
 include/asm-s390/marker.h  |   12 
 include/asm-sh/marker.h|   12 
 include/asm-sh64/marker.h  |   12 
 include/asm-sparc/marker.h |   12 
 include/asm-sparc64/marker.h   |   12 
 include/asm-um/marker.h|   12 
 include/asm-v850/marker.h  |   12 
 include/asm-x86_64/marker.h|   12 
 include/asm-xtensa/marker.h|   12 
 include/linux/marker.h |4 +++-
 24 files changed, 5 insertions(+), 255 deletions(-)

Index: linux-2.6-lttng/include/asm-arm/marker.h
===
--- linux-2.6-lttng.orig/include/asm-arm/marker.h   2007-05-10 
09:02:16.0 -0400
+++ linux-2.6-lttng/include/asm-arm/marker.h2007-05-10 09:02:31.0 
-0400
@@ -1,13 +1 @@
-/*
- * marker.h
- *
- * Code markup for dynamic and static tracing. Architecture specific
- * optimisations.
- *
- * No optimisation implemented.
- *
- * This file is released under the GPLv2.
- * See the file COPYING for more details.
- */
-
 #include 
Index: linux-2.6-lttng/include/asm-cris/marker.h
===
--- linux-2.6-lttng.orig/include/asm-cris/marker.h  2007-05-10 
09:02:16.0 -0400
+++ linux-2.6-lttng/include/asm-cris/marker.h   2007-05-10 09:02:35.0 
-0400
@@ -1,13 +1 @@
-/*
- * marker.h
- *
- * Code markup for dynamic and static tracing. Architecture specific
- * optimisations.
- *
- * No optimisation implemented.
- *
- * This file is released under the GPLv2.
- * See the file COPYING for more details.
- */
-
 #include 
Index: linux-2.6-lttng/include/asm-frv/marker.h
===
--- linux-2.6-lttng.orig/include/asm-frv/marker.h   2007-05-10 
09:02:16.0 -0400
+++ linux-2.6-lttng/include/asm-frv/marker.h2007-05-10 09:02:38.0 
-0400
@@ -1,13 +1 @@
-/*
- * marker.h
- *
- * Code markup for dynamic and static tracing. Architecture specific
- * optimisations.
- *
- * No optimisation implemented.
- *
- * This file is released under the GPLv2.
- * See the file COPYING for more details.
- */
-
 #include 
Index: linux-2.6-lttng/include/asm-generic/marker.h
===
--- linux-2.6-lttng.orig/include/asm-generic/marker.h   2007-05-10 
09:02:17.0 -0400
+++ linux-2.6-lttng/include/asm-generic/marker.h2007-05-10 
09:04:14.0 -0400
@@ -1,18 +1,6 @@
 #ifndef _ASM_GENERIC_MARKER_H
 #define _ASM_GENERIC_MARKER_H
 
-/*
- * marker.h
- *
- * Code markup for dynamic and static tracing. Generic header.
- *
- * This file is released under the GPLv2.
- * See the file COPYING for more details.
- *
- * Note : the empty asm volatile with read constraint is used here instead of a
- * "used" attribute to fix a gcc 4.1.x bug.
- */
-
 #define _MF_DEFAULT(_MF_LOCKDEP | _MF_PRINTK)
 
 #define MARK_OPTIMIZED MARK_GENERIC
Index: linux-2.6-lttng/include/asm-h8300/marker.h
===
--- linux-2.6-lttng.orig/include/asm-h8300/marker.h 2007-05-10 
09:02:17.0 -0400
+++ linux-2.6-lttng/include/asm-h8300/marker.h  2007-05-10 09:04:23.0 
-0400
@@ -1,13 +1 @@
-/*
- * marker.h
- *
- * Code markup for dynamic and static tracing. Architecture specific
- * optimisations.
- *
- * No optimisation implemented.
- *
- * This file is released under the GPLv2.
- * See the file COPYING for more details.
- */
-
 #include 
Index: linux-2.6-lttng/include/asm-i386/marker.h
===
--- linux-2.6-lttng.orig/include/asm-i386/marker.h  2007-05-10 
09:02:17.0 -0400
+++ linux-2.6-lttng/include/asm-i386/marker.h   2007-05-10 09:05:06.0

Re: [patch 02/10] Linux Kernel Markers, architecture independent code.

[Mathieu Desnoyers]

Linux Kernel Markers - Architecture Independant Code fix 2

Fix trivial SMP bug in list_modules.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
 kernel/module.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/kernel/module.c
===
--- linux-2.6-lttng.orig/kernel/module.c2007-05-10 08:51:02.0 
-0400
+++ linux-2.6-lttng/kernel/module.c 2007-05-10 08:51:06.0 -0400
@@ -2657,13 +2657,16 @@
/* Enumerate loaded modules */
struct list_head*i;
struct module   *mod;
-   unsigned long refcount = 0;
+   unsigned long refcount;
+   int cpu;
 
mutex_lock(&module_mutex);
list_for_each(i, &modules) {
mod = list_entry(i, struct module, list);
+   refcount = 0;
 #ifdef CONFIG_MODULE_UNLOAD
-   refcount = local_read(&mod->ref[0].count);
+   for_each_online_cpu(cpu)
+   refcount += local_read(&mod->ref[cpu].count);
 #endif //CONFIG_MODULE_UNLOAD
trace_mark(list_module, "%s %d %lu",
mod->name, mod->state, refcount);

-- 
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: HDIO_DRIVE_CMD and hdparm

[Mark Lord]

Alan Cox wrote:

  - SCSI doesn't handle HDIO_DRIVE_CMD(null), and returns EINVAL
=> fine for hdparm
  - If a block device doesn't support the ioctl, blkdev_driver_ioctl() returns
ENOTTY
=> hdparm error message


Those are both correct
-ENOTTY I don't know this ioctl
-EINVAL I know this ioctl, usage wrong


Exactly.
I'll have hdparm-7.4 not complain on ENOTTY as well.

-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 07/10] Linux Kernel Markers - Documentation

[Pekka J Enberg]

On Thu, 10 May 2007, Alan Cox wrote:
> Because people want to know what it is really for ? It's quite amazing
> really at the same time as people are posting crypto keys everywhere in
> defiance of USSA law, we've got free software people trying to remove
> references to a piece of out of tree software, and one that is free
> software. 

Oh, I am not advocating censorship. I was merely pointing out that it 
seems silly to mention out-of-tree users because they come and go. Who 
knows whether LTTng or SystemTAP will be relevant five years from now? 
Besides, are we sure the document includes all potential users now? We 
wouldn't want to show favorism to any particular projects, now would we?

On Thu, 10 May 2007, Alan Cox wrote: 
> And as I keep saying the tree is full of references to out of tree stuff.
> The documentation directory alone currently contains over a thousand http
> URLS as of 2.6.21-rc6-mm1.

Many of the already out of date or expiring in the near future... But 
whatever, I don't care too much. Just wanted to say the review comment 
makes sense to me.

Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Performance Stats: Kernel patch

[Maxim Uvarov]

I'm sending here the latest version of this patch.
Seems it was not on lkml mail list.

Patch makes available to the user the following
task and process performance statistics:
* Involuntary Context Switches (task_struct->nivcsw)
* Voluntary Context Switches (task_struct->nvcsw)
* Number of system calls (added new counter
  thread_info->sysall_count)
   
Statistics information is available from:
1. taskstats interface (Documentation/accounting/)
2. /proc/PID/status (task only).

This data is useful for detecting hyperactivity
patterns between processes.

Signed-off-by: Maxim Uvarov <[EMAIL PROTECTED]>

Signed-off-by: Maxim Uvarov <[EMAIL PROTECTED]> 
 
---

 Documentation/accounting/getdelays.c  |   20 ++--
 Documentation/accounting/taskstats-struct.txt |7 +++
 arch/i386/kernel/asm-offsets.c|1 +
 arch/i386/kernel/entry.S  |3 +++
 arch/powerpc/kernel/asm-offsets.c |2 ++
 arch/powerpc/kernel/entry_32.S|5 +
 arch/powerpc/kernel/entry_64.S|5 +
 arch/x86_64/kernel/asm-offsets.c  |1 +
 arch/x86_64/kernel/entry.S|3 +++
 fs/proc/array.c   |   14 ++
 include/asm-i386/thread_info.h|1 +
 include/asm-powerpc/thread_info.h |1 +
 include/asm-x86_64/thread_info.h  |1 +
 include/linux/taskstats.h |6 +-
 kernel/fork.c |3 +++
 kernel/taskstats.c|6 ++
 16 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/Documentation/accounting/getdelays.c 
b/Documentation/accounting/getdelays.c
index e9126e7..1be7d65 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -49,6 +49,7 @@ char name[100];
 int dbg;
 int print_delays;
 int print_io_accounting;
+int print_task_stats;
 __u64 stime, utime;
 
 #define PRINTF(fmt, arg...) {  \
@@ -187,7 +188,7 @@ void print_delayacct(struct taskstats *t)
   "IO%15s%15s\n"
   "  %15llu%15llu\n"
   "MEM   %15s%15s\n"
-  "  %15llu%15llu\n\n",
+  "  %15llu%15llu\n"
   "count", "real total", "virtual total", "delay total",
   t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
   t->cpu_delay_total,
@@ -196,6 +197,15 @@ void print_delayacct(struct taskstats *t)
   "count", "delay total", t->swapin_count, t->swapin_delay_total);
 }
 
+void print_taskstats(struct taskstats *t)
+{
+   printf("\n\nTask  %15s%15s%15s\n"
+  "  %15lu%15lu%15lu\n",
+  "syscalls", "voluntary", "nonvoluntary",
+  t->syscall_counter, t->nvcsw, t->nivcsw);
+
+}
+
 void print_ioacct(struct taskstats *t)
 {
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
@@ -227,7 +237,7 @@ int main(int argc, char *argv[])
struct msgtemplate msg;
 
while (1) {
-   c = getopt(argc, argv, "diw:r:m:t:p:v:l");
+   c = getopt(argc, argv, "qdiw:r:m:t:p:v:l");
if (c < 0)
break;
 
@@ -240,6 +250,10 @@ int main(int argc, char *argv[])
printf("printing IO accounting\n");
print_io_accounting = 1;
break;
+   case 'q':
+   printf("printing task/process stasistics:\n");
+   print_task_stats = 1;
+   break;
case 'w':
strncpy(logfile, optarg, MAX_FILENAME);
printf("write to file %s\n", logfile);
@@ -381,6 +395,8 @@ int main(int argc, char *argv[])
print_delayacct((struct 
taskstats *) NLA_DATA(na));
if (print_io_accounting)
print_ioacct((struct 
taskstats *) NLA_DATA(na));
+   if (print_task_stats)
+   print_taskstats((struct 
taskstats *) NLA_DATA(na));
if (fd) {
if (write(fd, 
NLA_DATA(na), na->nla_len) < 0) {
err(1,"write 
error\n");
diff --git a/Documentation/accounting/taskstats-struct.txt 
b/Documentation/accounting/taskstats-struct.txt
index 661c797..5dac173 100644
--- a/Documentation/accounting/taskstats-struct.txt
+++ b/Documentation/accounting/taskstats-struct.txt
@@ -22,6 +22,8 @@ There a

Re: HDIO_DRIVE_CMD and hdparm

[Mark Lord]

Geert Uytterhoeven wrote:

Hi,

`hdparm -t' uses HDIO_DRIVE_CMD(null) to flush the disk's buffer.


More correctly, that command is supposed to act like an I/O queue "barrier"
operation, not returning from the syscall until everything queued in front
of it has been issued/completed.

I believe that only the original IDE driver actually implements it, though.
And hdparm-7.4 (not released yet) will no longer complain about ENOTTY.

Note that current versions of hdparm use SG_IO/ATA_16 (SAT) for nearly 
everything
now, only falling back to the older ioctl's for drivers which reject the SAT 
attempt.

I'd love to find a USB drive enclosure that supports SAT.
Anyone know of one?

And does the USB storage layer actually pass the ATA_16 packets to the device?

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: Hi, I have one question about rt_mutex.

[Steven Rostedt]

Li Yu wrote:
>> Now since mutexes can be defined by user-land applications, we don't
> want a DOS
>> type of application that nests large amounts of mutexes to create a large
>> PI chain, and have the code holding spin locks while looking at a large
>> amount of data. So to prevent this, the implementation not only implements
>> a maximum lock depth, but also only holds at most two different locks at a
>> time, as it walks the PI chain. More about this below.
> 
> After read the implementation of rt_mutex_adjust_prio_chain(), I found
> the we really require maximin lock depth (1024 default), but I can not
> see the check for more same locks duplication. Does this doc is
> inconsistent with code?

Nope, the code and the doc are still the same.

The thing that was most difficult in writing that document, was a way to
talk about the user locks (futex - fast user mutex) and the kernel locks
(spin_locks) without confusing the two.  The max depth is in reference
to the user futex, but the comment about the "at most two different
locks" is referencing the kernel's spin_locks.

I don't remember talking about looking for "lock duplication", which I'm
thinking you are referring to circular dead locks. I didn't cover that
in the document and I believe I even mentioned that I would not cover
the debug aspect of the code which would handle catching circular deadlocks.

But back to the "no more than two kernel locks held". This is very
important. Some PI implementations requires all locks in the PI chain to
have their internal locks held (as in spin_locks).  But letting user
space determine the number of spin locks held can cause large latencies
for the rest of the system.  So we designed a method to only need to
hold two internal spin_locks in the PI chain at a time.  The kernel
doesn't care if the user application is abusing itself (holding too many
of it's own user locks).  But the kernel does care if a user application
can affect other non related applications.

As Esben already mentioned, the PI chain even lets the locking user
mutex schedule without holding any kernel locks.  This is very key. It
keeps the latency down on setting up a PI chain which can be very expensive.

Note: Esben helped a lot in the development of the final design of
rtmutex.c.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Bug in fs/afs/write.c function afs_write_back_from_locked_page()

[David Howells]

David Howells <[EMAIL PROTECTED]> wrote:

> How about the attached instead?

Blech.  How about this instead?  I forgot to remove the extra put_page() you
added.

David
---
AFS: Fix interminable loop in afs_write_back_from_locked_page()

From: Mika Kukkonen <[EMAIL PROTECTED]>

Following bug was uncovered by compiling with '-W' flag:

  CC [M]  fs/afs/write.o
fs/afs/write.c: In function ‘afs_write_back_from_locked_page’:
fs/afs/write.c:398: warning: comparison of unsigned expression >= 0 is always 
true

Loop variable 'n' is unsigned, so wraps around happily as far as I can
see. Trival fix attached (compile tested only).

Signed-Off-By: Mika Kukkonen <[EMAIL PROTECTED]>
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---

 fs/afs/write.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/afs/write.c b/fs/afs/write.c
index 67ae4db..28f3751 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -395,8 +395,9 @@ static int afs_write_back_from_locked_page(struct 
afs_writeback *wb,
if (n == 0)
goto no_more;
if (pages[0]->index != start) {
-   for (n--; n >= 0; n--)
-   put_page(pages[n]);
+   do {
+   put_page(pages[--n]);
+   } while (n > 0);
goto no_more;
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 7/12] i386 sg: add support for chaining scatterlists

[Satyam Sharma]

On 5/10/07, Jens Axboe <[EMAIL PROTECTED]> wrote:

[...]
+static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
+   struct scatterlist *sgl)
+{
+#ifndef ARCH_HAS_SG_CHAIN
+   BUG();
+#endif


Hmmm ... so we better also make sure all users call this from within
an "#ifdef ARCH_HAS_SG_CHAIN" themselves (or else make this a config
option defined in the arch/.../defconfig of archs that support this
and then make the calling code's Kconfig option "depends on ... &&
ARCH_FOO").

(Just saw a previous thread, Andrew seems to have beaten me to this observation)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] libata: add human-readable error value decoding

[Mark Lord]

Tejun Heo wrote:

Robert Hancock wrote:

This adds human-readable decoding of the ATA status and error registers
(similar
to what drivers/ide does) as well as the SATA Serror register to libata

...

I'm not really convinced whether this is necessary.  The human readable
form is also a bit cryptic and can get quite long.  So, mild NACK from me.


Same here, but I would like to see it in there under a CONFIG_DEBUG_LIBATA
kernel build option or something.  Kind of like the "FANCY_STATUS_DUMPS" flag
that drivers/ide used to have for this kind of stuff.

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: [PATCH 2.6.21] m32r: Fix switch_to macro to push/pop frame pointer if needed

[Hirokazu Takata]

From: Andrew Morton <[EMAIL PROTECTED]>
> On Thu, 10 May 2007 13:58:36 +0900 Hirokazu Takata <[EMAIL PROTECTED]> wrote:
> 
> > +#if defined(CONFIG_FRAME_POINTER)
> > +|| !defined(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER)
> 
> hm, I didn't know that the preprocessor permitted that.
> 
> I'll stick a \ in there to be safe.
> 

Oops! It was my mistake.
Here is a revised patch, please replace the previous one.

Thanks,

-- Takata

This patch fixes a rarely-happened but severe scheduling problem of
the recent m32r kernel of 2.6.17-rc3 or later.

In the following previous m32r patch, the switch_to macro was
modified not to do unnecessary push/pop operations for tuning.
> [PATCH] m32r: update switch_to macro for tuning
> 4127272c38619c56f0c1aa01d01c7bd757db70a1

In this modification, only 'lr' and 'sp' registers are push/pop'ed,
assuming that the m32r kernel is always compiled with
-fomit-frame-pointer option.

However, in 2.6 kernel, kernel/sched.c is irregularly compiled
with -fno-omit-frame-pointer if CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER
is not defined.

 -- kernel/Makefile --
   :
 ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
 # needed for x86 only.  Why this used to be enabled for all architectures is 
beyond
 # me.  I suspect most platforms don't need this, but until we know that for 
sure
 # I turn this off for IA-64 only.  Andreas Schwab says it's also needed on m68k
 # to get a correct value for the wait-channel (WCHAN in ps). --davidm
 CFLAGS_sched.o := $(PROFILING) -fno-omit-frame-pointer
 endif
   :
 ---

Therefore, for the recent m32r kernel, we have to push/pop 'fp'
(frame pointer) if CONFIG_FRAME_POINTER is defined or
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not defined.

Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]>
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
 arch/m32r/Kconfig |4 
 include/asm-m32r/system.h |   11 +++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9740d6b..c3bb8a7 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -241,6 +241,10 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
 
+config SCHED_NO_NO_OMIT_FRAME_POINTER
+bool
+default y
+
 config PREEMPT
bool "Preemptible Kernel"
help
diff --git a/include/asm-m32r/system.h b/include/asm-m32r/system.h
index 99ee098..76a6255 100644
--- a/include/asm-m32r/system.h
+++ b/include/asm-m32r/system.h
@@ -21,12 +21,22 @@
  * `next' and `prev' should be struct task_struct, but it isn't always defined
  */
 
+#if defined(CONFIG_FRAME_POINTER) \
+|| !defined(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER)
+#define M32R_PUSH_FP " push fp\n"
+#define M32R_POP_FP  " pop  fp\n"
+#else
+#define M32R_PUSH_FP ""
+#define M32R_POP_FP  ""
+#endif
+
 #define switch_to(prev, next, last)  do { \
__asm__ __volatile__ ( \
"   sethlr, #high(1f)   \n" \
"   or3 lr, lr, #low(1f)\n" \
"   st  lr, @%4  ; store old LR \n" \
"   ld  lr, @%5  ; load new LR  \n" \
+   M32R_PUSH_FP \
"   st  sp, @%2  ; store old SP \n" \
"   ld  sp, @%3  ; load new SP  \n" \
"   push%1  ; store `prev' on new stack \n" \
@@ -34,6 +44,7 @@
"   .fillinsn   \n" \
"1: \n" \
"   pop %0  ; restore `__last' from new stack   \n" \
+   M32R_POP_FP \
: "=r" (last) \
: "0" (prev), \
  "r" (&(prev->thread.sp)), "r" (&(next->thread.sp)), \
-- 
1.5.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Andi, you broke my laptop :-)

[Joerg Roedel]

On Thu, May 10, 2007 at 03:01:44PM +0200, Andi Kleen wrote:
> On Wed, May 09, 2007 at 12:56:16PM -0700, Pete Zaitcev wrote:
> > Hi, Andi:
> > 
> > The attached patch (actually, git show output) makes my Dell 1501 to hang
> > on boot. Sorry, I have no clue why... The culprit is found with git bisect.
> > But yes, it's an AMD MK-36. I use an x86_64 kernel. It is 100% reproducible.
> 
> MK-36? Does it have SVM? 
> 
> Anyways we previously had issues with this being miscompiled, but 
> I thought the latest patch should have been ok. What compiler do you use?
> 
> Can you send me a disassembly listing of arch/x86_64/kernel/time.o?

I debugged this problem a bit and my compiler[1]interprets the =A
constraint as %rax instead of %edx:%eax on x86_64 which causes the
problem. The appended patch provides a workaround for this and fixed the
hang on my machine.

[1] gcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-5)

Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>

-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
diff --git a/include/asm-i386/alternative.h b/include/asm-i386/alternative.h
index 0f70b37..eb7da54 100644
--- a/include/asm-i386/alternative.h
+++ b/include/asm-i386/alternative.h
@@ -98,6 +98,12 @@ static inline void alternatives_smp_switch(int smp) {}
  ".previous" : output : [feat] "i" (feature), ##input)
 
 /*
+ * use this macro(s) if you need more than one output parameter
+ * in alternative_io
+ */
+#define ASM_OUTPUT2(a, b) a, b
+
+/*
  * Alternative inline assembly for SMP.
  *
  * The LOCK_PREFIX macro defined here replaces the LOCK and
diff --git a/include/asm-i386/tsc.h b/include/asm-i386/tsc.h
index 3f3c1fa..62c091f 100644
--- a/include/asm-i386/tsc.h
+++ b/include/asm-i386/tsc.h
@@ -35,14 +35,16 @@ static inline cycles_t get_cycles(void)
 static __always_inline cycles_t get_cycles_sync(void)
 {
unsigned long long ret;
-   unsigned eax;
+   unsigned eax, edx;
 
/*
 * Use RDTSCP if possible; it is guaranteed to be synchronous
 * and doesn't cause a VMEXIT on Hypervisors
 */
alternative_io(ASM_NOP3, ".byte 0x0f,0x01,0xf9", X86_FEATURE_RDTSCP,
-"=A" (ret), "0" (0ULL) : "ecx", "memory");
+  ASM_OUTPUT2("=a" (eax), "=d" (edx)),
+  "a" (0U), "d" (0U) : "ecx", "memory");
+   ret = (((unsigned long long)edx) << 32) | ((unsigned long long)eax);
if (ret)
return ret;
 
diff --git a/include/asm-x86_64/alternative.h b/include/asm-x86_64/alternative.h
index a09fe85..a094276 100644
--- a/include/asm-x86_64/alternative.h
+++ b/include/asm-x86_64/alternative.h
@@ -103,6 +103,12 @@ static inline void alternatives_smp_switch(int smp) {}
  ".previous" : output : [feat] "i" (feature), ##input)
 
 /*
+ * use this macro(s) if you need more than one output parameter
+ * in alternative_io
+ */
+#define ASM_OUTPUT2(a, b) a, b
+
+/*
  * Alternative inline assembly for SMP.
  *
  * The LOCK_PREFIX macro defined here replaces the LOCK and

Re: [patch 06/10] Linux Kernel Markers - Non optimized architectures

[Alan Cox]

> - Fix optimisation -> optimization typo in powerpc and i386 headers.

That isn't a typo, it's correct as is.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] NLM program ID for user space NLM server

[Trond Myklebust]

On Thu, 2007-05-10 at 13:59 +0300, Menny Hamburger wrote:
> Hi,
> 
> We have a our own userland NFSD and NLM service running that implement
> all the NLM/NFS functionality.
> We do not want to modify the way the client does his mounts.
> 
> M.

The client needs to have lockd running (as service 100021) in order to
allow the NSM daemon to notify it of server reboots.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [bisect] NFS regression breaks X

[Chuck Lever]

Trond Myklebust wrote:

On Wed, 2007-05-09 at 15:52 -0700, Andrew Morton wrote:

It's a bit rough that Jeff spent a large amount of time hunting down an
already-known bug.  That's normally my job :(


The bug was reported by Florin Iucha (on lkml!) on Saturday. It has only
just been debugged, and I was in fact in the middle of marshalling the
fixes.


This five-week-old diff only ever appeared in 2.6.21-mm1, which was
released four days ago.  It was then whizzed into mainline.  We thus lost
five weeks public testing which would probably have saved Jeff his pain.

What went wrong?


Probably my fault. I've had a couple of weeks of heavy travel due to
various circumstances that were beyond my control, and so I had little
time in which to test the stuff and push it out.

Another factor that is affecting us is the slow but gradual collapse of
the OSDL NFSv4 regression testing effort.


I had expected that many of these issues would be caught by the OSDL 
test harness.  I learned only yesterday that it was no longer available, 
so I am making an effort to broaden my personal test regime.
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard

Re: [patch 07/10] Linux Kernel Markers - Documentation

[Alan Cox]

O> Oh, I am not advocating censorship. I was merely pointing out that it 
> seems silly to mention out-of-tree users because they come and go. Who 
> knows whether LTTng or SystemTAP will be relevant five years from now? 

And in the intervening five years (or more likely 7 or more for
systemtap) the documentation will be very useful.

> Besides, are we sure the document includes all potential users now? We 
> wouldn't want to show favorism to any particular projects, now would we?

Absolutely not - and isn't it more useful to let users know about all of
the tools that this enables ?

> 
> On Thu, 10 May 2007, Alan Cox wrote: 
> > And as I keep saying the tree is full of references to out of tree stuff.
> > The documentation directory alone currently contains over a thousand http
> > URLS as of 2.6.21-rc6-mm1.
> 
> Many of the already out of date or expiring in the near future... 

Have you done a statistically valid sampling or is this guessing ?

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MMC: Flush mmc workqueue late in the boot sequence

[Pierre Ossman]

Haavard Skinnemoen wrote:
> 
> What exactly makes this unreliable? This is done almost exactly the
> same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
> 

I am not against the function of waiting for an initial scan, what I oppose is
using side effects to achieve that function. I do not want to take
responsibility for something that easily breaks because we use a kernel
subsystem for something it wasn't meant for.

That said, if there is a precedent for achieving this function a certain way, I
might be convinced to let it in. I'll have a look at that scsi example.

> 
> I don't know about USB, but root=/dev/mmcblk0p1 used to work before
> 2.6.20 and it doesn't work anymore. Doesn't that make this a regression?
> 

Yes and no. It depends on if it was an official function, or just an effect of
how things currently were implemented. As far as I can see, it's the latter. The
MMC layer goes through several steps that could very well get delayed or happen
in parallel. So the fact that it happened to work the way you wanted it to was
sheer luck.

Rgds
Pierre




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 8/12] x86-64: update iommu/dma mapping functions to sg helpers

[Benny Halevy]

Jens Axboe wrote:

> @@ -323,13 +324,17 @@ static int __dma_map_cont(struct scatterlist *sg, int 
> start, int stopat,
>  {
>   unsigned long iommu_start = alloc_iommu(pages);
>   unsigned long iommu_page = iommu_start; 
> - int i;
> + struct scatterlist *s;
> + int i, nelems;
>  
>   if (iommu_start == -1)
>   return -1;
> +
> + nelems = stopat - start;
> + while (start--)
> + sg = sg_next(sg);

Ouch.  This will suck if we merge many times in a long list.
How about keeping and passing start as a struct scatterlist * rather
than an index? (see attached example, (compiles, bu untested though)


>   
> - for (i = start; i < stopat; i++) {
> - struct scatterlist *s = &sg[i];
> + for_each_sg(sg, s, nelems, i) {
>   unsigned long pages, addr;
>   unsigned long phys_addr = s->dma_address;


There seems to be a bug hiding here as now i is in [0, nelems) now,
not [start, stopat) so "if (i == start)" below should turn into "if (i == 0)"

this is fixed by comparing pointers instead way in the attached example.

>   
> @@ -360,12 +365,14 @@ static inline int dma_map_cont(struct scatterlist *sg, 
> int start, int stopat,
> struct scatterlist *sout,
> unsigned long pages, int need)
>  {
> - if (!need) { 
> + if (!need) {
>   BUG_ON(stopat - start != 1);
> - *sout = sg[start]; 
> - sout->dma_length = sg[start].length; 
> + while (--start)
> + sg = sg_next(sg);

same efficiency issue as above.

> + *sout = *sg;
> + sout->dma_length = sg->length;
>   return 0;
> - } 
> + }
>   return __dma_map_cont(sg, start, stopat, sout, pages);
>  }
>   


diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 8bc2ed7..48ce635 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -319,27 +319,23 @@ static int dma_map_sg_nonforce(struct device *dev, struct 
scatterlist *sg,
 }
 
 /* Map multiple scatterlist entries continuous into the first. */
-static int __dma_map_cont(struct scatterlist *sg, int start, int stopat,
+static int __dma_map_cont(struct scatterlist *start, int nelems,
  struct scatterlist *sout, unsigned long pages)
 {
unsigned long iommu_start = alloc_iommu(pages);
unsigned long iommu_page = iommu_start; 
struct scatterlist *s;
-   int i, nelems;
+   int i;
 
if (iommu_start == -1)
return -1;
 
-   nelems = stopat - start;
-   while (start--)
-   sg = sg_next(sg);
-   
-   for_each_sg(sg, s, nelems, i) {
+   for_each_sg(start, s, nelems, i) {
unsigned long pages, addr;
unsigned long phys_addr = s->dma_address;

-   BUG_ON(i > start && s->offset);
-   if (i == start) {
+   BUG_ON(s != start && s->offset);
+   if (s == start) {
*sout = *s; 
sout->dma_address = iommu_bus_base;
sout->dma_address += iommu_page*PAGE_SIZE + s->offset;
@@ -361,19 +357,17 @@ static int __dma_map_cont(struct scatterlist *sg, int 
start, int stopat,
return 0;
 }
 
-static inline int dma_map_cont(struct scatterlist *sg, int start, int stopat,
+static inline int dma_map_cont(struct scatterlist *start, int nelems,
  struct scatterlist *sout,
  unsigned long pages, int need)
 {
if (!need) {
-   BUG_ON(stopat - start != 1);
-   while (--start)
-   sg = sg_next(sg);
-   *sout = *sg;
-   sout->dma_length = sg->length;
+   BUG_ON(nelems != 1);
+   *sout = *start;
+   sout->dma_length = start->length;
return 0;
}
-   return __dma_map_cont(sg, start, stopat, sout, pages);
+   return __dma_map_cont(start, nelems, sout, pages);
 }

 /*
@@ -387,7 +381,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg, 
int nents, int dir)
int start;
unsigned long pages = 0;
int need = 0, nextneed;
-   struct scatterlist *s, *ps;
+   struct scatterlist *s, *ps, *start_sg;
 
if (nents == 0) 
return 0;
@@ -397,6 +391,7 @@ int gart_map_sg(struct device *dev, struct scatterlist *sg, 
int nents, int dir)
 
out = 0;
start = 0;
+   start_sg = sg;
ps = NULL; /* shut up gcc */
for_each_sg(sg, s, nents, i) {
dma_addr_t addr = page_to_phys(s->page) + s->offset;
@@ -411,12 +406,13 @@ int gart_map_sg(struct device *dev, struct scatterlist 
*sg, int nents, int dir)
   boundary and the new one doesn't have an offset. */
 

Re: [git patch] move USB net drivers to drivers/net

[Duncan Sands]

On Thursday 10 May 2007 14:12:47 Indan Zupancic wrote:
> Hello,
> 
> On Thu, May 10, 2007 03:38, Jeff Garzik wrote:
> >
> > This was ACK'd by Greg, as you see in the sign-offs.  See the commit
> > below for rationale.
> >
> > USB is now treated like other buses, for network drivers:
> > * USB network driver patches should go to me and netdev
> > * Just like in PCI or PCMCIA land, bus-specific code may
> >   originate from the USB side of the house (Greg's tree).
> >
> >
> >
> > Please pull from 'usb-move' branch of
> > master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git usb-move
> >
> > to receive the following update:
> >
> >
> > commit 5b2fc499917e5897a13add780e181b4cef197072
> > Author: Jeff Garzik <[EMAIL PROTECTED]>
> > Date:   Wed May 9 21:31:55 2007 -0400
> >
> > Move USB network drivers to drivers/net/usb.
> >
> > It is preferable to group drivers by usage (net, scsi, ATA, ...) than
> > by bus.  When reviewing drivers, the [PCI|USB|PCMCIA|...] maintainer
> > is probably less qualified on networking issues than a networking
> > maintainer.  Also, from a practical standpoint, chips often
> > appear on multiple buses, which is why we do not put drivers into
> > drivers/pci/net.
> 
> What about drivers/usb/atm/?

I don't mind if it moves to drivers/atm/, though I don't see the point of it.

Best wishes,

Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] update sysfs kset initialisation in PPC64 DLPAR IO driver

[Andy Whitcroft]

Move the rpadlpar device from "struct subsystem" to "struct kset"
following the changes in sysfs.

Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---

Ok, this patch seems to sort out the compile problem
here and indeed boots and runs kernbench.  Perhaps
you could confirm this is sufficient.


diff --git a/drivers/pci/hotplug/rpadlpar_sysfs.c 
b/drivers/pci/hotplug/rpadlpar_sysfs.c
index 6c5be3f..ed4de59 100644
--- a/drivers/pci/hotplug/rpadlpar_sysfs.c
+++ b/drivers/pci/hotplug/rpadlpar_sysfs.c
@@ -129,13 +129,13 @@ struct kobj_type ktype_dlpar_io = {
 };
 
 struct kset dlpar_io_kset = {
-   .subsys = &pci_hotplug_slots_subsys,
.kobj = {.name = DLPAR_KOBJ_NAME, .ktype=&ktype_dlpar_io,},
.ktype = &ktype_dlpar_io,
 };
 
 int dlpar_sysfs_init(void)
 {
+   kobj_set_kset_s(&dlpar_io_kset, pci_hotplug_slots_subsys);
if (kset_register(&dlpar_io_kset)) {
printk(KERN_ERR "rpadlpar_io: cannot register kset for %s\n",
dlpar_io_kset.kobj.name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/12] crypto: don't pollute the global namespace with sg_next()

[Benny Halevy]

Jens Axboe wrote:
> It's a subsystem function, prefix it as such.

Jens, Boaz and I talked about this over lunch.
I wonder whether the crypto code must use your implementation
instead of its own as it needs to over the sglist, e.g. for
calculating iscsi (data) digest.

The crypto implementation of chained sglists in crypto/scatterwalk.h
determines the chain link by !sg->length which will sorta work
with your implementation, however the marker bit on page pointer must
be cleared to use it.

Also, is it possible that after the original sglist has gone through
dma_map_sg and entries were merged, some entries will have zero
length?  I'm not sure... If so, if the crypto implementation scans
the sg list after it was dma mapped (maybe in a retry path) it
may hit an entry that looks to it like a chaining link.  This
might be an existing bug and another reason for the crypto code
to use your implementation.

Thanks,

Benny

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 00/15] s390 patches for 2.6.22

[Martin Schwidefsky]

A few fixes, some compiler warnings and the Kconfig cleanup.
s390 now uses the common drivers/Kconfig file instead of the
home-brewn drivers/s390/Kconfig. There are some more config
options for s390 now, not all of them make sense but as long
as the code compiles no harm is done.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 01/15] fix subsystem removal fallout

[Martin Schwidefsky]

From: Cornelia Huck <[EMAIL PROTECTED]>

This patch fixes compilation on s390 after the removal of
struct subsystem.

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/hypfs/inode.c |2 +-
 arch/s390/kernel/ipl.c  |   26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

Index: quilt-2.6/arch/s390/hypfs/inode.c
===
--- quilt-2.6.orig/arch/s390/hypfs/inode.c
+++ quilt-2.6/arch/s390/hypfs/inode.c
@@ -477,7 +477,7 @@ static int __init hypfs_init(void)
goto fail_diag;
}
}
-   kset_set_kset_s(&s390_subsys, hypervisor_subsys);
+   kobj_set_kset_s(&s390_subsys, hypervisor_subsys);
rc = subsystem_register(&s390_subsys);
if (rc)
goto fail_sysfs;
Index: quilt-2.6/arch/s390/kernel/ipl.c
===
--- quilt-2.6.orig/arch/s390/kernel/ipl.c
+++ quilt-2.6/arch/s390/kernel/ipl.c
@@ -816,23 +816,23 @@ static int __init ipl_register_fcp_files
 {
int rc;
 
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_fcp_attr_group);
if (rc)
goto out;
-   rc = sysfs_create_bin_file(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_bin_file(&ipl_subsys.kobj,
   &ipl_parameter_attr);
if (rc)
goto out_ipl_parm;
-   rc = sysfs_create_bin_file(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_bin_file(&ipl_subsys.kobj,
   &ipl_scp_data_attr);
if (!rc)
goto out;
 
-   sysfs_remove_bin_file(&ipl_subsys.kset.kobj, &ipl_parameter_attr);
+   sysfs_remove_bin_file(&ipl_subsys.kobj, &ipl_parameter_attr);
 
 out_ipl_parm:
-   sysfs_remove_group(&ipl_subsys.kset.kobj, &ipl_fcp_attr_group);
+   sysfs_remove_group(&ipl_subsys.kobj, &ipl_fcp_attr_group);
 out:
return rc;
 }
@@ -846,7 +846,7 @@ static int __init ipl_init(void)
return rc;
switch (ipl_info.type) {
case IPL_TYPE_CCW:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_ccw_attr_group);
break;
case IPL_TYPE_FCP:
@@ -854,11 +854,11 @@ static int __init ipl_init(void)
rc = ipl_register_fcp_files();
break;
case IPL_TYPE_NSS:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_nss_attr_group);
break;
default:
-   rc = sysfs_create_group(&ipl_subsys.kset.kobj,
+   rc = sysfs_create_group(&ipl_subsys.kobj,
&ipl_unknown_attr_group);
break;
}
@@ -885,7 +885,7 @@ static int __init reipl_nss_init(void)
 
if (!MACHINE_IS_VM)
return 0;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_nss_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_nss_attr_group);
if (rc)
return rc;
strncpy(reipl_nss_name, kernel_nss_name, NSS_NAME_SIZE + 1);
@@ -900,7 +900,7 @@ static int __init reipl_ccw_init(void)
reipl_block_ccw = (void *) get_zeroed_page(GFP_KERNEL);
if (!reipl_block_ccw)
return -ENOMEM;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_ccw_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_ccw_attr_group);
if (rc) {
free_page((unsigned long)reipl_block_ccw);
return rc;
@@ -938,7 +938,7 @@ static int __init reipl_fcp_init(void)
reipl_block_fcp = (void *) get_zeroed_page(GFP_KERNEL);
if (!reipl_block_fcp)
return -ENOMEM;
-   rc = sysfs_create_group(&reipl_subsys.kset.kobj, &reipl_fcp_attr_group);
+   rc = sysfs_create_group(&reipl_subsys.kobj, &reipl_fcp_attr_group);
if (rc) {
free_page((unsigned long)reipl_block_fcp);
return rc;
@@ -990,7 +990,7 @@ static int __init dump_ccw_init(void)
dump_block_ccw = (void *) get_zeroed_page(GFP_KERNEL);
if (!dump_block_ccw)
return -ENOMEM;
-   rc = sysfs_create_group(&dump_subsys.kset.kobj, &dump_ccw_attr_group);
+   rc = sysfs_create_group(&dump_subsys.kobj, &dump_ccw_attr_group);
if (rc) {
free_page((unsigned long)dump_block_ccw);
return rc;
@@ -1014,7 +1014,7 @@ static int __init dump_fcp_init(void)
dump_block_fcp = (void *) get_zeroed_page(GFP_KERNEL);
if (!dump_block_fcp)
return -ENOMEM;
-  

[patch 03/15] cio: Make some structures and a function static.

[Martin Schwidefsky]

From: Cornelia Huck <[EMAIL PROTECTED]>

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/cio/css.c|3 +--
 drivers/s390/cio/css.h|2 --
 drivers/s390/cio/device.c |4 ++--
 3 files changed, 3 insertions(+), 6 deletions(-)

Index: quilt-2.6/drivers/s390/cio/css.c
===
--- quilt-2.6.orig/drivers/s390/cio/css.c
+++ quilt-2.6/drivers/s390/cio/css.c
@@ -191,8 +191,7 @@ static int css_register_subchannel(struc
return ret;
 }
 
-int
-css_probe_device(struct subchannel_id schid)
+static int css_probe_device(struct subchannel_id schid)
 {
int ret;
struct subchannel *sch;
Index: quilt-2.6/drivers/s390/cio/css.h
===
--- quilt-2.6.orig/drivers/s390/cio/css.h
+++ quilt-2.6/drivers/s390/cio/css.h
@@ -138,9 +138,7 @@ struct css_driver {
  * all css_drivers have the css_bus_type
  */
 extern struct bus_type css_bus_type;
-extern struct css_driver io_subchannel_driver;
 
-extern int css_probe_device(struct subchannel_id);
 extern int css_sch_device_register(struct subchannel *);
 extern void css_sch_device_unregister(struct subchannel *);
 extern struct subchannel * get_subchannel_by_schid(struct subchannel_id);
Index: quilt-2.6/drivers/s390/cio/device.c
===
--- quilt-2.6.orig/drivers/s390/cio/device.c
+++ quilt-2.6/drivers/s390/cio/device.c
@@ -129,7 +129,7 @@ static void io_subchannel_verify(struct 
 static void io_subchannel_ioterm(struct device *);
 static void io_subchannel_shutdown(struct subchannel *);
 
-struct css_driver io_subchannel_driver = {
+static struct css_driver io_subchannel_driver = {
.subchannel_type = SUBCHANNEL_TYPE_IO,
.drv = {
.name = "io_subchannel",
@@ -546,7 +546,7 @@ static struct attribute_group ccwdev_att
.attrs = ccwdev_attrs,
 };
 
-struct attribute_group *ccwdev_attr_groups[] = {
+static struct attribute_group *ccwdev_attr_groups[] = {
&ccwdev_attr_group,
NULL,
 };

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 02/15] cio: Get rid of _ccw_device_get_device_number().

[Martin Schwidefsky]

From: Cornelia Huck <[EMAIL PROTECTED]>

The function shouldn't have existed in the first place (not MSS-aware).
Introduce a new function ccw_device_get_id() that extracts the
ccw_dev_id structure of a ccw device and convert all users of
_ccw_device_get_device_number to ccw_device_get_id.

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/block/dasd_diag.c  |   10 ++
 drivers/s390/block/dasd_ioctl.c |4 +++-
 drivers/s390/char/raw3270.c |5 +++--
 drivers/s390/cio/device_ops.c   |   11 +++
 include/asm-s390/ccwdev.h   |3 ++-
 5 files changed, 25 insertions(+), 8 deletions(-)

Index: quilt-2.6/drivers/s390/block/dasd_diag.c
===
--- quilt-2.6.orig/drivers/s390/block/dasd_diag.c
+++ quilt-2.6/drivers/s390/block/dasd_diag.c
@@ -50,6 +50,7 @@ struct dasd_diag_private {
struct dasd_diag_rw_io iob;
struct dasd_diag_init_io iib;
blocknum_t pt_block;
+   struct ccw_dev_id dev_id;
 };
 
 struct dasd_diag_req {
@@ -102,7 +103,7 @@ mdsk_init_io(struct dasd_device *device,
iib = &private->iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));
 
-   iib->dev_nr = _ccw_device_get_device_number(device->cdev);
+   iib->dev_nr = private->dev_id.devno;
iib->block_size = blocksize;
iib->offset = offset;
iib->flaga = DASD_DIAG_FLAGA_DEFAULT;
@@ -127,7 +128,7 @@ mdsk_term_io(struct dasd_device * device
private = (struct dasd_diag_private *) device->private;
iib = &private->iib;
memset(iib, 0, sizeof (struct dasd_diag_init_io));
-   iib->dev_nr = _ccw_device_get_device_number(device->cdev);
+   iib->dev_nr = private->dev_id.devno;
rc = dia250(iib, TERM_BIO);
return rc;
 }
@@ -166,7 +167,7 @@ dasd_start_diag(struct dasd_ccw_req * cq
private = (struct dasd_diag_private *) device->private;
dreq = (struct dasd_diag_req *) cqr->data;
 
-   private->iob.dev_nr = _ccw_device_get_device_number(device->cdev);
+   private->iob.dev_nr = private->dev_id.devno;
private->iob.key = 0;
private->iob.flags = DASD_DIAG_RWFLAG_ASYNC;
private->iob.block_count = dreq->block_count;
@@ -323,11 +324,12 @@ dasd_diag_check_device(struct dasd_devic
"memory allocation failed for private data");
return -ENOMEM;
}
+   ccw_device_get_id(device->cdev, &private->dev_id);
device->private = (void *) private;
}
/* Read Device Characteristics */
rdc_data = (void *) &(private->rdc_data);
-   rdc_data->dev_nr = _ccw_device_get_device_number(device->cdev);
+   rdc_data->dev_nr = private->dev_id.devno;
rdc_data->rdc_len = sizeof (struct dasd_diag_characteristics);
 
rc = diag210((struct diag210 *) rdc_data);
Index: quilt-2.6/drivers/s390/block/dasd_ioctl.c
===
--- quilt-2.6.orig/drivers/s390/block/dasd_ioctl.c
+++ quilt-2.6/drivers/s390/block/dasd_ioctl.c
@@ -255,6 +255,7 @@ dasd_ioctl_information(struct dasd_devic
unsigned long flags;
int rc;
struct ccw_device *cdev;
+   struct ccw_dev_id dev_id;
 
if (!device->discipline->fill_info)
return -EINVAL;
@@ -270,8 +271,9 @@ dasd_ioctl_information(struct dasd_devic
}
 
cdev = device->cdev;
+   ccw_device_get_id(cdev, &dev_id);
 
-   dasd_info->devno = _ccw_device_get_device_number(device->cdev);
+   dasd_info->devno = dev_id.devno;
dasd_info->schid = _ccw_device_get_subchannel_number(device->cdev);
dasd_info->cu_type = cdev->id.cu_type;
dasd_info->cu_model = cdev->id.cu_model;
Index: quilt-2.6/drivers/s390/char/raw3270.c
===
--- quilt-2.6.orig/drivers/s390/char/raw3270.c
+++ quilt-2.6/drivers/s390/char/raw3270.c
@@ -589,9 +589,10 @@ static int
 __raw3270_size_device_vm(struct raw3270 *rp)
 {
int rc, model;
+   struct ccw_dev_id dev_id;
 
-   raw3270_init_diag210.vrdcdvno = 
-   _ccw_device_get_device_number(rp->cdev);
+   ccw_device_get_id(rp->cdev, &dev_id);
+   raw3270_init_diag210.vrdcdvno = dev_id.devno;
raw3270_init_diag210.vrdclen = sizeof(struct diag210);
rc = diag210(&raw3270_init_diag210);
if (rc)
Index: quilt-2.6/drivers/s390/cio/device_ops.c
===
--- quilt-2.6.orig/drivers/s390/cio/device_ops.c
+++ quilt-2.6/drivers/s390/cio/device_ops.c
@@ -616,6 +616,17 @@ ccw_device_get_chp_desc(struct ccw_devic
return chp_get_chp_desc(chpid);
 }
 
+/**
+ * ccw_device_get_id - obtain a ccw device id
+ * @cdev: device to obtain the id for
+ * @dev_id: where to fill in the values
+ */
+void c

[patch 05/15] dasd: Fix modular build.

[Martin Schwidefsky]

From: Cornelia Huck <[EMAIL PROTECTED]>

Add missing export of dasd_generic_read_dev_chars().

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/block/dasd.c |1 +
 1 file changed, 1 insertion(+)

Index: quilt-2.6/drivers/s390/block/dasd.c
===
--- quilt-2.6.orig/drivers/s390/block/dasd.c
+++ quilt-2.6/drivers/s390/block/dasd.c
@@ -2219,6 +2219,7 @@ int dasd_generic_read_dev_chars(struct d
dasd_sfree_request(cqr, cqr->device);
return ret;
 }
+EXPORT_SYMBOL_GPL(dasd_generic_read_dev_chars);
 
 static int __init
 dasd_init(void)

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 04/15] monreader inlining cleanup.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/char/monreader.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Index: quilt-2.6/drivers/s390/char/monreader.c
===
--- quilt-2.6.orig/drivers/s390/char/monreader.c
+++ quilt-2.6/drivers/s390/char/monreader.c
@@ -97,7 +97,7 @@ static u8 user_data_sever[16] = {
  * Create the 8 bytes EBCDIC DCSS segment name from
  * an ASCII name, incl. padding
  */
-static inline void dcss_mkname(char *ascii_name, char *ebcdic_name)
+static void dcss_mkname(char *ascii_name, char *ebcdic_name)
 {
int i;
 
@@ -191,7 +191,7 @@ static inline u32 mon_rec_end(struct mon
return *((u32 *) (mon_mca_start(monmsg) + monmsg->mca_offset + 8));
 }
 
-static inline int mon_check_mca(struct mon_msg *monmsg)
+static int mon_check_mca(struct mon_msg *monmsg)
 {
if ((mon_rec_end(monmsg) <= mon_rec_start(monmsg)) ||
(mon_rec_start(monmsg) < mon_dcss_start) ||
@@ -209,8 +209,8 @@ static inline int mon_check_mca(struct m
return 0;
 }
 
-static inline int mon_send_reply(struct mon_msg *monmsg,
-struct mon_private *monpriv)
+static int mon_send_reply(struct mon_msg *monmsg,
+ struct mon_private *monpriv)
 {
int rc;
 
@@ -236,7 +236,7 @@ static inline int mon_send_reply(struct 
return 0;
 }
 
-static inline void mon_free_mem(struct mon_private *monpriv)
+static void mon_free_mem(struct mon_private *monpriv)
 {
int i;
 
@@ -246,7 +246,7 @@ static inline void mon_free_mem(struct m
kfree(monpriv);
 }
 
-static inline struct mon_private *mon_alloc_mem(void)
+static struct mon_private *mon_alloc_mem(void)
 {
int i;
struct mon_private *monpriv;
@@ -307,7 +307,7 @@ static inline void mon_next_mca(struct m
monmsg->pos = 0;
 }
 
-static inline struct mon_msg *mon_next_message(struct mon_private *monpriv)
+static struct mon_msg *mon_next_message(struct mon_private *monpriv)
 {
struct mon_msg *monmsg;
 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 06/15] Avoid sparse warnings.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

Monthly sparse warning avoidance patch. Sigh.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---

 drivers/s390/block/dasd.c  |7 ---
 drivers/s390/block/dasd_eckd.c |6 +++---
 drivers/s390/char/sclp.h   |3 +++
 drivers/s390/char/sclp_sdias.c |8 
 drivers/s390/char/zcore.c  |9 +++--
 drivers/s390/net/qeth_mpc.c|4 ++--
 drivers/s390/scsi/zfcp_aux.c   |8 +++-
 drivers/s390/scsi/zfcp_dbf.c   |2 +-
 include/asm-s390/ipl.h |2 +-
 9 files changed, 24 insertions(+), 25 deletions(-)

Index: quilt-2.6/drivers/s390/block/dasd.c
===
--- quilt-2.6.orig/drivers/s390/block/dasd.c
+++ quilt-2.6/drivers/s390/block/dasd.c
@@ -2174,9 +2174,10 @@ dasd_generic_notify(struct ccw_device *c
return ret;
 }
 
-struct dasd_ccw_req * dasd_generic_build_rdc(struct dasd_device *device,
-void *rdc_buffer,
-int rdc_buffer_size, char *magic)
+static struct dasd_ccw_req *dasd_generic_build_rdc(struct dasd_device *device,
+  void *rdc_buffer,
+  int rdc_buffer_size,
+  char *magic)
 {
struct dasd_ccw_req *cqr;
struct ccw1 *ccw;
Index: quilt-2.6/drivers/s390/block/dasd_eckd.c
===
--- quilt-2.6.orig/drivers/s390/block/dasd_eckd.c
+++ quilt-2.6/drivers/s390/block/dasd_eckd.c
@@ -450,9 +450,9 @@ dasd_eckd_generate_uid(struct dasd_devic
return 0;
 }
 
-struct dasd_ccw_req * dasd_eckd_build_rcd_lpm(struct dasd_device *device,
- void *rcd_buffer,
- struct ciw *ciw, __u8 lpm)
+static struct dasd_ccw_req *dasd_eckd_build_rcd_lpm(struct dasd_device *device,
+   void *rcd_buffer,
+   struct ciw *ciw, __u8 lpm)
 {
struct dasd_ccw_req *cqr;
struct ccw1 *ccw;
Index: quilt-2.6/drivers/s390/char/sclp.h
===
--- quilt-2.6.orig/drivers/s390/char/sclp.h
+++ quilt-2.6/drivers/s390/char/sclp.h
@@ -132,6 +132,9 @@ int sclp_deactivate(void);
 int sclp_reactivate(void);
 int sclp_service_call(sclp_cmdw_t command, void *sccb);
 
+int sclp_sdias_init(void);
+void sclp_sdias_exit(void);
+
 /* useful inlines */
 
 /* VM uses EBCDIC 037, LPAR+native(SE+HMC) use EBCDIC 500 */
Index: quilt-2.6/drivers/s390/char/sclp_sdias.c
===
--- quilt-2.6.orig/drivers/s390/char/sclp_sdias.c
+++ quilt-2.6/drivers/s390/char/sclp_sdias.c
@@ -66,9 +66,9 @@ static DEFINE_MUTEX(sdias_mutex);
 
 static void sdias_callback(struct sclp_req *request, void *data)
 {
-   struct sdias_sccb *sccb;
+   struct sdias_sccb *cbsccb;
 
-   sccb = (struct sdias_sccb *) request->sccb;
+   cbsccb = (struct sdias_sccb *) request->sccb;
sclp_req_done = 1;
wake_up(&sdias_wq); /* Inform caller, that request is complete */
TRACE("callback done\n");
@@ -229,7 +229,7 @@ out:
return rc;
 }
 
-int __init sdias_init(void)
+int __init sclp_sdias_init(void)
 {
int rc;
 
@@ -248,7 +248,7 @@ int __init sdias_init(void)
return 0;
 }
 
-void __exit sdias_exit(void)
+void __exit sclp_sdias_exit(void)
 {
debug_unregister(sdias_dbf);
sclp_unregister(&sclp_sdias_register);
Index: quilt-2.6/drivers/s390/char/zcore.c
===
--- quilt-2.6.orig/drivers/s390/char/zcore.c
+++ quilt-2.6/drivers/s390/char/zcore.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include "sclp.h"
 
 #define TRACE(x...) debug_sprintf_event(zcore_dbf, 1, x)
 #define MSG(x...) printk( KERN_ALERT x )
@@ -564,8 +565,6 @@ static void __init zcore_header_init(int
get_cpu_id(&hdr->cpu_id);
 }
 
-extern int sdias_init(void);
-
 static int __init zcore_init(void)
 {
unsigned char arch;
@@ -582,7 +581,7 @@ static int __init zcore_init(void)
TRACE("wwpn:   %llx\n", (unsigned long long) ipl_info.data.fcp.wwpn);
TRACE("lun:%llx\n", (unsigned long long) ipl_info.data.fcp.lun);
 
-   rc = sdias_init();
+   rc = sclp_sdias_init();
if (rc)
goto fail;
 
@@ -634,12 +633,10 @@ fail:
return rc;
 }
 
-extern void sdias_exit(void);
-
 static void __exit zcore_exit(void)
 {
debug_unregister(zcore_dbf);
-   sdias_exit();
+   sclp_sdias_exit();
diag308(DIAG308_REL_HSA, NULL);
 }
 
Index: quilt-2.6/drivers/s390/net/qeth_mpc.c
===
--- quilt-2.6.orig/

[patch 08/15] Avoid compile warning.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

arch/s390/mm/fault.c: In function `signal_return': 
arch/s390/mm/fault.c:256: warning: unused variable `compat' 

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---

 arch/s390/mm/fault.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: quilt-2.6/arch/s390/mm/fault.c
===
--- quilt-2.6.orig/arch/s390/mm/fault.c
+++ quilt-2.6/arch/s390/mm/fault.c
@@ -253,7 +253,10 @@ static int signal_return(struct mm_struc
 unsigned long address, unsigned long error_code)
 {
u16 instruction;
-   int rc, compat;
+   int rc;
+#ifdef CONFIG_COMPAT
+   int compat;
+#endif
 
pagefault_disable();
rc = __get_user(instruction, (u16 __user *) regs->psw.addr);

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 11/15] Kconfig: unwanted menus for s390.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Disable some more menus in the configuration files that are of no
interest to a s390 machine.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/dma/Kconfig |1 +
 drivers/input/Kconfig   |1 +
 drivers/isdn/Kconfig|1 +
 drivers/net/phy/Kconfig |1 +
 drivers/rtc/Kconfig |1 +
 net/ax25/Kconfig|2 +-
 net/bluetooth/Kconfig   |2 +-
 net/irda/Kconfig|2 +-
 8 files changed, 8 insertions(+), 3 deletions(-)

Index: quilt-2.6/drivers/dma/Kconfig
===
--- quilt-2.6.orig/drivers/dma/Kconfig
+++ quilt-2.6/drivers/dma/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "DMA Engine support"
+   depends on !S390
 
 config DMA_ENGINE
bool "Support for DMA engines"
Index: quilt-2.6/drivers/input/Kconfig
===
--- quilt-2.6.orig/drivers/input/Kconfig
+++ quilt-2.6/drivers/input/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Input device support"
+   depends on !S390
 
 config INPUT
tristate "Generic input layer (needed for keyboard, mouse, ...)" if 
EMBEDDED
Index: quilt-2.6/drivers/isdn/Kconfig
===
--- quilt-2.6.orig/drivers/isdn/Kconfig
+++ quilt-2.6/drivers/isdn/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "ISDN subsystem"
+   depends on !S390
 
 config ISDN
tristate "ISDN support"
Index: quilt-2.6/drivers/net/phy/Kconfig
===
--- quilt-2.6.orig/drivers/net/phy/Kconfig
+++ quilt-2.6/drivers/net/phy/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "PHY device support"
+   depends on !S390
 
 config PHYLIB
tristate "PHY Device support and infrastructure"
Index: quilt-2.6/drivers/rtc/Kconfig
===
--- quilt-2.6.orig/drivers/rtc/Kconfig
+++ quilt-2.6/drivers/rtc/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Real Time Clock"
+   depends on !S390
 
 config RTC_LIB
tristate
Index: quilt-2.6/net/ax25/Kconfig
===
--- quilt-2.6.orig/net/ax25/Kconfig
+++ quilt-2.6/net/ax25/Kconfig
@@ -3,7 +3,7 @@
 #
 
 menuconfig HAMRADIO
-   depends on NET
+   depends on NET && !S390
bool "Amateur Radio support"
help
  If you want to connect your Linux box to an amateur radio, answer Y
Index: quilt-2.6/net/bluetooth/Kconfig
===
--- quilt-2.6.orig/net/bluetooth/Kconfig
+++ quilt-2.6/net/bluetooth/Kconfig
@@ -3,7 +3,7 @@
 #
 
 menuconfig BT
-   depends on NET
+   depends on NET && !S390
tristate "Bluetooth subsystem support"
help
  Bluetooth is low-cost, low-power, short-range wireless technology.
Index: quilt-2.6/net/irda/Kconfig
===
--- quilt-2.6.orig/net/irda/Kconfig
+++ quilt-2.6/net/irda/Kconfig
@@ -3,7 +3,7 @@
 #
 
 menuconfig IRDA
-   depends on NET
+   depends on NET && !S390
tristate "IrDA (infrared) subsystem support"
select CRC_CCITT
---help---

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 13/15] Kconfig: use common Kconfig files for s390.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Disband drivers/s390/Kconfig, use the common Kconfig files. The s390
specific config options from drivers/s390/Kconfig are moved to the
respective common Kconfig files.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/Kconfig  |   49 +++--
 drivers/block/Kconfig  |4 
 drivers/char/Kconfig   |2 
 drivers/crypto/Kconfig |   22 
 drivers/s390/Kconfig   |  239 -
 drivers/s390/block/Kconfig |   11 --
 drivers/s390/char/Kconfig  |  166 +++
 drivers/s390/net/Kconfig   |8 -
 include/asm-s390/param.h   |2 
 9 files changed, 217 insertions(+), 286 deletions(-)

Index: quilt-2.6/arch/s390/Kconfig
===
--- quilt-2.6.orig/arch/s390/Kconfig
+++ quilt-2.6/arch/s390/Kconfig
@@ -4,27 +4,23 @@
 #
 
 config MMU
-   bool
-   default y
+   def_bool y
 
 config ZONE_DMA
def_bool y
depends on 64BIT
 
 config LOCKDEP_SUPPORT
-   bool
-   default y
+   def_bool y
 
 config STACKTRACE_SUPPORT
-   bool
-   default y
+   def_bool y
 
 config RWSEM_GENERIC_SPINLOCK
bool
 
 config RWSEM_XCHGADD_ALGORITHM
-   bool
-   default y
+   def_bool y
 
 config ARCH_HAS_ILOG2_U32
bool
@@ -35,8 +31,7 @@ config ARCH_HAS_ILOG2_U64
default n
 
 config GENERIC_HWEIGHT
-   bool
-   default y
+   def_bool y
 
 config GENERIC_TIME
def_bool y
@@ -55,8 +50,7 @@ config NO_DMA
 mainmenu "Linux Kernel Configuration"
 
 config S390
-   bool
-   default y
+   def_bool y
 
 source "init/Kconfig"
 
@@ -280,6 +274,10 @@ config WARN_STACK_SIZE
 config ARCH_POPULATES_NODE_MAP
def_bool y
 
+comment "Kernel preemption"
+
+source "kernel/Kconfig.preempt"
+
 source "mm/Kconfig"
 
 config HOLES_IN_ZONE
@@ -320,17 +318,6 @@ config QDIO_DEBUG
 
 comment "Misc"
 
-config PREEMPT
-   bool "Preemptible Kernel"
-   help
- This option reduces the latency of the kernel when reacting to
- real-time or interactive events by allowing a low priority process to
- be preempted even if it is in kernel mode executing a system call.
- This allows applications to run more reliably even when the system is
- under load.
-
- Say N if you are unsure.
-
 config IPL
bool "Builtin IPL record support"
help
@@ -488,6 +475,8 @@ config APPLDATA_NET_SUM
  This can also be compiled as a module, which will be called
  appldata_net_sum.o.
 
+source kernel/Kconfig.hz
+
 config NO_IDLE_HZ
bool "No HZ timer ticks in idle"
help
@@ -535,18 +524,12 @@ endmenu
 source "net/Kconfig"
 
 config PCMCIA
-   bool
-   default n
-
-source "drivers/base/Kconfig"
+   def_bool n
 
-source "drivers/connector/Kconfig"
-
-source "drivers/scsi/Kconfig"
-
-source "drivers/s390/Kconfig"
+config CCW
+   def_bool y
 
-source "drivers/net/Kconfig"
+source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
Index: quilt-2.6/drivers/block/Kconfig
===
--- quilt-2.6.orig/drivers/block/Kconfig
+++ quilt-2.6/drivers/block/Kconfig
@@ -444,8 +444,6 @@ config CDROM_PKTCDVD_WCACHE
  this option is dangerous unless the CD-RW media is known good, as we
  don't do deferred write error handling yet.
 
-source "drivers/s390/block/Kconfig"
-
 config ATA_OVER_ETH
tristate "ATA over Ethernet support"
depends on NET
@@ -453,6 +451,8 @@ config ATA_OVER_ETH
This driver provides Support for ATA over Ethernet block
devices like the Coraid EtherDrive (R) Storage Blade.
 
+source "drivers/s390/block/Kconfig"
+
 endmenu
 
 endif
Index: quilt-2.6/drivers/char/Kconfig
===
--- quilt-2.6.orig/drivers/char/Kconfig
+++ quilt-2.6/drivers/char/Kconfig
@@ -1081,5 +1081,7 @@ config DEVPORT
depends on ISA || PCI
default y
 
+source "drivers/s390/char/Kconfig"
+
 endmenu
 
Index: quilt-2.6/drivers/crypto/Kconfig
===
--- quilt-2.6.orig/drivers/crypto/Kconfig
+++ quilt-2.6/drivers/crypto/Kconfig
@@ -56,4 +56,26 @@ config CRYPTO_DEV_GEODE
  To compile this driver as a module, choose M here: the module
  will be called geode-aes.
 
+config ZCRYPT
+   tristate "Support for PCI-attached cryptographic adapters"
+   depends on S390
+   select ZCRYPT_MONOLITHIC if ZCRYPT="y"
+   default "m"
+   help
+ Select this option if you want to use a PCI-attached cryptographic
+ adapter like:
+ + PCI Cryptographic Accelerator (PCICA)
+ + PCI Cryptographic Coprocessor (PCICC)
+ + PCI-X Cryptographic Coprocessor (PCIXCC)
+ + Crypto Express2 Coprocessor (CEX2C)
+ + 

[patch 14/15] Kconfig: no wireless on s390.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Hide the config menues for wireless on s390.

Cc: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/net/wireless/Kconfig |1 +
 net/Kconfig  |1 +
 2 files changed, 2 insertions(+)

Index: quilt-2.6/drivers/net/wireless/Kconfig
===
--- quilt-2.6.orig/drivers/net/wireless/Kconfig
+++ quilt-2.6/drivers/net/wireless/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Wireless LAN"
+   depends on !S390
 
 config WLAN_PRE80211
bool "Wireless LAN (pre-802.11)"
Index: quilt-2.6/net/Kconfig
===
--- quilt-2.6.orig/net/Kconfig
+++ quilt-2.6/net/Kconfig
@@ -218,6 +218,7 @@ config FIB_RULES
bool
 
 menu "Wireless"
+   depends on !S390
 
 source "net/wireless/Kconfig"
 source "net/mac80211/Kconfig"

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/15] update default configuration.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/defconfig |  234 
 1 file changed, 128 insertions(+), 106 deletions(-)

Index: quilt-2.6/arch/s390/defconfig
===
--- quilt-2.6.orig/arch/s390/defconfig
+++ quilt-2.6/arch/s390/defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.21-rc1
-# Wed Feb 21 10:44:30 2007
+# Linux kernel version: 2.6.21
+# Thu May 10 15:18:19 2007
 #
 CONFIG_MMU=y
 CONFIG_ZONE_DMA=y
@@ -14,6 +14,7 @@ CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_BUG=y
 CONFIG_NO_IOMEM=y
+CONFIG_NO_DMA=y
 CONFIG_S390=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
@@ -41,9 +42,11 @@ CONFIG_AUDIT=y
 # CONFIG_AUDITSYSCALL is not set
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=17
 # CONFIG_CPUSETS is not set
 CONFIG_SYSFS_DEPRECATED=y
 # CONFIG_RELAY is not set
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_SYSCTL=y
@@ -60,12 +63,14 @@ CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 CONFIG_SHMEM=y
-CONFIG_SLAB=y
 CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLUB_DEBUG=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
-# CONFIG_SLOB is not set
 
 #
 # Loadable module support
@@ -128,6 +133,14 @@ CONFIG_CHECK_STACK=y
 CONFIG_STACK_GUARD=256
 # CONFIG_WARN_STACK is not set
 CONFIG_ARCH_POPULATES_NODE_MAP=y
+
+#
+# Kernel preemption
+#
+# CONFIG_PREEMPT_NONE is not set
+# CONFIG_PREEMPT_VOLUNTARY is not set
+CONFIG_PREEMPT=y
+CONFIG_PREEMPT_BKL=y
 CONFIG_SELECT_MEMORY_MODEL=y
 CONFIG_FLATMEM_MANUAL=y
 # CONFIG_DISCONTIGMEM_MANUAL is not set
@@ -150,7 +163,6 @@ CONFIG_QDIO=y
 #
 # Misc
 #
-CONFIG_PREEMPT=y
 CONFIG_IPL=y
 # CONFIG_IPL_TAPE is not set
 CONFIG_IPL_VM=y
@@ -163,6 +175,11 @@ CONFIG_PFAULT=y
 CONFIG_VIRT_TIMER=y
 CONFIG_VIRT_CPU_ACCOUNTING=y
 # CONFIG_APPLDATA_BASE is not set
+CONFIG_HZ_100=y
+# CONFIG_HZ_250 is not set
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=100
 CONFIG_NO_IDLE_HZ=y
 CONFIG_NO_IDLE_HZ_INIT=y
 CONFIG_S390_HYPFS_FS=y
@@ -177,7 +194,6 @@ CONFIG_NET=y
 #
 # Networking options
 #
-# CONFIG_NETDEBUG is not set
 CONFIG_PACKET=y
 # CONFIG_PACKET_MMAP is not set
 CONFIG_UNIX=y
@@ -216,6 +232,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
 CONFIG_IPV6=y
 # CONFIG_IPV6_PRIVACY is not set
 # CONFIG_IPV6_ROUTER_PREF is not set
+# CONFIG_IPV6_OPTIMISTIC_DAD is not set
 # CONFIG_INET6_AH is not set
 # CONFIG_INET6_ESP is not set
 # CONFIG_INET6_IPCOMP is not set
@@ -240,7 +257,12 @@ CONFIG_IPV6_SIT=y
 #
 # SCTP Configuration (EXPERIMENTAL)
 #
-# CONFIG_IP_SCTP is not set
+CONFIG_IP_SCTP=m
+# CONFIG_SCTP_DBG_MSG is not set
+# CONFIG_SCTP_DBG_OBJCNT is not set
+# CONFIG_SCTP_HMAC_NONE is not set
+# CONFIG_SCTP_HMAC_SHA1 is not set
+CONFIG_SCTP_HMAC_MD5=y
 
 #
 # TIPC Configuration (EXPERIMENTAL)
@@ -263,9 +285,6 @@ CONFIG_IPV6_SIT=y
 #
 CONFIG_NET_SCHED=y
 CONFIG_NET_SCH_FIFO=y
-CONFIG_NET_SCH_CLK_JIFFIES=y
-# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
-# CONFIG_NET_SCH_CLK_CPU is not set
 
 #
 # Queueing/Scheduling
@@ -308,11 +327,14 @@ CONFIG_NET_ESTIMATOR=y
 #
 # CONFIG_NET_PKTGEN is not set
 # CONFIG_NET_TCPPROBE is not set
-# CONFIG_HAMRADIO is not set
-# CONFIG_IRDA is not set
-# CONFIG_BT is not set
-# CONFIG_IEEE80211 is not set
+# CONFIG_AF_RXRPC is not set
+# CONFIG_RFKILL is not set
 # CONFIG_PCMCIA is not set
+CONFIG_CCW=y
+
+#
+# Device Drivers
+#
 
 #
 # Generic Driver Options
@@ -330,6 +352,37 @@ CONFIG_SYS_HYPERVISOR=y
 # CONFIG_CONNECTOR is not set
 
 #
+# Block devices
+#
+# CONFIG_BLK_DEV_COW_COMMON is not set
+CONFIG_BLK_DEV_LOOP=m
+# CONFIG_BLK_DEV_CRYPTOLOOP is not set
+CONFIG_BLK_DEV_NBD=m
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=4096
+CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# S/390 block device drivers
+#
+CONFIG_BLK_DEV_XPRAM=m
+# CONFIG_DCSSBLK is not set
+CONFIG_DASD=y
+CONFIG_DASD_PROFILE=y
+CONFIG_DASD_ECKD=y
+CONFIG_DASD_FBA=y
+CONFIG_DASD_DIAG=y
+CONFIG_DASD_EER=y
+
+#
+# Misc devices
+#
+# CONFIG_BLINK is not set
+
+#
 # SCSI device support
 #
 # CONFIG_RAID_ATTRS is not set
@@ -356,6 +409,7 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_CONSTANTS=y
 CONFIG_SCSI_LOGGING=y
 CONFIG_SCSI_SCAN_ASYNC=y
+CONFIG_SCSI_WAIT_SCAN=m
 
 #
 # SCSI Transports
@@ -372,34 +426,6 @@ CONFIG_SCSI_FC_ATTRS=y
 # CONFIG_ISCSI_TCP is not set
 # CONFIG_SCSI_DEBUG is not set
 CONFIG_ZFCP=y
-CONFIG_CCW=y
-
-#
-# Block devices
-#
-# CONFIG_BLK_DEV_COW_COMMON is not set
-CONFIG_BLK_DEV_LOOP=m
-# CONFIG_BLK_DEV_CRYPTOLOOP is not set
-CONFIG_BLK_DEV_NBD=m
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_COUNT=16
-CONFIG_BLK_DEV_RAM_SIZE=4096
-CONFIG_BLK_DEV_RA

[patch 12/15] Kconfig: common config options for s390.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Disable some configuration options in the common Kconfig files that
are of no interest to a s390 machine. Enable hangcheck timer.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/char/Kconfig |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: quilt-2.6/drivers/char/Kconfig
===
--- quilt-2.6.orig/drivers/char/Kconfig
+++ quilt-2.6/drivers/char/Kconfig
@@ -6,6 +6,7 @@ menu "Character devices"
 
 config VT
bool "Virtual terminal" if EMBEDDED
+   depends on !S390
select INPUT
default y if !VIOCONS
---help---
@@ -766,7 +767,7 @@ config NVRAM
 
 config RTC
tristate "Enhanced Real Time Clock Support"
-   depends on !PPC && !PARISC && !IA64 && !M68K && (!SPARC || PCI) && !FRV 
&& !ARM && !SUPERH
+   depends on !PPC && !PARISC && !IA64 && !M68K && (!SPARC || PCI) && !FRV 
&& !ARM && !SUPERH && !S390
---help---
  If you say Y here and create a character special file /dev/rtc with
  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -814,7 +815,7 @@ config SGI_IP27_RTC
 
 config GEN_RTC
tristate "Generic /dev/rtc emulation"
-   depends on RTC!=y && !IA64 && !ARM && !M32R && !SPARC && !FRV
+   depends on RTC!=y && !IA64 && !ARM && !M32R && !SPARC && !FRV && !S390
---help---
  If you say Y here and create a character special file /dev/rtc with
  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -1045,7 +1046,7 @@ config HPET_MMAP
 
 config HANGCHECK_TIMER
tristate "Hangcheck timer"
-   depends on X86 || IA64 || PPC64
+   depends on X86 || IA64 || PPC64 || S390
help
  The hangcheck-timer module detects when the system has gone
  out to lunch past a certain margin.  It can reboot the system

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 10/15] Kconfig: menus with depends on HAS_IOMEM.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Add "depends on HAS_IOMEM" to a number of menus to make them
disappear for s390 which does not have I/O memory.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/ata/Kconfig|1 +
 drivers/char/ipmi/Kconfig  |2 ++
 drivers/char/tpm/Kconfig   |1 +
 drivers/edac/Kconfig   |1 +
 drivers/hwmon/Kconfig  |1 +
 drivers/i2c/Kconfig|1 +
 drivers/ide/Kconfig|1 +
 drivers/infiniband/Kconfig |1 +
 drivers/leds/Kconfig   |1 +
 drivers/media/Kconfig  |1 +
 drivers/mfd/Kconfig|1 +
 drivers/mmc/Kconfig|1 +
 drivers/mtd/Kconfig|1 +
 drivers/parport/Kconfig|1 +
 drivers/pnp/Kconfig|1 +
 drivers/serial/Kconfig |1 +
 drivers/spi/Kconfig|1 +
 drivers/telephony/Kconfig  |1 +
 drivers/usb/Kconfig|1 +
 drivers/video/Kconfig  |1 +
 drivers/w1/Kconfig |1 +
 sound/Kconfig  |1 +
 22 files changed, 23 insertions(+)

Index: quilt-2.6/drivers/ata/Kconfig
===
--- quilt-2.6.orig/drivers/ata/Kconfig
+++ quilt-2.6/drivers/ata/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Serial ATA (prod) and Parallel ATA (experimental) drivers"
+   depends on HAS_IOMEM
 
 config ATA
tristate "ATA device support"
Index: quilt-2.6/drivers/char/ipmi/Kconfig
===
--- quilt-2.6.orig/drivers/char/ipmi/Kconfig
+++ quilt-2.6/drivers/char/ipmi/Kconfig
@@ -3,6 +3,8 @@
 #
 
 menu "IPMI"
+   depends on HAS_IOMEM
+
 config IPMI_HANDLER
tristate 'IPMI top-level message handler'
help
Index: quilt-2.6/drivers/char/tpm/Kconfig
===
--- quilt-2.6.orig/drivers/char/tpm/Kconfig
+++ quilt-2.6/drivers/char/tpm/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "TPM devices"
+   depends on HAS_IOMEM
 
 config TCG_TPM
tristate "TPM Hardware Support"
Index: quilt-2.6/drivers/edac/Kconfig
===
--- quilt-2.6.orig/drivers/edac/Kconfig
+++ quilt-2.6/drivers/edac/Kconfig
@@ -7,6 +7,7 @@
 #
 
 menu 'EDAC - error detection and reporting (RAS) (EXPERIMENTAL)'
+   depends on HAS_IOMEM
 
 config EDAC
tristate "EDAC core system error reporting (EXPERIMENTAL)"
Index: quilt-2.6/drivers/hwmon/Kconfig
===
--- quilt-2.6.orig/drivers/hwmon/Kconfig
+++ quilt-2.6/drivers/hwmon/Kconfig
@@ -4,6 +4,7 @@
 
 menuconfig HWMON
tristate "Hardware Monitoring support"
+   depends on HAS_IOMEM
default y
help
  Hardware monitoring devices let you monitor the hardware health
Index: quilt-2.6/drivers/i2c/Kconfig
===
--- quilt-2.6.orig/drivers/i2c/Kconfig
+++ quilt-2.6/drivers/i2c/Kconfig
@@ -4,6 +4,7 @@
 
 menuconfig I2C
tristate "I2C support"
+   depends on HAS_IOMEM
---help---
  I2C (pronounce: I-square-C) is a slow serial bus protocol used in
  many micro controller applications and developed by Philips.  SMBus,
Index: quilt-2.6/drivers/ide/Kconfig
===
--- quilt-2.6.orig/drivers/ide/Kconfig
+++ quilt-2.6/drivers/ide/Kconfig
@@ -7,6 +7,7 @@
 if BLOCK
 
 menu "ATA/ATAPI/MFM/RLL support"
+   depends on HAS_IOMEM
 
 config IDE
tristate "ATA/ATAPI/MFM/RLL support"
Index: quilt-2.6/drivers/infiniband/Kconfig
===
--- quilt-2.6.orig/drivers/infiniband/Kconfig
+++ quilt-2.6/drivers/infiniband/Kconfig
@@ -1,4 +1,5 @@
 menu "InfiniBand support"
+   depends on HAS_IOMEM
 
 config INFINIBAND
depends on PCI || BROKEN
Index: quilt-2.6/drivers/leds/Kconfig
===
--- quilt-2.6.orig/drivers/leds/Kconfig
+++ quilt-2.6/drivers/leds/Kconfig
@@ -1,5 +1,6 @@
 
 menu "LED devices"
+   depends on HAS_IOMEM
 
 config NEW_LEDS
bool "LED Support"
Index: quilt-2.6/drivers/media/Kconfig
===
--- quilt-2.6.orig/drivers/media/Kconfig
+++ quilt-2.6/drivers/media/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Multimedia devices"
+   depends on HAS_IOMEM
 
 config VIDEO_DEV
tristate "Video For Linux"
Index: quilt-2.6/drivers/mfd/Kconfig
===
--- quilt-2.6.orig/drivers/mfd/Kconfig
+++ quilt-2.6/drivers/mfd/Kconfig
@@ -3,6 +3,7 @@
 #
 
 menu "Multifunction device drivers"
+   depends on HAS_IOMEM
 
 config MFD_SM501
tristate "Support for Silicon Motion SM501"
Index: quilt-2.6/drivers/mmc/Kconfig
==

[patch 09/15] Kconfig: refine depends statements.

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Refine some depends statements to limit their visibility to the
environments that are actually supported.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/auxdisplay/Kconfig |1 +
 drivers/char/Kconfig   |2 ++
 drivers/ieee1394/Kconfig   |1 +
 drivers/kvm/Kconfig|1 +
 drivers/message/fusion/Kconfig |1 +
 drivers/message/i2o/Kconfig|1 +
 6 files changed, 7 insertions(+)

Index: quilt-2.6/drivers/auxdisplay/Kconfig
===
--- quilt-2.6.orig/drivers/auxdisplay/Kconfig
+++ quilt-2.6/drivers/auxdisplay/Kconfig
@@ -6,6 +6,7 @@
 #
 
 menu "Auxiliary Display support"
+   depends on PARPORT
 
 config KS0108
tristate "KS0108 LCD Controller"
Index: quilt-2.6/drivers/char/Kconfig
===
--- quilt-2.6.orig/drivers/char/Kconfig
+++ quilt-2.6/drivers/char/Kconfig
@@ -81,6 +81,7 @@ config VT_HW_CONSOLE_BINDING
 
 config SERIAL_NONSTANDARD
bool "Non-standard serial port support"
+   depends on HAS_IOMEM
---help---
  Say Y here if you have any non-standard serial boards -- boards
  which aren't supported using the standard "dumb" serial driver.
@@ -858,6 +859,7 @@ config COBALT_LCD
 
 config DTLK
tristate "Double Talk PC internal speech card support"
+   depends on ISA
help
  This driver is for the DoubleTalk PC, a speech synthesizer
  manufactured by RC Systems ().  It is also
Index: quilt-2.6/drivers/ieee1394/Kconfig
===
--- quilt-2.6.orig/drivers/ieee1394/Kconfig
+++ quilt-2.6/drivers/ieee1394/Kconfig
@@ -1,4 +1,5 @@
 menu "IEEE 1394 (FireWire) support"
+   depends on PCI || BROKEN
 
 config IEEE1394
tristate "IEEE 1394 (FireWire) support"
Index: quilt-2.6/drivers/kvm/Kconfig
===
--- quilt-2.6.orig/drivers/kvm/Kconfig
+++ quilt-2.6/drivers/kvm/Kconfig
@@ -2,6 +2,7 @@
 # KVM configuration
 #
 menu "Virtualization"
+   depends on X86
 
 config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
Index: quilt-2.6/drivers/message/fusion/Kconfig
===
--- quilt-2.6.orig/drivers/message/fusion/Kconfig
+++ quilt-2.6/drivers/message/fusion/Kconfig
@@ -1,5 +1,6 @@
 
 menu "Fusion MPT device support"
+   depends on PCI
 
 config FUSION
bool
Index: quilt-2.6/drivers/message/i2o/Kconfig
===
--- quilt-2.6.orig/drivers/message/i2o/Kconfig
+++ quilt-2.6/drivers/message/i2o/Kconfig
@@ -1,5 +1,6 @@
 
 menu "I2O device support"
+   depends on PCI
 
 config I2O
tristate "I2O support"

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] MMC updates

[Pierre Ossman]

Hi Nicolas,

You seem to be the source of this workaround, and also the maintainer of
PXA. So I guess this falls into your lap either way. Highlights from my
discussion with Russell:

Pierre Ossman wrote:
> Russell King wrote:
>   
>> > Dug out from the ARM kautobuild...
>> >
>> > drivers/mmc/host/pxamci.c: In function 'pxamci_cmd_done':
>> > drivers/mmc/host/pxamci.c:236: error: 'MMC_ALL_SEND_CID' undeclared (first 
>> > use in this function)
>> > drivers/mmc/host/pxamci.c:236: error: (Each undeclared identifier is 
>> > reported only once
>> > drivers/mmc/host/pxamci.c:236: error: for each function it appears in.)
>> > drivers/mmc/host/pxamci.c:237: error: 'MMC_SEND_CSD' undeclared (first use 
>> > in this function)
>> > drivers/mmc/host/pxamci.c:238: error: 'MMC_SEND_CID' undeclared (first use 
>> > in this function)
>> >
>> >   
>> 
>
> What are opcode defines doing in the driver?

Pierre Ossman wrote:
> Russell King wrote:
>   
>> See the comments immediately above and below its use.
>>
>> Welcome to buggy hardware.
>>
>>   
>> 
>
> I've read through the erratum, and to me it seems like the bug affects
> all long replies, not just these codes. So I think the code should be
> fixed to look at the response flag, not the opcode.
>
> Do you have hardware so that you can test such a change?
>
>   

I guess the same question goes to you. :)

Rgds

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 07/15] qdio: re-add lost perf_stats.tl_runs change in qdio_handle_pci

[Martin Schwidefsky]

From: Ursula Braun <[EMAIL PROTECTED]>

Statement has been inadvertently lost with commit
00c0c6466c66bdf05f2a3dcf59e6895179ea8b76.

Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/s390/cio/qdio.c |1 +
 1 file changed, 1 insertion(+)

Index: quilt-2.6/drivers/s390/cio/qdio.c
===
--- quilt-2.6.orig/drivers/s390/cio/qdio.c
+++ quilt-2.6/drivers/s390/cio/qdio.c
@@ -1983,6 +1983,7 @@ qdio_handle_pci(struct qdio_irq *irq_ptr
if (q->is_input_q&QDIO_FLAG_NO_INPUT_INTERRUPT_CONTEXT)
qdio_mark_q(q);
else {
+   qdio_perf_stat_dec(&perf_stats.tl_runs);
__qdio_inbound_processing(q);
}
}

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] UDF: check for allocated memory for inode data

[Cyrill Gorcunov]

This patch adds cheking for granted memory while
filling up inode data to prevent possible NULL
pointer usage. If there is not enough memory to
fill inode data we just mark it as "bad".

Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>

---

Please check the patch, maybe just marking inode as
"bad" is not a good solution.

 fs/udf/inode.c |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index c846155..91cddae 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1144,6 +1144,13 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
UDF_I_EFE(inode) = 1;
UDF_I_USE(inode) = 0;
UDF_I_DATA(inode) = kmalloc(inode->i_sb->s_blocksize - 
sizeof(struct extendedFileEntry), GFP_KERNEL);
+   if (!UDF_I_DATA(inode))
+   {
+   printk(KERN_ERR "udf: udf_fill_inode(ino %ld) no free 
memory\n",
+  inode->i_ino);
+   make_bad_inode(inode);
+   return;
+   }
memcpy(UDF_I_DATA(inode), bh->b_data + sizeof(struct 
extendedFileEntry), inode->i_sb->s_blocksize - sizeof(struct 
extendedFileEntry));
}
else if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_FE)
@@ -1151,6 +1158,13 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
UDF_I_EFE(inode) = 0;
UDF_I_USE(inode) = 0;
UDF_I_DATA(inode) = kmalloc(inode->i_sb->s_blocksize - 
sizeof(struct fileEntry), GFP_KERNEL);
+   if (!UDF_I_DATA(inode))
+   {
+   printk(KERN_ERR "udf: udf_fill_inode(ino %ld) no free 
memory\n",
+  inode->i_ino);
+   make_bad_inode(inode);
+   return;
+   }
memcpy(UDF_I_DATA(inode), bh->b_data + sizeof(struct 
fileEntry), inode->i_sb->s_blocksize - sizeof(struct fileEntry));
}
else if (le16_to_cpu(fe->descTag.tagIdent) == TAG_IDENT_USE)
@@ -1161,6 +1175,13 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
le32_to_cpu(
((struct unallocSpaceEntry 
*)bh->b_data)->lengthAllocDescs);
UDF_I_DATA(inode) = kmalloc(inode->i_sb->s_blocksize - 
sizeof(struct unallocSpaceEntry), GFP_KERNEL);
+   if (!UDF_I_DATA(inode))
+   {
+   printk(KERN_ERR "udf: udf_fill_inode(ino %ld) no free 
memory\n",
+  inode->i_ino);
+   make_bad_inode(inode);
+   return;
+   }
memcpy(UDF_I_DATA(inode), bh->b_data + sizeof(struct 
unallocSpaceEntry), inode->i_sb->s_blocksize - sizeof(struct 
unallocSpaceEntry));
return;
}
@@ -1178,7 +1199,7 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
inode->i_nlink = le16_to_cpu(fe->fileLinkCount);
if (!inode->i_nlink)
inode->i_nlink = 1;
-   
+
inode->i_size = le64_to_cpu(fe->informationLength);
UDF_I_LENEXTENTS(inode) = inode->i_size;
 
@@ -1230,7 +1251,7 @@ static void udf_fill_inode(struct inode *inode, struct 
buffer_head *bh)
}
else
{
-   inode->i_blocks = le64_to_cpu(efe->logicalBlocksRecorded) << 
+   inode->i_blocks = le64_to_cpu(efe->logicalBlocksRecorded) <<
(inode->i_sb->s_blocksize_bits - 9);
 
if ( udf_stamp_to_time(&convtime, &convtime_usec,
@@ -2059,7 +2080,7 @@ int8_t udf_delete_aext(struct inode *inode, struct 
extent_position epos,
mark_buffer_dirty_inode(oepos.bh, inode);
}
}
-   
+
brelse(epos.bh);
brelse(oepos.bh);
return (elen >> 30);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 07/10] Linux Kernel Markers - Documentation

[Pekka J Enberg]

On Thu, 10 May 2007, Alan Cox wrote:
> > Besides, are we sure the document includes all potential users now? We 
> > wouldn't want to show favorism to any particular projects, now would we?
> 
> Absolutely not - and isn't it more useful to let users know about all of
> the tools that this enables ?

So set up a http//www.linux-markers.org/ and add the list there. We're not 
going to start accepting patches that add "potentially useful new tools" 
to Documentation/marker.txt are we?

On Thu, 10 May 2007, Alan Cox wrote:
> > Many of the already out of date or expiring in the near future... 
> 
> Have you done a statistically valid sampling or is this guessing ?

It's an educated guess which proves nothing but gets the point across 
quite nicely ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] leds:arch/sh/boards/landisk LEDs supports

[Paul Mundt]

kogiidena-san,

On Thu, May 10, 2007 at 08:52:13PM +0900, kogiidena wrote:
> diff -urpN OLD/drivers/leds/leds-landisk.c NEW/drivers/leds/leds-landisk.c
> --- OLD/drivers/leds/leds-landisk.c   1970-01-01 09:00:00.0 +0900
> +++ NEW/drivers/leds/leds-landisk.c   2007-05-10 20:07:11.0 +0900
[snip]
> +spinlock_t landisk_led_lock;

DEFINE_SPINLOCK(), please.

> +static int landisk_arch; /* 0:LANDISK, LANTank 1:USL-5P */
> +
If you're going to do this, enums are probably the cleaner way to go.
Checking landisk_arch == 0 all over the place is non-obvious without
seeing this comment.

> +static void landisk_led_set(struct led_classdev *led_cdev,
> + enum led_brightness value)
> +{
> + u8 tmp;
> + int bitmask;
> + unsigned long flags;
> +
> + bitmask = 0x01 << (led_cdev - &landisk_leds[0]);
> +
> + spin_lock_irqsave(&landisk_led_lock, flags);
> + tmp = ctrl_inb(PA_LED);
> + if (value)
> + tmp |= bitmask;
> + else
> + tmp &= ~bitmask;
> + ctrl_outb(tmp, PA_LED);

You may also want some sanity checking here, while PA_LED is only 8-bits,
your bitmask is not.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Intel IXP4xx network drivers v.3 - QMGR

[Krzysztof Halasa]

Lennert Buytenhek <[EMAIL PROTECTED]> writes:

> The way I see it, that means that you do want to scale back your
> other SRAM allocations if you know that you're going to need a lot
> of SRAM (say, for ethernet RX/TX queues.)

Yep, I will then add "queue_size" parameter to the platform data.
Or something like that.

> Or you can put this knowledge in the board support code (cleaner, IMHO.)

Sure.

> That way, you can _guarantee_ that you'll always have enough SRAM
> to be able to use the functionality that is exposed on the board you
> are running on (which is a desirable property, IMHO), which is
> something that you can't achieve with an allocator, as far as I can
> see.

I'd have to put SRAM address in the board code instead. Certainly
not required at this point, and perhaps it will be never needed.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86 setup rewrite tree ready for flamage^W review

[Alexander van Heukelum]

On Tue, 08 May 2007 22:15:21 -0700, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> I believe the x86 setup tree is now finished.  I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.

Hi!

Only tiny sparks^Wremarks, I'm afraid. ;)

I've briefly looked at the new code in arch/i386/boot and as far 
as I can determine in a short amount of time all functionality is
basically there, with the exception of the 'scan' functionality for 
bios modes. Maybe it is not needed anymore? I have used this 
functionality to find non-standard modes recently (for a kernel 
crash during boot).

Random remarks about config-differences:

The new code does not use VIDEO_SELECT and X86_SPEEDSTEP_SMI
(i386-only): both parts are always compiled in. The new code uses FB:
the old code allowed setting a graphics mode, even without FB support.
Shared config options that affect the code generation: EDD, RELOCATABLE,
FIRMWARE_EDID, and APM (i386-only). Some code also depends on X86_ELAN
and X86_VOYAGER.

Allnoconfig realmode kernel part increases by about 3.5 kb:
old x86_64:  Boot sector 512 bytes. / Setup is 4737 bytes.
new x86_64:  Setup is 8808 bytes (padded to 9216 bytes).
old i386:  Boot sector 512 bytes. / Setup is 4842 bytes.
new i386:  Setup is 8776 bytes (padded to 9216 bytes).

When all relevant options are enabled about 1.5 kb:
old x86_64:  Boot sector 512 bytes. / Setup is 7394 bytes.
new x86_64:  Setup is 9672 bytes (padded to 9728 bytes).
old i386:  Boot sector 512 bytes. / Setup is 7649 bytes.
new i386:  Setup is 9896 bytes (padded to 10240 bytes).

So the code explosion is not too bad. Although... it is helps quite a
bit that the old setup contains a chunk of slightly more than 3 kb of
zeros which has disappeared with the new code. On the other hand, the
new code provides a valuable debugging tool in the form of a printf
function.

$ size arch/i386/boot/setup.elf
   textdata bss dec hex filename
   9768  966056   159203e30 setup.elf

How much memory should we expect to be available? Is the assert for
32 kb for text+data+bss in setup.ld reasonable? Is it guaranteed
that the bootloader stores the commandline after _end?

The amount of code that depends on config options is relatively small.
Would it make sense to just compile everything independent of config
options and determine what should be done at run-time? And/or separate
the bootcode related config-options and put them under EMBEDDED/TINY?

If space is not that much of an issue, could you imagine putting
the decompression/relocation/misc.c code in setup too? This would
make it easier to start thinking of a new kernel image format without
breaking bootloaders that use a bzImage in the intended way.

Good luck,
Alexander
-- 
  Alexander van Heukelum
  [EMAIL PROTECTED]

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] update sysfs kset initialisation in PPC64 DLPAR IO driver

[Greg KH]

On Thu, May 10, 2007 at 03:00:50PM +0100, Andy Whitcroft wrote:
> 
> Move the rpadlpar device from "struct subsystem" to "struct kset"
> following the changes in sysfs.
> 
> Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
> ---
> 
>   Ok, this patch seems to sort out the compile problem
>   here and indeed boots and runs kernbench.  Perhaps
>   you could confirm this is sufficient.

As per the discussion on the pci hotplug list, no, this doesn't seem to
fix the problem.  The developers there are looking into it.  If you can
test out patches for this, I'm sure the people there would appreciate
the help.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 07/10] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Wed, May 09, 2007 at 09:56:02PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> Please remove all references to out of tree code from the kernel 
> documentation.
> 

Since I expect people who will read this documentation to be familiar
with kprobes already, I tried to make the adaptation process as easy as
possible for them. You will find similar examples in
Documentation/kprobes.txt.

Also, this kind of example, which describes what kernel code is needed
to use the markers (this can be either a separate kernel module or
embedded in the kernel, like the blktrace example), seems to be a
straightforward way to teach people how to use the markers.

Mathieu

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

Kernel BUG: NULL pointer dereference , reference to sys_recvmsg

[Croulder Croulder]

Greetings,

The next report is a Kernel NULL pointer dereference in tcp/ip (IPv4).

I see that message all time in syslog.conf and console.

Kernel compiled with gcc 4.1.1->   (Debian 4.1.1-21)
Kernel Version: 2.6.21.1 (official source code)
Processor: 2 x Xeon 2.8
Ram: 1G
Swap: 1G
Raid: Using raid software (Raid1 and Rai5)
Network report: 2Mb/sg output , 512Kb/sg input
Protocols: tcp, udp, icmp, arp


server kernel: EIP: [] sys_recvmsg+0x100/0x1cd SS:ESP 0068:ec9f1e7c
May 10 13:41:22 server kernel: BUG: unable to handle kernel NULL
pointer dereference at virtual address 000f
May 10 13:41:22 server kernel:  printing eip:
May 10 13:41:22 server kernel: c03bc7df
May 10 13:41:22 server kernel: *pde = 
May 10 13:41:22 server kernel: Oops:  [#64]
May 10 13:41:22 server kernel: SMP
May 10 13:41:22 server kernel: Modules linked in:
May 10 13:41:22 server kernel: CPU:1
May 10 13:41:22 server kernel: EIP:0060:[]Not tainted VLI
May 10 13:41:22 server kernel: EFLAGS: 00010202   (2.6.21.1-dh1 #7)
May 10 13:41:22 server kernel: EIP is at sys_recvmsg+0x100/0x1cd
May 10 13:41:22 server kernel: eax: bf5f4148   ebx:    ecx:
7d00   edx: 0040
May 10 13:41:22 server kernel: esi:    edi:    ebp:
ec9f1f08   esp: ec9f1e7c
May 10 13:41:22 server kernel: ds: 007b   es: 007b   fs: 00d8  gs:
0033  ss: 0068
May 10 13:41:22 server kernel: Process hlxserverplus (pid: 32149,
ti=ec9f task=f4bc90b0 task.ti=ec9f)
May 10 13:41:22 server kernel: Stack: 0001 bf5f4148 0008
c0139979 0002 0044 0002 
May 10 13:41:22 server kernel:000280d2 c0563630 
0001 3aa4bcb4 0001 ff4be90f 5761ed52
May 10 13:41:22 server kernel:c13edca0 096c 000280d2
c0563628 f4bc90b0 c0139a47 0044 ec9f1efa
May 10 13:41:22 server kernel: Call Trace:
May 10 13:41:22 server kernel:  [] get_page_from_freelist+0x24d/0x2c9
May 10 13:41:22 server kernel:  [] __alloc_pages+0x52/0x286
May 10 13:41:22 server kernel:  [] tcp_v4_hash+0xfe/0x110
May 10 13:41:22 server kernel:  [] release_sock+0x12/0x9c
May 10 13:41:22 server kernel:  [] sys_socketcall+0x239/0x242
May 10 13:41:22 server kernel:  [] do_page_fault+0x0/0x512
May 10 13:41:22 server kernel:  [] syscall_call+0x7/0xb
May 10 13:41:22 server kernel:  ===
May 10 13:41:22 server kernel: Code: c0 89 c1 89 84 24 ec 00 00 00 0f
88 a9 00 00 00 8b 84 24 dc 00 00 00 c7 84 24 e4 00 00 00 00 00 00 00
89 da 83 ca 40 89 44 24 04 <8b> 46 10 f6 40 19 08 89 f0 0f 45 da 8d 94
24 cc 00 00 00 89 1c
May 10 13:41:22 server kernel: EIP: []
sys_recvmsg+0x100/0x1cd SS:ESP 0068:ec9f1e7c



any fix?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 00/16] raid acceleration and asynchronous offload api for 2.6.22

[Tomasz Chmielewski]

Ronen Shitrit wrote:


The resync numbers you sent, looks very promising :)
Do you have any performance numbers that you can share for these set of
patches, which shows the Rd/Wr IO bandwidth.


I have some simple tests made with hdparm, with the results I don't 
understand.


We see hdparm results are fine if we access the whole device:

thecus:~# hdparm -Tt /dev/sdd

/dev/sdd:
 Timing cached reads:   392 MB in  2.00 seconds = 195.71 MB/sec
 Timing buffered disk reads:  146 MB in  3.01 seconds =  48.47 MB/sec


But are 10 times worse (Timing buffered disk reads) when we access 
partitions:


thecus:/# hdparm -Tt /dev/sdc1 /dev/sdd1

/dev/sdc1:
 Timing cached reads:   396 MB in  2.01 seconds = 197.18 MB/sec
 Timing buffered disk reads:   16 MB in  3.32 seconds =   4.83 MB/sec

/dev/sdd1:
 Timing cached reads:   394 MB in  2.00 seconds = 196.89 MB/sec
 Timing buffered disk reads:   16 MB in  3.13 seconds =   5.11 MB/sec


Why is it so much worse?


I used 2.6.21-iop1 patches from http://sf.net/projects/xscaleiop; right 
now I use 2.6.17-iop1, for which the results are ~35 MB/s when accessing 
a device (/dev/sdd) or a partition (/dev/sdd1).



In kernel config, I enabled Intel DMA engines.

The device I use is Thecus n4100, it is "Platform: IQ31244 (XScale)", 
and has 600 MHz CPU.



--
Tomasz Chmielewski
http://wpkg.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 07/10] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Wed, May 09, 2007 at 09:56:02PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> Please remove all references to out of tree code from the kernel 
> documentation.
> 

Hrm, I see.. you are objecting to mentioning of "LTTng, LKET, SystemTAP"...
I agree : it belongs to a changelog (which is bounded in time) rather
than to the documentation itself.

-- 
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: Andi, you broke my laptop :-)

[Andi Kleen]

On Thu, May 10, 2007 at 03:35:56PM +0200, Joerg Roedel wrote:
> On Thu, May 10, 2007 at 03:01:44PM +0200, Andi Kleen wrote:
> > On Wed, May 09, 2007 at 12:56:16PM -0700, Pete Zaitcev wrote:
> > > Hi, Andi:
> > > 
> > > The attached patch (actually, git show output) makes my Dell 1501 to hang
> > > on boot. Sorry, I have no clue why... The culprit is found with git 
> > > bisect.
> > > But yes, it's an AMD MK-36. I use an x86_64 kernel. It is 100% 
> > > reproducible.
> > 
> > MK-36? Does it have SVM? 
> > 
> > Anyways we previously had issues with this being miscompiled, but 
> > I thought the latest patch should have been ok. What compiler do you use?
> > 
> > Can you send me a disassembly listing of arch/x86_64/kernel/time.o?
> 
> I debugged this problem a bit and my compiler[1]interprets the =A
> constraint as %rax instead of %edx:%eax on x86_64 which causes the
> problem. The appended patch provides a workaround for this and fixed the
> hang on my machine.

Hmm yes now I can reproduce it too. I didn't see any hangs so i suppose 
my (and that of most -mm tester's) compiled binary always happened to have a 
suitable value in edx

Thanks for the patch.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 PATCH 22/26] dm: bio list helpers

[Jan Engelhardt]

On May 8 2007 17:41, Andrew Morton wrote:
>On Tue, 8 May 2007 20:48:45 +0100
>Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
>
>> +#define BIO_LIST_INIT { .head = NULL, .tail = NULL }
>> +
>> +#define BIO_LIST(bl) \
>> +struct bio_list bl = BIO_LIST_INIT
>
>BIO_LIST is a strange name for something which initialises storage.

So try DEFINE_BIO_LIST, it goes in line with DEFINE_SPINLOCK for example.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.22 PATCH 22/26] dm: bio list helpers

[Jan Engelhardt]

On May 9 2007 08:49, Jens Axboe wrote:
>On Tue, May 08 2007, Andrew Morton wrote:
>> > +#define bio_list_for_each(bio, bl) \
>> > +  for (bio = (bl)->head; bio && ({ prefetch(bio->bi_next); 1; }); \
>> > +   bio = bio->bi_next)
>> > +
>
>Besides, manual prefetching is very rarely a win. I dabbled with some
>benchmarks a few weeks back (with the doubly linked lists), and in most
>cases it was actually a loss. So I'd vote for just removing the
>prefetch() above.

So is the prefetching in the basic ADTs (e.g. linux/list.h) a loss too?



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

why are we reduce spin-lock and replace it with lock-free?

[liang yuanen]

Three are many many spin-lock in the kernel code, and in multi-core
conditions, it push down the kernel performance.why are we reduce
spin-lock and replace it with lock-free?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[Phillip Susi]

Stefan Richter wrote:

The SCSI stack already has infrastructure for multi-threaded discovery
and probing.


So?  It would still benefit from using a generic framework that other 
buses can use as well.  Not to mention that the current scsi specific 
framework tends to cause unstable names doesn't 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: Announcing free software drivers for the new Intel® 965GM Express Chipset

[Jan Engelhardt]

On May 10 2007 00:28, Jeff Garzik wrote:
>
> Great news.
>
> Here's hoping that Intel produces a standalone video card eventually, to
> further take away market share from closed source competitors.
>
>   Jeff, not biased at all...

http://www.pledgebank.com/open3d
Heh - I just wonder if Intel gets there first!



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 06/10] Linux Kernel Markers - Non optimized architectures

[Mathieu Desnoyers]

* Alan Cox ([EMAIL PROTECTED]) wrote:
> > - Fix optimisation -> optimization typo in powerpc and i386 headers.
> 
> That isn't a typo, it's correct as is.
> 
> Alan

Well, it's correct or not depending on which side of the ocean you are.
but as I used "optimization" everywhere else in my code, I simply try to
be consistent.

-- 
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: Andi, you broke my laptop :-)

[Benny Halevy]

Joerg's patch works for me too.

Thanks,

Benny

Andi Kleen wrote:
> On Thu, May 10, 2007 at 03:35:56PM +0200, Joerg Roedel wrote:
>> On Thu, May 10, 2007 at 03:01:44PM +0200, Andi Kleen wrote:
>>> On Wed, May 09, 2007 at 12:56:16PM -0700, Pete Zaitcev wrote:
 Hi, Andi:

 The attached patch (actually, git show output) makes my Dell 1501 to hang
 on boot. Sorry, I have no clue why... The culprit is found with git bisect.
 But yes, it's an AMD MK-36. I use an x86_64 kernel. It is 100% 
 reproducible.
>>> MK-36? Does it have SVM? 
>>>
>>> Anyways we previously had issues with this being miscompiled, but 
>>> I thought the latest patch should have been ok. What compiler do you use?
>>>
>>> Can you send me a disassembly listing of arch/x86_64/kernel/time.o?
>> I debugged this problem a bit and my compiler[1]interprets the =A
>> constraint as %rax instead of %edx:%eax on x86_64 which causes the
>> problem. The appended patch provides a workaround for this and fixed the
>> hang on my machine.
> 
> Hmm yes now I can reproduce it too. I didn't see any hangs so i suppose 
> my (and that of most -mm tester's) compiled binary always happened to have a 
> suitable value in edx
> 
> Thanks for the patch.
> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Benny Halevy
Panasas Inc.
Accelerating Time to Results(TM) with Clustered Storage

www.panasas.com
[EMAIL PROTECTED]
Tel/Fax: +972-3-647-8340
Mobile: +972-54-802-8340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6.21-mm2] driver-core: make devt_attr and uevent_attr static

[Tejun Heo]

devt_attr and uevent_attr are either allocated dynamically with or
embedded in device and class_device as they needed their owner field
set to the module implementing the driver.  Now that sysfs implements
immediate disconnect and owner field removed from struct attribute,
there is no reason to do this.  Remove these attributes from
[class_]device and use static attribute structures instead.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
 drivers/base/class.c   |   44 
 drivers/base/core.c|   45 +++--
 include/linux/device.h |5 -
 3 files changed, 31 insertions(+), 63 deletions(-)

Index: tree0/drivers/base/class.c
===
--- tree0.orig/drivers/base/class.c
+++ tree0/drivers/base/class.c
@@ -312,9 +312,6 @@ static void class_dev_release(struct kob
 
pr_debug("device class '%s': release.\n", cd->class_id);
 
-   kfree(cd->devt_attr);
-   cd->devt_attr = NULL;
-
if (cd->release)
cd->release(cd);
else if (cls->release)
@@ -564,6 +561,9 @@ static ssize_t show_dev(struct class_dev
return print_dev_t(buf, class_dev->devt);
 }
 
+static struct class_device_attribute class_devt_attr =
+   __ATTR(dev, S_IRUGO, show_dev, NULL);
+
 static ssize_t store_uevent(struct class_device *class_dev,
const char *buf, size_t count)
 {
@@ -571,6 +571,9 @@ static ssize_t store_uevent(struct class
return count;
 }
 
+static struct class_device_attribute class_uevent_attr =
+   __ATTR(uevent, S_IWUSR, NULL, store_uevent);
+
 void class_device_initialize(struct class_device *class_dev)
 {
kobj_set_kset_s(class_dev, class_obj_subsys);
@@ -620,30 +623,15 @@ int class_device_add(struct class_device
  &parent_class->subsys.kobj, "subsystem");
if (error)
goto out3;
-   class_dev->uevent_attr.attr.name = "uevent";
-   class_dev->uevent_attr.attr.mode = S_IWUSR;
-   class_dev->uevent_attr.store = store_uevent;
-   error = class_device_create_file(class_dev, &class_dev->uevent_attr);
+
+   error = class_device_create_file(class_dev, &class_uevent_attr);
if (error)
goto out3;
 
if (MAJOR(class_dev->devt)) {
-   struct class_device_attribute *attr;
-   attr = kzalloc(sizeof(*attr), GFP_KERNEL);
-   if (!attr) {
-   error = -ENOMEM;
-   goto out4;
-   }
-   attr->attr.name = "dev";
-   attr->attr.mode = S_IRUGO;
-   attr->show = show_dev;
-   error = class_device_create_file(class_dev, attr);
-   if (error) {
-   kfree(attr);
+   error = class_device_create_file(class_dev, &class_devt_attr);
+   if (error)
goto out4;
-   }
-
-   class_dev->devt_attr = attr;
}
 
error = class_device_add_attrs(class_dev);
@@ -686,10 +674,10 @@ int class_device_add(struct class_device
  out6:
class_device_remove_attrs(class_dev);
  out5:
-   if (class_dev->devt_attr)
-   class_device_remove_file(class_dev, class_dev->devt_attr);
+   if (MAJOR(class_dev->devt))
+   class_device_remove_file(class_dev, &class_devt_attr);
  out4:
-   class_device_remove_file(class_dev, &class_dev->uevent_attr);
+   class_device_remove_file(class_dev, &class_uevent_attr);
  out3:
kobject_del(&class_dev->kobj);
  out2:
@@ -789,9 +777,9 @@ void class_device_del(struct class_devic
sysfs_remove_link(&class_dev->kobj, "device");
}
sysfs_remove_link(&class_dev->kobj, "subsystem");
-   class_device_remove_file(class_dev, &class_dev->uevent_attr);
-   if (class_dev->devt_attr)
-   class_device_remove_file(class_dev, class_dev->devt_attr);
+   class_device_remove_file(class_dev, &class_uevent_attr);
+   if (MAJOR(class_dev->devt))
+   class_device_remove_file(class_dev, &class_devt_attr);
class_device_remove_attrs(class_dev);
class_device_remove_groups(class_dev);
 
Index: tree0/drivers/base/core.c
===
--- tree0.orig/drivers/base/core.c
+++ tree0/drivers/base/core.c
@@ -308,6 +308,9 @@ static ssize_t store_uevent(struct devic
return count;
 }
 
+static struct device_attribute uevent_attr =
+   __ATTR(uevent, S_IRUGO | S_IWUSR, show_uevent, store_uevent);
+
 static int device_add_attributes(struct device *dev,
 struct device_attribute *attrs)
 {
@@ -421,6 +424,9 @@ static ssize_t show_dev(struct device *d
return print_dev_t(buf, dev->devt);
 }
 
+static struct device_attribute devt_attr =
+   __ATTR(dev, S_IRUGO, sh

Re: [2.6.22 PATCH 22/26] dm: bio list helpers

[Alan Cox]

On Thu, 10 May 2007 16:17:57 +0200 (MEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> 
> On May 9 2007 08:49, Jens Axboe wrote:
> >On Tue, May 08 2007, Andrew Morton wrote:
> >> > +#define bio_list_for_each(bio, bl) \
> >> > +for (bio = (bl)->head; bio && ({ prefetch(bio->bi_next); 1; }); 
> >> > \
> >> > + bio = bio->bi_next)
> >> > +
> >
> >Besides, manual prefetching is very rarely a win. I dabbled with some
> >benchmarks a few weeks back (with the doubly linked lists), and in most
> >cases it was actually a loss. So I'd vote for just removing the
> >prefetch() above.
> 
> So is the prefetching in the basic ADTs (e.g. linux/list.h) a loss too?

Depends on the box it seems. On the newest systems the processor
prefetching seems to be very much smarter. On a "classic" AMD Athlon the
prefetching made the scheduler about 1.5% faster...

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: why are we reduce spin-lock and replace it with lock-free?

[Alan Cox]

On Thu, 10 May 2007 22:23:32 +0800
"liang yuanen" <[EMAIL PROTECTED]> wrote:

> Three are many many spin-lock in the kernel code, and in multi-core
> conditions, it push down the kernel performance.why are we reduce
> spin-lock and replace it with lock-free?

If you can find algorithms which are lock free, faster than taking the
lock and have bounded resource consumption then you can test them with
the kernel and send patches. 

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add LZO1X compression support to the kernel

[Jan Engelhardt]

On May 9 2007 23:21, Andrew Morton wrote:
>On Wed, 02 May 2007 09:56:23 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote:
>
>> Add LZO1X compression/decompression support to the kernel.
>> 
>> This is based on the standard userspace lzo library, particularly
>> minilzo with the headers much trimmed down and simplified for kernel
>> use. Its structured so that it should still diff with the userspace
>> version for ease of future updating.
>
>Well that's attractive-looking code.
>Why is this needed?  What code plans to use it?

Perhaps squashfs [not included] could use it as an alternative to
zlib or LZMA* [not included either].

* That's floating patches not in the official squashfs AFAICT.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

[Haavard Skinnemoen]

On Thu, 10 May 2007 15:45:54 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:

> Haavard Skinnemoen wrote:
> > 
> > What exactly makes this unreliable? This is done almost exactly the
> > same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
> > 
> 
> I am not against the function of waiting for an initial scan, what I oppose is
> using side effects to achieve that function. I do not want to take
> responsibility for something that easily breaks because we use a kernel
> subsystem for something it wasn't meant for.

Ok, is there any better way to achieve the same this? As far as I
can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
same purpose -- it ensures that scans that have already been started
will have completed before the function continues.

> That said, if there is a precedent for achieving this function a certain way, 
> I
> might be convinced to let it in. I'll have a look at that scsi example.

Thanks.

> > I don't know about USB, but root=/dev/mmcblk0p1 used to work before
> > 2.6.20 and it doesn't work anymore. Doesn't that make this a regression?
> > 
> 
> Yes and no. It depends on if it was an official function, or just an effect of
> how things currently were implemented. As far as I can see, it's the latter. 
> The
> MMC layer goes through several steps that could very well get delayed or 
> happen
> in parallel. So the fact that it happened to work the way you wanted it to was
> sheer luck.

I wouldn't call it luck. The way mmc_rescan() is implemented, any scans
that are started before late_initcall time are completed before
mmc_finish_detect() returns. The steps are all done synchronously in
the workqueue function.

And I never realized that using a block device as a parameter to the
root= parameter could possibly be "unofficial" functionality...?

Haavard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] driver-core: don't free devt_attr till the device is released

[Tejun Heo]

Currently, devt_attr for the "dev" file is freed immediately on device
removal, but if the "dev" sysfs file is open when a device is removed,
sysfs will access its attribute structure for further access including
close resulting in jumping to garbled address.  Fix it by postponing
freeing devt_attr to device release time.

Note that devt_attr for class_device is already freed on release.

This bug is reported by Chris Rankin as bugzilla bug#8198.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Chris Rankin <[EMAIL PROTECTED]>
---
Applies well to 2.6.20 and 21.  As sysfs-immediate-disconnect doesn't
seem to be included in 2.6.22, this should be included in linus#master
too (applies well there as well).

* This is the second post.  Something went wrong with the recipients
  list on the first posting.  Both are same.

Thanks.

 drivers/base/core.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: tree0/drivers/base/core.c
===
--- tree0.orig/drivers/base/core.c
+++ tree0/drivers/base/core.c
@@ -93,6 +93,9 @@ static void device_release(struct kobjec
 {
struct device * dev = to_dev(kobj);
 
+   kfree(dev->devt_attr);
+   dev->devt_attr = NULL;
+
if (dev->release)
dev->release(dev);
else if (dev->class && dev->class->dev_release)
@@ -650,10 +653,8 @@ void device_del(struct device * dev)
 
if (parent)
klist_del(&dev->knode_parent);
-   if (dev->devt_attr) {
+   if (dev->devt_attr)
device_remove_file(dev, dev->devt_attr);
-   kfree(dev->devt_attr);
-   }
if (dev->class) {
sysfs_remove_link(&dev->kobj, "subsystem");
/* If this is not a "fake" compatible device, remove the
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free

[Kok, Auke]

Tomohiro Kusumi wrote:

Hi

As you can see in the "10. pci_enable_device_bars() and Legacy I/O
Port space" of the Documentation/pci.txt, the latest kernel has
interfaces for PCI device drivers to tell the kernel which resource
the driver want to use, ex. I/O port or MMIO.

I've made a patch which makes Intel e1000 driver legacy I/O port
free by using the PCI core changes I mentioned above. The Intel
e1000 driver can handle some of its devices without using I/O port.
So this patch changes the driver not to enable/request I/O port
region depending on the device id.

As a result, the driver can handle its device even when there are
huge number of PCI devices being used on the system and no I/O
port region assigned to the device.


Tomohiro,

I'm ok with the bottom part of the patch, but I do not like the modification of 
the pci device ID table in this way. As Arjan van der Ven previously commented 
as well, this makes it hard for future device ID's to be bound to the driver.


On top of that, there is no logical correlation between the mapping and 
chipsets, so a lot of information is lost in that table. It really does not show 
which _chipsets_ support this functionality.


I think if we want to work with this, we need some way of mapping the device 
ID's back to chipsets, and enable the feature on that basis.


Auke



Tomohiro Kusumi

Signed-off-by: Tomohiro Kusumi <[EMAIL PROTECTED]>

---
 e1000.h  |6 +-
 e1000_main.c |  152 +++
 2 files changed, 86 insertions(+), 72 deletions(-)

diff -uprN linux-2.6.21.orig/drivers/net/e1000/e1000.h 
linux-2.6.21/drivers/net/e1000/e1000.h
--- linux-2.6.21.orig/drivers/net/e1000/e1000.h 2007-05-09 18:02:26.0 
+0900
+++ linux-2.6.21/drivers/net/e1000/e1000.h  2007-05-09 18:02:59.0 
+0900
@@ -74,8 +74,9 @@
 #define BAR_1  1
 #define BAR_5  5

-#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
+#define E1000_USE_IOPORT   (1 << 0)
+#define INTEL_E1000_ETHERNET_DEVICE(device_id, flags) {\
+   PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id), .driver_data = flags}

 struct e1000_adapter;

@@ -347,6 +348,7 @@ struct e1000_adapter {
boolean_t quad_port_a;
unsigned long flags;
uint32_t eeprom_wol;
+   int bars;   /* BARs to be enabled */
 };

 enum e1000_state_t {
diff -uprN linux-2.6.21.orig/drivers/net/e1000/e1000_main.c 
linux-2.6.21/drivers/net/e1000/e1000_main.c
--- linux-2.6.21.orig/drivers/net/e1000/e1000_main.c2007-05-09 
18:02:27.0 +0900
+++ linux-2.6.21/drivers/net/e1000/e1000_main.c 2007-05-09 18:03:00.0 
+0900
@@ -48,65 +48,65 @@ static char e1000_copyright[] = "Copyrig
  *   {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
  */
 static struct pci_device_id e1000_pci_tbl[] = {
-   INTEL_E1000_ETHERNET_DEVICE(0x1000),
-   INTEL_E1000_ETHERNET_DEVICE(0x1001),
-   INTEL_E1000_ETHERNET_DEVICE(0x1004),
-   INTEL_E1000_ETHERNET_DEVICE(0x1008),
-   INTEL_E1000_ETHERNET_DEVICE(0x1009),
-   INTEL_E1000_ETHERNET_DEVICE(0x100C),
-   INTEL_E1000_ETHERNET_DEVICE(0x100D),
-   INTEL_E1000_ETHERNET_DEVICE(0x100E),
-   INTEL_E1000_ETHERNET_DEVICE(0x100F),
-   INTEL_E1000_ETHERNET_DEVICE(0x1010),
-   INTEL_E1000_ETHERNET_DEVICE(0x1011),
-   INTEL_E1000_ETHERNET_DEVICE(0x1012),
-   INTEL_E1000_ETHERNET_DEVICE(0x1013),
-   INTEL_E1000_ETHERNET_DEVICE(0x1014),
-   INTEL_E1000_ETHERNET_DEVICE(0x1015),
-   INTEL_E1000_ETHERNET_DEVICE(0x1016),
-   INTEL_E1000_ETHERNET_DEVICE(0x1017),
-   INTEL_E1000_ETHERNET_DEVICE(0x1018),
-   INTEL_E1000_ETHERNET_DEVICE(0x1019),
-   INTEL_E1000_ETHERNET_DEVICE(0x101A),
-   INTEL_E1000_ETHERNET_DEVICE(0x101D),
-   INTEL_E1000_ETHERNET_DEVICE(0x101E),
-   INTEL_E1000_ETHERNET_DEVICE(0x1026),
-   INTEL_E1000_ETHERNET_DEVICE(0x1027),
-   INTEL_E1000_ETHERNET_DEVICE(0x1028),
-   INTEL_E1000_ETHERNET_DEVICE(0x1049),
-   INTEL_E1000_ETHERNET_DEVICE(0x104A),
-   INTEL_E1000_ETHERNET_DEVICE(0x104B),
-   INTEL_E1000_ETHERNET_DEVICE(0x104C),
-   INTEL_E1000_ETHERNET_DEVICE(0x104D),
-   INTEL_E1000_ETHERNET_DEVICE(0x105E),
-   INTEL_E1000_ETHERNET_DEVICE(0x105F),
-   INTEL_E1000_ETHERNET_DEVICE(0x1060),
-   INTEL_E1000_ETHERNET_DEVICE(0x1075),
-   INTEL_E1000_ETHERNET_DEVICE(0x1076),
-   INTEL_E1000_ETHERNET_DEVICE(0x1077),
-   INTEL_E1000_ETHERNET_DEVICE(0x1078),
-   INTEL_E1000_ETHERNET_DEVICE(0x1079),
-   INTEL_E1000_ETHERNET_DEVICE(0x107A),
-   INTEL_E1000_ETHERNET_DEVICE(0x107B),
-   INTEL_E1000_ETHERNET_DEVICE(0x107C),
-   INTEL_E1000_ETHERNET_DEVICE(0x107D),
-   INTEL_E1000_ETHERNET_DEVICE(0x107E),
-   INTEL_E1000_ETHERNET_DEVICE(0x107F),
-   INTEL_E1000_ETHERNET_DEVICE(0x108A),
-   INTEL_E1000_ETHERNET_DEVICE(0x108B),
-   INTEL_E1000_ETHERNET_DEVICE(0x108C),
-   I

Re: Long file names in VFAT broken with iocharset=utf8

[Bodo Eggert]

Albert Cahalan <[EMAIL PROTECTED]> wrote:
> On 5/9/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:

>> 3. this still does not answer how can I *create* long name from within Linux.
> 
> WTF? These names are too annoying to use, even if there
> weren't this limit. Anything over about 29 characters is in
> need of a rename. (that'd be 58 bytes for you, which is OK)
> The limit is already 4 times larger than what is reasonable.

Just because you limit yourself to 80 chars minus "ls -l"-clutter, this is
no reason why I shouldn't use long filenames. If I need to handle these
filenames, I can enlarge the terminal window or read the next line.

E.g.: I have a music file named "artist - title.ext", where the artist
name is 103 characters long, using abbreviations. In order to enter that
name, I have to press seven keys, including the escape character.
There is nothing unreasonable in using that name.

If I could not use these filenames, I'd have to use e.g. numbers instead of
filenames and a database containing the mapping from name to number,
duplicating the function of a directory. That's bullsh... . You should rather
bump NAME_MAX and, if you are concerned about legacy applications, make it
optional. Having some names to be illegal becaue of their length on a
filesystem not allowing command.com metacharacters is not a problem.
-- 
Funny quotes:
3. On the other hand, you have different fingers.

Friß, Spammer: [EMAIL PROTECTED] [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: [GIT PULL] MMC updates

[Nicolas Pitre]

On Thu, 10 May 2007, Pierre Ossman wrote:

> You seem to be the source of this workaround, and also the maintainer of
> PXA.

Well... I used to.

But the only MMC capable PXA hardware in working conditions I have 
access to at the moment is PXA255 based which doesn't suffer from this 
erratum.

> Pierre Ossman wrote:
> > Russell King wrote:
> >   
> >> See the comments immediately above and below its use.
> >>
> >> Welcome to buggy hardware.
> >>
> >>   
> >> 
> >
> > I've read through the erratum, and to me it seems like the bug affects
> > all long replies, not just these codes. So I think the code should be
> > fixed to look at the response flag, not the opcode.
> >
> > Do you have hardware so that you can test such a change?
> >
> >   
> 
> I guess the same question goes to you. :)

People in better position than I currently do to test a fix are most 
likely to be found on lak.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE)

[Stefan Richter]

Phillip Susi wrote:
> Stefan Richter wrote:
>> The SCSI stack already has infrastructure for multi-threaded discovery
>> and probing.
> 
> So?  It would still benefit from using a generic framework that other 
> buses can use as well.

Perhaps, perhaps not.  Many details of the If and How of asynchronous,
parallelized probing rest with the low-level drivers.

[BTW, which ever team attempts to design this generic framework please
brings in detailed knowledge of a variety of bus architectures.  I for
one would like to contribute with what I know about IEEE 1394, but
before that I still have to experiment on my own before I have a good
understanding of how to parallelize IEEE 1394 scanning and probing, and
the IEEE 1394 core is being radically reworked at the moment anyway.]

> Not to mention that the current scsi specific 
> framework tends to cause unstable names doesn't it?

No.  Reality causes "unstable" names.  Or more precisely, we ultimately
can't get persistent names from dumb enumerations according to probing
order.  We get persistent names by reading persistent device properties
in userspace and by letting userspace rename or give aliases to devices.

Names based on probing order are fine for really simplistic setups like
the famous Aunt Tilly's home computer --- but not for the general case
that you are trying to cover.

(Sorry for repeating what has been said before in this thread.)
-- 
Stefan Richter
-=-=-=== -=-= -=-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

[Jan Engelhardt]

On May 9 2007 18:51, Linus Torvalds wrote:
>
>(But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is probably 
>some strange mixup of Andrew Morton and Andi Kleen in your mind ;)

What do the letters kp stand for?


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] Re: mm snapshot broken-out-2007-05-10-03-06.tar.gz uploaded

[Jeremy Fitzhardinge]

Michal Piotrowski wrote:
> Hi Jeremy,
>
> [EMAIL PROTECTED] napisał(a):
>   
>> The mm snapshot broken-out-2007-05-10-03-06.tar.gz has been uploaded to
>>
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-05-10-03-06.tar.gz
>>
>> 
>
> Bug reported here http://lkml.org/lkml/2007/4/25/400 is back.
>   

Yes, we never worked out what was going wrong.  It seems to be a strange
interaction between lock API testing and Andi's sched_clock() changes,
which is triggered by my softlockup changes.  But given that lock API
testing has no explicit interaction with either sched_clock() or the
softlockup watchdog, its completely mysterious that it should be
affected in this way.

We ended up with an appeal to Ingo, but he's ignored it so far.

J

> [0.00] 
> [0.00] | Locking API testsuite:
> [0.00] 
> 
> [0.00]  | spin |wlock |rlock |mutex | 
> wsem | rsem |
> [0.00]   
> --
> [0.00]  A-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.00]  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.01]  A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.01]  A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.02]  A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.03]  A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.04]  A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.06] double unlock:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.06]   initialize held:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.06]  bad unlock order:  ok  |  ok  |  ok  |  ok  | 
>  ok  |  ok  |
> [0.07]   
> --
> [0.07]   recursive read-lock: |  ok  |
>  |  ok  |
> [0.07]recursive read-lock #2: |  ok  |
>  |  ok  |
> [0.07] mixed read-write-lock: |  ok  |
>  |  ok  |
> [0.07] mixed write-read-lock: |  ok  |
>  |  ok  |
> [0.07]   
> --
> [0.07]  hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
> [0.07]  soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
> [0.07]  hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
> [0.07]  soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
> [0.07]sirq-safe-A => hirqs-on/12:  ok  |  ok  |irq event 
> stamp: 472
> [0.08] hardirqs last  enabled at (472): [] 
> irqsafe2A_rlock_12+0xb6/0xc7
> [0.08] hardirqs last disabled at (471): [] 
> native_sched_clock+0x70/0x118
> [0.08] softirqs last  enabled at (468): [] 
> irqsafe2A_rlock_12+0xa1/0xc7
> [0.08] softirqs last disabled at (464): [] 
> irqsafe2A_rlock_12+0xc/0xc7
> [0.08] FAILED| [] dump_trace+0x63/0x1eb
> [0.08]  [] show_trace_log_lvl+0x1a/0x30
> [0.08]  [] show_trace+0x12/0x14
> [0.08]  [] dump_stack+0x16/0x18
> [0.08]  [] dotest+0x8d/0x3f4
> [0.08]  [] locking_selftest+0x915/0x1a58
> [0.08]  [] start_kernel+0x27d/0x34f
> [0.08]  ===
> [0.08]
> [0.08]sirq-safe-A => hirqs-on/21:irq event stamp: 476
> [0.08] hardirqs last  enabled at (476): [] 
> irqsafe2A_spin_21+0x1c/0xc7
> [0.08] hardirqs last disabled at (475): [] 
> native_sched_clock+0x70/0x118
> [0.08] softirqs last  enabled at (468): [] 
> irqsafe2A_rlock_12+0xa1/0xc7
> [0.08] softirqs last disabled at (464): [] 
> irqsafe2A_rlock_12+0xc/0xc7
> [0.08]   ok  |irq event stamp: 480
> [0.08] hardirqs last  enabled at (480): [] 
> irqsafe2A_wlock_21+0x1c/0xc7
> [0.08] hardirqs last disabled at (479): [] 
> native_sched_clock+0x70/0x118
> [0.08] softirqs last  enabled at (468): [] 
> irqsafe2A_rlock_12+0xa1/0xc7
> [0.08] softirqs last disabled at (464): [] 
> irqsafe2A_rlock_12+0xc/0xc7
> [0.08]   ok  |irq event stamp: 484
> [0.08] hardirqs last  enabled at (484): [] 
> irqsafe2A_rlock_21+0x1c/0xc7
> [0.08] hardirqs last disabled at (483): [] 
> native_sched_clock+0x70/0x118
> [0.08] softirqs last  enabled at (468): [] 
> irqsafe2A_rlock_12+0xa1/0xc7
> [0.08] softirqs last disabled at (464): [] 
> irqsafe2A_rlock_12+0xc/0xc7
> [0.000

Re: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

[Xavier Bestel]

On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote:
> >(But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is
> probably 
> >some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
> 
> What do the letters kp stand for?

"Keep Patching" ?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Kconfig: SCSI_ESP_CORE depends on HAS_DMA

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 drivers/scsi/Kconfig |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -urpN linux-2.6/drivers/scsi/Kconfig linux-2.6-patched/drivers/scsi/Kconfig
--- linux-2.6/drivers/scsi/Kconfig  2007-05-10 15:17:27.0 +0200
+++ linux-2.6-patched/drivers/scsi/Kconfig  2007-05-10 15:18:12.0 
+0200
@@ -1755,7 +1755,7 @@ config SUN3X_ESP
 
 config SCSI_ESP_CORE
tristate "ESP Scsi Driver Core"
-   depends on SCSI
+   depends on SCSI && HAS_DMA
select SCSI_SPI_ATTRS
 
 config SCSI_SUNESP


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Long file names in VFAT broken with iocharset=utf8

[Jan Engelhardt]

On May 10 2007 16:49, Bodo Eggert wrote:
>
>Just because you limit yourself to 80 chars minus "ls -l"-clutter, this is
>no reason why I shouldn't use long filenames. If I need to handle these
>filenames, I can enlarge the terminal window or read the next line.
>
>E.g.: I have a music file named "artist - title.ext", where the artist
>name is 103 characters long, using abbreviations. In order to enter that
>name, I have to press seven keys, including the escape character.
>There is nothing unreasonable in using that name.

What name would that be? I cannot dream up any IME that outputs _that_
many characters for that few keystrokes. Even with CJ(K), 7 keystrokes can
make at most 21 bytes if I had to take a good guess.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver-core: don't free devt_attr till the device is released

[Greg KH]

On Thu, May 10, 2007 at 04:45:17PM +0200, Tejun Heo wrote:
> Currently, devt_attr for the "dev" file is freed immediately on device
> removal, but if the "dev" sysfs file is open when a device is removed,
> sysfs will access its attribute structure for further access including
> close resulting in jumping to garbled address.  Fix it by postponing
> freeing devt_attr to device release time.
> 
> Note that devt_attr for class_device is already freed on release.
> 
> This bug is reported by Chris Rankin as bugzilla bug#8198.
> 
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> Cc: Chris Rankin <[EMAIL PROTECTED]>
> ---
> Applies well to 2.6.20 and 21.  As sysfs-immediate-disconnect doesn't
> seem to be included in 2.6.22, this should be included in linus#master
> too (applies well there as well).

As I don't think we should be adding your sysfs rework to 2.6.22 just
yet, any objections to me just sending this to Linus for 2.6.22 and
waiting on your previous one for when the whole sysfs rework patchset is
sent?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] driver-core: don't free devt_attr till the device is released

[Tejun Heo]

Greg KH wrote:
>> Applies well to 2.6.20 and 21.  As sysfs-immediate-disconnect doesn't
>> seem to be included in 2.6.22, this should be included in linus#master
>> too (applies well there as well).
> 
> As I don't think we should be adding your sysfs rework to 2.6.22 just
> yet, any objections to me just sending this to Linus for 2.6.22 and
> waiting on your previous one for when the whole sysfs rework patchset is
> sent?

No objection at all.  That actually is exactly my intention.  The
make-attrs-static patch will conflict with this fix tho.  Just let me
know when it breaks, I'll post updated one.

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/

[PATCH] Couple fixes to fs/ecryptfs/inode.c

[Mika Kukkonen]

Following was uncovered by compiling the kernel with '-W' flag:

  CC [M]  fs/ecryptfs/inode.o
fs/ecryptfs/inode.c: In function ‘ecryptfs_lookup’:
fs/ecryptfs/inode.c:304: warning: comparison of unsigned expression < 0 is 
always false
fs/ecryptfs/inode.c: In function ‘ecryptfs_symlink’:
fs/ecryptfs/inode.c:486: warning: comparison of unsigned expression < 0 is 
always false

Function ecryptfs_encode_filename() can return -ENOMEM, so change the
variables to plain int, as in the first case the only real use actually
expects int, and in latter case there is no use beoynd the error check.

Signed-off-by: Mika Kukkonen <[EMAIL PROTECTED]>

diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 1548be2..d230a48 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -282,7 +282,7 @@ static struct dentry *ecryptfs_lookup(struct inode *dir, 
struct dentry *dentry,
struct dentry *lower_dentry;
struct vfsmount *lower_mnt;
char *encoded_name;
-   unsigned int encoded_namelen;
+   int encoded_namelen;
struct ecryptfs_crypt_stat *crypt_stat = NULL;
struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
char *page_virt = NULL;
@@ -473,7 +473,7 @@ static int ecryptfs_symlink(struct inode *dir, struct 
dentry *dentry,
struct dentry *lower_dir_dentry;
umode_t mode;
char *encoded_symname;
-   unsigned int encoded_symlen;
+   int encoded_symlen;
struct ecryptfs_crypt_stat *crypt_stat = NULL;
 
lower_dentry = ecryptfs_dentry_to_lower(dentry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/7] libata: check for AN support

[Randy Dunlap]

On Wed, 9 May 2007 22:09:52 -0700 Andrew Morton wrote:

> On Wed, 9 May 2007 16:38:09 -0700 Kristen Carlson Accardi <[EMAIL PROTECTED]> 
> wrote:
> 
> >  /**
> > + * ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES
> > + *   with sector count set to indicate
> > + *   Asynchronous Notification feature
> 
> I think kenreldoc requires that all this be on a single line?

Correct.

> > + * @dev: Device to which command will be sent
> > + *
> > + * Issue SET FEATURES - SATA FEATURES command to device @dev
> > + * on port @ap.
> > + *
> > + * LOCKING:
> > + * PCI/etc. bus probe sem.
> > + *
> > + * RETURNS:
> > + * 0 on success, AC_ERR_* mask otherwise.
> > + */
> 
> ooh, locking and return value documentation.  Often missed, and nice.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Current git fails to compile on AMD64 for three days in a row

[Florin Iucha]

I just pulled the current git (de5603748af8bf7deac403e6ba92887f8d18e812)
and tried to compile it on my AMD64 box, to test Chuck's RPC fix.  It
fails:

   arch/x86_64/kernel/head64.c: In function ‘x86_64_start_kernel’:
   arch/x86_64/kernel/head64.c:70: error: size of array ‘type name’ is negative

It is failing in the same way since Monday.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

Re: [patch 1/4] KMON - kmon device/instrumentation ...

[Davide Libenzi]

On Thu, 10 May 2007, Andi Kleen wrote:

> Davide Libenzi <[EMAIL PROTECTED]> writes:
> 
> > This patch serie introduces a way to log high frequency/volume data
> > out of the kernel. Logging scheduler operations for example, with
> > loads that generate tenths of thousands of context switches per second
> > (possibly from multiple CPUs), can overload the kernel printk. Also,
> > logging in binary form helps in reducing the size of the logged data
> > that is tranfered from kernel to userspace. The kmon logger uses per
> > CPU buffers (rings) that are flushed at a given frequency to all the
> > instances of the kmon devices.
> 
> Sounds like you reinvented relayfs? (and ktrace before that)

I simply didn't know about relayfs ;) Randy told me when I posted 
those, that BTW were never intended for merging. The buffering method used 
is more similar to oprofile though.


- Davide


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] AFS: Fix interminable loop in afs_write_back_from_locked_page()

[David Howells]

Following bug was uncovered by compiling with '-W' flag:

  CC [M]  fs/afs/write.o
fs/afs/write.c: In function ‘afs_write_back_from_locked_page’:
fs/afs/write.c:398: warning: comparison of unsigned expression >= 0 is always 
true

Loop variable 'n' is unsigned, so wraps around happily as far as I can
see. Trival fix attached (compile tested only).

Signed-Off-By: Mika Kukkonen <[EMAIL PROTECTED]>
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---

 fs/afs/write.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/afs/write.c b/fs/afs/write.c
index 67ae4db..28f3751 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -395,8 +395,9 @@ static int afs_write_back_from_locked_page(struct 
afs_writeback *wb,
if (n == 0)
goto no_more;
if (pages[0]->index != start) {
-   for (n--; n >= 0; n--)
-   put_page(pages[n]);
+   do {
+   put_page(pages[--n]);
+   } while (n > 0);
goto no_more;
}
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Fix bug in mm/thrash.c function grab_swap_token()

[Satyam Sharma]

On 5/10/07, Mika Kukkonen <[EMAIL PROTECTED]> wrote:

Following bug was uncovered by compiling with '-W' flag:

  CC  mm/thrash.o
mm/thrash.c: In function 'grab_swap_token':
mm/thrash.c:52: warning: comparison of unsigned expression < 0 is always false

Field token_priority is unsigned, so decrementing first and the checking
is not a good plan. Attached patch (compile tested) reverses the order.


Heh, yeah. Actually, decrementing first and then checking < 0 to clamp
to zero is _never_ a good plan. If the original author thought he was
optimizing speed that way, he was clearly mistaken.


Btw, I'm not sure if likely() makes any sense in this new situation.


Right, if(likely(...)) without an else wouldn't make much sense ...


Signed-off-by: Mika Kukkonen <[EMAIL PROTECTED]>

diff --git a/mm/thrash.c b/mm/thrash.c
index 9ef9071..c4c5205 100644
--- a/mm/thrash.c
+++ b/mm/thrash.c
@@ -48,9 +48,8 @@ void grab_swap_token(void)
if (current_interval < current->mm->last_interval)
current->mm->token_priority++;
else {
-   current->mm->token_priority--;
-   if (unlikely(current->mm->token_priority < 0))
-   current->mm->token_priority = 0;
+   if (likely(current->mm->token_priority > 0))
+   current->mm->token_priority--;
}
/* Check if we deserve the token */
if (current->mm->token_priority >


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] AFS: Fix a couple of problems with unlinking AFS files

[David Howells]

Fix a couple of problems with unlinking AFS files.

 (1) The parent directory wasn't being updated properly between unlink() and
 the following lookup().

 It seems that, for some reason, invalidate_remote_inode() wasn't
 discarding the directory contents correctly, so this patch calls
 invalidate_inode_pages2() instead on non-regular files.

 (2) afs_vnode_deleted_remotely() should handle vnodes that don't have a
 source server recorded without oopsing.

Signed-off-by: David Howells <[EMAIL PROTECTED]>
---

 fs/afs/file.c  |2 +-
 fs/afs/inode.c |   10 +++---
 fs/afs/super.c |3 ++-
 fs/afs/vnode.c |   33 +
 4 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 3e25795..9c0e721 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -236,7 +236,7 @@ static void afs_invalidatepage(struct page *page, unsigned 
long offset)
 {
int ret = 1;
 
-   kenter("{%lu},%lu", page->index, offset);
+   _enter("{%lu},%lu", page->index, offset);
 
BUG_ON(!PageLocked(page));
 
diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 515a5d1..47f5fed 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -209,11 +209,15 @@ bad_inode:
  */
 void afs_zap_data(struct afs_vnode *vnode)
 {
-   _enter("zap data {%x:%u}", vnode->fid.vid, vnode->fid.vnode);
+   _enter("{%x:%u}", vnode->fid.vid, vnode->fid.vnode);
 
/* nuke all the non-dirty pages that aren't locked, mapped or being
-* written back */
-   invalidate_remote_inode(&vnode->vfs_inode);
+* written back in a regular file and completely discard the pages in a
+* directory or symlink */
+   if (S_ISREG(vnode->vfs_inode.i_mode))
+   invalidate_remote_inode(&vnode->vfs_inode);
+   else
+   invalidate_inode_pages2(vnode->vfs_inode.i_mapping);
 }
 
 /*
diff --git a/fs/afs/super.c b/fs/afs/super.c
index d24be33..422f532 100644
--- a/fs/afs/super.c
+++ b/fs/afs/super.c
@@ -488,6 +488,7 @@ static struct inode *afs_alloc_inode(struct super_block *sb)
vnode->flags= 1 << AFS_VNODE_UNSET;
vnode->cb_promised  = false;
 
+   _leave(" = %p", &vnode->vfs_inode);
return &vnode->vfs_inode;
 }
 
@@ -498,7 +499,7 @@ static void afs_destroy_inode(struct inode *inode)
 {
struct afs_vnode *vnode = AFS_FS_I(inode);
 
-   _enter("{%lu}", inode->i_ino);
+   _enter("%p{%x:%u}", inode, vnode->fid.vid, vnode->fid.vnode);
 
_debug("DESTROY INODE %p", inode);
 
diff --git a/fs/afs/vnode.c b/fs/afs/vnode.c
index ec81466..bea8bd9 100644
--- a/fs/afs/vnode.c
+++ b/fs/afs/vnode.c
@@ -175,24 +175,33 @@ static void afs_vnode_deleted_remotely(struct afs_vnode 
*vnode)
 {
struct afs_server *server;
 
+   _enter("{%p}", vnode->server);
+
set_bit(AFS_VNODE_DELETED, &vnode->flags);
 
server = vnode->server;
-   if (vnode->cb_promised) {
-   spin_lock(&server->cb_lock);
+   if (server) {
if (vnode->cb_promised) {
-   rb_erase(&vnode->cb_promise, &server->cb_promises);
-   vnode->cb_promised = false;
+   spin_lock(&server->cb_lock);
+   if (vnode->cb_promised) {
+   rb_erase(&vnode->cb_promise,
+&server->cb_promises);
+   vnode->cb_promised = false;
+   }
+   spin_unlock(&server->cb_lock);
}
-   spin_unlock(&server->cb_lock);
-   }
 
-   spin_lock(&vnode->server->fs_lock);
-   rb_erase(&vnode->server_rb, &vnode->server->fs_vnodes);
-   spin_unlock(&vnode->server->fs_lock);
+   spin_lock(&server->fs_lock);
+   rb_erase(&vnode->server_rb, &server->fs_vnodes);
+   spin_unlock(&server->fs_lock);
 
-   vnode->server = NULL;
-   afs_put_server(server);
+   vnode->server = NULL;
+   afs_put_server(server);
+   } else {
+   ASSERT(!vnode->cb_promised);
+   }
+
+   _leave("");
 }
 
 /*
@@ -225,7 +234,7 @@ void afs_vnode_finalise_status_update(struct afs_vnode 
*vnode,
  */
 static void afs_vnode_status_update_failed(struct afs_vnode *vnode, int ret)
 {
-   _enter("%p,%d", vnode, ret);
+   _enter("{%x:%u},%d", vnode->fid.vid, vnode->fid.vnode, ret);
 
spin_lock(&vnode->lock);
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] NLM program ID for user space NLM server

[Menny Hamburger]

The idea in the change was to be able to override NLM_PROGRAM with
another definition (from our slightly customized build system), so that
the kernel never tries to register port 100021.

We understand that if all mounts are with 'nolock' this wouldn't happen,
and indeed, we configured our mounts that way, but we want to protect
ourself from some innocent mounter that doesn't know/care about NLM,
doesn't use 'nolock' and could cause the kernel to take away our port.
This of course happened in real life.

If such patch would be accepted, it could save some time to anyone who
tries to run user mode NLM server, but it's pretty esoteric, so maybe
this discussion is enough to document the issue. 

-Original Message-
From: Trond Myklebust [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 10, 2007 3:39 PM
To: Menny Hamburger
Cc: Neil Brown; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] NLM program ID for user space NLM server

On Thu, 2007-05-10 at 13:59 +0300, Menny Hamburger wrote:
> Hi,
> 
> We have a our own userland NFSD and NLM service running that implement

> all the NLM/NFS functionality.
> We do not want to modify the way the client does his mounts.
> 
> M.

The client needs to have lockd running (as service 100021) in order to
allow the NSM daemon to notify it of server reboots.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] memory hotremove patch take 2 [02/10] (make page unused)

[Mel Gorman]

On Wed, 9 May 2007, Yasunori Goto wrote:


This patch is for supporting making page unused.



Without reading the patch, this could also be interesting when trying to 
free a block of pages for a contiguous allocation without racing against 
other allocators.



Isolate pages by capturing freed pages before inserting free_area[],
buddy allocator.
If you have an idea for avoiding spin_lock(), please advise me.



Again, commenting on this before I read the patch. Grouping pages by 
mobility uses a bitmap to track flags affecting a block of pages. If you 
used a bit there and added a MIGRATE_ISOLATING type, the pages on free 
would get placed in those freelists. As long as MIGRATE_ISOLATING is not 
in fallbacks[] in page_alloc.c, the pages would not get allocated. This 
should avoid the need for a separate spinlock.


That said, it increases the size of struct zone more than yours do and 
ties these patches to a part of grouping pages by mobility which you don't 
do currently.



Isolating pages in free_area[] is implemented in other patch.



I haven't seen that part yet but it sounds like it does something similar 
to move_freepages() so there may be code to be shared there.



Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>


include/linux/mmzone.h |8 +
include/linux/page_isolation.h |   52 +++
mm/Kconfig |7 +
mm/page_alloc.c|  187 +
4 files changed, 254 insertions(+)

Index: current_test/include/linux/mmzone.h
===
--- current_test.orig/include/linux/mmzone.h2007-05-08 15:06:49.0 
+0900
+++ current_test/include/linux/mmzone.h 2007-05-08 15:08:03.0 +0900
@@ -314,6 +314,14 @@ struct zone {
/* zone_start_pfn == zone_start_paddr >> PAGE_SHIFT */
unsigned long   zone_start_pfn;

+#ifdef CONFIG_PAGE_ISOLATION
+   /*
+*  For pages which are not used but not free.
+*  See include/linux/page_isolation.h
+*/
+   spinlock_t  isolation_lock;
+   struct list_headisolation_list;
+#endif


Using MIGRATE_ISOLATING instead of this approach does mean that there will 
be MAX_ORDER additional struct free_area added to the zone. That is more 
lists than this approach.


I am somewhat suprised that CONFIG_PAGE_ISOLATION exists as a separate 
option. If it was a compile-time option at all, I would expect it to 
depend on memory hot-remove being selected.



/*
 * zone_start_pfn, spanned_pages and present_pages are all
 * protected by span_seqlock.  It is a seqlock because it has
Index: current_test/mm/page_alloc.c
===
--- current_test.orig/mm/page_alloc.c   2007-05-08 15:07:20.0 +0900
+++ current_test/mm/page_alloc.c2007-05-08 15:08:34.0 +0900
@@ -41,6 +41,7 @@
#include 
#include 
#include 
+#include 

#include 
#include 
@@ -448,6 +449,9 @@ static inline void __free_one_page(struc
if (unlikely(PageCompound(page)))
destroy_compound_page(page, order);

+   if (page_under_isolation(zone, page, order))
+   return;
+


Using MIGRATE_ISOLATING would avoid a potential list search here.


page_idx = page_to_pfn(page) & ((1 << MAX_ORDER) - 1);

VM_BUG_ON(page_idx & (order_size - 1));
@@ -3259,6 +3263,10 @@ static void __meminit free_area_init_cor
zone->nr_scan_inactive = 0;
zap_zone_vm_stats(zone);
atomic_set(&zone->reclaim_in_progress, 0);
+#ifdef CONFIG_PAGE_ISOLATION
+   spin_lock_init(&zone->isolation_lock);
+   INIT_LIST_HEAD(&zone->isolation_list);

i> +#endif

if (!size)
continue;

@@ -4214,3 +4222,182 @@ void set_pageblock_flags_group(struct pa
else
__clear_bit(bitidx + start_bitidx, bitmap);
}
+
+#ifdef CONFIG_PAGE_ISOLATION
+/*
+ * Page Isolation.
+ *
+ * If a page is removed from usual free_list and will never be used,
+ * It is linked to "struct isolation_info" and set Reserved, Private
+ * bit. page->mapping points to isolation_info in it.
+ * and page_count(page) is 0.
+ *
+ * This can be used for creating a chunk of contiguous *unused* memory.
+ *
+ * current user is Memory-Hot-Remove.
+ * maybe move to some other file is better.


page_isolation.c to match the header filename seems reasonable. 
page_alloc.c has a lot of multi-function stuff like memory initialisation 
in it.



+ */
+static void
+isolate_page_nolock(struct isolation_info *info, struct page *page, int order)
+{
+   int pagenum;
+   pagenum = 1 << order;
+   while (pagenum > 0) {
+   SetPageReserved(page);
+   SetPagePrivate(page);
+   page->private = (unsigned long)info;
+   

Re: [PATCH] driver-core: don't free devt_attr till the device is released

[Kay Sievers]

On 5/10/07, Tejun Heo <[EMAIL PROTECTED]> wrote:

Currently, devt_attr for the "dev" file is freed immediately on device
removal, but if the "dev" sysfs file is open when a device is removed,
sysfs will access its attribute structure for further access including
close resulting in jumping to garbled address.  Fix it by postponing
freeing devt_attr to device release time.

Note that devt_attr for class_device is already freed on release.


Hi Tejun,
your rework removes the "owner" field from the attributes. I think we
kept the "dev" and "uevent" attribute as part of "struct device" only
to be able to assign it the actual owner of the module that has
created the device. The attribute can probably just live as one
instance statically in the driver core now?

Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/