Re: [PATCH -mm] Fix lseek on /proc/kcore

[Alexey Dobriyan]

On Thu, Mar 22, 2007 at 02:14:35PM +0100, Arjan van de Ven wrote:
> On Thu, 2007-03-22 at 12:56 +0300, Alexey Dobriyan wrote:
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -167,8 +167,9 @@ static loff_t proc_reg_llseek(struct fil
> > llseek = pde->proc_fops->llseek;
> > spin_unlock(&pde->pde_unload_lock);
> >
> > -   if (llseek)
> > -   rv = llseek(file, offset, whence);
> > +   if (!llseek)
> > +   llseek = default_llseek;
> > +   rv = llseek(file, offset, whence);
> >
>
> this has potential impact way outside kcore..
>
> did you audit all proc users to see if they can deal with lseek?

Mainline deals with lseek on proc entries as follows:
* use default_llseek()
* but if proc entry set ->llseek via ->proc_fops, use custom llseek

With introduction of proxying, ->llseek was suddenly set on all proc
entries, so default_llseek() was never used, but -E started to be
returned for all of them that were relying on default_llseek().

So this patch brings proc_reg_llseek() in sync with vfs_llseek().

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/2] revoke: break cow for private mappings

[Nick Piggin]

Pekka J Enberg wrote:

From: Pekka Enberg <[EMAIL PROTECTED]>

We need to break COW for private mappings to make sure a process cannot
read new data after an inode has been revoked.


Seems OK.



Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/revoke.c |   85 +++-
 1 file changed, 73 insertions(+), 12 deletions(-)

Index: uml-2.6/fs/revoke.c
===
--- uml-2.6.orig/fs/revoke.c2007-03-26 18:10:24.0 +0300
+++ uml-2.6/fs/revoke.c 2007-03-26 18:27:25.0 +0300
@@ -174,12 +174,58 @@ static inline bool need_revoke(struct vm
if (file->f_path.dentry->d_inode != inode)
return false;
 
-	if (!(vma->vm_flags & VM_SHARED))

-   return false;
-
return file != to_exclude;
 }
 
+static int __revoke_break_cow(struct task_struct *tsk, struct inode *inode,

+ struct file *to_exclude)
+{
+   struct mm_struct *mm = tsk->mm;
+   struct vm_area_struct *vma;
+   int err = 0;
+
+   down_write(&mm->mmap_sem);
+   for (vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
+   int ret;
+
+   if (vma->vm_flags & VM_SHARED)
+   continue;
+
+   if (!need_revoke(vma, inode, to_exclude))
+   continue;
+
+   ret = get_user_pages(tsk, tsk->mm, vma->vm_start,
+vma->vm_end-vma->vm_start, 1, 1, NULL,
+NULL);


get_user_pages length argument is in # of pages, rather than address range,
I think. vma_pages is what you want?


+   if (ret < 0) {
+   err = ret;
+   break;
+   }
+   }
+   up_write(&mm->mmap_sem);


I think you just need down_read of mmap_sem here?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

Re: 2.6.21-rc4-mm1

[Cornelia Huck]

On Wed, 28 Mar 2007 03:26:35 +0200,
Eric Rannaud <[EMAIL PROTECTED]> wrote:

> The reason for that original patch was that it is actually possible for the
> uevent functions to return -ENOMEM, the uevent buffer being statically
> allocated to BUFFER_SIZE (2048).

So maybe -ENOMEM should still be propagated? We just don't want to fail
device_add because of it.

> It used to be 1024 but that was not
> always enough and it was doubled a while ago [1]. Using add_uevent_var()
> makes this less of a problem as such an overflow should be catched
> cleanly [2].

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

Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Cornelia Huck]

On Tue, 27 Mar 2007 15:50:06 -0700,
Greg KH <[EMAIL PROTECTED]> wrote:

> > Greg, what about driver-core-per-subsystem-multithreaded-probing.patch?
> > PCI_MULTITHREAD_PROBE shoudn't be broken with that, only in mainline?
> 
> Do you want to enable PCI multithreaded probing using your patch?  I
> don't think the world is ready for pci multithreaded probing as was
> determined by the zillion of bug reports from people who like to enable
> config options that state in big letters, "THIS WILL BREAK YOUR BOX"...

But IIRC, that was without my patch? Wouldn't per-subsystem
multithreaded probing just expose bugs that could also be exposed on
SMP systems?

> And I'm still questioning if we should add your patch at all, as I don't
> think any other subsystems need it.  Do you?

The css/ccw busses may profit from it, since we tend to have thousands
of devices there. OTOH, we've already tried to make probing as
asynchronous as possible, so maybe there isn't that much gain. I'd need
to do some measurements (when I find some time...)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux page cache issue?

[Matthias Kaehlcke]

according to the chapter "Linux Kernel Overview" of the
kernelhacking-HOWTO the page cache holds pages associated with *open*
files:

The Page Cache

The page cache is made up of pages, each of which refers to a 4kB
portion of data associated with an open file. The data contained in a
page may come from several disk blocks, which may or may not be
physically neighbours on the disk. The page cache is largely used to
interface the requirements of the memory management subsystem (which
uses fixed, 4kB pages) to the VFS subsystem (which uses different size
blocks for different devices).

The page cache has two important data structures, a page hash table
and an inode queue. The page hash table is used to quickly find the
page descriptor of the page holding data associated with an inode and
offset within a file. The inode queue contains lists of page
descriptors relating to open files.

http://www.kernelhacking.org/docs/kernelhacking-HOWTO/indexs03.html

m.

El Wed, Mar 28, 2007 at 02:45:23AM -0400 Xin Zhao ha dit:

> Hi,
> 
> If a Linux process opens and reads a file A, then it closes the file.
> Will Linux keep the file A's data in cache for a while in case another
> process opens and reads the same in a short time? I think that is what
> I heard before.
> 
> But after I digged into the kernel code, I am confused.
> 
> When a process closes the file A, iput() will be called, which in turn
> calls the follows two functions:
> iput_final()->generic_drop_inode()
> 
> But from the following calling chain, we can see that file close will
> eventually lead to evict and free all cached pages. Actually in
> truncate_complete_page(), the pages will be freed.  This seems to
> imply that Linux has to re-read the same data from disk even if
> another process B read the same file right after process A closes the
> file. That does not make sense to me.
> 
> /***calling chain ***/
> generic_delete_inode/generic_forget_inode()->
> truncate_inode_pages()->truncate_inode_pages_range()->
> truncate_complete_page()->remove_from_page_cache()->
> __remove_from_page_cache()->radix_tree_delete()
> 
> Am I missing something? Can someone please provide some advise?
> 
> Thanks a lot
> -x
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
   For to be free is not merely to cast off
   one's chains, but to live in a way that
  respects and enhances the freedom of others
   (Nelson Mandela)
 .''`.
using free software / Debian GNU/Linux | http://debian.org  : :'  :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4  `-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] scheduler: strange behavor with massive interactive processes

[Mike Galbraith]

Greetings!

On Tue, 2007-03-27 at 07:04 +0200, Mike Galbraith wrote:
> On Tue, 2007-03-27 at 10:34 +0900, Satoru Takeuchi wrote:

> > When I was executing massive interactive processes, I found that some of 
> > them
> > occupy CPU time and the others hardly run.
> > 
> > It seems that some of processes which occupy CPU time always has max 
> > effective
> > prio (default+5) and the others have max - 1. What happen here is...
> > 
> >  1. If there are moderate number of max interactive processes, they can be
> > re-inserted into active queue without falling down its priority again 
> > and
> > again.
> >  2. In this case, the others seldom run, and can't get max effective 
> > priority
> > at next exhausting because scheduler considers them to sleep too long.
> >  3. Goto 1, OOPS!
> 
> Ah, that's a new twist.  Cool testcase.  A mechanism which was put in
> specifically to prevent tasks from jumping straight to max interactive,
> and thus hurting truly interactive tasks, is starving these not truly
> interactive (but nothing says they couldn't be) tasks.

I puttered around with your testcase a bit, and didn't see interactive
tasks starving other interactive tasks so much as plain old interactive
tasks starving expired tasks, which they're supposed to be able to do,
but to a limited degree.  Merely forcing array switches fixes that here,
however array switches can be _very_ rough on interactivity, so I tried
a hybrid of the forced array switch and...

> One way to prevent this may be to do something very simple like (I did
> this here a while back) upon timeslice completion (or possibly better,
> round-robin interval [whenever]), promote a task from a lower priority
> queue.  Tasks are then always crawling up the ladder, and _will_ be
> inserted into the stream no matter what is going on in the system.

...the above, and it seems to work.  Below is a rough (second) cut,
which tries to preserve interactivity, but also ensure that
non-interactive tasks _will_ receive cpu in a reasonable amount of time.
It only engages when we're not expiring non-interactive tasks, ie should
have no effect until we're exclusively running interactive tasks, but
then it should also prevent the interactive/interactive starvation
scenario as well.  It doesn't attempt to enforce fairness, only prevent
terminal starvation.  With this patch^W(mess?;) I got the numbers below,
whereas without it, the distribution was pretty ugly.  I didn't try it
with many many attackers.  (many many false interactive tasks is doomed
unless you detect and switch behavior)

Interactivity still seems to be fine with reasonable non-interactive
loads despite ~reserving more bandwidth for non-interactive tasks.  Only
lightly tested, YMMV, and of course the standard guarantee applies ;)

-Mike

[EMAIL PROTECTED]: ./massive_intr 20 180
009417  3450
009419  2965
009423  3068
009406  2565
009403  2964
009421  2949
009422  2314
009420  2879
009418  2730
009415  3126
009405  2737
009408  3664
009424  3355
009414  2947
009416  4340
009407  3424
009412  3491
009404  3101
009413  2553
009425  3396

2.6.21-rc5

--- kernel/sched.c.org  2007-03-27 15:47:49.0 +0200
+++ kernel/sched.c  2007-03-28 08:53:17.0 +0200
@@ -234,7 +234,8 @@ struct rq {
 */
unsigned long nr_uninterruptible;
 
-   unsigned long expired_timestamp;
+   unsigned long switch_timestamp;
+   unsigned long last_expired;
/* Cached timestamp set by update_cpu_clock() */
unsigned long long most_recent_timestamp;
struct task_struct *curr, *idle;
@@ -3051,9 +3052,9 @@ static inline int expired_starving(struc
 {
if (rq->curr->static_prio > rq->best_expired_prio)
return 1;
-   if (!STARVATION_LIMIT || !rq->expired_timestamp)
+   if (!STARVATION_LIMIT)
return 0;
-   if (jiffies - rq->expired_timestamp > STARVATION_LIMIT * rq->nr_running)
+   if (jiffies - rq->switch_timestamp > STARVATION_LIMIT * rq->nr_running)
return 1;
return 0;
 }
@@ -3131,8 +3132,75 @@ void account_steal_time(struct task_stru
cpustat->steal = cputime64_add(cpustat->steal, tmp);
 }
 
+/*
+ * Promote and requeue the next lower priority task.  If no task
+ * is available in the active array, switch to the expired array.
+ * @rq: runqueue to search.
+ * @prio: priority at which to begin search.
+ */
+static inline int promote_next_lower(struct rq *rq, int prio)
+{
+   struct prio_array *array = rq->active;
+   unsigned long *bitmap;
+   struct task_struct *p = NULL; 
+   unsigned long long now = rq->most_recent_timestamp;
+   int idx = prio + 1, found_noninteractive = 0;
+
+repeat:
+   bitmap = array->bitmap;
+   idx = find_next_bit(bitmap, MAX_PRIO, idx);
+   if (idx < MAX_PRIO) {
+   struct list_head *queue = array->queue + idx;
+
+ 

Re: [patch 1/8] Processor degredation support.

[Pavel Machek]

On Wed 2007-03-28 08:54:43, Heiko Carstens wrote:
> > > +++ linux-2.6/drivers/s390/char/sclp_confmgm.c
> > 
> > Can we get less cyptic name?
> 
> Would you like to see sclp_configuration_management.c?

No, but maybe sclp_manager.c or sclp_config.c?


> > > +static void sclp_conf_receiver_fn(struct evbuf_header *evbuf)
> > > +{
> > > + struct conf_mgm_data *cdata;
> > > +
> > > + cdata = (struct conf_mgm_data *)(evbuf + 1);
> > > + if (cdata->ev_qualifier == EV_QUAL_CAP_CHANGE)
> > > + /* Will be parsed. Don't change. */
> > > + printk(KERN_WARNING "sclp: CPU capability changed.\n");
> > > +}
> > 
> > What's that? I do not think printk provides guaranteed delivery.
> 
> True. But which generic interface is currently used to notify user space
> of state changes? Maybe a uevent for the cpu device..

Maybe.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: disable local apic timer via command line or dmi quirk

[Thomas Gleixner]

Len,

On Tue, 2007-03-27 at 23:28 -0400, Len Brown wrote:
> Is this failure specific to NO_HZ, and that is why the "nolapic_timer" fix is 
> i386 only?
> I'm running 2.6.21-rc5 an nx6325 here in 64-bit mode and I don't see the 
> dramatic
> boot failure described earlier in this thread.

The difference between x86_64 and i386 is that on i386 we now switch off
the PIT and do the jiffies increment in the local apic timer interrupt.
This is necessary for NO_HZ and HIGH_RES_TIMERS. We just fall back to
the PIT in C3 (enforced to C2 now due to massive breakage).

You can see the same problem on x86_64 by adding "apicmaintimer" to the
kernel command line. This should make your box really slow.

> However, I have observed that when running on battery,
> the LOC falls behind the irq0 timer to the tune of about
> 2 interrupt/minute.  eg. when i booted my machine, LOC was
> behind irq0 by 50, and now about a 20 minutes later it is behind
> irq0 by 99.  However, the LOC for each processor remain at
> a constant offset with respect to each other.
> 
> I do not see these this drift when running on AC.
> Yes, the system exports just C1 in both cases.

Right, but it does bad magic when running on battery. The offsets you
observe are due to the LAPIC stops. The delta is rather small, because
you wake up via the PIT periodically, so the APICs start to run as well.
And they do it on both cores.

Someone should apply a huge clue stick to BIOS developers.

I have some experimental code to detect the LAPIC breakage during run
time, but this needs more thought and is definitely not 2.6.21 material.

> Other oddities is the IRQ name on irq0 is garbled:
> 
> [EMAIL PROTECTED]:~> uname -a; cat /proc/interrupts; sleep 100; cat 
> /proc/interrupts
> Linux nx6325 2.6.21-rc5 #37 SMP Tue Mar 27 22:26:00 EDT 2007 x86_64 x86_64 
> x86_64 GNU/Linux
>CPU0   CPU1
>   0: 723812  0-edge  timer

Hrmpf. Ingo ???

tglx


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

Re: controlling mmap()'d vs read/write() pages

[Balbir Singh]

Herbert Poetzl wrote:

To me, one of the keys of Linux's "global optimizations" is being able
to use any memory globally for its most effective purpose, globally
(please ignore highmem :).  Let's say I have a 1GB container on a
machine that is at least 100% committed.  I mmap() a 1GB file and touch
the entire thing (I never touch it again).  I then go open another 1GB
file and r/w to it until the end of time.  I'm at or below my RSS limit,
but that 1GB of RAM could surely be better used for the second file.
How do we do this if we only account for a user's RSS?  Does this fit
into Alan's unfair bucket? ;)


what's the difference to a normal Linux system here?
when low on memory, the system will reclaim pages, and
guess what pages will be reclaimed first ...



But would it not bias application writers towards using read()/write()
calls over mmap()? They know that their calls are likely to be faster
when the application is run in a container. Without page cache control
we'll end up creating an asymmetrical container, where certain usage is 
charged and some usage is not.


Also, please note that when a page is unmapped and moved to swap cache;
the swap cache uses the page cache. Without page cache control, we could
end up with too many pages moving over to the swap cache and still
occupying memory, while the original intension was to avoid this
scenario.

--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[Paolo Ornati]

On Wed, 28 Mar 2007 09:46:40 +0200
Oliver Joa <[EMAIL PROTECTED]> wrote:

> What can be wrong? There is nothing special, only board, cpu and 
> harddisk, no other hardware. The board is running with the newest 
> available bios. I bought a Intel-board, because normally Intel is 
> supported very well.

What Seagate is it?  (hdparm -I /dev/sda | head)

I have this one:

ATA device, with non-removable media
Model Number:   ST380817AS
Serial Number:  4MR08EK8
Firmware Revision:  3.42


and it gives problems with NCQ enabled.

Try turning NCQ off with:

echo 1 > /sys/block/sda/device/queue_depth

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

[PATCH] replace spin_lock_irqsave with spin_lock

[Hisashi Hifumi]

IRQ is already disabled through local_irq_disable().
So spin_lock_irqsave() can be replaced with spin_lock().

Thanks.

Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>

--- linux-2.6.21-rc5.org/arch/i386/kernel/reboot.c	2007-02-05 
03:44:54.0 +0900
+++ linux-2.6.21-rc5-test/arch/i386/kernel/reboot.c	2007-03-28 
17:57:56.0 +0900

@@ -197,8 +197,6 @@ static unsigned char jump_to_bios [] =
  */
 void machine_real_restart(unsigned char *code, int length)
 {
-   unsigned long flags;
-
local_irq_disable();

/* Write zero to CMOS register number 0x0f, which the BIOS POST
@@ -211,9 +209,9 @@ void machine_real_restart(unsigned char
   safe side.  (Yes, CMOS_WRITE does outb_p's. -  Paul G.)
 */

-   spin_lock_irqsave(&rtc_lock, flags);
+   spin_lock(&rtc_lock);
CMOS_WRITE(0x00, 0x8f);
-   spin_unlock_irqrestore(&rtc_lock, flags);
+   spin_unlock(&rtc_lock);

/* Remap the kernel at virtual address zero, as well as offset zero
   from the kernel segment.  This assumes the kernel segment starts at

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 resend v4] update ctime and mtime for mmaped write

[linux]

> But if you didn't notice until now, then the current implementation
> must be pretty reasonable for you use as well.

Oh, I definitely noticed.  As soon as I tried to port my application
to 2.6, it broke - as evidenced by my complaints last year.  The
current solution is simple - since it's running on dedicated boxes,
leave them on 2.4.

I've now got the hint on how to make it work on 2.6 (sync_file_range()),
so I can try again.  But the pressure to upgrade is not strong, so it
might be a while.

You may recall, this subthread started when I responding to "the
only reason to use msync(MS_ASYNC) is to update timestamps" with a
counterexample.  I still think the purpose of the call is a hint to the
kernel that writing to the specified page(s) is complete and now would be
a good time to clean them.  Which has very little to do with timestamps.

Now, my application, which leaves less than a second between the MS_ASYNC
and a subsequent MS_SYNC to check whether it's done, broke, but I can
imagine similar cases where MS_ASYNC would remain a useful hint to reduce
the sort of memory hogging generally associated with "dd if=/dev/zero"
type operations.

Reading between the lines of the standard, that seems (to me, at least)
to obviously be the intended purpose of msync(MS_ASYNC).  I wonder if
there's any historical documentation describing the original intent
behind creating the call.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 support for deferrable timers (respun)

[Andi Kleen]

Venki Pallipadi <[EMAIL PROTECTED]> writes:
> +++ new/kernel/timer.c2007-03-26 15:19:35.0 -0800
> @@ -74,7 +74,7 @@
>   tvec_t tv3;
>   tvec_t tv4;
>   tvec_t tv5;
> -} cacheline_aligned_in_smp;
> +} cacheline_aligned;

Why this change?  It should be aligned to 2 bytes anyways.

>  static DEFINE_PER_CPU(tvec_base_t *, tvec_bases) = &boot_tvec_bases;
>  
> +/*
> + * The lowest bit of base ptr in timer is used as a flag to indicate
> + * 'deferrable' nature of the timer. Functions below help us manage that 
> flag.
> + */
> +static inline unsigned int tbase_get_deferrable(struct tvec_t_base_s *base)
> +{
> + return ((unsigned int)base & TBASE_DEFERRABLE_FLAG);

This will warn on 64bit for cast ptr -> int


-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 2/2] revoke: break cow for private mappings

[Pekka Enberg]

On 3/28/07, Nick Piggin <[EMAIL PROTECTED]> wrote:

> + ret = get_user_pages(tsk, tsk->mm, vma->vm_start,
> +  vma->vm_end-vma->vm_start, 1, 1, NULL,
> +  NULL);

get_user_pages length argument is in # of pages, rather than address range,
I think. vma_pages is what you want?


Yes.

On 3/28/07, Nick Piggin <[EMAIL PROTECTED]> wrote:

> + up_write(&mm->mmap_sem);

I think you just need down_read of mmap_sem here?


Indeed. Thanks Nick.

 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/

Re: 2.6.20.3-rt8 - DMA suffers excessive delay periodically

[John]

Lee Revell wrote:


John wrote:


I'm runnning 2.6.20.3 patched with -rt8 (and glibc 2.3.6).
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8

I've written a program to highlight a phenomenon I don't understand.

This system includes a PCI board that provides data at ~38 Mbit/s.
I request data in lumps of 1316 bytes.
In other words, a new request should complete every 277 µs.

However, if I time stamp each packet as soon as I receive it, I notice
that almost exactly every 2 seconds, the packet is received 30-100
microseconds late.


Sounds like periodic SMM traps.  There's not much you can do about
them other than to avoid such hardware if you have tight RT
constraints.  The RTAI people have some code to disable SMM but it
does not work on all chipsets and may render some of your hardware
inoperable.


The motherboard is an EBC-2000T.
http://www.adlinktech.com/PD/web/PD_detail.php?pid=213

lspci -vvv output provided as an attachment.

VIA Pro133T chipset:
http://www.via.com.tw/en/products/chipsets/legacy/pro133/
http://www.via.com.tw/en/products/chipsets/legacy/pro133a/

dmesg mentions:
DMI 2.3 present.

Is this related to SMM?

As far as I can tell, the BIOS is Phoenix AwardBIOS v6.00PG.

Would someone know how to disable SMM in this BIOS?


Is this a laptop?  They are plagued with SMM problems...


No it is an "indutrial" motherboard.
Although I don't know what makes it "industrial".

Regards.
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] 
(rev c4)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x 
AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 
40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- Reset- FastB2B-
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+

02:0f.0 Multimedia controller: PLX Technology, Inc. Francois
Subsystem: PHILIPS Business Electronics B.V.: Unknown device d128
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 

Re: [PATCH] Add support for ITE887x serial chipsets

[Niels de Vos]

On Tue, 2007-03-27 at 14:30 -0400, [EMAIL PROTECTED] wrote:
> Minor point: the chip part numbers are actually IT887x, not ITE887x.

You are correct. Vendor is ITE, product IT887x (id=8872). What is the
advised naming convention for something like this?

> I STFW for a data sheet, but didn't have immediate luck.  Does anyone know 
> where to find
> documentation?

I can't even find the product on the official ITE site... The sheets I
have come from our BIOS development team. I've uploaded them on our FTP
server. The files will be deleted automatically in a few days.

- 
- 

-- 
Niels de Vos <[EMAIL PROTECTED]>
Wincor Nixdorf International GmbH

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

Re: HPA patches

[Alan Cox]

On Wed, 28 Mar 2007 01:08:52 +0100
Matthew Garrett <[EMAIL PROTECTED]> wrote:

> On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote:
> > For reference this is what I am currently using with 2.6.21-rc4-mm1 and
> > it is working for all my test cases so far: Its basically Kyle's patch
> > with a libata switch to turn it on/off and some minor fixups from
> > the original patch as posted
> 
> Fails for me on a Macbook Pro with:

Ok thanks. This is interesting as the only thing new it is doing is
asking for the HPA size. Does I think explain the problem however: Can
you move the HPA setting call to after the mode has been set and see if
that makes the problem vanish ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

[Pavel Machek]

Hi!

> >>So if you have reported a regression in the 2.6.21-rc 
> >>series, please check 2.6.21-rc5, and update your 
> >>report as appropriate (whether fixed or "still 
> >>problems with xyzzy").
> >
> >[just got back from vacation, or would have sent this 
> >earlier]
> >
> >FWIW, I'm still leaning towards disabling libata ACPI 
> >support by default for 2.6.21.
> >
> >Upstream has Alan's fix for the worst PATA problems, 
> >but for different reasons, I think PATA ACPI and SATA 
> >ACPI support in libata does not feel quite ready for 
> >prime time in 2.6.21.
> >
> >Scream now, or hold your peace until 2.6.22... :)
> 
> I second disabling ACPI for 2.6.21.

Ugh.. does that mean we'll have 'regression reports' as in 'it worked
ok in -rc5, broken in final?

Well, suspend is currently so broken that we'll be flooded by reports,
anyway, but could we get at least define in code so that we can
tell users to flip it?

Or maybe it is enough to make libata dependend on EXPERIMETAL?
...making it dependend on BROKEN should be definitely enough...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ATA ACPI (was Re: Linux 2.6.21-rc5)

[Tejun Heo]

Pavel Machek wrote:
> Hi!
> 
 So if you have reported a regression in the 2.6.21-rc 
 series, please check 2.6.21-rc5, and update your 
 report as appropriate (whether fixed or "still 
 problems with xyzzy").
>>> [just got back from vacation, or would have sent this 
>>> earlier]
>>>
>>> FWIW, I'm still leaning towards disabling libata ACPI 
>>> support by default for 2.6.21.
>>>
>>> Upstream has Alan's fix for the worst PATA problems, 
>>> but for different reasons, I think PATA ACPI and SATA 
>>> ACPI support in libata does not feel quite ready for 
>>> prime time in 2.6.21.
>>>
>>> Scream now, or hold your peace until 2.6.22... :)
>> I second disabling ACPI for 2.6.21.
> 
> Ugh.. does that mean we'll have 'regression reports' as in 'it worked
> ok in -rc5, broken in final?
> 
> Well, suspend is currently so broken that we'll be flooded by reports,
> anyway, but could we get at least define in code so that we can
> tell users to flip it?

Just the default value for libata.noacpi is changed to 1, so user can
easily reenable it by passing boot/module parameter.

-- 
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: [CHAR] Wire up DEC serial drivers in Kconfig

[Maciej W. Rozycki]

On Wed, 28 Mar 2007, Ralf Baechle wrote:

> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>

Acked-by: Maciej W. Rozycki <[EMAIL PROTECTED]>

 I'm not sure it's worth the hassle -- I'm in the middle of moving the 
driver to drivers/serial/, which I should finish soon after I reestablish 
my home network.  Otherwise I'm fine with it.  Has anybody actually 
requested it?

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

PCI: cannot adjust BAR (not I/O)

[Rene Herman]

Hi Greg.

On an older Intel 430VX system, 2.6.20.4 complains a bit:

===
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
:00:07.1: cannot adjust BAR0 (not I/O)
:00:07.1: cannot adjust BAR1 (not I/O)
:00:07.1: cannot adjust BAR2 (not I/O)
:00:07.1: cannot adjust BAR3 (not I/O)
Boot video device is :00:08.0
pnp: the driver 'system' has been registered
pnp: match found with the PnP device '00:07' and the driver 'system'
NET: Registered protocol family 2
===

00:07.1 is IDE (lspci -s 7.1 -vv attached, due to wrap). It's no doubt 
safe to ignore but looks a bit alarming...


Rene.

00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 
(prog-if 80 [Master])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 

[GIT PULL] sh fixes

[Paul Mundt]

Please pull from:

master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git

Which contains:

Kristoffer Ericson (1):
  sh: Trivial fix for hp6xx build.

Paul Mundt (2):
  sh: Kill bogus GCC4 symbol exports.
  sh: Fixup __cmpxchg() compile breakage with gcc4.

 arch/sh/kernel/sh_ksyms.c |3 ---
 include/asm-sh/hp6xx.h|6 +++---
 include/asm-sh/system.h   |1 +
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/sh/kernel/sh_ksyms.c b/arch/sh/kernel/sh_ksyms.c
index fe1b276..6e0d10f 100644
--- a/arch/sh/kernel/sh_ksyms.c
+++ b/arch/sh/kernel/sh_ksyms.c
@@ -82,9 +82,6 @@ DECLARE_EXPORT(__movstr);
 DECLARE_EXPORT(__movmem_i4_even);
 DECLARE_EXPORT(__movmem_i4_odd);
 DECLARE_EXPORT(__movmemSI12_i4);
-DECLARE_EXPORT(__sdivsi3_i4i);
-DECLARE_EXPORT(__udiv_qrnnd_16);
-DECLARE_EXPORT(__udivsi3_i4i);
 #else /* GCC 3.x */
 DECLARE_EXPORT(__movstr_i4_even);
 DECLARE_EXPORT(__movstr_i4_odd);
diff --git a/include/asm-sh/hp6xx.h b/include/asm-sh/hp6xx.h
index f35134c..53ca564 100644
--- a/include/asm-sh/hp6xx.h
+++ b/include/asm-sh/hp6xx.h
@@ -10,9 +10,9 @@
  *
  */
 
-#define HP680_BTN_IRQ  IRQ0_IRQ
-#define HP680_TS_IRQ   IRQ3_IRQ
-#define HP680_HD64461_IRQ  IRQ4_IRQ
+#define HP680_BTN_IRQ  32/* IRQ0_IRQ */
+#define HP680_TS_IRQ   35/* IRQ3_IRQ */
+#define HP680_HD64461_IRQ  36/* IRQ4_IRQ */
 
 #define DAC_LCD_BRIGHTNESS 0
 #define DAC_SPEAKER_VOLUME 1
diff --git a/include/asm-sh/system.h b/include/asm-sh/system.h
index b1e42e7..4a6a19f 100644
--- a/include/asm-sh/system.h
+++ b/include/asm-sh/system.h
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[Oliver Joa]

hi,

Paolo Ornati wrote:

[...]


What Seagate is it?  (hdparm -I /dev/sda | head)

I have this one:

ATA device, with non-removable media
Model Number:   ST380817AS
Serial Number:  4MR08EK8
Firmware Revision:  3.42


Model Number:   ST3160827AS
Serial Number:  3MT053DX
Firmware Revision:  3.42





and it gives problems with NCQ enabled.

Try turning NCQ off with:

echo 1 > /sys/block/sda/device/queue_depth


i did this already (in the first startup-script). It does not help.

Another Idea?

Thanks

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

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[Paolo Ornati]

On Wed, 28 Mar 2007 12:59:10 +0200
Oliver Joa <[EMAIL PROTECTED]> wrote:

> i did this already (in the first startup-script). It does not help.
> 
> Another Idea?

try replacing the SATA cable...

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

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[David Chinner]

On Tue, Mar 27, 2007 at 06:16:04PM +0200, Oliver Joa wrote:
> Hi,
> 
> since some weeks i try to get my new hardware running:
> 
> Intel(R) Core(TM)2 CPU  6300  @ 1.86GHz
> Intel DP965LT Mainboard
> Seagate SATA-Harddisk in AHCI-Mode
> 
> After some hours of running or after some heavy file-i/o
> (find / | cpio -padm /test) I always get a corrupted
> XFS-filesystem.

What is the corruption message in the log from XFS?
Can you please post that? Without it we really can't help you.

Also, please check to see if there are any I/O errors
in the log around the time the corruption message appears.

> I used already the following Kernels:
> 2.6.19.2
> 2.6.19.7
> 2.6.20.2
> 2.6.20.4
> 
> After xfs_repair I get damaged files in lost+found.
> 
> I read in newsgroups that the write-cache of the harddisk
> should be turned of, but the messages are all very old.

That's really only an issue for crashes, not runtime failures.

> I also often get a sata-bus-reset with the kernels 2.6.19.2
> and 2.6.20.2.

I/O errors. That's what we need to isolate first. The reports in
your logs are the first thing we need to s.

Cheers,

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

Re: [patch] sched: accurate user accounting

[Ingo Molnar]

* malc <[EMAIL PROTECTED]> wrote:

> This situation is harder to write a hog-like testcase for. Anyhow it 
> seems the difference in percentage stems from the `intr' field of 
> `/proc/stat', which fits. And following patch (which should be applied 
> on top of yours) seems to help. I wouldn't really know what to do with 
> softirq and the rest of counts touched by this function, so i left 
> them alone.
> 
> Comments?

i like it. FYI, i've applied your patch to -rt.

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

Re: [BUG] scheduler: strange behavor with massive interactive processes

[Ingo Molnar]

* Mike Galbraith <[EMAIL PROTECTED]> wrote:

> + struct task_struct *p = NULL; 

(small nit: extra space at the end of line.)

> + rq->best_expired_prio = MAX_PRIO;
> +#if 0
> + rq->switch_timestamp = jiffies;
> +#endif

remove this chunk? (i dont think we want to touch switch_timestamp here)

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

Re: [BUG] scheduler: strange behavor with massive interactive processes

[Mike Galbraith]

(oops, wrong button, went without CCs.  sorry for duplicate)

On Wed, 2007-03-28 at 13:45 +0200, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> 
> > +   struct task_struct *p = NULL; 
> 
> (small nit: extra space at the end of line.)
> 
> > +   rq->best_expired_prio = MAX_PRIO;
> > +#if 0
> > +   rq->switch_timestamp = jiffies;
> > +#endif
> 
> remove this chunk? (i dont think we want to touch switch_timestamp here)

I'll clean it up, and see if I can do better.

-Mike

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

miniroot ramdisk corruption during intense memory usage

[Peter Bier]

The following sympthom occured in a variant of the Knoppix-like linux appliance.

I get a corrupted miniroot ramdisk filesystem under kernel version 2.6.19.1 
under intense memory usage during early startup of the system. 

In the course of a lengthy investigation of this behavior, I found out that the 
memory pages containing the miniroot ramdisk are freed during the initial 
installation 

process due to a memory shortage. It turned out, that shrink_active_list() 
calls pagevec_strip(), which in turn calls try_to_release_page() which finally 
calls try_to_free_buffers() which drops the corresponding buffers; if this 
succeeds, it seems to cause the page to become freed later. 

This causes pointers of indirect blocks of the filesystem of the miniroot 
ramdisk to be replaced by zero-filled pages later in the the system's history.

I fixed this by adding a new flag PG_ramdisk in the include file page-flags.h, 
setting the flag during ramdisk loading in ramdisk_commit_write() and checking 
for the flag in try_to_free_buffers() and retruning 0 as result immediately 
without freeing the buffers. 

I am not aware if that is the adequate way to solve the problem or if there is 
a solution that requires fewer and more localized changes of the system, 
avoiding to give the ramdisk pages a specific treatment

 

 

I did not observe this problem prior to kernel version 2.6.19.1, but I'm not 
sure whether ths was simply caused by coincidental circumstances during 
startup. 

 

 

 

Peter Bier

___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

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

[2.6 patch] i386/x86_64: sys_ioperm() prototype cleanup

[Adrian Bunk]

- there's no reason for duplicating the prototype from 
  include/linux/syscalls.h in include/asm-x86_64/unistd.h
- every file should #include the headers containing the prototypes for
  it's global functions

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/i386/kernel/ioport.c   |1 +
 arch/x86_64/kernel/ioport.c |1 +
 include/asm-x86_64/unistd.h |1 -
 3 files changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.21-rc4-mm1/include/asm-x86_64/unistd.h.old2007-03-26 
15:45:56.0 +0200
+++ linux-2.6.21-rc4-mm1/include/asm-x86_64/unistd.h2007-03-26 
15:46:05.0 +0200
@@ -655,7 +655,6 @@
 #include 
 
 asmlinkage long sys_iopl(unsigned int level, struct pt_regs *regs);
-asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on);
 struct sigaction;
 asmlinkage long sys_rt_sigaction(int sig,
const struct sigaction __user *act,
--- linux-2.6.21-rc4-mm1/arch/i386/kernel/ioport.c.old  2007-03-26 
15:44:17.0 +0200
+++ linux-2.6.21-rc4-mm1/arch/i386/kernel/ioport.c  2007-03-26 
15:44:39.0 +0200
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
 static void set_bitmap(unsigned long *bitmap, unsigned int base, unsigned int 
extent, int new_value)
--- linux-2.6.21-rc4-mm1/arch/x86_64/kernel/ioport.c.old2007-03-26 
15:43:45.0 +0200
+++ linux-2.6.21-rc4-mm1/arch/x86_64/kernel/ioport.c2007-03-26 
15:44:01.0 +0200
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
 static void set_bitmap(unsigned long *bitmap, unsigned int base, unsigned int 
extent, int new_value)

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

[2.6 patch] i386/x86_64: remove UNEXPECTED_IO_APIC()

[Adrian Bunk]

Many years ago, UNEXPECTED_IO_APIC() contained printk()'s (but nothing more).

Now that it's completely empty for years, we can as well remove it.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/i386/kernel/io_apic.c   |   30 --
 arch/x86_64/kernel/io_apic.c |   28 
 2 files changed, 58 deletions(-)

--- linux-2.6.21-rc4-mm1/arch/i386/kernel/io_apic.c.old 2007-03-27 
04:18:36.0 +0200
+++ linux-2.6.21-rc4-mm1/arch/i386/kernel/io_apic.c 2007-03-27 
04:19:49.0 +0200
@@ -1403,10 +1403,6 @@ static void __init setup_ExtINT_IRQ0_pin
enable_8259A_irq(0);
 }
 
-static inline void UNEXPECTED_IO_APIC(void)
-{
-}
-
 void __init print_IO_APIC(void)
 {
int apic, i;
@@ -1446,34 +1442,12 @@ void __init print_IO_APIC(void)
printk(KERN_DEBUG "...: physical APIC id: %02X\n", 
reg_00.bits.ID);
printk(KERN_DEBUG "...: Delivery Type: %X\n", 
reg_00.bits.delivery_type);
printk(KERN_DEBUG "...: LTS  : %X\n", reg_00.bits.LTS);
-   if (reg_00.bits.ID >= get_physical_broadcast())
-   UNEXPECTED_IO_APIC();
-   if (reg_00.bits.__reserved_1 || reg_00.bits.__reserved_2)
-   UNEXPECTED_IO_APIC();
 
printk(KERN_DEBUG " register #01: %08X\n", reg_01.raw);
printk(KERN_DEBUG "... : max redirection entries: %04X\n", 
reg_01.bits.entries);
-   if ((reg_01.bits.entries != 0x0f) && /* older (Neptune) boards */
-   (reg_01.bits.entries != 0x17) && /* typical ISA+PCI boards */
-   (reg_01.bits.entries != 0x1b) && /* Compaq Proliant boards */
-   (reg_01.bits.entries != 0x1f) && /* dual Xeon boards */
-   (reg_01.bits.entries != 0x22) && /* bigger Xeon boards */
-   (reg_01.bits.entries != 0x2E) &&
-   (reg_01.bits.entries != 0x3F)
-   )
-   UNEXPECTED_IO_APIC();
 
printk(KERN_DEBUG "... : PRQ implemented: %X\n", 
reg_01.bits.PRQ);
printk(KERN_DEBUG "... : IO APIC version: %04X\n", 
reg_01.bits.version);
-   if ((reg_01.bits.version != 0x01) && /* 82489DX IO-APICs */
-   (reg_01.bits.version != 0x10) && /* oldest IO-APICs */
-   (reg_01.bits.version != 0x11) && /* Pentium/Pro IO-APICs */
-   (reg_01.bits.version != 0x13) && /* Xeon IO-APICs */
-   (reg_01.bits.version != 0x20)/* Intel P64H (82806 AA) */
-   )
-   UNEXPECTED_IO_APIC();
-   if (reg_01.bits.__reserved_1 || reg_01.bits.__reserved_2)
-   UNEXPECTED_IO_APIC();
 
/*
 * Some Intel chipsets with IO APIC VERSION of 0x1? don't have reg_02,
@@ -1483,8 +1457,6 @@ void __init print_IO_APIC(void)
if (reg_01.bits.version >= 0x10 && reg_02.raw != reg_01.raw) {
printk(KERN_DEBUG " register #02: %08X\n", reg_02.raw);
printk(KERN_DEBUG "... : arbitration: %02X\n", 
reg_02.bits.arbitration);
-   if (reg_02.bits.__reserved_1 || reg_02.bits.__reserved_2)
-   UNEXPECTED_IO_APIC();
}
 
/*
@@ -1496,8 +1468,6 @@ void __init print_IO_APIC(void)
reg_03.raw != reg_01.raw) {
printk(KERN_DEBUG " register #03: %08X\n", reg_03.raw);
printk(KERN_DEBUG "... : Boot DT: %X\n", 
reg_03.bits.boot_DT);
-   if (reg_03.bits.__reserved_1)
-   UNEXPECTED_IO_APIC();
}
 
printk(KERN_DEBUG " IRQ redirection table:\n");
--- linux-2.6.21-rc4-mm1/arch/x86_64/kernel/io_apic.c.old   2007-03-27 
04:20:22.0 +0200
+++ linux-2.6.21-rc4-mm1/arch/x86_64/kernel/io_apic.c   2007-03-27 
04:20:51.0 +0200
@@ -907,10 +907,6 @@ static void __init setup_ExtINT_IRQ0_pin
enable_8259A_irq(0);
 }
 
-void __init UNEXPECTED_IO_APIC(void)
-{
-}
-
 void __apicdebuginit print_IO_APIC(void)
 {
int apic, i;
@@ -946,40 +942,16 @@ void __apicdebuginit print_IO_APIC(void)
printk(KERN_DEBUG "IO APIC #%d..\n", mp_ioapics[apic].mpc_apicid);
printk(KERN_DEBUG " register #00: %08X\n", reg_00.raw);
printk(KERN_DEBUG "...: physical APIC id: %02X\n", 
reg_00.bits.ID);
-   if (reg_00.bits.__reserved_1 || reg_00.bits.__reserved_2)
-   UNEXPECTED_IO_APIC();
 
printk(KERN_DEBUG " register #01: %08X\n", *(int *)®_01);
printk(KERN_DEBUG "... : max redirection entries: %04X\n", 
reg_01.bits.entries);
-   if ((reg_01.bits.entries != 0x0f) && /* older (Neptune) boards */
-   (reg_01.bits.entries != 0x17) && /* typical ISA+PCI boards */
-   (reg_01.bits.entries != 0x1b) && /* Compaq Proliant boards */
-   (reg_01.bits.entries != 0x1f) && /* dual Xeon boards */
-   (reg_01.bits.entries != 0x22) && /* bigger Xeon boards */
-   (reg_01.bits.e

[-mm patch] no longer #include

[Adrian Bunk]

On Tue, Mar 27, 2007 at 01:11:50PM -0400, Mathieu Desnoyers wrote:

> Hi Adrian,
> 
> Since kdebug.h seems to have moved from asm/ to linux/ in Andrew's tree, I
> guess the #include  should be removed ? linux/kdebug.h
> already includes asm/kdebug.h.

Agreed, additional patch to remove all #include 's is
below.

> Mathieu

cu
Adrian


<--  snip  -->


Include the new linux/kdebug.h instead of asm/kdebug.h.

Simply remove the asm/kdebug.h include if both had been included.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/i386/kernel/marker.c |1 -
 arch/s390/kernel/dis.c|2 +-
 drivers/char/ipmi/ipmi_watchdog.c |1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

--- linux-2.6.21-rc5-mm2/arch/i386/kernel/marker.c.old  2007-03-27 
23:27:56.0 +0200
+++ linux-2.6.21-rc5-mm2/arch/i386/kernel/marker.c  2007-03-27 
23:28:04.0 +0200
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define BREAKPOINT_INSTRUCTION  0xcc
 #define BREAKPOINT_INS_LEN 1
--- linux-2.6.21-rc5-mm2/arch/s390/kernel/dis.c.old 2007-03-27 
23:28:12.0 +0200
+++ linux-2.6.21-rc5-mm2/arch/s390/kernel/dis.c 2007-03-27 23:28:25.0 
+0200
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -33,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifndef CONFIG_64BIT
 #define ONELONG "%08lx: "
--- linux-2.6.21-rc5-mm2/drivers/char/ipmi/ipmi_watchdog.c.old  2007-03-27 
23:28:34.0 +0200
+++ linux-2.6.21-rc5-mm2/drivers/char/ipmi/ipmi_watchdog.c  2007-03-27 
23:28:56.0 +0200
@@ -61,7 +61,6 @@
how it will work.  So in the unlikely event that another
architecture supports this, we can figure out a good generic
mechanism for it at that time. */
-#include 
 #define HAVE_DIE_NMI_POST
 #endif
 

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

[2.6 patch] make arch/i386/kernel/io_apic.c:timer_irq_works() static again

[Adrian Bunk]

timer_irq_works() needlessly became global.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.21-rc5-mm2/arch/i386/kernel/io_apic.c.old 2007-03-28 
00:04:18.0 +0200
+++ linux-2.6.21-rc5-mm2/arch/i386/kernel/io_apic.c 2007-03-28 
00:04:28.0 +0200
@@ -1904,7 +1904,7 @@ __setup("no_timer_check", notimercheck);
  * - if this function detects that timer IRQs are defunct, then we fall
  *   back to ISA timer IRQs
  */
-int __init timer_irq_works(void)
+static int __init timer_irq_works(void)
 {
unsigned long t1 = jiffies;
 

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

[-mm patch] drivers/mtd/ubi/: make code static

[Adrian Bunk]

On Mon, Mar 26, 2007 at 08:57:06PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc4-mm1:
>...
>  git-ubi.patch
>...
>  git trees
>...


This patch makes needlessly global code static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/mtd/ubi/eba.c  |4 ++--
 drivers/mtd/ubi/vtbl.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.21-rc5-mm2/drivers/mtd/ubi/eba.c.old  2007-03-27 
23:36:48.0 +0200
+++ linux-2.6.21-rc5-mm2/drivers/mtd/ubi/eba.c  2007-03-27 23:38:05.0 
+0200
@@ -489,8 +489,8 @@ out_unlock:
  * Returns new physical eraseblock number in case of success, and a negative
  * error code in case of failure.
  */
-int recover_peb(struct ubi_device *ubi, int pnum, int vol_id, int lnum,
-   const void *buf, int offset, int len)
+static int recover_peb(struct ubi_device *ubi, int pnum, int vol_id, int lnum,
+  const void *buf, int offset, int len)
 {
int err, idx = vol_id2idx(ubi, vol_id), new_pnum, data_size, tries = 0;
struct ubi_volume *vol = ubi->volumes[idx];
--- linux-2.6.21-rc5-mm2/drivers/mtd/ubi/vtbl.c.old 2007-03-27 
23:38:54.0 +0200
+++ linux-2.6.21-rc5-mm2/drivers/mtd/ubi/vtbl.c 2007-03-27 23:39:08.0 
+0200
@@ -68,7 +68,7 @@ static void paranoid_vtbl_check(const st
 #endif
 
 /* Empty volume table record */
-struct ubi_vtbl_record empty_vtbl_record;
+static struct ubi_vtbl_record empty_vtbl_record;
 
 /**
  * ubi_change_vtbl_record - change volume table record.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 16/21] MSI: arch should connect the irq and the msi_desc desc when it's ready

[Eric W. Biederman]

Michael Ellerman <[EMAIL PROTECTED]> writes:

> set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
> it at some point in their setup routine, and then the generic code sets up the
> reverse mapping from the msi_desc back to the irq.
>
> set_irq_msi() should really do both connections, making it the one and only
> call required to connect an irq with it's MSI desc.

Hmm.  This comment should be a little more forceful than a suggestion
to make ti clear you have made that change somewhere in this
patch.

> It should be the arch code that calls set_irq_msi(), and it should do so
> only once it's sure it's not going to fail the irq allocation.
>
> Given that there's no need for the arch to return the irq anymore, the return
> value from the arch setup routine just becomes 0 for success and !0 for
> failure.

Call it negative for failure, or possibly nonzero.  !0 == 1  Which
isn't what you meant, and is confusing comparing it to the code.

Ok.  This is likely me limit of picking on your patches for tonight.



> Index: msi-new/arch/ia64/kernel/msi_ia64.c
> ===
> --- msi-new.orig/arch/ia64/kernel/msi_ia64.c
> +++ msi-new/arch/ia64/kernel/msi_ia64.c
> @@ -74,7 +74,6 @@ int ia64_setup_msi_irq(struct pci_dev *p
>   if (irq < 0)
>   return irq;
>  
> - set_irq_msi(irq, desc);
>   dest_phys_id = cpu_physical_id(first_cpu(cpu_online_map));
>   vector = irq;
>  
> @@ -91,11 +90,13 @@ int ia64_setup_msi_irq(struct pci_dev *p
>   MSI_DATA_DELIVERY_FIXED |
>   MSI_DATA_VECTOR(vector);
>  
> + desc->irq = irq;
Setting desc->irq just before set_irq_msi appears redundant here.
> + set_irq_msi(irq, desc);
>   set_irq_chip_and_handler(irq, &ia64_msi_chip, handle_edge_irq);
>   get_irq_chip(irq)->mask(irq);
>   write_msi_msg(irq, &msg);
>  
> - return irq;
> + return 0;
>  }
>  
>  void ia64_teardown_msi_irq(unsigned int irq)

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

Re: [PATCH] kdump/kexec: calculate note size at compile time

[Vivek Goyal]

On Wed, Mar 28, 2007 at 04:13:20PM +0900, Horms wrote:
[..]
> 
> DESC is probably a better name that BODY here, I meant to update
> that before posting. An updated version is below.
> 
> > > +#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
> > 
> > Why are we multiplying KEXEC_NOTE_HEAD_BYTES with 2?
> 
> The way that the note merging code works in vmcore it assumes that
> the area is a list of notes. And there is a terminating note that
> has all the header values set to 0, and nothing else. So the time 2
> is for the space to store the terminating note.
> 

Ok.. Got it. Looks fine to me. 

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

Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]

[Jiri Slaby]

Dmitry Torokhov napsal(a):
> On Tuesday 27 March 2007 17:34, johann deneux wrote:
>> What about adding a member to ff_effect which would be the number of the 
>> motor?
>> We can't change the layout of ff_effect too much though, so we have to
>> find unused bits and put them to work.
>>
>> For instance, we could replace
>>
>> __u16 type;
>>
>> by
>>
>> __u8 motor;
>> __u8 type;
>>
> 
> Splitting type field seems to be a good idea.

For me too, if 3-4 context switches for one effect are not too much in ~ kHz
freq. I'll try that.

thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4/5] 2.6.21-rc5: known regressions

[Ingo Molnar]

* Adrian Bunk <[EMAIL PROTECTED]> wrote:

> Subject: second suspend to disk in a row results in an oops  (MSI)
> References : http://lkml.org/lkml/2007/3/17/43
>  http://lkml.org/lkml/2007/3/22/150
>  http://lkml.org/lkml/2007/3/26/205
>  http://lkml.org/lkml/2007/3/26/76
> Submitter  : Thomas Meyer <[EMAIL PROTECTED]>
>  Frédéric Riss <[EMAIL PROTECTED]>
>  Marcus Better <[EMAIL PROTECTED]>
> Handled-By : Eric W. Biederman <[EMAIL PROTECTED]>
> Patch  : http://lkml.org/lkml/2007/3/24/136
> Status : patch was suggested

i can reproduce a crash on the second suspend-to-ram, on a T60. I get a 
crash here:

 #ifdef CONFIG_PM
 static void __pci_restore_msi_state(struct pci_dev *dev)
 {
 int pos;
 u16 control;
 struct msi_desc *entry;

 if (!dev->msi_enabled)
 return;

 entry = get_irq_msi(dev->irq);
 pos = entry->msi_attrib.pos; < crash on NULL dereference


i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on 
the VGA screen so no dump of it available. Can write down more info if  
it's helpful.)

I have tried Eric's patch above but now i always get a hang after 
"system 00:00: resuming", already upon the first suspend-resume. Not 
even the NMI watchdog can get the system out of that hang.

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

Re: [PATCH 0/4] coredump: core dump masking support v4

[Kawai, Hidehiro]

Hi,
Thank you for your kind comments.
I'm sorry for my late reply. 

Andrew Morton wrote:

> On Fri, 02 Mar 2007 13:41:30 +0900
> "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:
> 
>>This patch series is version 4 of the core dump masking feature,
>>which provides a per-process flag not to dump anonymous shared
>>memory segments.
> 
> First up, please convince us that this problem cannot be solved in
> userspace. 
> Note that we now support dumping core over a pipe to a
> userspace application which can perform filtering such as this (see
> Documentation/sysctl/kernel.txt:core_pattern).

I understand.  Thank you for your suggestion.  I'll reply about it in
another mail, but it may take a few days.

 
> Assuming that your argument is successful...
> 
> - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is
>   there, I believe, to handle the case where a coredump is presently in
>   progress.  We don't want to change the filtering rule while the dump is
>   happening.
> 
>   What I suggest you do instead is to take a copy of
>   mm->coredump_omit_anon_shared into a local variable with one single read
>   per coredump.  Pass that local down into all the callees which need to
>   see it.  That way, no locking is needed.

Previous v3 patchset does what you suggest, and here are links to the
patches:

[PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory
http://lkml.org/lkml/2007/2/16/156

[PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory
http://lkml.org/lkml/2007/2/16/157

However, there was an opposite opinion.  To pass the flag status, I
added omit_anon_shared argument to elf_fdpic_dump_segments().  Then,
David pointed that the argument was unncecessary, because the function
also receives mm_struct *mm which includes coredump_omit_anon_shared.
But mm->coredump_omit_anon_shared can be changed while core dumping, and
it may causes the core file to be corrupted.  So in v4 patchset I used
r/w semaphore to prevent mm->coredump_omit_anon_shared from being changed.

If I add an addtional argument to elf_fdpic_dump_segments() again, I
have to explain it to David.  I'll tell him that removing mm argument
from the function will be a solution since it refers current->mm directly
and the mm argument is never used.

 
> - These games we're playing with the atomicity of the bitfields in the
>   mm_struct need to go away.
> 
>   First up, please prepare a standalone patch which removes
>   mm_struct.dumpable and adds `unsigned long mm_struct.flags'.  Include a
>   comment telling people that they must use atomic bitops (set_bit, 
> clear_bit) on
>   mm_struct.flags.

OK.  I'll do it in the next version.


> - Finally, the code as you have it here is very specific to your specific
>   requirement: don't dump shared memory segments.
> 
>   But if we're going to implement in-kernel core-dump filtering of this
>   nature, we should design it extensibly, even if we don't actually
>   implement those extensions at this time.

I understood. Since I had done so initially, I'll revert it to.

 
>   Because other people might (reasonably) wish to omit anonymous memory,
>   or private mappings, or file-backed VMAs, or whatever.
> 
>   So maybe /proc/pid/coredump_omit_anon_shared should become
>   /proc/pid/core_dumpfilter, which is a carefully documented bitmask.

There are people who wish to dump VMAs which are not dumped by default.
Taking this into account, some bits of core_dumpfilter will be set by
default.  This means users have to be aware of the default bitmask
when they change the bitmask.  Perhaps changing the bitmask requires
3 steps:

  1. read the default bitmask
  2. change bits of the mask
  3. write it to the proc entry

So I think it is better if we provide /proc/pid/core_flags (default:
all bits are 0) instead of core_dumpfilter.  With this interface,
users who use only one bit of the bitmask (this will be a common case) 
just have to write 2^n to the proc entry.  It takes only one step:

 1. write a value to the proc entry

If we can implement at the same cost, core_flags will be better
because it is useful for users.  What would you think about that?


By the way, Robin Holt wrote as follows:

> Can you make this a little more transparent?  Having a magic bitmask does
> not seem like the best way to do stuff.  Could you maybe make a core_flags
> directory with a seperate file for each flag.  It could still map to a
> single field in the mm, but be broken out for the proc filesystem.

Do you think Robin's suggestion is acceptable?

Best regards,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

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

Re: [4/5] 2.6.21-rc5: known regressions

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

>  entry = get_irq_msi(dev->irq);
>  pos = entry->msi_attrib.pos; < crash on NULL dereference
> 
> 
> i.e. 'entry' is NULL after get_irq_msi(). (i can see the crash only on 
> the VGA screen so no dump of it available. Can write down more info if 
> it's helpful.)
> 
> I have tried Eric's patch above but now i always get a hang after 
> "system 00:00: resuming", already upon the first suspend-resume. Not 
> even the NMI watchdog can get the system out of that hang.

find below the PM log of a successful suspend/resume cycle. (I've marked 
the place that hangs with '[hard hang]')

Ingo

>
PM: Preparing system for mem sleep
Stopping tasks ... done.
psmouse serio2: suspend
psmouse serio1: suspend
atkbd serio0: suspend
i8042 i8042: suspend
sd 0:0:0:0: suspend
ide 0.0: suspend
serial8250 serial8250: suspend
platform vesafb.0: suspend
pci_express :00:1c.3:pcie03: suspend
pci_express :00:1c.3:pcie02: suspend
pci_express :00:1c.3:pcie00: suspend
pci_express :00:1c.2:pcie03: suspend
pci_express :00:1c.2:pcie02: suspend
pci_express :00:1c.2:pcie00: suspend
pci_express :00:1c.1:pcie03: suspend
pci_express :00:1c.1:pcie02: suspend
pci_express :00:1c.1:pcie00: suspend
pci_express :00:1c.0:pcie03: suspend
pci_express :00:1c.0:pcie02: suspend
pci_express :00:1c.0:pcie00: suspend
platform pcspkr: suspend
pnp 00:0a: suspend
i8042 aux 00:09: suspend
i8042 kbd 00:08: suspend
pnp 00:07: suspend
pnp 00:06: suspend
pnp 00:05: suspend
pnp 00:04: suspend
pnp 00:03: suspend
system 00:02: suspend
pnp 00:01: suspend
system 00:00: suspend
yenta_cardbus :15:00.0: suspend
pci :03:00.0: suspend
e1000 :02:00.0: suspend
pci :03:00.0: resuming
yenta_cardbus :15:00.0: resuming
PM: Writing back config space on device :15:00.0 at offset f (was 34001ff, 
writing 5c0010b)
PM: Writing back config space on device :15:00.0 at offset e (was 0, 
writing 94fc)
PM: Writing back config space on device :15:00.0 at offset d (was 0, 
writing 9400)
PM: Writing back config space on device :15:00.0 at offset c (was 0, 
writing 90fc)
PM: Writing back config space on device :15:00.0 at offset b (was 0, 
writing 9000)
PM: Writing back config space on device :15:00.0 at offset a (was 0, 
writing 8bfff000)
PM: Writing back config space on device :15:00.0 at offset 9 (was 0, 
writing 8800)
PM: Writing back config space on device :15:00.0 at offset 8 (was 0, 
writing e3fff000)
PM: Writing back config space on device :15:00.0 at offset 7 (was 0, 
writing e000)
PM: Writing back config space on device :15:00.0 at offset 6 (was 0, 
writing b0171615)
PM: Writing back config space on device :15:00.0 at offset 4 (was 0, 
writing e430)
PM: Writing back config space on device :15:00.0 at offset 3 (was 2, 
writing 2a820)
PM: Writing back config space on device :15:00.0 at offset 1 (was 210, 
writing 217)
system 00:00: resuming <-- [ hard hang ]
pnp 00:01: resuming
system 00:02: resuming
pnp 00:03: resuming
pnp 00:04: resuming
pnp 00:05: resuming
pnp 00:06: resuming
pnp 00:07: resuming
i8042 kbd 00:08: resuming
i8042 aux 00:09: resuming
pnp 00:0a: resuming
platform pcspkr: resuming
pci_express :00:1c.0:pcie00: resuming
pci_express :00:1c.0:pcie02: resuming
pci_express :00:1c.0:pcie03: resuming
pci_express :00:1c.1:pcie00: resuming
pci_express :00:1c.1:pcie02: resuming
pci_express :00:1c.1:pcie03: resuming
pci_express :00:1c.2:pcie00: resuming
pci_express :00:1c.2:pcie02: resuming
pci_express :00:1c.2:pcie03: resuming
pci_express :00:1c.3:pcie00: resuming
pci_express :00:1c.3:pcie02: resuming
pci_express :00:1c.3:pcie03: resuming
platform vesafb.0: resuming
serial8250 serial8250: resuming
ide 0.0: resuming
sd 0:0:0:0: resuming
i8042 i8042: resuming
atkbd serio0: resuming
psmouse serio1: resuming
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
psmouse serio2: resuming
ata1: waiting for device to spin up (7 secs)
Restarting tasks ... done.
e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow 
Control: RX/TX
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA
PM: Preparing system for mem sleep
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[Oliver Joa]

Hi,

David Chinner wrote:

[...]


What is the corruption message in the log from XFS?
Can you please post that? Without it we really can't help you.

Also, please check to see if there are any I/O errors
in the log around the time the corruption message appears.


Ok, here is a test:

test:/# find / -xdev | cpio -padm /test/
cpio: /usr/src/linux-2.6.20.2/Documentation/networking/NAPI_HOWTO.txt: 
Structure needs cleaning

3648371 blocks
test:/#

test:/home/olli# uname -a
Linux test 2.6.20.4-majestix-1 #1 SMP PREEMPT Tue Mar 27 12:15:41 CEST 
2007 i686 GNU/Linux


dmesg gives the following:
[15442.935941] Filesystem "sda3": XFS internal error xfs_iformat(6) at 
line 492 of file fs/xfs/xfs_inode.c.  Caller 0xc0211f94

[15442.936003]  [] xfs_iread+0x4ee/0x6e8
[15442.936039]  [] xfs_iget+0x2e4/0x714
[15442.936071]  [] xfs_iget+0x2e4/0x714
[15442.936101]  [] xfs_dir_lookup_int+0x7d/0xd4
[15442.936135]  [] xfs_lookup+0x52/0x78
[15442.936167]  [] xfs_vn_lookup+0x3b/0x70
[15442.936201]  [] do_lookup+0xa3/0x140
[15442.936234]  [] __link_path_walk+0x73d/0xb5e
[15442.936278]  [] xfs_iunlock+0x51/0x6d
[15442.936309]  [] link_path_walk+0x44/0xb3
[15442.936342]  [] do_path_lookup+0x176/0x191
[15442.936373]  [] getname+0x59/0x8f
[15442.936402]  [] __user_walk_fd+0x2f/0x45
[15442.936431]  [] vfs_lstat_fd+0x16/0x3d
[15442.936461]  [] sys_lstat64+0xf/0x23
[15442.936490]  [] syscall_call+0x7/0xb
[15442.936519]  ===

And after this command:

test:/# rm /usr/src/linux-2.6.20.2/Documentation/networking/NAPI_HOWTO.txt
rm: cannot remove 
`/usr/src/linux-2.6.20.2/Documentation/networking/NAPI_HOWTO.txt': 
Structure needs cleaning

test:/#

I got:

[18359.750604] Filesystem "sda3": XFS internal error xfs_iformat(6) at 
line 492 of file fs/xfs/xfs_inode.c.  Caller 0xc0211f94

[18359.750701]  [] xfs_iread+0x4ee/0x6e8
[18359.750755]  [] xfs_iget+0x2e4/0x714
[18359.750802]  [] xfs_iget+0x2e4/0x714
[18359.750849]  [] xfs_dir_lookup_int+0x7d/0xd4
[18359.750897]  [] xfs_lookup+0x52/0x78
[18359.750943]  [] xfs_vn_lookup+0x3b/0x70
[18359.750990]  [] do_lookup+0xa3/0x140
[18359.751036]  [] __link_path_walk+0x73d/0xb5e
[18359.751086]  [] link_path_walk+0x44/0xb3
[18359.751133]  [] rb_insert_color+0x4c/0xad
[18359.751180]  [] vma_link+0x54/0xcd
[18359.751226]  [] do_path_lookup+0x176/0x191
[18359.751273]  [] getname+0x59/0x8f
[18359.751318]  [] __user_walk_fd+0x2f/0x45
[18359.751364]  [] vfs_lstat_fd+0x16/0x3d
[18359.751410]  [] rb_insert_color+0x4c/0xad
[18359.751457]  [] vma_link+0x54/0xcd
[18359.751501]  [] sys_lstat64+0xf/0x23
[18359.751546]  [] do_page_fault+0x277/0x526
[18359.751595]  [] do_page_fault+0x0/0x526
[18359.751640]  [] syscall_call+0x7/0xb
[18359.751686]  [] rsc_parse+0x6f/0x37f
[18359.751732]  ===
[18359.751784] Filesystem "sda3": XFS internal error xfs_iformat(6) at 
line 492 of file fs/xfs/xfs_inode.c.  Caller 0xc0211f94

[18359.751859]  [] xfs_iread+0x4ee/0x6e8
[18359.751906]  [] xfs_iget+0x2e4/0x714
[18359.751952]  [] xfs_iget+0x2e4/0x714
[18359.751998]  [] xfs_dir_lookup_int+0x7d/0xd4
[18359.752047]  [] xfs_lookup+0x52/0x78
[18359.752094]  [] xfs_vn_lookup+0x3b/0x70
[18359.752140]  [] __lookup_hash+0xb1/0xe1
[18359.752191]  [] do_unlinkat+0x5f/0x126
[18359.752237]  [] do_page_fault+0x277/0x526
[18359.752285]  [] syscall_call+0x7/0xb
[18359.752331]  [] rsc_parse+0x6f/0x37f
[18359.752376]  ===



Thanks a Lot

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

Re: [4/5] 2.6.21-rc5: known regressions

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> PM: Writing back config space on device :15:00.0 at offset 4 (was 0, 
> writing e430)
> PM: Writing back config space on device :15:00.0 at offset 3 (was 2, 
> writing 2a820)
> PM: Writing back config space on device :15:00.0 at offset 1 (was 
> 210, writing 217)
> system 00:00: resuming <-- [ hard hang ]
> pnp 00:01: resuming
> system 00:02: resuming
> pnp 00:03: resuming

ok, this was a red herring: the hard hang was an effect of netconsole 
combined with CONFIG_DISABLE_CONSOLE_SUSPEND. Disabling netconsole 
solved it. I'll now re-test Eric's MSI patch.

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

[patch] MSI-X: fix resume crash

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> [...] I'll now re-test Eric's MSI patch.

Eric's patch seems to have done the trick on my T60: i've done 10 
suspend+resumes and each worked fine. I've tidied up the description 
part of Eric's patch a bit for upstream application - find it below.

Ingo

-->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <[EMAIL PROTECTED]>

I think the right solution is to simply make pci_enable_device just flip 
enable bits and move the rest of the work someplace else.

However a thorough cleanup is a little extreme for this point in the 
release cycle, so I think a quick hack that makes the code not stomp the 
irq when msi irq's are enabled should be the first fix.  Then we can 
later make the code not change the irqs at all.

Tony, Len the way pci_disable_device is being used in a suspend/resume 
path by a few drivers is completely incompatible with the way irqs are 
allocated on ia64.  In particular people the following sequence occurs 
in several drivers.

probe:
  pci_enable_device(pdev);
  request_irq(pdev->irq);
suspend:
  pci_disable_device(pdev);
resume:
  pci_enable_device(pdev);
remove:
  free_irq(pdev->irq);
  pci_disable_device(pdev);

What I'm proposing we do is move the irq allocation code out of 
pci_enable_device and the irq freeing code out of pci_disable_device in 
the future.  If we move ia64 to a model where the irq number equal the 
gsi like we have for x86_64 and are in the middle of for i386 that 
should be pretty straight forward.  It would even be relatively simple 
to delay vector allocation in that context until request_irq, if we 
needed the delayed allocation benefit.  Do you two have any problems 
with moving in that direction?

If fixing the arch code is unacceptable for some reason I'm not aware of 
we need to audit the 10-20 drivers that call pci_disable_device in their 
suspend/resume processing and ensure that they have freed all of the 
irqs before that point.  Given that I have bug reports on the msi path I 
know that isn't true.

From: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 arch/cris/arch-v32/drivers/pci/bios.c |4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c   |3 ++-
 arch/i386/pci/common.c|6 --
 arch/ia64/pci/pci.c   |8 ++--
 4 files changed, 15 insertions(+), 6 deletions(-)

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ linux/arch/cris/arch-v32/drivers/pci/bios.c
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
 
-   return pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   pcibios_enable_irq(dev);
+   return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ linux/arch/frv/mb93090-mb00/pci-vdk.c
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
-   pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   pcibios_enable_irq(dev);
return 0;
 }
Index: linux/arch/i386/pci/common.c
===
--- linux.orig/arch/i386/pci/common.c
+++ linux/arch/i386/pci/common.c
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
 
-   return pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-   if (pcibios_disable_irq)
+   if (!dev->msi_enabled && pcibios_disable_irq)
pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===
--- linux.orig/arch/ia64/pci/pci.c
+++ linux/arch/ia64/pci/pci.c
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
if (ret < 0)
return ret;
 
-   return acpi_pci_irq_enable(dev);
+   if (!dev->msi_enabled)
+   return acpi_pci_irq_enable(dev);
+   return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
BUG_ON(atomic_read(&dev->enable_cnt));
-   acpi_pci_irq_disable(dev);
+   if (!dev->msi_enabled)
+   acpi_pci_irq_disable(dev);
+   return 0;
 }
 
 void
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://ww

RE: question on tty open and close

[Stuart MacDonald]

From: [EMAIL PROTECTED] 
> in tty_io.c::tty_open():
[snip]
> We find that a failure in open() leads to release_dev() being called.
> release_dev() calls close():
> 
>   if (tty->driver->close)
>   tty->driver->close(tty, filp);
> 
> So we have a file that's closed although open() never succeeded?

That's correct! It's been a pain in my butt for years.

> What's the reason for that?

No idea. Would *love* to hear an explanation.

..Stu

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

Re: question on tty open and close

[Oliver Neukum]

Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
> > We find that a failure in open() leads to release_dev() being called.
> > release_dev() calls close():
> > 
> >   if (tty->driver->close)
> >   tty->driver->close(tty, filp);
> > 
> > So we have a file that's closed although open() never succeeded?
> 
> That's correct! It's been a pain in my butt for years.

How did you deal with that proctological issue?

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Eric W. Biederman]

Adrian Bunk <[EMAIL PROTECTED]> writes:


> I think I got your problem:
>
> After rebooting, you do "git bisect [bad|good]"  *once*.
>
> Then recompile the kernel from the current tree, reboot, and again
> *once* "git bisect [bad|good]".
>
> etc.

Sounds right.

Someone else doing the bisect suggested that
0475ac0845f9295bc5f69af45f58dff2c104c8d1 is the problem commit.
Unfortunately I can't see anything wrong there.

Sid when you get that far if you can confirm or deny that
0475ac0845f9295bc5f69af45f58dff2c104c8d1 is the problem commit
I would appreciate the extra data point.  Having two people
report the problem at the exact same place would confirm for
me that we actually have a good trace, and that I really am
blind.

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

RE: question on tty open and close

[Stuart MacDonald]

From: Oliver Neukum [mailto:[EMAIL PROTECTED] 
> Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
> > > We find that a failure in open() leads to release_dev() 
> being called.
> > > release_dev() calls close():
> > > 
> > >   if (tty->driver->close)
> > >   tty->driver->close(tty, filp);
> > > 
> > > So we have a file that's closed although open() never succeeded?
> > 
> > That's correct! It's been a pain in my butt for years.
> 
> How did you deal with that proctological issue?

Just make sure the close() handles the situation properly. It makes
reference counting...  fun.

The serial driver has always handled it like this.

..Stu

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

[Eric W. Biederman]

Ingo Molnar <[EMAIL PROTECTED]> writes:

> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> [...] I'll now re-test Eric's MSI patch.
>
> Eric's patch seems to have done the trick on my T60: i've done 10 
> suspend+resumes and each worked fine. I've tidied up the description 
> part of Eric's patch a bit for upstream application - find it below.

Thanks.  Tidying up the description has been on my todo list for the
last little bit but I just haven't gotten there.

I've gotten at least Tony's sign off on the architectural direction
so there is nothing to prevent this patch from going in.  Unless
Linus or someone wants a more thorough patch this late in the
release cycle.

Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>


> -->
> Subject: [patch] MSI-X: fix resume crash
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> I think the right solution is to simply make pci_enable_device just flip 
> enable bits and move the rest of the work someplace else.
>
> However a thorough cleanup is a little extreme for this point in the 
> release cycle, so I think a quick hack that makes the code not stomp the 
> irq when msi irq's are enabled should be the first fix.  Then we can 
> later make the code not change the irqs at all.
>
> Tony, Len the way pci_disable_device is being used in a suspend/resume 
> path by a few drivers is completely incompatible with the way irqs are 
> allocated on ia64.  In particular people the following sequence occurs 
> in several drivers.
>
> probe:
>   pci_enable_device(pdev);
>   request_irq(pdev->irq);
> suspend:
>   pci_disable_device(pdev);
> resume:
>   pci_enable_device(pdev);
> remove:
>   free_irq(pdev->irq);
>   pci_disable_device(pdev);
>
> What I'm proposing we do is move the irq allocation code out of 
> pci_enable_device and the irq freeing code out of pci_disable_device in 
> the future.  If we move ia64 to a model where the irq number equal the 
> gsi like we have for x86_64 and are in the middle of for i386 that 
> should be pretty straight forward.  It would even be relatively simple 
> to delay vector allocation in that context until request_irq, if we 
> needed the delayed allocation benefit.  Do you two have any problems 
> with moving in that direction?
>
> If fixing the arch code is unacceptable for some reason I'm not aware of 
> we need to audit the 10-20 drivers that call pci_disable_device in their 
> suspend/resume processing and ensure that they have freed all of the 
> irqs before that point.  Given that I have bug reports on the msi path I 
> know that isn't true.
>
> From: Eric W. Biederman <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
>  arch/cris/arch-v32/drivers/pci/bios.c |4 +++-
>  arch/frv/mb93090-mb00/pci-vdk.c   |3 ++-
>  arch/i386/pci/common.c|6 --
>  arch/ia64/pci/pci.c   |8 ++--
>  4 files changed, 15 insertions(+), 6 deletions(-)
>
> Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
> ===
> --- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
> +++ linux/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
>   if ((err = pcibios_enable_resources(dev, mask)) < 0)
>   return err;
>  
> - return pcibios_enable_irq(dev);
> + if (!dev->msi_enabled)
> + pcibios_enable_irq(dev);
> + return 0;
>  }
>  
>  int pcibios_assign_resources(void)
> Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
> ===
> --- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
> +++ linux/arch/frv/mb93090-mb00/pci-vdk.c
> @@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
>  
>   if ((err = pcibios_enable_resources(dev, mask)) < 0)
>   return err;
> - pcibios_enable_irq(dev);
> + if (!dev->msi_enabled)
> + pcibios_enable_irq(dev);
>   return 0;
>  }
> Index: linux/arch/i386/pci/common.c
> ===
> --- linux.orig/arch/i386/pci/common.c
> +++ linux/arch/i386/pci/common.c
> @@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
>   if ((err = pcibios_enable_resources(dev, mask)) < 0)
>   return err;
>  
> - return pcibios_enable_irq(dev);
> + if (!dev->msi_enabled)
> + return pcibios_enable_irq(dev);
> + return 0;
>  }
>  
>  void pcibios_disable_device (struct pci_dev *dev)
>  {
> - if (pcibios_disable_irq)
> + if (!dev->msi_enabled && pcibios_disable_irq)
>   pcibios_disable_irq(dev);
>  }
> Index: linux/arch/ia64/pci/pci.c
> ===
> --- linux.orig/arch/ia64/pci/pci.c
> +++ linux/arch/ia64/pci/pci.c
> @@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
>   if (ret < 0)
>   return ret;
>  
> - return acp

[PATCH] revoke: break cow fixes

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

As pointed out by Nick Piggin, __revoke_break_cow() only needs to do
down_read() and we must use vma_pages() for get_user_pages().

Cc: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/revoke.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: uml-2.6/fs/revoke.c
===
--- uml-2.6.orig/fs/revoke.c2007-03-28 12:25:29.0 +0300
+++ uml-2.6/fs/revoke.c 2007-03-28 12:54:49.0 +0300
@@ -184,7 +184,7 @@ static int __revoke_break_cow(struct tas
struct vm_area_struct *vma;
int err = 0;
 
-   down_write(&mm->mmap_sem);
+   down_read(&mm->mmap_sem);
for (vma = mm->mmap; vma != NULL; vma = vma->vm_next) {
int ret;
 
@@ -195,14 +195,13 @@   int err = 0;
continue;
 
ret = get_user_pages(tsk, tsk->mm, vma->vm_start,
-vma->vm_end-vma->vm_start, 1, 1, NULL,
-NULL);
+vma_pages(vma), 1, 1, NULL, NULL);
if (ret < 0) {
err = ret;
break;
}
}
-   up_write(&mm->mmap_sem);
+   up_read(&mm->mmap_sem);
return err;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] drivers/mtd/ubi/: make code static

[Artem Bityutskiy]

Adrian Bunk wrote:

This patch makes needlessly global code static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>


Thanks, will be fixed.

--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MSI-X: fix resume crash

[Ingo Molnar]

* Eric W. Biederman <[EMAIL PROTECTED]> wrote:

> > Eric's patch seems to have done the trick on my T60: i've done 10 
> > suspend+resumes and each worked fine. I've tidied up the description 
> > part of Eric's patch a bit for upstream application - find it below.
> 
> Thanks.  Tidying up the description has been on my todo list for the 
> last little bit but I just haven't gotten there.
> 
> I've gotten at least Tony's sign off on the architectural direction so 
> there is nothing to prevent this patch from going in.  Unless Linus or 
> someone wants a more thorough patch this late in the release cycle.
> 
> Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>

i've updated the patch below with your sign-off, and trimmed the 
description to the relevant bits, for easy upstream application.

Ingo

->
Subject: [patch] MSI-X: fix resume crash
From: Eric W. Biederman <[EMAIL PROTECTED]>

So I think the right solution is to simply make pci_enable_device just 
flip enable bits and move the rest of the work someplace else.

However a thorough cleanup is a little extreme for this point in the 
release cycle, so I think a quick hack that makes the code not stomp the 
irq when msi irq's are enabled should be the first fix.  Then we can 
later make the code not change the irqs at all.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 arch/cris/arch-v32/drivers/pci/bios.c |4 +++-
 arch/frv/mb93090-mb00/pci-vdk.c   |3 ++-
 arch/i386/pci/common.c|6 --
 arch/ia64/pci/pci.c   |8 ++--
 4 files changed, 15 insertions(+), 6 deletions(-)

Index: linux/arch/cris/arch-v32/drivers/pci/bios.c
===
--- linux.orig/arch/cris/arch-v32/drivers/pci/bios.c
+++ linux/arch/cris/arch-v32/drivers/pci/bios.c
@@ -100,7 +100,9 @@ int pcibios_enable_device(struct pci_dev
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
 
-   return pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   pcibios_enable_irq(dev);
+   return 0;
 }
 
 int pcibios_assign_resources(void)
Index: linux/arch/frv/mb93090-mb00/pci-vdk.c
===
--- linux.orig/arch/frv/mb93090-mb00/pci-vdk.c
+++ linux/arch/frv/mb93090-mb00/pci-vdk.c
@@ -466,6 +466,7 @@ int pcibios_enable_device(struct pci_dev
 
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
-   pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   pcibios_enable_irq(dev);
return 0;
 }
Index: linux/arch/i386/pci/common.c
===
--- linux.orig/arch/i386/pci/common.c
+++ linux/arch/i386/pci/common.c
@@ -434,11 +434,13 @@ int pcibios_enable_device(struct pci_dev
if ((err = pcibios_enable_resources(dev, mask)) < 0)
return err;
 
-   return pcibios_enable_irq(dev);
+   if (!dev->msi_enabled)
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-   if (pcibios_disable_irq)
+   if (!dev->msi_enabled && pcibios_disable_irq)
pcibios_disable_irq(dev);
 }
Index: linux/arch/ia64/pci/pci.c
===
--- linux.orig/arch/ia64/pci/pci.c
+++ linux/arch/ia64/pci/pci.c
@@ -557,14 +557,18 @@ pcibios_enable_device (struct pci_dev *d
if (ret < 0)
return ret;
 
-   return acpi_pci_irq_enable(dev);
+   if (!dev->msi_enabled)
+   return acpi_pci_irq_enable(dev);
+   return 0;
 }
 
 void
 pcibios_disable_device (struct pci_dev *dev)
 {
BUG_ON(atomic_read(&dev->enable_cnt));
-   acpi_pci_irq_disable(dev);
+   if (!dev->msi_enabled)
+   acpi_pci_irq_disable(dev);
+   return 0;
 }
 
 void
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question on tty open and close

[Alan Cox]

> > > > So we have a file that's closed although open() never succeeded?
> > > 
> > > That's correct! It's been a pain in my butt for years.
> > 
> > How did you deal with that proctological issue?
> 
> Just make sure the close() handles the situation properly. It makes
> reference counting...  fun.
> 
> The serial driver has always handled it like this.

I'm also not aware of any reason other than history, which means if
someone cares to double check the other drivers there really shouldn't be
an obstacle to "fixing" this behaviour.

Unless anyone knows different ?

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/

[2.6.21-rc5] forcedeth slow ifup.

[Gerhard Mack]

I'm not sure what's causing it but the onboard ethernet is taking a rather 
long time to come up.. the old nforce board worked fine and any other card 
is fast.

mgerhard:~# time ifup eth0
real0m12.397s
user0m0.214s
sys 0m0.160s

eth0  Link encap:Ethernet  HWaddr 00:18:F3:EB:DF:88
  inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
  inet6 addr: fe80::218:f3ff:feeb:df88/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:162472 errors:0 dropped:0 overruns:0 frame:0
  TX packets:176386 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:82252621 (78.4 MiB)  TX bytes:30913296 (29.4 MiB)
  Interrupt:23 Base address:0x2000

lspci shows:
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)

--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] aio: remove bare user-triggerable error printk

[Jeff Moyer]

==> On Tue, 27 Mar 2007 15:44:01 -0700 (PDT), Zach Brown <[EMAIL PROTECTED]> 
said:

Zach> aio: remove bare user-triggerable error printk The user can
Zach> generate console output if they cause do_mmap() to fail during
Zach> sys_io_setup().  This was seen in a regression test that does
Zach> exactly that by spinning calling mmap() until it gets -ENOMEM
Zach> before calling io_setup().

Zach> We don't need this printk all, just remove it.

ACK.

Zach> Signed-off-by: Zach Brown <[EMAIL PROTECTED]> ---

Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>


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

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Prarit Bhargava]

Jeremy Fitzhardinge wrote:


I haven't really worked out how this should interact with the nmi
watchdog; touch_nmi_watchdog() still ends up calling
touch_softlockup_watchdog(), so there's still some redundancy here.

  


touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs.

Currently, the code is incorrect -- it is calling 
touch_softlockup_watchdog which touches only the current CPU's 
softlockup watchdog.


I don't like the idea of having touch_softlockup_watchdog exported with 
your new code -- we still have two methods of effecting the softlockup 
watchdog and that's confusing and its going to cause serious problems 
down the road.  The nmi watchdog code seems fine with just touching the 
CPU's nmi watchdogs.


Is there a reason that you're pushing the enable/disable?  All the cases 
called out seem to be just fine with calls to either effect that CPU's 
softlockup watchdog or doing all CPU's softlockup watchdogs.  I'm not 
sure I see the benefit of complicating the softlockup watchdog code with 
this ...


I agree with the first patch of this set -- it makes sense.  But beyond 
that I'm not convinced the rest of the code is needed ... IMO.


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

Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
> On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> > On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > 
> > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > with/without CONFIG_NO_HZ.
> > >
> > > Does the patch below fix the HPET_TIMER=y case ?
> > 
> > Thomas, I tried, but it didn't help. Upon resume from ram, "date"
> > still didn't advance.
> 
> Can you please issue a SysRq-Q in this situation and provide the dmesg
> output ?
> 
> Thanks,
> 
>   tglx
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,
I almost sure Iknow why this happens,
The problem is that both hpet clock source and hpet clockevents 
doesn't have a suspend/resume function
On resume we should enable the main counter _and_ enable legacy 
replacement mode,
On my system main counter in enabled, by I think by bios, but 
legacy replacement mode is not, so if
a system doesn't use lapic as a tick source, but use 
hpet+broadcast, it will hang for sure on resume, and i tested it

The patch below is a temporally fix, until clock-events and 
clocksources will get proper suspend/resume hooks:

Regards,
Maxim Levitsky

---

Add suspend/resume for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>

---

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..a1ec79e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
unsigned long cfg, cmp, now;
uint64_t delta;
 
+
+   if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
+   {
+   unsigned long cfg = hpet_readl(HPET_CFG);
+   cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+   hpet_writel(cfg, HPET_CFG);
+   
+   }
+   
+
switch(mode) {
case CLOCK_EVT_MODE_PERIODIC:
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;

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

Re: Linux page cache issue?

[Dave Kleikamp]

On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote:
> Hi,
> 
> If a Linux process opens and reads a file A, then it closes the file.
> Will Linux keep the file A's data in cache for a while in case another
> process opens and reads the same in a short time? I think that is what
> I heard before.

Yes.

> But after I digged into the kernel code, I am confused.
> 
> When a process closes the file A, iput() will be called, which in turn
> calls the follows two functions:
> iput_final()->generic_drop_inode()

A comment from the top of fs/dcache.c:

/*
 * Notes on the allocation strategy:
 *
 * The dcache is a master of the icache - whenever a dcache entry
 * exists, the inode will always exist. "iput()" is done either when
 * the dcache entry is deleted or garbage collected.
 */

Basically, as long a a dentry is present, iput_final won't be called on
the inode.

> But from the following calling chain, we can see that file close will
> eventually lead to evict and free all cached pages. Actually in
> truncate_complete_page(), the pages will be freed.  This seems to
> imply that Linux has to re-read the same data from disk even if
> another process B read the same file right after process A closes the
> file. That does not make sense to me.
> 
> /***calling chain ***/
> generic_delete_inode/generic_forget_inode()->
> truncate_inode_pages()->truncate_inode_pages_range()->
> truncate_complete_page()->remove_from_page_cache()->
> __remove_from_page_cache()->radix_tree_delete()
> 
> Am I missing something? Can someone please provide some advise?
> 
> Thanks a lot
> -x

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

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

Re: question on tty open and close

[Paul Fulghum]

Alan Cox wrote:

I'm also not aware of any reason other than history, which means if
someone cares to double check the other drivers there really shouldn't be
an obstacle to "fixing" this behaviour.

Unless anyone knows different ?


As long as the new behavior continues to call
driver->close() if driver->open() succeeds
then I see no problem.

If individual drivers are correctly doing internal
reference counting to handle driver->close() calls
without a preceding successful driver->open() call
(usually just doing nothing), then they should
continue to operate correctly without the extra
and unnecessary driver->close().

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

Re: I/O memory barriers vs SMP memory barriers

[Paul E. McKenney]

On Mon, Mar 26, 2007 at 10:46:39AM +0200, Lennert Buytenhek wrote:
> On Sun, Mar 25, 2007 at 08:24:18PM -0700, Paul E. McKenney wrote:
> 
> > > > > > [ background: On ARM, SMP synchronisation does need barriers but 
> > > > > > device
> > > > > >   synchronisation does not.  The question is that given this, 
> > > > > > whether
> > > > > >   mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> > > > > >   supposed to sync against other CPUs or not, or whether only 
> > > > > > smp_mb()
> > > > > >   can be used for this.)  ]
> > > > > 
> > > > > H...
> > > > > 
> > > > > [snip]
> > > > 
> > > > 3.  Orders memory accesses and device accesses, but not necessarily
> > > > the union of the two -- mb(), rmb(), wmb().
> > > 
> > > If mb/rmb/wmb are required to order normal memory accesses, that means
> > > that the change made in commit 9623b3732d11b0a18d9af3419f680d27ea24b014
> > > to always define mb/rmb/wmb as barrier() on ARM systems was wrong.
> > 
> > This was on UP ARM systems, right?
> 
> No.
> 
> If you look at commit 9623b3732d11b0a18d9af3419f680d27ea24b014, you can
> see that it defines mb/rmb/wmb as barrier() on both ARM UP and SMP systems.
> The UP part is obviously fine, the SMP part is what is under debate here.

Yep, looks wrong to me.

> > Assuming that ARM CPUs respect the usual CPU-self-consistency
> > semantics, and given the background that device accesses are ordered,
> > then it might well be OK to have mb/rmb/wmb be barrier() on UP ARM
> > systems.
> > 
> > Most likely not on SMP ARM systems, however.
> 
> Given the semantics above, mb/rmb/wmb can obviously be just barrier()s
> on ARM UP systems.. I don't think anyone ever disagreed about that.

Good.

> > > Does everybody agree on these semantics, though?  At least David
> > > seems to think that mb/rmb/wmb aren't required to order normal
> > > memory accesses against each other..
> > 
> > Not on UP.  On SMP, ordering is (almost certainly) required.
> 
> 'almost certainly'?  That sounds like there is a possibility that it
> wouldn't have to?  What does this depend on?

The underlying memory model of the CPU.  For sequentially consistent
systems, only compiler barriers are required.  There are very few such
systems -- MIPS and PA-RISC, if I remember correctly.  Performance
dictates otherwise.

I believe that MIPS is -not- sequentially consistent, but have not yet
purchased an architecture reference manual.

> At least David and Catalin seem to disagree with the statement
> that mb/rmb/wmb should order accesses from different CPUs.  And
> memory-barriers.txt is pretty vague about this..

mb() needs to do everything that smp_mb() does, ditto for rmb() and
wmb().  There really are cases where both I/O and memory accesses
need to be ordered, so just providing separate memory ordering and
I/O ordering is not enough.

Given that ARM device drivers are accessing MMIO locations, which are
often slow anyway, how much is ARM really gaining by dropping memory
barriers when only I/O accesses need be ordered?  Is it measurable?
If not, there is no point in adding yet another set of combinatorial
choices to the memory-barrier API.

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

Re: question on tty open and close

[Alan Cox]

> As long as the new behavior continues to call
> driver->close() if driver->open() succeeds
> then I see no problem.

It breaks if any existing driver is doing no cleanup in ->open() when it
fails but relying upon ->close() being called. That is what needs
auditing first of all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21-rc5

[Andi Kleen]

On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
> Linus Torvalds napisał(a):
> > There's various fixes here, ranging from some architecture updates (ia64, 
> > ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> > 
> > And random one-liners.
> > 
> 
> I found this in mm snapshot
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
> it's in mainline too.
> 
> Andi, any progress with this bug?

Can you test this patch please? 

-Andi

i386/x86-64: Convert nmi reservation to be global

It doesn't make much sense to have this per CPU, because all
the services using NMIs run on all CPUs. So make it global.

This also fixes a warning about unprotected use of smp_processor_id
on preemptible kernels.

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

Index: linux/arch/i386/kernel/nmi.c
===
--- linux.orig/arch/i386/kernel/nmi.c
+++ linux/arch/i386/kernel/nmi.c
@@ -41,8 +41,8 @@ int nmi_watchdog_enabled;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]);
+static unsigned long perfctr_nmi_owner;
+static unsigned long evntsel_nmi_owner[3];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 
@@ -124,7 +124,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+   return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */
@@ -135,7 +135,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+   return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -145,7 +145,7 @@ int reserve_perfctr_nmi(unsigned int msr
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+   if (!test_and_set_bit(counter, &perfctr_nmi_owner))
return 1;
return 0;
 }
@@ -157,7 +157,7 @@ void release_perfctr_nmi(unsigned int ms
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, &__get_cpu_var(perfctr_nmi_owner));
+   clear_bit(counter, &perfctr_nmi_owner);
 }
 
 int reserve_evntsel_nmi(unsigned int msr)
@@ -167,7 +167,7 @@ int reserve_evntsel_nmi(unsigned int msr
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]))
+   if (!test_and_set_bit(counter, &evntsel_nmi_owner[0]))
return 1;
return 0;
 }
@@ -179,7 +179,7 @@ void release_evntsel_nmi(unsigned int ms
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, &__get_cpu_var(evntsel_nmi_owner)[0]);
+   clear_bit(counter, &evntsel_nmi_owner[0]);
 }
 
 static __cpuinit inline int nmi_known_cpu(void)
Index: linux/arch/x86_64/kernel/nmi.c
===
--- linux.orig/arch/x86_64/kernel/nmi.c
+++ linux/arch/x86_64/kernel/nmi.c
@@ -39,8 +39,8 @@ int panic_on_unrecovered_nmi;
  *   different subsystems this reservation system just tries to coordinate
  *   things a little
  */
-static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner);
-static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]);
+static unsigned perfctr_nmi_owner;
+static unsigned evntsel_nmi_owner[2];
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 
@@ -110,7 +110,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
 {
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+   return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 /* checks the an msr for availability */
@@ -121,7 +121,7 @@ int avail_to_resrv_perfctr_nmi(unsigned 
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   return (!test_bit(counter, &__get_cpu_var(perfctr_nmi_owner)));
+   return (!test_bit(counter, &perfctr_nmi_owner));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -131,7 +131,7 @@ int reserve_perfctr_nmi(unsigned int msr
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, &__get_cpu_var(perfctr_nmi_owner)))
+   if (!test_and_set_bit(counter, &perfctr_nmi_owner))
return 1;
return 0;
 }
@@ -143,7 +143,7 @@ void release_perfctr_nmi(unsigned int ms
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_

Re: question on tty open and close

[Paul Fulghum]

Alan Cox wrote:

It breaks if any existing driver is doing no cleanup in ->open() when it
fails but relying upon ->close() being called. That is what needs
auditing first of all.


Yes, I did not think of that.

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

Re: question on tty open and close

[Kilau, Scott]

> > > > > So we have a file that's closed although open() never
succeeded?
> > > > 
> > > > That's correct! It's been a pain in my butt for years.
> > > 
> > > How did you deal with that proctological issue?
> > 
> > Just make sure the close() handles the situation properly. It makes
> > reference counting...  fun.
> > 
> > The serial driver has always handled it like this.
> 
> I'm also not aware of any reason other than history, which means if
> someone cares to double check the other drivers there really shouldn't
be
> an obstacle to "fixing" this behaviour.
> 
> Unless anyone knows different ?

Hi Alan!

>From our (Digi's) drivers history, I believe you tried "fixing" it back
in the Red Hat 7.1 days. =)

Sadly, our drivers still carry this legacy fix around.

o Red Hat 7.1 -- Kernel Compatibility Issues
 Some 2.4 kernel-based distributions (Red Hat 7.1 included) have
a patch
 applied to them which modifies the behavior of Linux when an
open of
 a serial port is canceled (for instance, if an application is
waiting
 for the carrier signal and a user hits CTRL-C to kill the
application)

 With this behavior change, the device driver is unable to
cleanup its
 internal data structures and the sane functioning of the driver
is
 compromised.  The classic symptom of this problem is that the
command
 "lsmod", which (among other things) will return a count of the
 applications using the device driver, will return a non-zero
value
 even if all applications associated with the serial ports
 are killed.   

 Unfortunately, it is impossible (from within the device driver)
to
 determine which behavior is implemented in the running kernel.
 However, Digi now provides a workaround to allow customers with
this
 problem to change the Digi behavior to be compatible with these
 "patched" kernels.


I know backwards compatibility in the kernel isn't a concern at all,
which has been made abundantly clear, (ie, stable_api_nonsense.txt),
but this will impact *all* out of tree serial drivers.

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

Re: question on tty open and close

[Marcel Holtmann]

Hi Alan,

> > As long as the new behavior continues to call
> > driver->close() if driver->open() succeeds
> > then I see no problem.
> 
> It breaks if any existing driver is doing no cleanup in ->open() when it
> fails but relying upon ->close() being called. That is what needs
> auditing first of all.

I know at least that the Bluetooth TTY emulation (RFCOMM) will break
since I have a big fat warning in my code:

/* We don't leak this refcount. For reasons which are not entirely
   clear, the TTY layer will call our ->close() method even if the
   open fails. We decrease the refcount there, and decreasing it
   here too would cause breakage. */
dev = rfcomm_dev_get(id);
if (!dev)
return -ENODEV;

Regards

Marcel


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

Re: Linux 2.6.21-rc5

[Michal Piotrowski]

Andi Kleen napisał(a):
> On Tuesday 27 March 2007 20:53, Michal Piotrowski wrote:
>> Linus Torvalds napisał(a):
>>> There's various fixes here, ranging from some architecture updates (ia64, 
>>> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>>
>>> And random one-liners.
>>>
>> I found this in mm snapshot
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/1367.html
>> it's in mainline too.
>>
>> Andi, any progress with this bug?
> 
> Can you test this patch please? 
> 

BUG: using smp_processor_id() in preemptible [0001] code: mount/7245 
is fixed, thanks.


but I still get this

[  208.523901] =
[  208.529739] [ INFO: inconsistent lock state ]
[  208.534087] 2.6.21-rc5-g28defbea-dirty #131
[  208.538260] -
[  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  208.553553]  (oprofilefs_lock){+-..}, at: [] 
nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.561800] {hardirq-on-W} state was registered at:
[  208.55]   [] __lock_acquire+0x442/0xba1
[  208.571765]   [] lock_acquire+0x68/0x82
[  208.576519]   [] _spin_lock+0x35/0x42
[  208.581102]   [] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile]
[  208.588026]   [] ulong_write_file+0x2a/0x38 [oprofile]
[  208.594084]   [] vfs_write+0xaf/0x138
[  208.598658]   [] sys_write+0x3d/0x61
[  208.603171]   [] syscall_call+0x7/0xb
[  208.607751]   [] 0x
[  208.611478] irq event stamp: 575782
[  208.614960] hardirqs last  enabled at (575781): [] 
default_idle+0x3e/0x59
[  208.622645] hardirqs last disabled at (575782): [] 
call_function_interrupt+0x29/0x38
[  208.631281] softirqs last  enabled at (575768): [] 
__do_softirq+0xe4/0xea
[  208.638965] softirqs last disabled at (575759): [] 
do_softirq+0x64/0xd1
[  208.646478]
[  208.646479] other info that might help us debug this:
[  208.653003] no locks held by swapper/0.
[  208.656832]
[  208.656833] stack backtrace:
[  208.661199]  [] show_trace_log_lvl+0x1a/0x2f
[  208.666350]  [] show_trace+0x12/0x14
[  208.670811]  [] dump_stack+0x16/0x18
[  208.675272]  [] print_usage_bug+0x140/0x14a
[  208.680336]  [] mark_lock+0xa1/0x40b
[  208.684796]  [] __lock_acquire+0x3b3/0xba1
[  208.689775]  [] lock_acquire+0x68/0x82
[  208.694410]  [] _spin_lock+0x35/0x42
[  208.698869]  [] nmi_cpu_setup+0x15/0x4f [oprofile]
[  208.704540]  [] smp_call_function_interrupt+0x3a/0x56
[  208.710470]  [] call_function_interrupt+0x33/0x38
[  208.716053]  [] cpu_idle+0xb6/0xeb
[  208.720342]  [] start_secondary+0x333/0x33b
[  208.725407]  [<>] 0x0
[  208.728397]  ===


Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: miniroot ramdisk corruption during intense memory usage

[Phillip Susi]

Peter Bier wrote:

The following sympthom occured in a variant of the Knoppix-like linux appliance.

I get a corrupted miniroot ramdisk filesystem under kernel version 2.6.19.1 under intense memory usage during early startup of the system. 

In the course of a lengthy investigation of this behavior, I found out that the memory pages containing the miniroot ramdisk are freed during the initial installation 

process due to a memory shortage. It turned out, that shrink_active_list() calls pagevec_strip(), which in turn calls try_to_release_page() which finally calls try_to_free_buffers() which drops the corresponding buffers; if this succeeds, it seems to cause the page to become freed later. 


This causes pointers of indirect blocks of the filesystem of the miniroot 
ramdisk to be replaced by zero-filled pages later in the the system's history.

I fixed this by adding a new flag PG_ramdisk in the include file page-flags.h, setting the flag during ramdisk loading in ramdisk_commit_write() and checking for the flag in try_to_free_buffers() and retruning 0 as result immediately without freeing the buffers. 


I am not aware if that is the adequate way to solve the problem or if there is 
a solution that requires fewer and more localized changes of the system, 
avoiding to give the ramdisk pages a specific treatment

 

 

I did not observe this problem prior to kernel version 2.6.19.1, but I'm not sure whether ths was simply caused by coincidental circumstances during startup. 




The ramdisk driver already marks the pages as "do not discard".  Maybe 
you should investigate why that is no longer being respected?

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

Re: Corrupt XFS -Filesystems on new Hardware and Kernel

[Eric Sandeen]

Oliver Joa wrote:

Ok, here is a test:

test:/# find / -xdev | cpio -padm /test/
cpio: /usr/src/linux-2.6.20.2/Documentation/networking/NAPI_HOWTO.txt: 
Structure needs cleaning

3648371 blocks
test:/#


That, cryptically enough, means that the filesystem has detected a 
problem and has shut down.



test:/home/olli# uname -a
Linux test 2.6.20.4-majestix-1 #1 SMP PREEMPT Tue Mar 27 12:15:41 CEST 
2007 i686 GNU/Linux


dmesg gives the following:
[15442.935941] Filesystem "sda3": XFS internal error xfs_iformat(6) at 
line 492 of file fs/xfs/xfs_inode.c.  Caller 0xc0211f94

[15442.936003]  [] xfs_iread+0x4ee/0x6e8
[15442.936039]  [] xfs_iget+0x2e4/0x714
[15442.936071]  [] xfs_iget+0x2e4/0x714
[15442.936101]  [] xfs_dir_lookup_int+0x7d/0xd4
[15442.936135]  [] xfs_lookup+0x52/0x78
[15442.936167]  [] xfs_vn_lookup+0x3b/0x70
[15442.936201]  [] do_lookup+0xa3/0x140
[15442.936234]  [] __link_path_walk+0x73d/0xb5e
[15442.936278]  [] xfs_iunlock+0x51/0x6d
[15442.936309]  [] link_path_walk+0x44/0xb3
[15442.936342]  [] do_path_lookup+0x176/0x191
[15442.936373]  [] getname+0x59/0x8f
[15442.936402]  [] __user_walk_fd+0x2f/0x45
[15442.936431]  [] vfs_lstat_fd+0x16/0x3d
[15442.936461]  [] sys_lstat64+0xf/0x23
[15442.936490]  [] syscall_call+0x7/0xb
[15442.936519]  ===


For one reason or another, xfs has detected a corrupted on-disk inode 
format which it cannot recognize, and shuts down.  It is likely the 
result of something which has gone wrong previously.  xfs_repair should 
fix it.  Are there other non-xfs messages in your logs indicating other 
problems prior to this?


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

oracle sqlplus loop on 2.6.20

[Marco Berizzi]

Hello everybody.
I'm running oracle 10.2.0.1 on Slackware Linux 10.2
After 50 days uptime, sqlplus was looping forever.
I have killed all oracle processes and cleared all
semaphore and shared memory segment with ipcrm.
I have also unmounted & remounted the file system
where the oracle binaries and library resides,
but no luck. I have to do a shutdown.
This is the output from 'strace sqlplus'.
Any hint?

TIA

execve("/u01/app/oracle/product/10.2.0.1/bin/sqlplus", ["sqlplus"], [/*
39 vars */]) = 0
uname({sys="Linux", node="Tethys", ...}) = 0
brk(0)  = 0x804a000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
open("/u01/app/oracle/product/10.2.0.1/lib/tls/i686/sse2/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/tls/i686/sse2", 0xbfaed0c0)
= -1 ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/tls/i686/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/tls/i686", 0xbfaed0c0) = -1
ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/tls/sse2/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/tls/sse2", 0xbfaed0c0) = -1
ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/tls/libsqlplus.so", O_RDONLY)
= -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/tls", 0xbfaed0c0) = -1
ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/i686/sse2/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/i686/sse2", 0xbfaed0c0)
= -1 ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/i686/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/i686", 0xbfaed0c0) = -1
ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/sse2/libsqlplus.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/u01/app/oracle/product/10.2.0.1/lib/sse2", 0xbfaed0c0) = -1
ENOENT (No such file or directory)
open("/u01/app/oracle/product/10.2.0.1/lib/libsqlplus.so", O_RDONLY) = 3
read(3, "[EMAIL PROTECTED]"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0640, st_size=1047293, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe4000
mmap2(NULL, 728168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7f32000
mmap2(0xb7fdb000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa8) = 0xb7fdb000
close(3)= 0
open("/u01/app/oracle/product/10.2.0.1/lib/libclntsh.so.10.1", O_RDONLY)
= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\306"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0750, st_size=18440031, ...}) = 0
mmap2(NULL, 14298152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb718f000
mmap2(0xb7ebd000, 397312, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd2e) = 0xb7ebd000
mmap2(0xb7f1e000, 80936, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f1e000
close(3)= 0
open("/u01/app/oracle/product/10.2.0.1/lib/libnnz10.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3006\6"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0640, st_size=5480533, ...}) = 0
mmap2(NULL, 2110644, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb6f8b000
mmap2(0xb7167000, 155648, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1dc) = 0xb7167000
mmap2(0xb718d000, 5300, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb718d000
close(3)= 0
open("/u01/app/oracle/product/10.2.0.1/lib/libdl.so.2", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53426, ...}) = 0
mmap2(NULL, 53426, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f7d000
close(3)= 0
open("/lib/tls/libdl.so.2", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\v\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=13120, ...}) = 0
mmap2(NULL, 12392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb6f79000
mmap2(0xb6f7b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb6f7b000
close(3)= 0
open("/u01/app/oracle/product/10.2.0.1/lib/libm.so.6", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/lib/tls/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P3\0\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=176352, ...}) = 0
mmap2(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb6f56000
mmap2(0xb6f77000, 8192,

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

[Williams, Mitch A]

Eric W. Biederman wrote:
>The practical question in my book is do we set the enable/disable
>methods to the same functions as the mask/unmask methods or
>do we let them default to the crazy delayed disable scenario.
>
>Given that we do have a tiny race where we need to ensure the
>MSI is disabled before we unregister it, we don't know of any
>MSI implementation problems that will result in a screaming IRQ.
>I would say set enable/disable to the mask/unmask methods.
>

OK, that's easy.  I'll whip up a patch today, test it overnight,
and post it tomorrow.

Thanks for looking at this.

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

Re: oracle sqlplus loop on 2.6.20

[Lee Revell]

On 3/28/07, Marco Berizzi <[EMAIL PROTECTED]> wrote:

Hello everybody.
I'm running oracle 10.2.0.1 on Slackware Linux 10.2
After 50 days uptime, sqlplus was looping forever.
I have killed all oracle processes and cleared all
semaphore and shared memory segment with ipcrm.
I have also unmounted & remounted the file system
where the oracle binaries and library resides,
but no luck. I have to do a shutdown.
This is the output from 'strace sqlplus'.
Any hint?


Why do you think it's a kernel issue?  Sounds like an Oracle bug to me...

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

Re: oracle sqlplus loop on 2.6.20

[Marco Berizzi]

Lee Revell wrote:

> On 3/28/07, Marco Berizzi <[EMAIL PROTECTED]> wrote:
> > Hello everybody.
> > I'm running oracle 10.2.0.1 on Slackware Linux 10.2
> > After 50 days uptime, sqlplus was looping forever.
> > I have killed all oracle processes and cleared all
> > semaphore and shared memory segment with ipcrm.
> > I have also unmounted & remounted the file system
> > where the oracle binaries and library resides,
> > but no luck. I have to do a shutdown.
> > This is the output from 'strace sqlplus'.
> > Any hint?
>
> Why do you think it's a kernel issue?  Sounds like an Oracle bug to
me...

indeed. I'm becoming very small small small...
Sorry for the spam.
JFYI: there is bug in oracle when the machine
reaches 248 days uptime. (doc id 338461.1)
Sorry 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 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile

[Lee Schermerhorn]

PATCH 2.6.21-rc5-mm2:  add compile.h dependency for missing_syscalls.o

Add a dependency on include/linux/compile.h to missing_syscalls.o
target in init/Makefile.  Without this, [ia64] build fails with:

init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or directory
In file included from init/missing_syscalls.c:97:

Signed-off-by:  Lee Schermerhorn <[EMAIL PROTECTED]>

 init/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: Linux/init/Makefile
===
--- Linux.orig/init/Makefile2007-03-28 10:44:14.0 -0400
+++ Linux/init/Makefile 2007-03-28 11:02:59.0 -0400
@@ -21,7 +21,7 @@ clean-files := ../include/linux/compile.
 # dependencies on generated files need to be listed explicitly
 
 $(obj)/version.o: include/linux/compile.h
-$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h
+$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h include/linux/compile.h
 
 # compile.h changes depending on hostname, generation number, etc,
 # so we regenerate it always.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]: Resubmit Fix bogus softlockup warning with sysrq-t

[Prarit Bhargava]

New patch to replace

fix-bogus-softlockup-warning-with-sysrq-t.patch in -mm tree.

(Andi Kleen set me straight on the the touch_nmi_watchdog issue below.  I
should reset the softlockup watchdog for the calling cpu, not all of them
as I had originally coded before).

Please re-ack ...

P.
--
There are some situations when soft lockup warnings are expected in the
kernel.  For example, when doing an alt-sysrq-t on a large number of processes,
the dump to console can take a long time and the tasklist_lock is held over
that period.  This results in a bogus soft lockup warning.

This patch reworks touch_softlockup_watchdog to touch ALL cpu's
touch_timestamp.  It also introduces touch_cpu_softlockup_watchdog to touch
a single cpu's touch_timestamp.  This makes it functionally equivalent to
touch_nmi_watchdog (suggestion by davej).

nmi_watchdog is modified to touch only a single cpu's softlockup watchdog
(suggestion by Andi Kleen).

/drivers/ide/ide-iops.c does not need to call touch_softlockup_watchdog as it
is done in the call to touch_nmi_watchdog.

The EXPORT_SYMBOL for touch_softlockup_watchdog is needed by
drivers/scsi/ips.ko

Acked-by: Chris Lalancette <[EMAIL PROTECTED]>
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c
index 1470242..864399e 100644
--- a/arch/i386/kernel/nmi.c
+++ b/arch/i386/kernel/nmi.c
@@ -928,7 +928,7 @@ void touch_nmi_watchdog (void)
/*
 * Tickle the softlockup detector too:
 */
-   touch_softlockup_watchdog();
+   touch_cpu_softlockup_watchdog();
 }
 EXPORT_SYMBOL(touch_nmi_watchdog);
 
diff --git a/arch/ia64/kernel/uncached.c b/arch/ia64/kernel/uncached.c
index c58e933..db514bb 100644
--- a/arch/ia64/kernel/uncached.c
+++ b/arch/ia64/kernel/uncached.c
@@ -254,7 +254,7 @@ static int __init uncached_build_memmap(unsigned long 
uc_start,
struct gen_pool *pool = uncached_pools[nid].pool;
size_t size = uc_end - uc_start;
 
-   touch_softlockup_watchdog();
+   touch_cpu_softlockup_watchdog();
 
if (pool != NULL) {
memset((char *)uc_start, 0, size);
diff --git a/arch/x86_64/kernel/nmi.c b/arch/x86_64/kernel/nmi.c
index 82d9d85..ed7ec1f 100644
--- a/arch/x86_64/kernel/nmi.c
+++ b/arch/x86_64/kernel/nmi.c
@@ -811,7 +811,7 @@ void touch_nmi_watchdog (void)
per_cpu(nmi_touch, cpu) = 1;
}
 
-   touch_softlockup_watchdog();
+   touch_cpu_softlockup_watchdog();
 }
 
 int __kprobes nmi_watchdog_tick(struct pt_regs * regs, unsigned reason)
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index 1ee53a5..ff488e2 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -1232,7 +1232,6 @@ int ide_wait_not_busy(ide_hwif_t *hwif, unsigned long 
timeout)
 */
if (stat == 0xff)
return -ENODEV;
-   touch_softlockup_watchdog();
touch_nmi_watchdog();
}
return -EBUSY;
diff --git a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
index 30175c7..5fb2dce 100644
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -313,7 +313,7 @@ static void ide_pio_datablock(ide_drive_t *drive, struct 
request *rq,
if (rq->bio)/* fs request */
rq->errors = 0;
 
-   touch_softlockup_watchdog();
+   touch_cpu_softlockup_watchdog();
 
switch (drive->hwif->data_phase) {
case TASKFILE_MULTI_IN:
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 6af37b8..9669d5f 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -425,7 +425,7 @@ void nand_wait_ready(struct mtd_info *mtd)
do {
if (chip->dev_ready(mtd))
break;
-   touch_softlockup_watchdog();
+   touch_cpu_softlockup_watchdog();
} while (time_before(jiffies, timeo));
led_trigger_event(nand_led_trigger, LED_OFF);
 }
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 49fe299..113421e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -225,6 +225,7 @@ extern void scheduler_tick(void);
 #ifdef CONFIG_DETECT_SOFTLOCKUP
 extern void softlockup_tick(void);
 extern void spawn_softlockup_task(void);
+extern void touch_cpu_softlockup_watchdog(void);
 extern void touch_softlockup_watchdog(void);
 #else
 static inline void softlockup_tick(void)
@@ -233,6 +234,9 @@ static inline void softlockup_tick(void)
 static inline void spawn_softlockup_task(void)
 {
 }
+static inline void touch_cpu_softlockup_watchdog(void)
+{
+}
 static inline void touch_softlockup_watchdog(void)
 {
 }
diff --git a/kernel/panic.c b/kernel/panic.c
index 623d182..9e4565c 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -132,7 +132,7 @@ NORET_TYPE void panic(const char * fmt, ...)
 #endif
local_irq_enable();
for (i = 0;;) {
-   touch_softlockup_watchdo

Re: [PATCH] USB Elan FTDI: check for driver registration status

[Cyrill Gorcunov]

Pete, Luiz

check this one please.

I've inspected ftdi-elan.c for style and as result
the solution I propose is just to add explicit
destroying of worqueues if usb_register failed.

And Pete, take a look - whoa! - I've renamed error labels :)


Cyrill

---

 drivers/usb/misc/ftdi-elan.c |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index bc3327e..d9cbdb8 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -2910,24 +2910,28 @@ static int __init ftdi_elan_init(void)
 INIT_LIST_HEAD(&ftdi_static_list);
 status_queue = create_singlethread_workqueue("ftdi-status-control");
if (!status_queue)
-   goto err1;
+   goto err_status_queue;
 command_queue = create_singlethread_workqueue("ftdi-command-engine");
if (!command_queue)
-   goto err2;
+   goto err_command_queue;
 respond_queue = create_singlethread_workqueue("ftdi-respond-engine");
if (!respond_queue)
-   goto err3;
+   goto err_respond_queue;
 result = usb_register(&ftdi_elan_driver);
-if (result)
+if (result) {
+   destroy_workqueue(status_queue);
+   destroy_workqueue(command_queue);
+   destroy_workqueue(respond_queue);
 printk(KERN_ERR "usb_register failed. Error number %d\n",
   result);
+   }
 return result;
 
- err3:
+ err_respond_queue:
destroy_workqueue(command_queue);
- err2:
+ err_command_queue:
destroy_workqueue(status_queue);
- err1:
+ err_status_queue:
printk(KERN_ERR "%s couldn't create workqueue\n", 
ftdi_elan_driver.name);
return -ENOMEM;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sched: staircase deadline misc fixes

[Con Kolivas]

test.kernel.org found some idle time regressions in the latest update to the
staircase deadline scheduler and Andy Whitcroft helped me track down the 
offending problem which was present in all previous RSDL schedulers but
previously wouldn't be manifest without changes in nice. So here is a bugfix
for the set_load_weight being incorrectly set and a few other minor 
improvements. Thanks Andy!

I'm cautiously optimistic that we're at the thin edge of the bugfix wedge now.

---
set_load_weight() should be performed after p->quota is set. This fixes a
large SMP performance regression.

Make sure rr_interval is never set to less than one jiffy.

Some sanity checking in update_cpu_clock will prevent bogus sched_clock
values.

SCHED_BATCH tasks should not set the rq->best_static_prio field.

Correct sysctl rr_interval description to describe the value in milliseconds.

Style fixes.

Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>

---
 Documentation/sysctl/kernel.txt |8 ++--
 kernel/sched.c  |   73 +---
 2 files changed, 58 insertions(+), 23 deletions(-)

Index: linux-2.6.21-rc5-mm2/kernel/sched.c
===
--- linux-2.6.21-rc5-mm2.orig/kernel/sched.c2007-03-28 09:01:03.0 
+1000
+++ linux-2.6.21-rc5-mm2/kernel/sched.c 2007-03-29 00:02:33.0 +1000
@@ -88,10 +88,13 @@ unsigned long long __attribute__((weak))
 #define MAX_USER_PRIO  (USER_PRIO(MAX_PRIO))
 #define SCHED_PRIO(p)  ((p)+MAX_RT_PRIO)
 
-/* Some helpers for converting to/from nanosecond timing */
+/* Some helpers for converting to/from various scales.*/
 #define NS_TO_JIFFIES(TIME)((TIME) / (10 / HZ))
-#define NS_TO_MS(TIME) ((TIME) / 100)
+#define JIFFIES_TO_NS(TIME)((TIME) * (10 / HZ))
 #define MS_TO_NS(TIME) ((TIME) * 100)
+/* Can return 0 */
+#define MS_TO_JIFFIES(TIME)((TIME) * HZ / 1000)
+#define JIFFIES_TO_MS(TIME)((TIME) * 1000 / HZ)
 
 #define TASK_PREEMPTS_CURR(p, curr)((p)->prio < (curr)->prio)
 
@@ -852,16 +855,15 @@ static void requeue_task(struct task_str
 
 /*
  * task_timeslice - the total duration a task can run during one major
- * rotation.
+ * rotation. Returns value in jiffies.
  */
 static inline int task_timeslice(struct task_struct *p)
 {
-   int slice, rr;
+   int slice;
 
-   slice = rr = p->quota;
+   slice = NS_TO_JIFFIES(p->quota);
if (!rt_task(p))
-   slice += (PRIO_RANGE - 1 - TASK_USER_PRIO(p)) * rr;
-   slice = NS_TO_JIFFIES(slice) ? : 1;
+   slice += (PRIO_RANGE - 1 - TASK_USER_PRIO(p)) * slice;
return slice;
 }
 
@@ -875,7 +877,7 @@ static inline int task_timeslice(struct 
(((lp) * SCHED_LOAD_SCALE) / TIME_SLICE_NICE_ZERO)
 #define TASK_LOAD_WEIGHT(p)LOAD_WEIGHT(task_timeslice(p))
 #define RTPRIO_TO_LOAD_WEIGHT(rp)  \
-   (LOAD_WEIGHT((rr_interval + 20 + (rp
+   (LOAD_WEIGHT((MS_TO_JIFFIES(rr_interval) + 20 + (rp
 
 static void set_load_weight(struct task_struct *p)
 {
@@ -973,11 +975,15 @@ static int effective_prio(struct task_st
  * tick still. Below nice 0 they get progressively larger.
  * ie nice -6..0 = rr_interval. nice -10 = 2.5 * rr_interval
  * nice -20 = 10 * rr_interval. nice 1-19 = rr_interval / 2.
+ * Value returned is in nanoseconds.
  */
 static unsigned int rr_quota(struct task_struct *p)
 {
int nice = TASK_NICE(p), rr = rr_interval;
 
+   /* Ensure that rr_interval is at least 1 tick */
+   if (unlikely(!MS_TO_JIFFIES(rr)))
+   rr = rr_interval = JIFFIES_TO_MS(1) ? : 1;
if (!rt_task(p)) {
if (nice < -6) {
rr *= nice * nice;
@@ -3198,13 +3204,34 @@ EXPORT_PER_CPU_SYMBOL(kstat);
 /*
  * This is called on clock ticks and on context switches.
  * Bank in p->sched_time the ns elapsed since the last tick or switch.
+ * CPU scheduler quota accounting is also performed here.
+ * The value returned from sched_clock() occasionally gives bogus values so
+ * some sanity checking is required.
  */
 static inline void
-update_cpu_clock(struct task_struct *p, struct rq *rq, unsigned long long now)
+update_cpu_clock(struct task_struct *p, struct rq *rq, unsigned long long now,
+int tick)
 {
cputime64_t time_diff = now - p->last_ran;
+   unsigned int min_diff = 1000;
 
-   /* cpu scheduler quota accounting is performed here */
+   if (tick) {
+   /*
+* Called from scheduler_tick() there should be less than two
+* jiffies worth, and not negative/overflow.
+*/
+   if (time_diff > JIFFIES_TO_NS(2) || time_diff < min_diff)
+   time_diff = JIFFIES_TO_NS(1);
+   } else {
+   /*
+* Called from context_switch there should be less than one
+* jiffy worth, and not negative/overflowed. In

Re: Linux 2.6.21-rc5

[Jiri Kosina]

On Wed, 28 Mar 2007, Michal Piotrowski wrote:

> BUG: using smp_processor_id() in preemptible [0001] code: mount/7245 
> is fixed, thanks.
> but I still get this
> [  208.523901] =
> [  208.529739] [ INFO: inconsistent lock state ]
> [  208.534087] 2.6.21-rc5-g28defbea-dirty #131
> [  208.538260] -
> [  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
> [  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:

Perhaps something like the one below?


From: Jiri Kosina <[EMAIL PROTECTED]>

oprofile: fix potential deadlock on oprofilefs_lock

nmi_cpu_setup() is called from hardirq context and acquires oprofilefs_lock.
alloc_event_buffer() and oprofilefs_ulong_from_user() acquire this lock
without disabling irqs, which could deadlock.

Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>

 drivers/oprofile/event_buffer.c |5 +++--
 drivers/oprofile/oprofilefs.c   |5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/oprofile/event_buffer.c b/drivers/oprofile/event_buffer.c
index 00e937e..e7fbac5 100644
--- a/drivers/oprofile/event_buffer.c
+++ b/drivers/oprofile/event_buffer.c
@@ -70,11 +70,12 @@ void wake_up_buffer_waiter(void)
 int alloc_event_buffer(void)
 {
int err = -ENOMEM;
+   unsigned long flags;
 
-   spin_lock(&oprofilefs_lock);
+   spin_lock_irqsave(&oprofilefs_lock, flags);
buffer_size = fs_buffer_size;
buffer_watershed = fs_buffer_watershed;
-   spin_unlock(&oprofilefs_lock);
+   spin_unlock_irqrestore(&oprofilefs_lock, flags);
  
if (buffer_watershed >= buffer_size)
return -EINVAL;
diff --git a/drivers/oprofile/oprofilefs.c b/drivers/oprofile/oprofilefs.c
index 6e67b42..8543cb2 100644
--- a/drivers/oprofile/oprofilefs.c
+++ b/drivers/oprofile/oprofilefs.c
@@ -65,6 +65,7 @@ ssize_t oprofilefs_ulong_to_user(unsigned long val, char 
__user * buf, size_t co
 int oprofilefs_ulong_from_user(unsigned long * val, char const __user * buf, 
size_t count)
 {
char tmpbuf[TMPBUFSIZE];
+   unsigned long flags;
 
if (!count)
return 0;
@@ -77,9 +78,9 @@ int oprofilefs_ulong_from_user(unsigned long * val, char 
const __user * buf, siz
if (copy_from_user(tmpbuf, buf, count))
return -EFAULT;
 
-   spin_lock(&oprofilefs_lock);
+   spin_lock_irqsave(&oprofilefs_lock, flags);
*val = simple_strtoul(tmpbuf, NULL, 0);
-   spin_unlock(&oprofilefs_lock);
+   spin_unlock_irqrestore(&oprofilefs_lock, flags);
return 0;
 }

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

Re: [RFC] Virtual methods for devices and generalized GPIO support using it

[H. Peter Anvin]

Paul Sokolovsky wrote:


In this respect, VTABLE(), METHOD() macros serve the same purpose as 
container_of() and list_for_each() - they are besides offering (more) 
convenient syntax, also carry important annotattion and educational
messages, like "it's ok, and encouraged to embed one structure into 
another - use it!" or "list manipulation is a trivial operation for kernel,
and we want you to treat it as such and use in standard, easily 
distinguishable way".




You realize, right, that the Linux kernel already have a much cleaner 
way to do vtables in the kernel, without this kind of macro crappage? 
It's called an _ops table, and is used in a patternized way:


foo->x_ops->func(foo, ...);

... all over the kernel.  We like it that way.

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

Re: 2.6.21-rc5-mm1

[Mariusz Kozłowski]

Hello,

I run 2.6.21-rc4-mm1 with no hangs for a week.
Then when 2.6.21-rc5-mm1 showed up so I switched to it. Unfortunately
today my laptop hunged twice in a similar way as described here:

http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/index.html#1165

The difference is that it happened when I closed the lid in my laptop.
When reopend it the box was frozen (ACPI?). Again disk I/O was dead
so nothing was found in syslog.

I tried to reproduce it and capture something with netconsole.
I tortured the box for a few hours but the system did not hang. I pushed
the box real hard and what I got was only oom-killer firing etc ;-)
Anyway I found something else you might be interested in:



1) This happened when 'echo 3 > /proc/sys/vm/drop_caches' on really
   busy system.

 ===
 [ INFO: possible circular locking dependency detected ]
 2.6.21-rc5-mm1 #1
 ---
 bash/20633 is trying to acquire lock:
  (&journal->j_list_lock){--..}, at: [] 
journal_try_to_free_buffers+0x151/0x1bc
 
 but task is already holding lock:
  (inode_lock){--..}, at: [] drop_pagecache+0x58/0xf9
 
 which lock already depends on the new lock.
 
 
 the existing dependency chain (in reverse order) is:
 
 -> #1 (inode_lock){--..}:
[] __lock_acquire+0xe31/0xfe9
[] lock_acquire+0x69/0x83
[] _spin_lock+0x35/0x42
[] __mark_inode_dirty+0x4f/0x163
[] __set_page_dirty_nobuffers+0x99/0xf5
[] mark_buffer_dirty+0x1f/0x25
[] __journal_temp_unlink_buffer+0x88/0x1a8
[] __journal_unfile_buffer+0xb/0x15
[] __journal_refile_buffer+0xed/0xef
[] journal_commit_transaction+0xd8b/0x127f
[] kjournald+0xac/0x1ed
[] kthread+0xa2/0xc9
[] kernel_thread_helper+0x7/0x18
[] 0x
 
 -> #0 (&journal->j_list_lock){--..}:
[] __lock_acquire+0xc9a/0xfe9
[] lock_acquire+0x69/0x83
[] _spin_lock+0x35/0x42
[] journal_try_to_free_buffers+0x151/0x1bc
[] ext3_releasepage+0x3f/0x76
[] try_to_release_page+0x2f/0x4a
[] invalidate_mapping_pages+0xb6/0xee
[] drop_pagecache+0xa6/0xf9
[] drop_caches_sysctl_handler+0x54/0x69
[] proc_sys_write+0x80/0x8a
[] vfs_write+0x8b/0x11f
[] sys_write+0x3d/0x64
[] sysenter_past_esp+0x5d/0x99
[] 0x
 
 other info that might help us debug this:
 
 2 locks held by bash/20633:
  #0:  (&type->s_umount_key#16){}, at: [] drop_pagecache+0x47/0xf9
  #1:  (inode_lock){--..}, at: [] drop_pagecache+0x58/0xf9
 
 stack backtrace:
  [] show_trace_log_lvl+0x1a/0x30
  [] show_trace+0x12/0x14
  [] dump_stack+0x16/0x18
  [] print_circular_bug_tail+0x68/0x71
  [] __lock_acquire+0xc9a/0xfe9
  [] lock_acquire+0x69/0x83
  [] _spin_lock+0x35/0x42
  [] journal_try_to_free_buffers+0x151/0x1bc
  [] ext3_releasepage+0x3f/0x76
  [] try_to_release_page+0x2f/0x4a
  [] invalidate_mapping_pages+0xb6/0xee
  [] drop_pagecache+0xa6/0xf9
  [] drop_caches_sysctl_handler+0x54/0x69
  [] proc_sys_write+0x80/0x8a
  [] vfs_write+0x8b/0x11f
  [] sys_write+0x3d/0x64
  [] sysenter_past_esp+0x5d/0x99
 ===



2) This was found a couple minutes later when the system was
   really busy and close to oom condition.

 INFO: lockdep is turned off.
 BUG: soft lockup detected on CPU#0!
  [] show_trace_log_lvl+0x1a/0x30
  [] show_trace+0x12/0x14
  [] dump_stack+0x16/0x18
  [] softlockup_tick+0x81/0xa8
  [] run_local_timers+0x12/0x14
  [] update_process_times+0x2b/0x63
  [] tick_sched_timer+0x4d/0x9e
  [] hrtimer_interrupt+0x12e/0x1a6
  [] timer_interrupt+0xe/0x15
  [] handle_IRQ_event+0x28/0x59
  [] handle_level_irq+0x6e/0xe7
  [] do_IRQ+0x3d/0x7f
  [] common_interrupt+0x2e/0x34
  [] do_softirq+0x4d/0x50
  [] irq_exit+0x7e/0x80
  [] do_IRQ+0x42/0x7f
  [] common_interrupt+0x2e/0x34
  [] core_sys_select+0x1c6/0x310
  [] sys_select+0x39/0x18f
  [] sysenter_past_esp+0x5d/0x99
  ===
 Clocksource tsc unstable (delta = 9372804176 ns)
 Time: acpi_pm clocksource has been installed.

Please find .config attached. Not sure who to CC on this (as usual ;-)).

Regards,

Mariusz Kozlowski
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc5-mm1
# Tue Mar 27 07:33:50 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

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

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFI

[Patch -mm] integrity: ima identifiers

[Mimi Zohar]

This patch corrects the naming of global and other identifiers.

signed-off-by: Mimi Zohar <[EMAIL PROTECTED]>
signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
---

---
 security/evm/ima/ima.h   |   24 
 security/evm/ima/ima_fs.c|   18 +-
 security/evm/ima/ima_init.c  |   10 +-
 security/evm/ima/ima_main.c  |8 
 security/evm/ima/ima_queue.c |   24 
 5 files changed, 42 insertions(+), 42 deletions(-)

Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima.h
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/ima/ima.h
+++ linux-2.6.21-rc5-mm2/security/evm/ima/ima.h
@@ -34,26 +34,26 @@
 
 /* digest size for IMA, fits SHA1 or MD5 */
 #define IMA_DIGEST_SIZE20
-#define TCG_EVENT_NAME_LEN_MAX 255
+#define IMA_EVENT_NAME_LEN_MAX 255
 
 #define IMA_HASH_BITS 9
-#define MEASURE_HTABLE_SIZE (1 << IMA_HASH_BITS)
-#define HASH_KEY(digest) (hash_long( \
+#define IMA_MEASURE_HTABLE_SIZE (1 << IMA_HASH_BITS)
+#define IMA_HASH_KEY(digest) (hash_long( \
(unsigned long)(*digest), IMA_HASH_BITS));
 
 /* set during initialization */
 extern int ima_used_chip;
 
-struct measure_entry {
+struct ima_measure_entry {
u32 measure_flags;
u8 digest[IMA_DIGEST_SIZE]; /* sha1 or md5 measurement hash */
-   char file_name[TCG_EVENT_NAME_LEN_MAX + 1]; /* name + \0 */
+   char file_name[IMA_EVENT_NAME_LEN_MAX + 1]; /* name + \0 */
 };
 
-struct queue_entry {
+struct ima_queue_entry {
struct hlist_node hnext;/* place in hash collision list */
struct list_head later; /* place in ima_measurements list */
-   struct measure_entry *entry;
+   struct ima_measure_entry *entry;
 };
 
 extern struct list_head ima_measurements;  /* list of all measurements */
@@ -61,10 +61,10 @@ extern struct list_head ima_measurements
 /* declarations */
 int ima_fs_init(void);
 void ima_fs_cleanup(void);
-void create_htable(void);
+void ima_create_htable(void);
 void ima_invalidate_pcr(char *);
-int ima_add_measure_entry(struct measure_entry *entry);
-struct queue_entry *ima_lookup_digest_entry(u8 * digest);
+int ima_add_measure_entry(struct ima_measure_entry *entry);
+struct ima_queue_entry *ima_lookup_digest_entry(u8 * digest);
 
 /*
  * used to protect h_table and sha_table
@@ -75,8 +75,8 @@ struct ima_h_table {
atomic_t len;   /* number of stored measurements in the list */
atomic_t violations;
unsigned int max_htable_size;
-   struct hlist_head queue[MEASURE_HTABLE_SIZE];
-   atomic_t queue_len[MEASURE_HTABLE_SIZE];
+   struct hlist_head queue[IMA_MEASURE_HTABLE_SIZE];
+   atomic_t queue_len[IMA_MEASURE_HTABLE_SIZE];
 };
 extern struct ima_h_table ima_htable;
 
Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima_fs.c
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/ima/ima_fs.c
+++ linux-2.6.21-rc5-mm2/security/evm/ima/ima_fs.c
@@ -105,15 +105,15 @@ static int ima_measurements_show(struct 
 {
/* the list never shrinks, so we don't need a lock here */
struct list_head *lpos = v;
-   struct queue_entry *qe;
-   struct measure_entry *e;
+   struct ima_queue_entry *qe;
+   struct ima_measure_entry *e;
int filename_len;
int i;
u32 pcr = CONFIG_IMA_MEASURE_PCR_IDX;
char data[4];
 
/* get entry */
-   qe = list_entry(lpos, struct queue_entry, later);
+   qe = list_entry(lpos, struct ima_queue_entry, later);
e = qe->entry;
if (e == NULL)
return -1;
@@ -138,8 +138,8 @@ static int ima_measurements_show(struct 
 
/* 4th: eventDataSize */
filename_len = strlen(e->file_name);
-   if (filename_len > TCG_EVENT_NAME_LEN_MAX)
-   filename_len = TCG_EVENT_NAME_LEN_MAX;
+   if (filename_len > IMA_EVENT_NAME_LEN_MAX)
+   filename_len = IMA_EVENT_NAME_LEN_MAX;
 
memcpy(data, &filename_len, 4);
for (i = 0; i < 4; i++)
@@ -177,12 +177,12 @@ static int ima_ascii_measurements_show(s
 {
/* the list never shrinks, so we don't need a lock here */
struct list_head *lpos = v;
-   struct queue_entry *qe;
-   struct measure_entry *e;
+   struct ima_queue_entry *qe;
+   struct ima_measure_entry *e;
int i;
 
/* get entry */
-   qe = list_entry(lpos, struct queue_entry, later);
+   qe = list_entry(lpos, struct ima_queue_entry, later);
e = qe->entry;
if (e == NULL)
return -1;
@@ -269,7 +269,7 @@ out:
return -1;
 }
 
-void ima_fs_cleanup(void)
+void __exit ima_fs_cleanup(void)
 {
securityfs_remove(violations);
securityfs_remove(runtime_measurements_count);
Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima_init.c
===
-

[Patch -mm] integrity: ima exit

[Mimi Zohar]

This patch corrects calling an __exit function from a non-_-exit function.

signed-off-by: Mimi Zohar <[EMAIL PROTECTED]>
signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
---

 security/evm/ima/ima_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima_init.c
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/ima/ima_init.c
+++ linux-2.6.21-rc5-mm2/security/evm/ima/ima_init.c
@@ -111,7 +111,7 @@ int ima_init(void)
return ima_fs_init();
 }
 
-void ima_cleanup(void)
+void __exit ima_cleanup(void)
 {
ima_fs_cleanup();
 }
Index: linux-2.6.21-rc5-mm2/security/evm/evm_integrity.h
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/evm_integrity.h
+++ linux-2.6.21-rc5-mm2/security/evm/evm_integrity.h
@@ -9,21 +9,21 @@
 extern unsigned int evm_enable_ima;
 
 #ifdef CONFIG_IMA_MEASURE
-static inline int evm_ima_init(void)
+static int evm_ima_init(void)
 {
if (evm_enable_ima)
return ima_init();
return 0;
 }
 
-static inline void evm_ima_measure(const unsigned char *name, int hash_len,
+static void evm_ima_measure(const unsigned char *name, int hash_len,
   char *hash)
 {
if (evm_enable_ima)
ima_measure(name, hash_len, hash);
 }
 
-static inline void evm_ima_cleanup(void)
+static void __exit evm_ima_cleanup(void)
 {
if (evm_enable_ima)
ima_cleanup();
@@ -31,19 +31,19 @@ static inline void evm_ima_cleanup(void)
 }
 
 #else
-static inline int evm_ima_init(void)
+static int evm_ima_init(void)
 {
evm_enable_ima = 0;
return 0;
 }
 
-static inline void evm_ima_measure(const unsigned char *name, int hash_len,
+static void evm_ima_measure(const unsigned char *name, int hash_len,
   char *hash)
 {
return;
 }
 
-static inline void evm_ima_cleanup(void)
+static void __exit evm_ima_cleanup(void)
 {
evm_enable_ima = 0;
 }



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

[Patch -mm] integrity: ima cleanup

[Mimi Zohar]

This patch cleanups the few Lindent and sparse msgs

signed-off-by: Mimi Zohar <[EMAIL PROTECTED]>
signed-off-by: Kylene Hall <[EMAIL PROTECTED]>
---

Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima.h
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/ima/ima.h
+++ linux-2.6.21-rc5-mm2/security/evm/ima/ima.h
@@ -52,7 +52,7 @@ struct ima_measure_entry {
 
 struct ima_queue_entry {
struct hlist_node hnext;/* place in hash collision list */
-   struct list_head later; /* place in ima_measurements list */
+   struct list_head later; /* place in ima_measurements list */
struct ima_measure_entry *entry;
 };
 
@@ -72,7 +72,7 @@ struct ima_queue_entry *ima_lookup_diges
 extern spinlock_t ima_queue_lock;
 
 struct ima_h_table {
-   atomic_t len;   /* number of stored measurements in the list */
+   atomic_t len;   /* number of stored measurements in the list */
atomic_t violations;
unsigned int max_htable_size;
struct hlist_head queue[IMA_MEASURE_HTABLE_SIZE];
@@ -82,7 +82,7 @@ extern struct ima_h_table ima_htable;
 
 /* TPM "Glue" definitions */
 
-#define IMA_TPM ((TPM_ANY_TYPE<<16)| TPM_ANY_NUM)
+#define IMA_TPM u32)TPM_ANY_TYPE)<<16)| (u32)TPM_ANY_NUM)
 static inline void ima_extend(const u8 * hash)
 {
if (!ima_used_chip)
Index: linux-2.6.21-rc5-mm2/security/evm/ima/ima_fs.c
===
--- linux-2.6.21-rc5-mm2.orig/security/evm/ima/ima_fs.c
+++ linux-2.6.21-rc5-mm2/security/evm/ima/ima_fs.c
@@ -69,12 +69,11 @@ static void *ima_measurements_start(stru
return NULL;
 }
 
-static void *ima_measurements_next(struct seq_file *m, void *v,
-  loff_t * pos)
+static void *ima_measurements_next(struct seq_file *m, void *v, loff_t * pos)
 {
/* lock protects when reading beyond last element
 * against concurrent list-extension */
-   struct list_head *lpos = (struct list_head *) v;
+   struct list_head *lpos = (struct list_head *)v;
 
rcu_read_lock();
lpos = rcu_dereference(lpos->next);
@@ -88,7 +87,6 @@ static void ima_measurements_stop(struct
 {
 }
 
-
 /* print format:
  *   32bit-le=pcr#
  *   32bit-le=type# << flag
@@ -207,8 +205,7 @@ static struct seq_operations ima_ascii_m
.show = ima_ascii_measurements_show
 };
 
-static int ima_ascii_measurements_open(struct inode *inode,
-  struct file *file)
+static int ima_ascii_measurements_open(struct inode *inode, struct file *file)
 {
return seq_open(file, &ima_ascii_measurements_seqops);
 }
@@ -255,8 +252,7 @@ int ima_fs_init(void)
 
violations =
securityfs_create_file("violations", S_IRUSR | S_IRGRP,
-  ima_dir, NULL,
-  &ima_htable_violations_ops);
+  ima_dir, NULL, &ima_htable_violations_ops);
if (!violations || IS_ERR(violations))
goto out;
return 0;



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

Re: [PATCH] Add support for deferrable timers (respun)

[Venki Pallipadi]

On Wed, Mar 28, 2007 at 01:06:35PM +0200, Andi Kleen wrote:
> Venki Pallipadi <[EMAIL PROTECTED]> writes:
> > +++ new/kernel/timer.c  2007-03-26 15:19:35.0 -0800
> > @@ -74,7 +74,7 @@
> > tvec_t tv3;
> > tvec_t tv4;
> > tvec_t tv5;
> > -} cacheline_aligned_in_smp;
> > +} cacheline_aligned;
> 
> Why this change?  It should be aligned to 2 bytes anyways.

Just wanted to be cautious of all archs and all compilers.
 
> >  static DEFINE_PER_CPU(tvec_base_t *, tvec_bases) = &boot_tvec_bases;
> >  
> > +/*
> > + * The lowest bit of base ptr in timer is used as a flag to indicate
> > + * 'deferrable' nature of the timer. Functions below help us manage that 
> > flag.
> > + */
> > +static inline unsigned int tbase_get_deferrable(struct tvec_t_base_s *base)
> > +{
> > +   return ((unsigned int)base & TBASE_DEFERRABLE_FLAG);
> 
> This will warn on 64bit for cast ptr -> int

OK. Will change this to ptr->long->int in the update patch.

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

fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function

[Toralf Förster]

I compiled current git source 2.6.21-rc5-g28defbe and got this warning:
...
fs/block_dev.c: In function `bd_claim_by_kobject':
fs/block_dev.c:953: warning: 'found' might be used uninitialized in this 
function
...

-- 
MfG/Sincerely

Toralf Förster


pgp7LRXvtUWWq.pgp
Description: PGP signature

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Jeremy Fitzhardinge]

Prarit Bhargava wrote:
> I don't like the idea of having touch_softlockup_watchdog exported
> with your new code -- we still have two methods of effecting the
> softlockup watchdog and that's confusing and its going to cause
> serious problems down the road.

It's legacy.  There are a few places where it wasn't obvious to me how
to replace the touch_softlockup_watchdog, so I left them for now.  But
ideally I think they should all go away.

> Is there a reason that you're pushing the enable/disable?  All the
> cases called out seem to be just fine with calls to either effect that
> CPU's softlockup watchdog or doing all CPU's softlockup watchdogs.

Doing all CPUs is meaningless to me.  How does that make sense?  It
might work in the sense that messages go away, but doesn't it just hide
the fact that one CPU has gone into a spin?

> I agree with the first patch of this set -- it makes sense.  But
> beyond that I'm not convinced the rest of the code is needed ... IMO.

Zach has reported seeing spurious softlockup messages on idle machines
running under a hypervisor.  And there was also the discussion about how
to deal with a flash update system in which all CPUs are taken over by
the bios for a long period of time, which was causing softlockup to
trigger.  It seemed to me that these could all be dealt with in much the
same way, and that disable/enable semantics for dealing with
long-running timer holdoffs is more natural than trying to work out how
to periodically touch the watchdog timer.

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

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Prarit Bhargava]

Jeremy Fitzhardinge wrote:

Prarit Bhargava wrote:
  

I don't like the idea of having touch_softlockup_watchdog exported
with your new code -- we still have two methods of effecting the
softlockup watchdog and that's confusing and its going to cause
serious problems down the road.



It's legacy.  There are a few places where it wasn't obvious to me how
to replace the touch_softlockup_watchdog, so I left them for now.  But
ideally I think they should all go away.

  

Is there a reason that you're pushing the enable/disable?  All the
cases called out seem to be just fine with calls to either effect that
CPU's softlockup watchdog or doing all CPU's softlockup watchdogs.



Doing all CPUs is meaningless to me.  How does that make sense?  It
  


You don't have to do them all -- you could do one with (as in my 
previous patch -- which I'm not married to BTW ;) )


touch_cpu_softlockup_watchdog()

and all with

touch_softlockup_watchdog()


Zach has reported seeing spurious softlockup messages on idle machines
running under a hypervisor.  And there was also the discussion about how
to deal with a flash update system in which all CPUs are taken over by
the bios for a long period of time, which was causing softlockup to
trigger.  It seemed to me that these could all be dealt with in much the
same way, and that disable/enable semantics for dealing with
long-running timer holdoffs is more natural than trying to work out how
to periodically touch the watchdog timer.

  
But wouldn't a call to touch_[cpu_]softlockup_watchdog at the end of the 
flash update fix the problem?  And ditto for all other areas of the 
kernel where we know we're holding off scheduling?


P.



J
  

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

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Jeremy Fitzhardinge]

Prarit Bhargava wrote:
> You don't have to do them all -- you could do one with (as in my
> previous patch -- which I'm not married to BTW ;) )
>
> touch_cpu_softlockup_watchdog()
>
> and all with
>
> touch_softlockup_watchdog()

Well, I think changing the meaning of touch_softlockup_watchdog() for
all existing callers is wrong - even if you change most of them to refer
to the cpu-local function.  There are definitely specific occasions on
which touching all CPUs is the right thing to do, but not in the general
case.

The only thing I really care about in my patches is ignoring stolen
time.  It may be that fixing that is enough to fix the reported problems
with spurious watchdog messages on tickless idle CPUs.

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

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Prarit Bhargava]

Jeremy Fitzhardinge wrote:

Prarit Bhargava wrote:
  

You don't have to do them all -- you could do one with (as in my
previous patch -- which I'm not married to BTW ;) )

touch_cpu_softlockup_watchdog()

and all with

touch_softlockup_watchdog()



Well, I think changing the meaning of touch_softlockup_watchdog() for
all existing callers is wrong - even if you change most of them to refer
to the cpu-local function.  
Hmmm  it was suggested to me that I should mimic what 
touch_nmi_watchdog() does.



There are definitely specific occasions on
which touching all CPUs is the right thing to do, but not in the general
case.
  


Yep.  That's why I have both a single cpu touch and the whole shebang :)


The only thing I really care about in my patches is ignoring stolen
time.  It may be that fixing that is enough to fix the reported problems
with spurious watchdog messages on tickless idle CPUs.

  



J
  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20.3-rt8 - DMA suffers excessive delay periodically

[Lee Revell]

On 3/28/07, John <[EMAIL PROTECTED]> wrote:

Would someone know how to disable SMM in this BIOS?



There's no generic way.  Try disabling USB keyboard emulation and any
unused peripherals.  Also google "RTAI disable SMM".


> Is this a laptop?  They are plagued with SMM problems...

No it is an "indutrial" motherboard.
Although I don't know what makes it "industrial".



One would really hope that such a device would be designed for machine
control and similar RT apps and thus free of SMM...

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

Re: appletouch quirk doesn't run at resume

[Jiri Kosina]

On Tue, 27 Mar 2007, Thomas Meyer wrote:

> It seems, that after the resume all usb devices gets removed and plug in 
> again (virtually!). This results in a new input device name:

Yes, this is what actually happens. JFYI see current thread on lkml which 
is a bit realted - http://lkml.org/lkml/2007/3/27/149 if interested.

> This change confuses the X synaptics driver:
> Touchpad no synaptics event device found (checked 11 nodes)
> Touchpad The /dev/input/event* device nodes seem to be missing
> (EE) xf86OpenSerial: Cannot open device /dev/input/event2
> No such file or directory.
> (WW) Touchpad: cannot open input device
> One could say that the synaptics driver rightly complains about the 
> missing event2 device! So is this a bug in the X synaptics driver?

You can of course work this around by adding an udev rule such as

SUBSYSTEM=="input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"

and the let Xorg use /dev/input/appletouchpad, which will always be a 
symlink to the correct device.

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

Re: appletouch quirk doesn't run at resume

[Dmitry Torokhov]

On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:

On Tue, 27 Mar 2007, Thomas Meyer wrote:

> It seems, that after the resume all usb devices gets removed and plug in
> again (virtually!). This results in a new input device name:

Yes, this is what actually happens. JFYI see current thread on lkml which
is a bit realted - http://lkml.org/lkml/2007/3/27/149 if interested.

> This change confuses the X synaptics driver:
> Touchpad no synaptics event device found (checked 11 nodes)
> Touchpad The /dev/input/event* device nodes seem to be missing
> (EE) xf86OpenSerial: Cannot open device /dev/input/event2
> No such file or directory.
> (WW) Touchpad: cannot open input device
> One could say that the synaptics driver rightly complains about the
> missing event2 device! So is this a bug in the X synaptics driver?

You can of course work this around by adding an udev rule such as

SUBSYSTEM=="input",KERNEL=="event*",SYSFS{name}=="appletouch",SYMLINK+="input/appletouchpad"

and the let Xorg use /dev/input/appletouchpad, which will always be a
symlink to the correct device.



I am not sure if this would help... According to the excerpt from X
log synaptics driver attempted to scan evdev devices and locate the
touchpad. However if this scan happen before udev had a chance to
process the event and create new /dev/input/eventX device node it will
fail.

I wonder if we should adjust the X driver to spin for a couple of
seconds in EventAutoDevProbe if the touchpad was already seen once...
Peter?

--
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 3/4] Locally disable the softlockup watchdog rather than touching it

[Andi Kleen]

On Wednesday 28 March 2007 15:33, Prarit Bhargava wrote:
> 
> Jeremy Fitzhardinge wrote:
> >
> > I haven't really worked out how this should interact with the nmi
> > watchdog; touch_nmi_watchdog() still ends up calling
> > touch_softlockup_watchdog(), so there's still some redundancy here.
> >
> >   
> 
> touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs.

It is supposed to only touch the current CPU, just like it only touches
the NMI watchdog on the current CPU.


> 
> Currently, the code is incorrect -- it is calling 
> touch_softlockup_watchdog which touches only the current CPU's 
> softlockup watchdog.

Sounds correct to me.

-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 3/4] Locally disable the softlockup watchdog rather than touching it

[Prarit Bhargava]

touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs.



It is supposed to only touch the current CPU, just like it only touches
the NMI watchdog on the current CPU.

  


Andi,

(sorry for the cut-and-paste). 


touch_nmi_watchdogs sets EACH CPUs alert_counter to 0.

void touch_nmi_watchdog (void)
{
   if (nmi_watchdog > 0) {
   unsigned cpu;

   /*
* Just reset the alert counters, (other CPUs might be
* spinning on locks we hold):
*/
   for_each_present_cpu (cpu)
   alert_counter[cpu] = 0;
   }

   /*
* Tickle the softlockup detector too:
*/
   touch_softlockup_watchdog();
}

The call to touch_softlockup_watchdog here is incorrect -- it is only 
touching the current CPU's softlockup.


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

Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it

[Andi Kleen]

On Wednesday 28 March 2007 16:00, Prarit Bhargava wrote:
> 
> >> touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs.
> >> 
> >
> > It is supposed to only touch the current CPU, just like it only touches
> > the NMI watchdog on the current CPU.
> >
> >   
> 
> Andi,
> 
> (sorry for the cut-and-paste). 
> 
> touch_nmi_watchdogs sets EACH CPUs alert_counter to 0.

You're right. Sorry for the confusion.  

But just touching the current CPU would make much more sense. After all
the caller doesn't know anything about the state of other CPUs. Perhaps it 
would be best
to just change that and keep the softlockup semantics.

-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 3/4] Locally disable the softlockup watchdog rather than touching it

[Prarit Bhargava]

Andi Kleen wrote:

On Wednesday 28 March 2007 16:00, Prarit Bhargava wrote:
  

touch_nmi_watchdog is attempting to tickle _all_ CPUs softlockup watchdogs.



It is supposed to only touch the current CPU, just like it only touches
the NMI watchdog on the current CPU.

  
  

Andi,

(sorry for the cut-and-paste). 


touch_nmi_watchdogs sets EACH CPUs alert_counter to 0.



You're right. Sorry for the confusion.  


But just touching the current CPU would make much more sense. After all
the caller doesn't know anything about the state of other CPUs. Perhaps it 
would be best
to just change that and keep the softlockup semantics.
  
Yeah -- you're probably right, and besides that we're not seeing a crazy 
# of softlockup messages after touch_nmi_watchdogs calls.


My original comments regarding the code still stand though -- we 
shouldn't have multiple methods of playing with the softlockup watchdog.


P.


-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: Linux 2.6.21-rc5

[Michal Piotrowski]

On 28/03/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:

On Wed, 28 Mar 2007, Michal Piotrowski wrote:

> BUG: using smp_processor_id() in preemptible [0001] code: mount/7245
> is fixed, thanks.
> but I still get this
> [  208.523901] =
> [  208.529739] [ INFO: inconsistent lock state ]
> [  208.534087] 2.6.21-rc5-g28defbea-dirty #131
> [  208.538260] -
> [  208.542611] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
> [  208.548600] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:

Perhaps something like the one below?



Problem seems to be fixed. Thanks!

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fs/block_dev.c:953: warning: 'found' might be used uninitialized in this function

[Lee Revell]

On 3/28/07, Toralf Förster <[EMAIL PROTECTED]> wrote:

I compiled current git source 2.6.21-rc5-g28defbe and got this warning:
...
fs/block_dev.c: In function `bd_claim_by_kobject':
fs/block_dev.c:953: warning: 'found' might be used uninitialized in this 
function
...



Most of these warnings are really GCC bugs.  Please examine the code
in question.

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

Re: [PATCH 2.6.21-rc5-mm2] add compile.h dependency for missing_syscalls.o in init/Makefile

[Sam Ravnborg]

On Wed, Mar 28, 2007 at 11:56:01AM -0400, Lee Schermerhorn wrote:
> PATCH 2.6.21-rc5-mm2:  add compile.h dependency for missing_syscalls.o
> 
> Add a dependency on include/linux/compile.h to missing_syscalls.o
> target in init/Makefile.  Without this, [ia64] build fails with:
> 
> init/missing_syscalls.c:5:27: error: linux/compile.h: No such file or 
> directory
> In file included from init/missing_syscalls.c:97:

Thanks.
But in the end I made another solution that avoids the compile.h
dependency. It is kbuild.git and will appear in next -mm.

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

Re: Odd log message associated with NFS

[J. Bruce Fields]

On Tue, Mar 27, 2007 at 07:39:10PM +, Thorsten Kranzkowski wrote:
> Mar 16 16:57:06 Marvin kernel: svc: bad direction 268435456, dropping request
> Mar 16 17:58:19 Marvin kernel: svc: bad direction 268435456, dropping request
> Mar 16 19:55:49 Marvin kernel: svc: bad direction 268435456, dropping request

So that's 2^28, in a field that should always be zero.  It's the very
first check of any data read from the rpc call, so it'd be consistent
with the call data being garbage, for one reason or another.

What would cause that to happen, I don't know.  Do you have a reliable
way to reproduce it?

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

Re: 2.6.21-rc5-mm2

[Andreas Mohr]

Hi,

On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/
> 
> 
> - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU
>   scheduler has been added.

OOPS (hand-pasted), happens on roughly 85% of bootups, didn't seem to
occur during my several previous 2.6.21-rc4-mm1 bootups:

-
...
Setting up ICE socket directory /tmp/.ICE-unix...done.
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0024
! ==> last sysfs file: block/loop7/removable <===
Process init
trace:
show_trace_log_lvl+0x1a
show_stack_log_lvl+0x9d
show_registers+0x1c0
die+0xe5
do_page_fault+0x432
error_code+0x71
sysfs_drop_dentry+0x30
sysfs_hash_and_remove+0x8e
sysfs_remove_file+0xd
device_remove_file+0x1c
device_del+0x1ed
device_unregister+0x26
device_destroy+0x8a
vcs_remove_sysfs+0x1a
con_close+0x4c
release_dev+0x1f0
tty_release+0xa
__fput+0xb8
fput+0x31
filp_close+0x54
put_files_struct+0x7c
do_exit+0x1e3
sys_exit_group+0x0
sys_exit_group+0xf
syscall_call+0x7
EIP: __iget+0x6
Fixing recursive fault but reboot is needed!
-

Any hints? Possibly existing bug surfaced due to RSDL scheduling timing
differences? I did NOT test -mm1 to check this.

P3/700 UP i815 IDE ext3, Debian unstable.

Further .config available on request.

Note that something killed my /bin/run-parts (Debian) and S10portmap files
(and possibly some others are corrupted??), so it might be something fishy
(but this fishiness could also have uncovered this OOPS, so...).
Restoring those files didn't change the status quo.

CC'd relevant maintainers/recent submitters.

Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] clarify CONFIG_DEBUG_INFO help text

[Sam Ravnborg]

On Tue, Mar 27, 2007 at 03:21:33PM -0600, Andreas Dilger wrote:
> The following patch adds some extra clarification to the CONFIG_DEBUG_INFO
> Kconfig help text.  The current text is mostly a recursive definition and
> doesn't really say much of anything.  When I first read this I thought it
> was going to enable extra verbosity in debug messages or something, but it
> is only enabling the "gcc -g" compile option in the Makefile.
> 
> Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>

Thanks, I have added this to kbuild.git

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