Re: [RFC] Limit the size of the pagecache

[Vaidyanathan Srinivasan]

Christoph Lameter wrote:
> On Wed, 24 Jan 2007, Erik Andersen wrote:
> 
>> It would be far more useful if an application could hint to the
>> pagecache as to which files are and which files as not worth
>> caching, especially when the application knows a priori that data
>> from a particular file will or will not ever be reused.
> 
> It can give such hints via madvise(2).

I think you meant fadvise.  That is certainly a possibility which we
need to work on.  Current implementation of fadvise only throttles
read ahead in case of sequential access and flushes the file in case
of DONTNEED.  We leave it at default for NOREUSE.

In case of DONTNEED and NOREUSE, we need to limit the pages used for
page cache and also reclaim them as soon as possible.  Interaction of
 mmap() and fadvise is little more dfficult to handle.

--Vaidy

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

Re: [PATCH 7/8] user ns: handle file sigio

[Andrew Morton]

On Wed, 24 Jan 2007 12:58:45 -0600
"Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:

> > If we need to I can see doing something special if the process setting
> > fown has CAP_KILL
> 
> Obviously CAP_KILL is insufficient :)  I assume you mean a new
> CAP_XNS_CAP_KILL?
> 
> > and bypassing the security checks that way, but
> > hard coding rules like that when it doesn't appear we have any
> > experience to indicate we need the extra functionality looks
> > premature.
> 
> Ok, in this case actually I suspect you're right and we can just ditch
> the exception.  But in general the security discussion is one we should
> still have.

People like security.

Where do we now stand with this patch, and with "[PATCH 4/8] user ns: hook 
permission"?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MMC: au1xmmc R6 response support

[Manuel Lauss]

Hi Pierre,
> 
> > HEAD has this fixed. Every spec I can get my hands on states that R1 and
> > R6 have the same format. So it sounds like this controller is doing
> > something stupid.
> 
> Apparently my HW is broken... I got a hold of a DB1200 demoboard and
> the distributed version works fine there.

Actually, the bug is that because of MMC_RSP_R6 not being handled in
the switch in au1xmmc_send_command(), the controller gets told that
no response is expected. I changed the R6 to R1 in mmc.h, thats why
it worked in the demoboard, and it also works now on the previously
thought-to-be-broken HW.

So it's only broken in releases < 2.6.20-rc6.

Thanks,

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

Re: NCPFS and brittle connections

[Petr Vandrovec]

Pierre Ossman wrote:

Petr Vandrovec wrote:

Hello,
  create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process.  So it stops
resending, but local sequence count is already incremented.  Then when
next process tries to access ncpfs, server will ignore its requests as
it expects packet with sequence X, while packet with sequence X+1
arrived.


Figured something along those lines, but I couldn't find any docs on the
protocol so I wasn't sure. You wouldn't happen to have any pointers to
such docs?


You can download NCP documentation from Novell website.  Or you could, 
couple of months ago.  Unfortunately that documentation just describes 
different NCP calls, not transport - to my knowledge transport layer was 
never documented outside of Novell.



And unfortunately it is not possible to simple not increment sequence
number unless you get reply - when server receives two packets with
same sequence number, it simple resends answer it gave to first
request, without looking at request's body at all.  So in this case
server would answer, but would gave you bogus answer.


This sounds promising though. In that case it wouldn't be necessary to
store the entire request, just the sequence number, right?


Not quite.  If packet signatures are on then server needs to know packet 
you sent so it can correctly compute secret used for next packet (it is 
function of old secret, and data in current packet).  As current 
signatures implementation implement only partial signatures, you need 
just first 64bytes of the packet same - but at that point it may be 
better to just resend packet completely, as write request with correct 
file handle, length, and offset, but with only ~50 bytes of valid data 
is going to do lot of damage on the server.  So I would recommend 
resending original request...

Petr


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

Re: gpu sharing layer for kernel

[Paul Collins]

Hi Dave,

[EMAIL PROTECTED] writes:

> This patch series contains the gpu sharing layer for kernel that
> I've mentioned before. It should apply against Linus's git tree.

I gave the patches a go on my PowerBook.  I had to make a few changes
to get it to compile.  Works fine so far: I switched between VTs and X
with an accelerated GLX client active a few times, no problems.

When I did a sleep/resume cycle it wedged on resume, but I expect this
is due to my hacking up radeonfb_early_resume(), as seen in the last
hunk below, which was just aimed at just getting it to compile.


diff --git a/drivers/video/aty/radeon_backlight.c 
b/drivers/video/aty/radeon_backlight.c
index 3abfd4a..560568b 100644
--- a/drivers/video/aty/radeon_backlight.c
+++ b/drivers/video/aty/radeon_backlight.c
@@ -105,7 +105,7 @@ static int radeon_bl_update_status(struct backlight_device 
*bd)
   RADEON_PIXCLK_LVDS_ALWAYS_ON bit is off
*/
tmpPixclksCntl = INPLL(PIXCLKS_CNTL);
-   if (rinfo->is_mobility || rinfo->is_IGP)
+   if (rinfo->gpu_info->is_mobility || rinfo->gpu_info->is_IGP)
OUTPLLP(PIXCLKS_CNTL, 0, ~PIXCLK_LVDS_ALWAYS_ONb);
lvds_gen_cntl &= ~(LVDS_BL_MOD_LEVEL_MASK | LVDS_BL_MOD_EN);
lvds_gen_cntl |= (radeon_bl_get_level_brightness(pdata, 0) <<
@@ -119,7 +119,7 @@ static int radeon_bl_update_status(struct backlight_device 
*bd)
rinfo->pending_lvds_gen_cntl = lvds_gen_cntl;
mod_timer(&rinfo->lvds_timer,
  jiffies + 
msecs_to_jiffies(rinfo->panel_info.pwr_delay));
-   if (rinfo->is_mobility || rinfo->is_IGP)
+   if (rinfo->gpu_info->is_mobility || rinfo->gpu_info->is_IGP)
OUTPLL(PIXCLKS_CNTL, tmpPixclksCntl);
}
rinfo->init_state.lvds_gen_cntl &= ~LVDS_STATE_MASK;
@@ -176,10 +176,10 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
 * direction backlight should work on a given panel?
 */
pdata->negative =
-   (rinfo->family != CHIP_FAMILY_RV200 &&
-rinfo->family != CHIP_FAMILY_RV250 &&
-rinfo->family != CHIP_FAMILY_RV280 &&
-rinfo->family != CHIP_FAMILY_RV350);
+   (rinfo->gpu_info->family != CHIP_FAMILY_RV200 &&
+rinfo->gpu_info->family != CHIP_FAMILY_RV250 &&
+rinfo->gpu_info->family != CHIP_FAMILY_RV280 &&
+rinfo->gpu_info->family != CHIP_FAMILY_RV350);
 
 #ifdef CONFIG_PMAC_BACKLIGHT
pdata->negative = pdata->negative ||
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index f634c43..c8cc173 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1837,7 +1837,8 @@ static int radeonfb_set_par(struct fb_info *info)
 
 #ifdef CONFIG_BOOTX_TEXT
/* Update debug text engine */
-   btext_update_display(rinfo->fb_base_phys, mode->xres, mode->yres,
+   btext_update_display(rinfo->gpu_info->fb_base_phys,
+mode->xres, mode->yres,
 rinfo->depth, info->fix.line_length);
 #endif
 
diff --git a/drivers/video/aty/radeon_monitor.c 
b/drivers/video/aty/radeon_monitor.c
index 8625f5d..4cd4f34 100644
--- a/drivers/video/aty/radeon_monitor.c
+++ b/drivers/video/aty/radeon_monitor.c
@@ -122,7 +122,7 @@ static int __devinit radeon_probe_OF_head(struct 
radeonfb_info *rinfo, int head_
 while (dp == NULL)
return MT_NONE;
 
-   if (rinfo->has_CRTC2) {
+   if (rinfo->gpu_info->has_CRTC2) {
const char *pname;
int len, second = 0;
 
@@ -141,7 +141,7 @@ static int __devinit radeon_probe_OF_head(struct 
radeonfb_info *rinfo, int head_
/* Maybe check for LVDS_GEN_CNTL here ? I need 
to check out
 * what OF does when booting with lid closed
 */
-   if (mt == MT_DFP && rinfo->is_mobility)
+   if (mt == MT_DFP && 
rinfo->gpu_info->is_mobility)
mt = MT_LCD;
return mt;
} else if (pname[len-1] == 'B' && head_no == 1)
@@ -655,7 +655,7 @@ static void radeon_fixup_panel_info(struct radeonfb_info 
*rinfo)
 * PPC only for now...
 */
if (!rinfo->panel_info.use_bios_dividers && rinfo->mon1_type == MT_LCD
-   && rinfo->is_mobility) {
+   && rinfo->gpu_info->is_mobility) {
int ppll_div_sel;
u32 ppll_divn;
ppll_div_sel = INREG8(CLOCK_CNTL_INDEX + 1) & 0x3;
diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
index 9a59804..f113616 100644
--- a/drivers/video/aty/radeon_pm.c
+++ b/drivers/video/aty/radeon_pm.c
@@ -957,7 +957,7 @@ static

Re: [RFC] Limit the size of the pagecache

[Vaidyanathan Srinivasan]

Al Boldi wrote:
> Rik van Riel wrote:
>> Christoph Lameter wrote:
>>> This is a patch using some of Aubrey's work plugging it in what is IMHO
>>> the right way. Feel free to improve on it. I have gotten repeatedly
>>> requests to be able to limit the pagecache.
>> IMHO it's a bad hack.
>>
>> It would be better to identify the problem this "feature" is
>> trying to fix, and then fix the root cause.
> 
> Ok, here is the problem:  kswapd.
> 
> Limiting the page-cache memory inhibits invoking kswapd needlessly, aiding 
> performance and easing OOM pressures.

Apart from kswapd, limiting pagecache helps performance of
applications by not eating away their ANON pages or other parts of its
resident data set.  When there is enough free memory, then there is no
performance issue.  However memory is always utilized to the max.
Hence every pagecache page that is allocated should come from some
application's RSS, or from cold pagecache page.  If that page was
stolen from some application, then that application pays the price for
swapping or reading the page back to memory.  This scenario is what we
 want to avoid.  All that we are trying to achieve is that pagecache
eats a (unmapped) pagecache page and not steal memory from other
important application's resident set.

Certainly this should be a configurable option and kernel's behavior
should not be changed in general.

> I tried the patch; it works.

:)

> But it needs a bit of debugging.  Setting pagecache_ratio = 1 either 
> deadlocks or reduces thru-put to < 1mb/s.

Yes, going below 5% on my 1GB RAM machine causes severe performance
problems.  We need to hard wire a reasonable lower limit and not
provide a noose for the end user to tie around!

--Vaidy

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

Re: How to get /dev entry created automaticly for dynamic major number?

[Greg KH]

On Thu, Jan 25, 2007 at 09:35:07AM +0200, Markku Savela wrote:
> 
> If want to write a loadable module which "implements" a char device
> ("virtual", no real device present). How do I get the correct
> "/dev/foo" to appear automaticly?  What is the current recommended
> solution (kernel 2.6.17 in Ubuntu and later).
> 
> static int major;
> 
> static int __init foo_init(void)
> {
> ...
> major = register_chrdev(0, "foo", &fops);
> 
> }
> 
> static void __exit foo_exit(void)
> {
> ...
> if (major > 0)
> unregister_chrdev(major, "foo");
> ...
> }
> 
> I thought that the above code would be enough to trigger the "udevd",
> but apparently not (if it should, what is the match rule I have to
> use? DRIVER=="foo" or KERNEL="foo[0-9]*"? None of these seem to
> work). Do I have to do some additional poking with sysfs?  I can see
> my module there, but nothing else.
> 
> The problem seems to be that most information I find from books or net
> is out of date for 2.6, or carries note "these things are currently
> been changed". A pointer to a definitive documentation would also do!

If you look in the book, Linux Device Drivers, third edition, free
online, there's a section on what is needed for udev to work properly.

The ideas are still the same, but the way to do it has changed since the
book was written.  Just use a struct device and a class, and you will be
fine.  Look at the misc device core or the mem code in
drivers/char/mem.c for examples of what you need to do.

Hope this helps,

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

Re: [PATCH] MMC: au1xmmc R6 response support

[Pierre Ossman]

Manuel Lauss wrote:
> 
> Actually, the bug is that because of MMC_RSP_R6 not being handled in
> the switch in au1xmmc_send_command(), the controller gets told that
> no response is expected. I changed the R6 to R1 in mmc.h, thats why
> it worked in the demoboard, and it also works now on the previously
> thought-to-be-broken HW.
> 

So in order to detect any similar problems in the future, I'd like a
patch that adds a "default:" to that switch statement.

Rgds
-- 
 -- Pierre Ossman

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

Re: [PATCH] MMC: au1xmmc R6 response support

[Pierre Ossman]

Manuel Lauss wrote:
> 
> Apparently my HW is broken... I got a hold of a DB1200 demoboard and
> the distributed version works fine there.
> 
> I'm very sorry for the noise!
> 

No problem. Better safe than sorry.

> 
> Aren't people from AMD (now Raza) maintaining it? I have source for this
> driver which also implements SDIO, also from AMD. It's a bit dated (for
> 2.6.11). But I'm willing to look into problems, as long as I have access
> to the hardware.
> 

I have not heard anything from Raza, so I wouldn't even know who to
contact there.

Rgds
-- 
 -- Pierre Ossman

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

Re: [PATCH] lock stat for -rt 2.6.20-rc2-rt2.2.lock_stat.patch

[Ingo Molnar]

* Bill Huey <[EMAIL PROTECTED]> wrote:

> Latest patch here.
> 
>   
> http://finfin.is-a-geek.org/~billh/contention/patch-2.6.20-rc2-rt2.4.lock_stat.patch
>
> I'm going to review and hand merge your changes to the older patch 
> tonight.

one more suggestion: please do diffs in -p1 (not in -p0) format.

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: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Josh Triplett]

Paul E. McKenney wrote:
> This patch adds an optional preemption kernel thread to the rcutorture
> tests.  This thread sets itself to a low RT priority and chews up
> CPU in 10-second bursts, verifying that grace periods progress during
> this 10-second interval.  This has thus far passed about 30 hours of
> RCU torture testing on a 4-CPU (a pair of 2-CPU dies) 64-bit Xeon 
> system.
> 
> I am experimenting with more-vicious tests, but extra viciousness thus
> far comes at the expense of grotesque code.

Overall, the new feature seems like a good idea, and it should exercise the
new RCU boosting code.  Some comments below.

One major item: this new test feature really needs a new module parameter to
enable or disable it.

> diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/kernel/rcutorture.c 
> linux-2.6.20-rc4-rt1-rcubtorture/kernel/rcutorture.c
> --- linux-2.6.20-rc4-rt1/kernel/rcutorture.c  2007-01-09 10:59:54.0 
> -0800
> +++ linux-2.6.20-rc4-rt1-rcubtorture/kernel/rcutorture.c  2007-01-23 
> 11:27:49.0 -0800
> @@ -194,6 +194,8 @@ struct rcu_torture_ops {
>   int (*completed)(void);
>   void (*deferredfree)(struct rcu_torture *p);
>   void (*sync)(void);
> + void (*preemptstart)(void);
> + void (*preemptend)(void);
>   int (*stats)(char *page);
>   char *name;
>  };
> @@ -258,6 +260,71 @@ static void rcu_torture_deferred_free(st
>   call_rcu(&p->rtort_rcu, rcu_torture_cb);
>  }
>  
> +#ifndef CONFIG_PREEMPT_RCU_BOOST
> +static void rcu_preempt_start(void) { }
> +static void rcu_preempt_end(void) { }
> +static int rcu_preempt_stats(char *page) { return 0; }
> +#else /* #ifndef CONFIG_PREEMPT_RCU_BOOST */
> +
> +static struct task_struct *rcu_preeempt_task;
> +static long rcu_torture_preempt_errors = 0;

Might as well make this an unsigned long; negative values wouldn't make sense.

> +static int rcu_torture_preempt(void *arg)
> +{
> + int completedstart;
> + time_t gcstart;
> + struct sched_param sp;
> +
> + sp.sched_priority = MAX_RT_PRIO - 1;
> + sched_setscheduler(current, SCHED_RR, &sp);
> + current->flags |= PF_NOFREEZE;
> +
> + do {
> + completedstart = rcu_torture_completed();
> + gcstart = xtime.tv_sec;
> + while ((xtime.tv_sec - gcstart < 10) &&
> +(rcu_torture_completed() == completedstart))
> + cond_resched();
> + if (rcu_torture_completed() == completedstart)
> + rcu_torture_preempt_errors++;
> + schedule_timeout_interruptible(shuffle_interval * HZ);

Why call schedule_timeout_interruptible here without actually handling
interruptions?  So that you can send it a signal to cause the shuffle early?

> + } while (!kthread_should_stop());
> + return NULL;
> +}
> +
> +static void rcu_preempt_start(void)
> +{
> + rcu_preeempt_task = kthread_run(rcu_torture_preempt, NULL,
> + "rcu_torture_preempt");
> + if (IS_ERR(rcu_preeempt_task)) {
> + VERBOSE_PRINTK_ERRSTRING("Failed to create preempter");

This ought to include the errno value, PTR_ERR(rcu_preempt_task).

> + rcu_preeempt_task = NULL;
> + }
> +}
> +
> +static void rcu_preempt_end(void)
> +{
> + if (rcu_preeempt_task != NULL) {

if (rcu_preempt_task) would work just as well here.

> + VERBOSE_PRINTK_STRING("Stopping rcu_preempt task");
> + kthread_stop(rcu_preeempt_task);
> + }
> + rcu_preeempt_task = NULL;
> +}
> +
> +static int rcu_preempt_stats(char *page) {
> + int cnt = 0;
> +
> + cnt += sprintf(&page[cnt],
> +"Preemption stalls: %ld\n", rcu_torture_preempt_errors);
> + return (cnt);
> +}

How about just:
return sprintf(page, ...);
?

Also, if you decide to make rcu_torture_preempt_errors an unsigned long as
suggested above, this should use %lu.

> +#endif /* #else #ifndef CONFIG_PREEMPT_RCU_BOOST */
> +
> +static void rcu_preemptstart(void)
> +{
> + 
> +}
> +

This looks like a bit of stray code.

>  static struct rcu_torture_ops rcu_ops = {
>   .init = NULL,
>   .cleanup = NULL,
> @@ -267,7 +334,9 @@ static struct rcu_torture_ops rcu_ops = 
>   .completed = rcu_torture_completed,
>   .deferredfree = rcu_torture_deferred_free,
>   .sync = synchronize_rcu,
> - .stats = NULL,
> + .preemptstart = rcu_preempt_start,
> + .preemptend = rcu_preempt_end,
> + .stats = rcu_preempt_stats,
>   .name = "rcu"
>  };
>  
> @@ -306,6 +375,8 @@ static struct rcu_torture_ops rcu_sync_o
>   .completed = rcu_torture_completed,
>   .deferredfree = rcu_sync_torture_deferred_free,
>   .sync = synchronize_rcu,
> + .preemptstart = NULL,
> + .preemptend = NULL,
>   .stats = NULL,
>   .name = "rcu_sync"
>  };

Much like other common structures such as struct file_operations, no need to
explicitly specify members as NULL here; any member you don't specify wi

Re: [PATCH -mm 4/5][AIO] - AIO completion signal notification

[Sébastien Dugué]

On Thu, 25 Jan 2007 05:42:42 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 24, 2007 at 12:11:30PM +0100, S?bastien Dugu? wrote:
> > > > +   if (unlikely(!notify->sigq))
> > > > +   return -EAGAIN;
> > > 
> > > Did this just leak a ref on the task_struct?
> > > 
> > 
> >   No, the ref is released in really_put_req() when we dispose of
> > the iocb.
> 
> And the code really needs a comment explaining this.  I tripped over
> this before, and I think it's even already the second time Andrew
> stumbled over it.
> 

  OK, will do.

  Thanks,

  Sébastien.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.18-stable release plans?

[Chris Rankin]

--- Mark Rustad <[EMAIL PROTECTED]> wrote:
> We'll never know if any of these things were correlated with the  
> solar flares because they all seem to be one-off failures. I do find  
> it interesting though. Our systems seem to be doing statistically  
> better this month. What do you think?

Personally, I think it's all a bit moot unless you also have particle detectors 
above and below
all your machines so that you can interpolate particle tracks. I certainly see 
no reason why a
random high-energy particle passing through two different machines is ever 
likely to cause the
same error, unless that error is an outright systems crash. (Although that 
second report was from
someone with a tainted kernel, which makes it suspect.)

Cheers,
Chris




___ 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. 
http://uk.docs.yahoo.com/nowyoucan.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/

[PATCH -mm] AIO - Comment aio_setup_sigevent() explaining why there is no task ref leak

[Sébastien Dugué]

  Here it is

On Thu, 25 Jan 2007 05:42:42 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 24, 2007 at 12:11:30PM +0100, S?bastien Dugu? wrote:
> > > > +   if (unlikely(!notify->sigq))
> > > > +   return -EAGAIN;
> > > 
> > > Did this just leak a ref on the task_struct?
> > > 
> > 
> >   No, the ref is released in really_put_req() when we dispose of
> > the iocb.
> 
> And the code really needs a comment explaining this.  I tripped over
> this before, and I think it's even already the second time Andrew
> stumbled over it.
> 

From: Sébastien Dugué <[EMAIL PROTECTED]>

  Add a comment explaining why there is no task ref leak in
aio_setup_sigevent().


 aio.c |5 +
 1 file changed, 5 insertions(+)


Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc4-mm1/fs/aio.c
===
--- linux-2.6.20-rc4-mm1.orig/fs/aio.c  2007-01-17 08:59:16.0 +0100
+++ linux-2.6.20-rc4-mm1/fs/aio.c   2007-01-25 09:52:29.0 +0100
@@ -987,6 +987,11 @@ static long aio_setup_sigevent(struct ai
 */
notify->sigq = sigqueue_alloc();
 
+   /*
+* The task ref will be released in really_put_req()
+* when we dispose of the iocb later on in the submission
+* path.
+*/
if (unlikely(!notify->sigq))
return -EAGAIN;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra b ios 1.6

[Eamonn Hamilton]

Hi,

I didn't get a chance to try the -mm patch, but booting with acpi=off
works - other than no acpi, of course :)

What now?

Cheers,
Eamonn

On Thu, 2007-01-25 at 05:33 +, Luming Yu wrote:
> On 1/25/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:
> > I've also just found bug #7820 on bugzilla which has a patch which may
> > address this issue from Ingo.
> >
> > I'll give that a shot as well.
> >
> 
> Yes, that patch workaround the problem. But it is just a workaround.
> It would be much helpful to others by fixing the original problem.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: status of: tasklet_unlock_wait() causes soft lockup with -rt and ieee1394 audio

[Pieter Palmers]

Ingo Molnar wrote:

* Pieter Palmers <[EMAIL PROTECTED]> wrote:


Dear all,

What is the status with respect to this problem? I see that in the 
current -rt patch the problematic code piece is different. I 
personally haven't tried to reproduce this myself on a more recent 
kernel, but I just got a report from one of our users who experienced 
the same problem with 2.6.19-rt15 and RT preemption (desktop 
preemption works fine).


Should the latest -rt patches be fixed with respect to this issue? If 
so I'll try and test them, otherwise I omit the effort.


it's not fixed yet. Could you try the patch below?


Ingo,

I couldn't get my laptop booting on 2.6.20-rc3 or 2.6.19, but I passed 
the patch on to one of our users and he reports that it is working (on 
2.6.19-rt15).


Thanks,

Pieter



Ingo

---
 include/linux/interrupt.h |6 ++
 kernel/softirq.c  |   20 
 2 files changed, 22 insertions(+), 4 deletions(-)

Index: linux/include/linux/interrupt.h
===
--- linux.orig/include/linux/interrupt.h
+++ linux/include/linux/interrupt.h
@@ -328,10 +328,8 @@ static inline void tasklet_unlock(struct
clear_bit(TASKLET_STATE_RUN, &(t)->state);
 }
 
-static inline void tasklet_unlock_wait(struct tasklet_struct *t)

-{
-   while (test_bit(TASKLET_STATE_RUN, &(t)->state)) { barrier(); }
-}
+extern void tasklet_unlock_wait(struct tasklet_struct *t);
+
 #else
 # define tasklet_trylock(t)1
 # define tasklet_tryunlock(t)  1
Index: linux/kernel/softirq.c
===
--- linux.orig/kernel/softirq.c
+++ linux/kernel/softirq.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -656,6 +657,25 @@ void __init softirq_init(void)
open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
 }
 
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT)

+
+void tasklet_unlock_wait(struct tasklet_struct *t)
+{
+   while (test_bit(TASKLET_STATE_RUN, &(t)->state)) {
+   /*
+* Hack for now to avoid this busy-loop:
+*/
+#ifdef CONFIG_PREEMPT_RT
+   msleep(1);
+#else
+   barrier();
+#endif
+   }
+}
+EXPORT_SYMBOL(tasklet_unlock_wait);
+
+#endif
+
 static int ksoftirqd(void * __data)
 {
struct sched_param param = { .sched_priority = MAX_USER_RT_PRIO/2 };



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

Re: 2.6.18-stable release plans?

[Chris Rankin]

--- Ken Moffat <[EMAIL PROTECTED]> wrote:
> At the moment, you have a problem that nobody recognises.  If you're not
> willing to test if the problem happens repeatably, (you appear to
> have had one failure and immediately reverted to an old kernel), who
> do you think will be able to fix it?

This bug seems to be in the kernel's "memory management", and the last 
memory-related bug I had
(caused by a bad DIMM on another machine) caused creeping filesystem 
corruption. However, this
machine is my main desktop, and so I am keen to keep the filesystems intact. So 
yes, that involves
not running a kernel that has shown itself to be unreliable. 

I was hoping that someone with a deeper knowledge of the differences between 
2.6.18 and 2.6.19
would have an idea of what might have triggered this problem, and yes, I was 
also thinking that
some more people would trip over it and help debug it.

But anyway - can someone please tell me what "Eeek! page_mapcount(page) went 
negative! (-1)" is
*really* saying/implying? Because I am currently translating this as "I WANT TO 
EAT YOUR
FILESYSTEMS".

Cheers,
Chris






___ 
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at 
the Yahoo! Mail Championships. Plus: play games and win prizes. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] mm: Move common segments checks to separate function

[Ken Chen]

Dmitriy Monakhov wrote on Jan 24, 11:00 pm

> Move common segments checks from  __generic_file_aio_{read,write}_nolock()
> to separate helper function generic_segment_checks().WOW my eyes 
I'm realy sorry but this patch is litle bit broken. :(
I've forgot to check generic_segment_checks() return value.


why not remove the for loop all together?  like this:

http://groups.google.com/group/linux.kernel/browse_frm/thread/97550ddba48c8c8b/623ddad30b547702?lnk=st&q=&rnum=9#623ddad30b547702
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra b ios 1.6

[Luming Yu]

I didn't get a chance to try the -mm patch, but booting with acpi=off
works - other than no acpi, of course :)

What now?

Well, this should be ACPI interrupt configure issue.
Please feel free to enter a bug on bugzilla.kernel.org.
And, post acpidump output, /proc/interrupts ,lspci -vvx, dmesg for
(acpi=off ) there.

Thanks,
Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mmc: au1xmmc: return errors for unknown response types

[Manuel Lauss]

au1xmmc: return error when encountering unhandled/unknown response type.

Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>

--- a/drivers/mmc/au1xmmc.c.orig2007-01-25 09:56:10.851983000 +0100
+++ b/drivers/mmc/au1xmmc.c 2007-01-25 10:13:12.121983000 +0100
@@ -193,6 +194,8 @@ static int au1xmmc_send_command(struct a
u32 mmccmd = (cmd->opcode << SD_CMD_CI_SHIFT);
 
switch (mmc_resp_type(cmd)) {
+   case MMC_RSP_NONE:
+   break;
case MMC_RSP_R1:
mmccmd |= SD_CMD_RT_1;
break;
@@ -205,6 +208,10 @@ static int au1xmmc_send_command(struct a
case MMC_RSP_R3:
mmccmd |= SD_CMD_RT_3;
break;
+   default:
+   printk(KERN_INFO "au1xmmc: unhandled response type %02x\n",
+   mmc_resp_type(cmd));
+   return MMC_ERR_INVALID;
}
 
switch(cmd->opcode) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mmc: au1xmmc: implement proper ro switch detection

[Manuel Lauss]

au1xmmc: implement proper R/O switch detection.

Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>

--- a/drivers/mmc/au1xmmc.c.orig2007-01-25 09:56:10.851983000 +0100
+++ b/drivers/mmc/au1xmmc.c 2007-01-25 10:13:12.121983000 +0100
@@ -152,8 +152,9 @@ static inline int au1xmmc_card_inserted(
? 1 : 0;
 }
 
-static inline int au1xmmc_card_readonly(struct au1xmmc_host *host)
+static int au1xmmc_card_readonly(struct mmc_host *mmc)
 {
+   struct au1xmmc_host *host = mmc_priv(mmc);
return (bcsr->status & au1xmmc_card_table[host->id].wpstatus)
? 1 : 0;
 }
@@ -878,6 +885,7 @@ static void au1xmmc_init_dma(struct au1x
 struct mmc_host_ops au1xmmc_ops = {
.request= au1xmmc_request,
.set_ios= au1xmmc_set_ios,
+   .get_ro = au1xmmc_card_readonly,
 };
 
 static int __devinit au1xmmc_probe(struct platform_device *pdev)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)

[Oleg Verych]

On Wed, Jan 24, 2007 at 08:51:32PM -0500, Rob Landley wrote:
> On Wednesday 24 January 2007 4:03 pm, Oleg Verych wrote:
> 
> > Let me propose you to test this as solution, that need no awk, only shell:
> 
> Actually awk is one of the standard Single Unix Specification (version 3) 
> utilities and the kernel build uses it in a number of places, such as 
> arch/alpha/boot/Makefile, drivers/eisa/Makefile, scripts/ver_linux.

I saw that. If you will test my first replacements and it will be ok,
i will go to this.

> Your objection is a bit like saying "and don't use cat".  I'm saying don't 
> call cat "gcat" when you just mean plain old cat.

No it's not, really. I don't want to see pipes, fork()s, disk seek,
when task can be done without it. I know, what awk is, and i hope it
will have its better time.

> > p.s. who is going to make alternative to GNU make ? ;D
> 
> Me.  Seriously.  It's on my todo list, as part of the Firmware Linux project:

Well. I didn't expect such answer! So, after my trying to deal with
makefiles (there so many to cleanup and structure), i think it will be
easy to do so. I did contacted (ft)jam developers, but didn't get any
answer on current state of it vs GNU make.

> http://lwn.net/Articles/215941/
> 
> Although as major projects go, it's about fifth down on the list after 
> getting 
> toybox up to speed, writing a proper bash replacement shell, getting tcc to 
> build an unmodified Linux kernel, convincing the uClibc guys to HAVE ANOTHER 
> RELEASE ALREADY (it's been a year and a half, I _sent_ a cake)...

Thanks for information.

> Today, I'm writing a gene2fs that produces streaming output (I.E. it works 
> like tar).  It's not done yet...

Good luck !


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Add a rounddown_pow_of_two() macro to log2.h.

[Robert P. J. Day]

  In the same way that include/linux/log2.h defines the
roundup_pow_of_two() macro, define the rounddown_pow_of_two() macro so
peopls can stop re-implementing this operation using a loop.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  compile tested on x86 using "make allyesconfig", but there wasn't
much chance of the build failing anyway since the patch only adds the
macro definition, it doesn't change any existing code to use it.
those patches will be submitted later, bit by bit.

diff --git a/include/linux/log2.h b/include/linux/log2.h
index d02e1a5..6cf7081 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -52,6 +63,15 @@ unsigned long __roundup_pow_of_two(unsigned long n)
return 1UL << fls_long(n - 1);
 }

+/*
+ * round down to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __rounddown_pow_of_two(unsigned long n)
+{
+   return 1UL << (fls_long(n) - 1);
+}
+
 /**
  * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
  * @n - parameter
@@ -154,4 +174,20 @@ unsigned long __roundup_pow_of_two(unsigned long n)
__roundup_pow_of_two(n) \
  )

+/**
+ * rounddown_pow_of_two - round the given value down to nearest power of two
+ * @n - parameter
+ *
+ * round the given value down to the nearest power of two
+ * - the result is undefined when n == 0
+ * - this can be used to initialise global variables from constant data
+ */
+#define rounddown_pow_of_two(n)\
+(  \
+   __builtin_constant_p(n) ? ( \
+   (n == 1) ? 0 :  \
+   (1UL << ilog2(n)) : \
+   __rounddown_pow_of_two(n)   \
+ )
+
 #endif /* _LINUX_LOG2_H */

-- 
==
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://www.fsdev.dreamhosters.com/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
==
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH -rt 1/2] RCU priority boosting that survives semi-vicious testing

[Josh Triplett]

Overall, this code looks sensible to me.  Some comments on the patch below.

Paul E. McKenney wrote:
> --- linux-2.6.20-rc4-rt1/include/linux/rcupreempt.h   2007-01-09 
> 10:59:54.0 -0800
> +++ linux-2.6.20-rc4-rt1-rcub/include/linux/rcupreempt.h  2007-01-09 
> 11:01:12.0 -0800
[...]
> +enum rcu_boost_state {
> + RCU_BOOST_IDLE = 0,/* Not yet blocked if in RCU read-side. */
> + RCU_BOOST_BLOCKED = 1, /* Blocked from RCU read-side. */
> + RCU_BOOSTED = 2,   /* Boosting complete. */
> +};
> +
> +#define N_RCU_BOOST_STATE (RCU_BOOSTED + 1)

Here, you define the three possible states, the number of states.  But
later...

> diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/kernel/rcupreempt.c 
> linux-2.6.20-rc4-rt1-rcub/kernel/rcupreempt.c
> --- linux-2.6.20-rc4-rt1/kernel/rcupreempt.c  2007-01-09 10:59:54.0 
> -0800
> +++ linux-2.6.20-rc4-rt1-rcub/kernel/rcupreempt.c 2007-01-23 
> 15:41:33.0 -0800
> @@ -49,6 +49,7 @@
[...]
> +#ifdef CONFIG_PREEMPT_RCU_BOOST_STATS
> + long rbs_stats[N_RCU_BOOST_DAT_EVENTS][N_RCU_BOOST_STATE + 1];
> +#endif /* #ifdef CONFIG_PREEMPT_RCU_BOOST_STATS */

...you declare this array to have space for one more than that, and then...

> +#ifdef CONFIG_PREEMPT_RCU_BOOST_STATS
> +
> +/*
> + * Function to increment indicated ->rbs_stats[] element.
> + */
> +static inline void rcu_boost_dat_stat(struct rcu_boost_dat *rbdp,
> +   int event,
> +   enum rcu_boost_state oldstate)
> +{
> + if (oldstate >= RCU_BOOST_IDLE &&
> + oldstate <= RCU_BOOSTED) {
> + rbdp->rbs_stats[event][oldstate]++;
> + } else {
> + rbdp->rbs_stats[event][N_RCU_BOOST_STATE]++;

...you use the last element as what looks like an "unknown" counter.  How
about instead defining the enum to have an "unknown" state, defining
N_RCU_BOOST_STATE accordingly, and using N_RCU_BOOST_STATE without the +1 in
rbs_stats?  I think that would make the code much more self-documenting, and
less error-prone.

> +#define rcu_boost_dat_stat_block(rbdp, oldstate) \
> + rcu_boost_dat_stat(rbdp, RCU_BOOST_DAT_BLOCK, oldstate)
> +#define rcu_boost_dat_stat_boost(rbdp, oldstate) \
> + rcu_boost_dat_stat(rbdp, RCU_BOOST_DAT_BOOST, oldstate)
> +#define rcu_boost_dat_stat_unlock(rbdp, oldstate) \
> + rcu_boost_dat_stat(rbdp, RCU_BOOST_DAT_UNLOCK, oldstate)
> +
> +/*
> + * Prefix for kprint() strings for periodic statistics messages.
> + */
> +static char *rcu_boost_state_event[] = {
> + "block:  ",
> + "boost:  ",
> + "unlock: ",
> +};

I don't know for sure, but I *think* that GCC may sometimes generate more
efficient code if you use a char [][], rather than a char *[].

> +
> +/*
> + * Indicators for numbers in kprint() strings.  "!" indicates a state-event
> + * pair that should not happen, while "?" indicates a state that should
> + * not happen.
> + */
> +static char *rcu_boost_state_error[] = {
> +   /*ibBe*/
> + "   ?",  /* block */
> + "!  ?",  /* boost */
> + "?  ?",  /* unlock */
> +};

Likewise.  Also, the columns here don't seem to line up, probably because the
comment uses spaces and the other lines use a tab.

> +static void rcu_boost_dat_stat_print(void)
> +{
> + char buf[N_RCU_BOOST_STATE * (sizeof(long) * 3 + 2) + 2];

This expression really begs for some constants in place of the magic numbers,
or failing that, a comment.

> + int cpu;
> + int event;
> + int i;
> + static time_t lastprint = 0;
> + struct rcu_boost_dat *rbdp;
> + int state;
> + struct rcu_boost_dat sum;
> +
> + /* Wait a graceful interval between printk spamming. */
> +
> + if (xtime.tv_sec - lastprint <
> + CONFIG_PREEMPT_RCU_BOOST_STATS_INTERVAL)
> + return;

How about printk_ratelimit?  It takes a parameter for the rate.  (On the other
hand, it also takes a spinlock, which you might not want here, even in the
stats code.)

> + /* Print them out! */
> +
> + printk(KERN_ALERT
> +"rcu_boost_dat: idx=%d "
> +"b=%ld ul=%ld ub=%ld boost: a=%ld b=%ld\n",
> +rcu_boost_idx,
> +sum.rbs_blocked, sum.rbs_unlock, sum.rbs_unboosted,
> +sum.rbs_boost_attempt, sum.rbs_boost);
> + for (event = 0; event < N_RCU_BOOST_DAT_EVENTS; event++) {
> + i = 0;
> + for (state = 0; state <= N_RCU_BOOST_STATE; state++) {
> + i += sprintf(&buf[i], " %ld%c",
> +  sum.rbs_stats[event][state],
> +  rcu_boost_state_error[event][state]);
> + }
> + printk(KERN_ALERT "rcu_boost_dat %s %s\n",
> +rcu_boost_state_event[event], buf);
> + }

Most or all of these counters could likely become unsigned, since negative
values don't make sense for them.

> + /* Go away and don't come back for awhile. */
> +
> +   

Re: what kernel version embeds r1000 (RTL8168 Eth NICs)

[Bernhard Walle]

* Mihamina Rakotomandimby (R12y) <[EMAIL PROTECTED]> [2007-01-25 02:36]:
> Hello,
> I would like to know what version of the kernel will||had embed(ed) the
> r1000 driver.

The r8169 driver which is in the kernel should have the same
functionality.


Regards,
Bernhard


pgpmmWlm4UwNc.pgp
Description: PGP signature

Re: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Oleg Verych]

gmane.linux.kernel:
> Hi,

Hallo.

> recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> Intel 945 PM PCI-E Chipset, for details see attached log). After booting 
> the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also with 
> the 2.6.19.2, didn't try any other), some strange behaviour can be 
> observed.

There were disscussions about mmconfig and what nightmare it brought to
PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:


> At first the following messages appear in the log:
>
> ...
> [   40.303154] PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
> [   40.303157] PCI: Not using MMCONFIG.
>
> (not sure whether this is really a problem)

I think it may be the major problem.


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

Re: One-shot high-resolution POSIX timer periodically late

[John]

John Stultz wrote:


On Wed, 2007-01-24 at 10:41 +0100, John wrote:


I'm using the POSIX timers API. My platform is x86 running Linux
2.6.18.6 patched with the high-resolution timer subsystem.

http://www.tglx.de/hrtimers.html

I've written a small "de-jittering engine" that receives packets in
small bursts due to network jitter (typical average rate of 1000 packets
per second), and re-sends them at a "smooth" rate.

Just before I re-send a packet, I arm a one-shot timer in order to
receive a signal when it is time to send the next packet.

I've noticed a strange phenomenon that I cannot explain.

Sometimes (rarely) the one-shot timer will expire more than 50 µs later
than expected. This would seem normal, except that it happens periodically.

For example, my app had been running normally for 2 minutes when it
started printing diagnostics (see below).

The first T_NEXT_POP is the date the timer was supposed to expire,

NOW is the date the timer was handled after returning from sigwaitinfo
(I am aware that blocking signals, and handling them at a specific point
in the code will add some latency)

The second T_NEXT_POP is the date the next timer is supposed to expire.

DIFF is the difference between real and expected dates.

(All dates are CLOCK_MONOTONIC by the way.)

As you can see, the first diagnostic came at 472.410501014... Then
another diagnostic almost exactly two seconds apart 9 times in a row!

My process is the only SCHED_FIFO process on the system. There are no
user-space processes with a higher priority. AFAICT, only a kernel
thread could keep the CPU away from my app.

Is there a periodic kernel thread that runs every 2 seconds, cannot be
preempted, and runs for over 50 µs??


This sounds like a BIOS SMI issue. Can you reproduce this behavior on
different hardware?


I am not familiar with the low-level details of the PC.
Let me check Wikipedia...
http://en.wikipedia.org/wiki/System_Management_Mode
SMI = System Management Interrupt


* Since the SMM code (SMI handler) is installed by the system 
firmware (BIOS), the OS and the SMM code may have expectations about 
hardware settings that are incompatible, such as different ideas of how 
the APIC should be set up.


* Operations in SMM take CPU time away from the OS, since the CPU 
state must be stored to memory (SMRAM) and any write back caches must be 
flushed. This can destroy real-time behavior and cause clock ticks to 
get lost.


* A digital logic analyser may be required to determine if SMM is 
occurring.


* Recovering the SMI handler code to analyze it for bugs, 
vulnerabilities, and secrets requires a logic analyzer or dissassembly 
of the system firmware.



Do PCs typically enter System Management Mode periodically?

Is it possible to disable SMM?

According to the Wikipedia article, even the kernel is unaware that
the CPU has entered SMM, is that correct?

I've run my tests on a Dell PC. IIRC, the BIOS options are very basic.

I'll also try another PC as you suggest.

NB: I've attached dmesg and dot.config
If you see anything in there I should have turned on, or that I
should have turned off... (Should I disable power management?)

+

On a related note, John, AFAIU, you wrote the GTOD infrastructure. In my 
app, I need to call clock_gettime(CLOCK_MONOTONIC, ...) very often, i.e. 
around 2000 times every second (when I receive a packet, and when I 
re-send a packet). Is there a way to improve the overhead / latency of 
these calls? I've heard about vsyscalls, are they relevant?


Do I need a specific glibc to use vsyscalls?

If I call clock_gettime(CLOCK_MONOTONIC, &spec) twice in a row, then 
subtract the two timespecs, I get ~1400 ns on a 2.8 GHz P4. AFAIU, my 
clock source is acpi_pm. I tried setting it to tsc but it made hell 
break loose.


http://groups.google.com/group/fa.linux.kernel/msg/a095241d49adfc44?dmode=source

Apparently, 1400 ns is similar to what you observe with acpi_pm.
I suppose I'll need to use the TSC if I want any improvement?

+

Over the past few days, I've sent over 10 messages to the LKML, and none 
of them have been archived. It seems majordomo is dropping my messages. 
Do they look like spam?


Regards.
Linux version 2.6.18.5-hrt ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 PREEMPT 
Thu Dec 7 16:57:14 CET 2006
BIOS-provided physical RAM map:
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 1f77 (usable)
 BIOS-e820: 1f77 - 1f772000 (ACPI NVS)
 BIOS-e820: 1f772000 - 1f793000 (ACPI data)
 BIOS-e820: 1f793000 - 1f80 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fecf - fecf1000 (reserved)
 BIOS-e820: fed2 - fed9 (reserved)
 BIOS-e820: fee0 - fee1 (reserved)
 BIOS-e820: ffb0 - 0001 (reserved)
503MB 

Re: In-tree version of new FireWire drivers available

[Pieter Palmers]

Kristian Høgsberg wrote:

On 1/24/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:

Kristian Høgsberg wrote:

Changes since the merge into the linux1394 tree include:

 - gap count optimization
 - full bus management
 - loopback for async requests to the local node
 - a bug fix for a problem exposed by VIA 6306 controllers
 - a typo fix from the bitfield -> mask+shift conversion.

Kristian,

What is your ETA on a the completion of the isochronous interface?


I'm hoping I can wrap this up within the next 1-2 weeks.  So far I've
been thinking about how to use the dualbuffer receive mode, and it
turns out that it's a little tricky.  It's nothing that can't be
worked around, but I haven't yet made up my mind on the design.

Just to recap, the dual buffer receive mode, as described in section
10.2.3 of the OHCI spec allows us to set up DMA so that a fixed,
quadlet aligned amount of header data can be appended into one buffer
and the rest is appended into another buffer.  This allows us to strip
out the ieee1394 iso header as well as the iec61883 header for those
protocols.  That way DMA can assemble a complete DV frame without CPU
intervention, strip off audio headers or just strip the iso header
like video1394 does, which is sufficient for IIDC cameras.  So this
has the potential of actually replacing video1394 while at the same
time generalizing the iso header stripping feature to be useful for
iec61883 based protocols.

The problem is that the dual buffer descriptor stops appending when
*either* the header buffer or the payload buffer fills up.  When the
payload buffer fills up, and this is what we'll typically hit, the
last packet will continue into the buffer setup in the next desriptor,
and the contents will probably straddle the two buffers.  Each buffer
will be a page in memory and since we map those into user space linear
memory, that's not a problem.

I'd like to make one note here:
We should have a way to use smaller DMA buffers than one page size. If I 
remember correctly, the page size on my system is 4096 bytes, being 1024 
quadlets. If we assume a 4 channel audio stream, this corresponds to 256 
audio samples. This means that the controller generates an interrupt 
every 256 samples, making that we can achieve a latency of 512 samples 
at best. This is unacceptable in a pro-audio environment.


The current stack exhibits this problem, and I solve it by recalculating 
the max packet size, based upon the stream composition (i.e. expected 
packet size) and the requested audio buffer size, such that the 
interrupts are generated at a high enough frequency.


I'm not a kernel hacker, but when looking through the code I had the 
impression that smaller DMA buffers were possible (aren't smaller 
buffers used in packet-per-buffer mode?).




However, the other case is when the header buffer fills up.  In this
case, the DMA engine moves on to the next descriptor in the list and
starts from new in the payload buffer from that descriptor.  This
leaves a gap in the payload buffer associated with the old descriptor.
 Since this gap is within a page, we can't just map it away in the
linear user space mapping of the buffers, user space will see this gap
and have to compensate, by copying, for example.

We obviously want to avoid gaps in the payload buffer, so setting up
these descriptors, we need to make sure that the header buffer is big
enough to hold headers for all the packets it takes to fill up the
payload buffer.  Now the packetization process isn't deterministic -
in simple cases where the remote device is sampling using a clock
based off of the bus clock domain, then, for example, a 48kHz audio
signal can send 6 samples every cycle or maybe 3 packets with 8
samples and one empty packet consistently.  But if the AD converter is
driven using a seperate clock, there is going to be clock skew, and
suddenly there might be an extra empty packet.  And the thing is, even
without the clock skew problem, you don't know how the remote device
is going to throttle the packets.  All this to say that for a given
payload size, there is no way to reliably know how many packets the
remote device will use to transmit that payload.
A gap doesn't necessarily have to be a big problem as long as we know 
its position and size. I don't think it's a lot of overhead to skip a 
gap once in a while. Not having any would be better of course.


The ability to skip a gap will have to be implemented in (some) clients 
anyway, because it is not certain that a no-data packet won't contain 
payload. The current class driver for audio devices from Apple sends 
payload along with it's no-data packets. I don't really know if this is 
according to spec, but I assume so (haven't got them at hand).


In our application (FreeBoB), we know in advance what the size of a 
packet is going to be, as we only use blocking transmission. We also 
know how many (non no-data) packets we want to receive before being 
notified (some fraction of the audio buf

Re: Linux 2.6.20-rc6

[Sunil Naidu]

On 1/25/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:


It's been more than a week since -rc5, but I blame everybody (including
me) being away for Linux.conf.au and then me waiting for a few days
afterwards to let everybody sync up.

So there it is, -rc6, hopefully the last -rc of the series.



It was a cool booting, have really enjoyed this.

I have one question which is open (seems ignored or missed by u guys).

migration_cost=33 for 2.6.20-rc5
migration_cost=159 for 2.6.20-rc6

What does this mean?



Linus


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

Re: NCPFS and brittle connections

[Pierre Ossman]

Ok... how about this baby instead. I've replaced the stack allocated
request structure by one allocated with kmalloc() and reference counted
using an atomic_t. I couldn't see anything else that was associated to
the process, so I believe this should suffice.

(This is just a RFC. Once I get an ok from you I'll put together a more
proper patch mail)

diff --git a/fs/ncpfs/sock.c b/fs/ncpfs/sock.c
index e496d8b..fc6e02d 100644
--- a/fs/ncpfs/sock.c
+++ b/fs/ncpfs/sock.c
@@ -55,6 +55,7 @@ static int _send(struct socket *sock, const void
*buff, int len)
 struct ncp_request_reply {
struct list_head req;
wait_queue_head_t wq;
+   atomic_t refs;
struct ncp_reply_header* reply_buf;
size_t datalen;
int result;
@@ -67,6 +68,32 @@ struct ncp_request_reply {
u_int32_t sign[6];
 };
 
+static inline struct ncp_request_reply* ncp_alloc_req(void)
+{
+   struct ncp_request_reply *req;
+
+   req = kmalloc(sizeof(struct ncp_request_reply), GFP_KERNEL);
+   if (!req)
+   return NULL;
+
+   init_waitqueue_head(&req->wq);
+   atomic_set(&req->refs, (1));
+   req->status = RQ_IDLE;
+
+   return req;
+}
+
+static void ncp_req_get(struct ncp_request_reply *req)
+{
+   atomic_inc(&req->refs);
+}
+
+static void ncp_req_put(struct ncp_request_reply *req)
+{
+   if (atomic_dec_and_test(&req->refs))
+   kfree(req);
+}
+
 void ncp_tcp_data_ready(struct sock *sk, int len)
 {
struct ncp_server *server = sk->sk_user_data;
@@ -106,6 +133,7 @@ static inline void ncp_finish_request(struct
ncp_request_reply *req, int result)
req->result = result;
req->status = RQ_DONE;
wake_up_all(&req->wq);
+   ncp_req_put(req);
 }
 
 static void __abort_ncp_connection(struct ncp_server *server, struct
ncp_request_reply *aborted, int err)
@@ -308,6 +336,7 @@ static int ncp_add_request(struct ncp_server
*server, struct ncp_request_reply *
printk(KERN_ERR "ncpfs: tcp: Server died\n");
return -EIO;
}
+   ncp_req_get(req);
if (server->tx.creq || server->rcv.creq) {
req->status = RQ_QUEUED;
list_add_tail(&req->req, &server->tx.requests);
@@ -478,12 +507,6 @@ void ncpdgram_timeout_proc(struct work_struct *work)
mutex_unlock(&server->rcv.creq_mutex);
 }
 
-static inline void ncp_init_req(struct ncp_request_reply* req)
-{
-   init_waitqueue_head(&req->wq);
-   req->status = RQ_IDLE;
-}
-
 static int do_tcp_rcv(struct ncp_server *server, void *buffer, size_t len)
 {
int result;
@@ -678,25 +701,32 @@ static int do_ncp_rpc_call(struct ncp_server
*server, int size,
struct ncp_reply_header* reply_buf, int max_reply_size)
 {
int result;
-   struct ncp_request_reply req;
-
-   ncp_init_req(&req);
-   req.reply_buf = reply_buf;
-   req.datalen = max_reply_size;
-   req.tx_iov[1].iov_base = server->packet;
-   req.tx_iov[1].iov_len = size;
-   req.tx_iovlen = 1;
-   req.tx_totallen = size;
-   req.tx_type = *(u_int16_t*)server->packet;
-
-   result = ncp_add_request(server, &req);
+   struct ncp_request_reply *req;
+
+   req = ncp_alloc_req();
+   if (!req)
+   return -ENOMEM;
+
+   req->reply_buf = reply_buf;
+   req->datalen = max_reply_size;
+   req->tx_iov[1].iov_base = server->packet;
+   req->tx_iov[1].iov_len = size;
+   req->tx_iovlen = 1;
+   req->tx_totallen = size;
+   req->tx_type = *(u_int16_t*)server->packet;
+
+   result = ncp_add_request(server, req);
if (result < 0) {
return result;
}
-   if (wait_event_interruptible(req.wq, req.status == RQ_DONE)) {
-   ncp_abort_request(server, &req, -EIO);
-   }
-   return req.result;
+   if (wait_event_interruptible(req->wq, req->status == RQ_DONE))
+   result = -EINTR;
+   else
+   result = req->result;
+
+   ncp_req_put(req);
+
+   return result;
 }
 
 /*
@@ -751,11 +781,6 @@ static int ncp_do_request(struct ncp_server
*server, int size,
 
DDPRINTK("do_ncp_rpc_call returned %d\n", result);
 
-   if (result < 0) {
-   /* There was a problem with I/O, so the connections is
-* no longer usable. */
-   ncp_invalidate_conn(server);
-   }
return result;
 }

Rgds

-- 
 -- Pierre Ossman

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

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

Re: [PATCH 1/2]: Fix BUG in cancel_dirty_pages on XFS

[Nick Piggin]

David Chinner wrote:


Only if we leave the page in the page cache. If we toss the page,
the time it takes to do the I/O for the page fault is enough for
the direct I/o to complete. Sure it's not an absolute guarantee,
but if you want an absolute guarantee:


So I guess you *could* relax it in theory... Anyway, don't take
my pestering as advocacy for wanting XFS to do something more
clever in such a corner case. I think you're quite right to be
conservative and share codepaths between direct IO read and
write.

--
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: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra b ios 1.6

[Eamonn Hamilton]

done, bug number #7884

Cheers,
Eamonn

On Thu, 2007-01-25 at 09:17 +, Luming Yu wrote:
> > I didn't get a chance to try the -mm patch, but booting with acpi=off
> > works - other than no acpi, of course :)
> >
> > What now?
> Well, this should be ACPI interrupt configure issue.
> Please feel free to enter a bug on bugzilla.kernel.org.
> And, post acpidump output, /proc/interrupts ,lspci -vvx, dmesg for
> (acpi=off ) there.
> 
> Thanks,
> Luming


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

[Peter Zijlstra]

> Apart from kswapd, limiting pagecache helps performance of
> applications by not eating away their ANON pages or other parts of its
> resident data set.  When there is enough free memory, then there is no
> performance issue.  However memory is always utilized to the max.
> Hence every pagecache page that is allocated should come from some
> application's RSS, or from cold pagecache page.  If that page was
> stolen from some application, then that application pays the price for
> swapping or reading the page back to memory.  This scenario is what we
>  want to avoid.  All that we are trying to achieve is that pagecache
> eats a (unmapped) pagecache page and not steal memory from other
> important application's resident set.
> 
> Certainly this should be a configurable option and kernel's behavior
> should not be changed in general.

Ah, this would be a clear case of the page reclaim selecting the wrong
working set.

It is perfectly fine for a page cache page to evict a app page (be it
anon or not) if that page cache page is used more frequently than the
app page in question.

Trouble seems to be that the current algorithm gets it quite wrong at
times.

Also stating that free memory somehow is good for you is weird, free
memory is a loss, you under utilise your machine. Keeping clean
pagecache pages in there that are likely to be referenced again is a
clear win; it saves the tediously slow load from disk.

So you're now proposing to limit the page cache were as its clear that
the better solution would be to tune replacement policy (and or provide
hints to said mechanism using madvise/fadvise)

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

Strange LKML home page!!!

[Sunil Naidu]

Hello,

I got stunned when I opened www.lkml.org

=> lkml deals psp ipod laptop hotel flight travel holiday lcd
tv mac pc

All junk & nonsence .looks like a Domain seller!!!

What's the problem here?

~Akula2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] suspend/resume debugging: device filter

[Ingo Molnar]

Subject: [patch] suspend/resume debugging: device filter
From: Ingo Molnar <[EMAIL PROTECTED]>

this patch implements the /sys/power/filter attribute, which takes a 
string. If a device's name matches the filter string (exactly), then 
that device is excluded from suspend/resume.

this can be helpful in a number of ways when debugging suspend and 
resume problems:

 - if CONFIG_DISABLE_CONSOLE_SUSPEND is used then the serial
   console is still suspended after which point there's no
   log output. Doing "echo serial > /sys/power/filter" keeps
   the serial port active, so any messages (and crash info)
   after that point is displayed.

 - if a device is suspected to be the reason of resume failure
   then it can be excluded via the filter. That device obviously
   wont work, but users can thus help us debug resume problems
   in combination with pm_trace, without having to hack the kernel.

(note that you can obvious break suspend/resume via the filter, by 
excluding a vital device - so it is only to be used when suspend or 
resume is broken to begin with.)

it might be better to do this centrally in sysfs, via a per-device 
attribute, to individually enable suspend and resume on a per device 
basis, but my sysfs-fu is not strong enough for that now ;-)

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 drivers/base/power/resume.c  |6 
 drivers/base/power/suspend.c |3 +-
 include/linux/resume-trace.h |6 
 kernel/power/main.c  |   58 +++
 4 files changed, 72 insertions(+), 1 deletion(-)

Index: linux/drivers/base/power/resume.c
===
--- linux.orig/drivers/base/power/resume.c
+++ linux/drivers/base/power/resume.c
@@ -24,6 +24,9 @@ int resume_device(struct device * dev)
 {
int error = 0;
 
+   if (power_filter(dev))
+   return 0;
+
TRACE_DEVICE(dev);
TRACE_RESUME(0);
down(&dev->sem);
@@ -52,6 +55,9 @@ static int resume_device_early(struct de
 {
int error = 0;
 
+   if (power_filter(dev))
+   return 0;
+
TRACE_DEVICE(dev);
TRACE_RESUME(0);
if (dev->bus && dev->bus->resume_early) {
Index: linux/drivers/base/power/suspend.c
===
--- linux.orig/drivers/base/power/suspend.c
+++ linux/drivers/base/power/suspend.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include "../base.h"
 #include "power.h"
@@ -78,7 +79,7 @@ int suspend_device(struct device * dev, 
suspend_report_result(dev->class->suspend, error);
}
 
-   if (!error && dev->bus && dev->bus->suspend && 
!dev->power.power_state.event) {
+   if (!error && dev->bus && dev->bus->suspend && 
!dev->power.power_state.event && !power_filter(dev)) {
dev_dbg(dev, "%s%s\n",
suspend_verb(state.event),
((state.event == PM_EVENT_SUSPEND)
Index: linux/include/linux/resume-trace.h
===
--- linux.orig/include/linux/resume-trace.h
+++ linux/include/linux/resume-trace.h
@@ -9,6 +9,8 @@ struct device;
 extern void set_trace_device(struct device *);
 extern void generate_resume_trace(void *tracedata, unsigned int user);
 
+extern int power_filter(struct device *dev);
+
 #define TRACE_DEVICE(dev) set_trace_device(dev)
 #define TRACE_RESUME(user) do {\
if (pm_trace_enabled) { \
@@ -28,6 +30,10 @@ extern void generate_resume_trace(void *
 
 #define TRACE_DEVICE(dev) do { } while (0)
 #define TRACE_RESUME(dev) do { } while (0)
+static inline int power_filter(struct device *dev)
+{
+   return 0;
+}
 
 #endif
 
Index: linux/kernel/power/main.c
===
--- linux.orig/kernel/power/main.c
+++ linux/kernel/power/main.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -306,9 +307,66 @@ pm_trace_store(struct subsystem * subsys
 
 power_attr(pm_trace);
 
+/**
+ * filter - exclude drivers from suspend and resume
+ *
+ * show() returns the current filter
+ *
+ * store() accepts a new filter (up to 128 chars long)
+ *
+ * Do "echo serial > /sys/power/filter" to exclude the
+ * serial driver from suspension - this can be useful to
+ * get kernel messages out after the serial console, or to
+ * see which device causes a resume failure.
+ */
+
+#define FILTER_LEN 128
+
+static char power_filter_str[FILTER_LEN+1] = "";
+
+int power_filter(struct device *dev)
+{
+   const char *str = dev_driver_string(dev);
+
+   if (!strcmp(str, power_filter_str)) {
+   printk(KERN_INFO "power filter match for device: %s\n", str);
+   return 1;
+   }
+   return 0;
+}
+
+static ssize_t filter_show(

Re: Linux 2.6.20-rc6 - build failure

[Eyal Lebedinsky]

i386
Practically all modules selected.

  Building modules, stage 2.
  MODPOST 1931 modules
WARNING: drivers/atm/fore_200e.o - Section mismatch: reference to .init.text: 
from .text between 'fore200e_initialize' (at offset 0x25af) and 
'fore200e_monitor_putc'
WARNING: drivers/atm/lanai.o - Section mismatch: reference to .init.text: from 
.text between 'sram_test_pass' (at offset 0x1a8) and 'sram_test_and_clear'
WARNING: drivers/atm/zatm.o - Section mismatch: reference to .init.text: from 
.text after 'zatm_init_one' (at offset 0x1f25)
WARNING: drivers/atm/zatm.o - Section mismatch: reference to .init.text: from 
.text after 'zatm_init_one' (at offset 0x1f32)
WARNING: drivers/net/rrunner.o - Section mismatch: reference to 
.init.text:rr_init from .text between 'rr_init_one' (at offset 0x1d0) and 
'rr_remove_one'
WARNING: drivers/net/sis900.o - Section mismatch: reference to 
.init.text:sis900_mii_probe from .text between 'sis900_probe' (at offset 0x47b) 
and 'sis900_default_phy'
WARNING: drivers/net/sunhme.o - Section mismatch: reference to .init.text: from 
.text between 'happy_meal_pci_probe' (at offset 0x2add) and 
'happy_meal_pci_remove'
WARNING: drivers/net/tokenring/3c359.o - Section mismatch: reference to 
.init.text:xl_init from .text between 'xl_probe' (at offset 0x1da) and 
'xl_hw_reset'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to 
.init.text: from .text between 'de_init_one' (at offset 0x2151) and 
'de_remove_one'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to 
.init.text: from .text between 'de_init_one' (at offset 0x2158) and 
'de_remove_one'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to 
.init.text: from .text between 'de_init_one' (at offset 0x2220) and 
'de_remove_one'
WARNING: "__udivdi3" [fs/ocfs2/ocfs2.ko] undefined!
make[1]: *** [__modpost] Error 1

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Limit the size of the pagecache

[Vaidyanathan Srinivasan]

Peter Zijlstra wrote:
>> Apart from kswapd, limiting pagecache helps performance of
>> applications by not eating away their ANON pages or other parts of its
>> resident data set.  When there is enough free memory, then there is no
>> performance issue.  However memory is always utilized to the max.
>> Hence every pagecache page that is allocated should come from some
>> application's RSS, or from cold pagecache page.  If that page was
>> stolen from some application, then that application pays the price for
>> swapping or reading the page back to memory.  This scenario is what we
>>  want to avoid.  All that we are trying to achieve is that pagecache
>> eats a (unmapped) pagecache page and not steal memory from other
>> important application's resident set.
>>
>> Certainly this should be a configurable option and kernel's behavior
>> should not be changed in general.
> 
> Ah, this would be a clear case of the page reclaim selecting the wrong
> working set.
> 
> It is perfectly fine for a page cache page to evict a app page (be it
> anon or not) if that page cache page is used more frequently than the
> app page in question.

Well, this is true only as long as all applications running in the
system are graded equally and it is kernel's job to provide the best
of the system resources to all applications.

> Trouble seems to be that the current algorithm gets it quite wrong at
> times.

The current reclaim code does a good job based on the assumption that
pages belonging to different applications have equal priority.  The
aging of the page is independent of application's priority or class.
This is good for best overall system performance.

The new use case that is challenging this assumption is the fact that
application groups fall into different class on the same system and
there is a need to make certain class perform better at the cost of
certain other class of applications.  In this scenario system
performance is not judged by overall average throughput, but by
performance of certain class of applications only.

A backup job running in the database server can take any amount of
performance hit to marginally improve database performance since that
is what the users care about.  We would run into similar situations
when running various virtualization and consolidation solutions.

> Also stating that free memory somehow is good for you is weird, free
> memory is a loss, you under utilise your machine. Keeping clean
> pagecache pages in there that are likely to be referenced again is a
> clear win; it saves the tediously slow load from disk.

Agreed

> 
> So you're now proposing to limit the page cache were as its clear that
> the better solution would be to tune replacement policy (and or provide
> hints to said mechanism using madvise/fadvise)

Well, we may need to use both the approach.  Hints with
madvise/fadvise is definitely a good approach and the kernel should
take these hints aggressively. Yet even with these hints we may want
to have limits in the interest of other applications that do not use
pagecache.

System wide limit to pagecache may not sound very interesting, but if
we think about 'containers' and group of process having such limits it
will have more practical use cases.  An aggregation of process having
 limit on pagecache would give relative importance to certain class of
pages during page replacement.  Controlling limits among group of
applications will help achieve peak application performance with the
applications that we care about.

--Vaidy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] alsa: correct nonsensical sysfs device symlinks

[Pierre Ossman]

Christopher "Monty" Montgomery wrote:
> This patch was generated against 2.6.20-rc5; it fixes a bug that
> cropped up in a late 2.6.19-mm kernel.
> 
> When ALSA's sysfs device creation was converted from using
> class_device_create() to device_create(), the fourth param from
> class_device_create() [dev] was simply plugged into arg 2 of
> device_create().  This causes the device symlinks under all the
> class/sound/[node] to point to nonsensical places.  Among other
> problems, this breaks HAL and all audio software that depends on HAL.
> 

There are no device symlinks anymore, so the current behaviour seems
correct. HAL should follow the symlink, then move up in the device tree
to find a suitable parent.

Rgds
Pierre




signature.asc
Description: OpenPGP digital signature

Re: [patch] suspend/resume debugging: device filter

[Nigel Cunningham]

Hi.

On Thu, 2007-01-25 at 12:05 +0100, Ingo Molnar wrote:
> it might be better to do this centrally in sysfs, via a per-device 
> attribute, to individually enable suspend and resume on a per device 
> basis, but my sysfs-fu is not strong enough for that now ;-)

Yeah. I was thinking recently of doing a per-device attribute, but like
so many things at the moment, getting around to it is a little bit of a
problem.

> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
>  drivers/base/power/resume.c  |6 
>  drivers/base/power/suspend.c |3 +-
>  include/linux/resume-trace.h |6 
>  kernel/power/main.c  |   58 
> +++

Should the sysfs stuff (not just this) be in kernel/power/main.c? I
wonder if it would be better put in drivers/base?

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] suspend/resume debugging: device filter

[Pavel Machek]

Hi!

> Subject: [patch] suspend/resume debugging: device filter
> From: Ingo Molnar <[EMAIL PROTECTED]>
> 
> this patch implements the /sys/power/filter attribute, which takes a 
> string. If a device's name matches the filter string (exactly), then 
> that device is excluded from suspend/resume.
> 
> this can be helpful in a number of ways when debugging suspend and 
> resume problems:
> 
>  - if CONFIG_DISABLE_CONSOLE_SUSPEND is used then the serial
>console is still suspended after which point there's no
>log output. Doing "echo serial > /sys/power/filter" keeps
>the serial port active, so any messages (and crash info)
>after that point is displayed.
> 
>  - if a device is suspected to be the reason of resume failure
>then it can be excluded via the filter. That device obviously
>wont work, but users can thus help us debug resume problems
>in combination with pm_trace, without having to hack the kernel.
> 
> (note that you can obvious break suspend/resume via the filter, by 
> excluding a vital device - so it is only to be used when suspend or 
> resume is broken to begin with.)

Should this go to Documentation/power?

> it might be better to do this centrally in sysfs, via a per-device 
> attribute, to individually enable suspend and resume on a per device 
> basis, but my sysfs-fu is not strong enough for that now ;-)

Yep, I think it should go to per-device attribute. Also it would be
nice to name it somehow like debug_suspend_filter or something, so
that people have less tendency to play with it.
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: mailing list

[Jesper Juhl]

On 24/01/07, Fabien Mercier <[EMAIL PROTECTED]> wrote:

I am working in video card development and I would like to be on your
mailing list.


http://www.tux.org/lkml/#s3-1

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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/

[patch] suspend debugging: simulate suspend-to-RAM

[Ingo Molnar]

Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <[EMAIL PROTECTED]>

most resume bugs are due to the kernel hanging or crashing while trying 
to resume a specific device. It is extremely hard to debug such hangs 
because often when the hang happens there's no console available yet.

Make debugging such bugs easier by offering a resume mode that does not 
actually call into the BIOS to turn off the machine. This, in 
combination with earlyprintk=serial,ttyS0,115200,keep , 
CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and 
/sys/power/filter enables me to have a fully functional serial console 
during the full suspend/resume cycle.

I debugged two suspend bugs in the -rt kernel this way already, so it's 
pretty useful.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 Documentation/kernel-parameters.txt |4 
 drivers/acpi/sleep/main.c   |   15 ++-
 include/linux/acpi.h|1 +
 kernel/sysctl.c |   16 
 4 files changed, 35 insertions(+), 1 deletion(-)

Index: linux/Documentation/kernel-parameters.txt
===
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
@@ -159,6 +159,10 @@ and is between 256 and 4096 characters. 
 
acpi_osi=   [HW,ACPI] empty param disables _OSI
 
+   acpi_simulate_suspend_to_ram
+   [KNL] Do not call into BIOS to do suspend-to-RAM
+   Format: <0/1>
+
acpi_serialize  [HW,ACPI] force serialization of AML methods
 
acpi_skip_timer_override [HW,ACPI]
Index: linux/drivers/acpi/sleep/main.c
===
--- linux.orig/drivers/acpi/sleep/main.c
+++ linux/drivers/acpi/sleep/main.c
@@ -35,6 +35,14 @@ static u32 acpi_suspend_states[] = {
 
 static int init_8259A_after_S1;
 
+/*
+ * simulate entry into the BIOS - this way the system will not
+ * be turned off for real, and the kernel's resume functionality
+ * can be debugged while still having some system capabilities
+ * left. This is especially useful in combination with /sys/power/filter.
+ */
+int acpi_simulate_suspend_to_ram;
+
 /**
  * acpi_pm_prepare - Do preliminary suspend work.
  * @pm_state:  suspend state we're entering.
@@ -91,7 +99,12 @@ static int acpi_pm_enter(suspend_state_t
break;
 
case PM_SUSPEND_MEM:
-   do_suspend_lowlevel();
+   if (unlikely(acpi_simulate_suspend_to_ram)) {
+   printk(KERN_INFO "ACPI: simulating suspend-to-RAM: "
+"not calling BIOS.\n");
+   } else {
+   do_suspend_lowlevel();
+   }
break;
 
case PM_SUSPEND_DISK:
Index: linux/include/linux/acpi.h
===
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -438,6 +438,7 @@ extern int pci_mmcfg_config_num;
 
 extern int sbf_port;
 extern unsigned long acpi_video_flags;
+extern int acpi_simulate_suspend_to_ram;
 
 #else  /* !CONFIG_ACPI */
 
Index: linux/kernel/sysctl.c
===
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -329,6 +329,14 @@ static ctl_table kern_table[] = {
.proc_handler   = &proc_dointvec,
},
{
+   .ctl_name   = CTL_UNNUMBERED,
+   .procname   = "futex_performance_hack",
+   .data   = &futex_performance_hack,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = &proc_dointvec,
+   },
+   {
.ctl_name   = KERN_PANIC,
.procname   = "prof_pid",
.data   = &prof_pid,
@@ -908,6 +916,14 @@ static ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = &proc_doulongvec_minmax,
},
+   {
+   .ctl_name   = CTL_UNNUMBERED,
+   .procname   = "acpi_simulate_suspend_to_ram",
+   .data   = &acpi_simulate_suspend_to_ram,
+   .maxlen = sizeof (int),
+   .mode   = 0644,
+   .proc_handler   = &proc_dointvec,
+   },
 #endif
 #ifdef CONFIG_IA64
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Limit the size of the pagecache

[Al Boldi]

Peter Zijlstra wrote:
> > Apart from kswapd, limiting pagecache helps performance of
> > applications by not eating away their ANON pages or other parts of its
> > resident data set.  When there is enough free memory, then there is no
> > performance issue.  However memory is always utilized to the max.
> > Hence every pagecache page that is allocated should come from some
> > application's RSS, or from cold pagecache page.  If that page was
> > stolen from some application, then that application pays the price for
> > swapping or reading the page back to memory.  This scenario is what we
> >  want to avoid.  All that we are trying to achieve is that pagecache
> > eats a (unmapped) pagecache page and not steal memory from other
> > important application's resident set.
> >
> > Certainly this should be a configurable option and kernel's behavior
> > should not be changed in general.
>
> Ah, this would be a clear case of the page reclaim selecting the wrong
> working set.

Yes.

> It is perfectly fine for a page cache page to evict a app page (be it
> anon or not) if that page cache page is used more frequently than the
> app page in question.

It seems, that there is currently a clear preference for pagecache-page over 
app-page.  Some form of prio-selection could probably aid the situation.

> Trouble seems to be that the current algorithm gets it quite wrong at
> times.

It breaks down when memory gets tight.  You can actually hear it thrashing 
the disk, although it's not supposed to thrash, even with swapoff.

> Also stating that free memory somehow is good for you is weird, free
> memory is a loss, you under utilise your machine. Keeping clean
> pagecache pages in there that are likely to be referenced again is a
> clear win; it saves the tediously slow load from disk.

That's the theory.

> So you're now proposing to limit the page cache

As a workaround.

> where as its clear that
> the better solution would be to tune replacement policy

Yes.  Hopefully successfully.

> (and or provide
> hints to said mechanism using madvise/fadvise)

Not feasible; source is sometimes not immediately available.


Thanks!

--
Al

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

[Al Boldi]

Vaidyanathan Srinivasan wrote:
> Al Boldi wrote:
> > Rik van Riel wrote:
> >> Christoph Lameter wrote:
> >>> This is a patch using some of Aubrey's work plugging it in what is
> >>> IMHO the right way. Feel free to improve on it. I have gotten
> >>> repeatedly requests to be able to limit the pagecache.
> >>
> >> IMHO it's a bad hack.
> >>
> >> It would be better to identify the problem this "feature" is
> >> trying to fix, and then fix the root cause.
> >
> > Ok, here is the problem:  kswapd.
> >
> > Limiting the page-cache memory inhibits invoking kswapd needlessly,
> > aiding performance and easing OOM pressures.
>
> Apart from kswapd, limiting pagecache helps performance of
> applications by not eating away their ANON pages or other parts of its
> resident data set.  When there is enough free memory, then there is no
> performance issue.  However memory is always utilized to the max.
> Hence every pagecache page that is allocated should come from some
> application's RSS, or from cold pagecache page.  If that page was
> stolen from some application, then that application pays the price for
> swapping or reading the page back to memory.  This scenario is what we
>  want to avoid.  All that we are trying to achieve is that pagecache
> eats a (unmapped) pagecache page and not steal memory from other
> important application's resident set.

Agreed 100%.  Thanks for expanding exactly what I meant.

> Certainly this should be a configurable option and kernel's behavior
> should not be changed in general.
>
> > I tried the patch; it works.
> >
> :)
> :
> > But it needs a bit of debugging.  Setting pagecache_ratio = 1 either
> > deadlocks or reduces thru-put to < 1mb/s.
>
> Yes, going below 5% on my 1GB RAM machine causes severe performance
> problems.  We need to hard wire a reasonable lower limit and not
> provide a noose for the end user to tie around!

One reason to test full range settings, is to expose underlying system 
problems, like scalability.  By limiting the range, you only hide a problem 
that was exposed.


Thanks!

--
Al

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

Re: One-shot high-resolution POSIX timer periodically late

[John]

[ Re-sending in the hope that it will be archived ]

Ingo Molnar wrote:


John Stultz wrote:


On Wed, 2007-01-24 at 10:41 +0100, John wrote:


I'm using the POSIX timers API. My platform is x86 running Linux
2.6.18.6 patched with the high-resolution timer subsystem.

http://www.tglx.de/hrtimers.html

My process is the only SCHED_FIFO process on the system. There are 
no user-space processes with a higher priority. AFAICT, only a 
kernel thread could keep the CPU away from my app.


Is there a periodic kernel thread that runs every 2 seconds, cannot 
be preempted, and runs for over 50 µs??


This sounds like a BIOS SMI issue. Can you reproduce this behavior on 
different hardware?


note that only the -hrt patchset is used - not the full -rt patchset
- so 50 usecs delays (and more) are quite possible and common.


Ingo,

You are correct, I only used -hrt.
I will _definitely_ give -rt a try.

I am fully aware that an occasional 100 µs delay is possible, given a
soft real-time operating system. However, what I cannot explain is:

Why do these /occasional/ delays always happen a multiple of 2 seconds
apart? Can you explain this odd behavior?


My question would be: does the same problem occur with the full -rt
patchset and PREEMPT_RT? (see http://rt.wiki.kernel.org for details)


I will test on a different PC, as John suggested.
I will try the full -rt patchset in a few days.

+

On a related note, there is no -hrt patch for 2.6.19:
http://www.tglx.de/projects/hrtimers/
Is it because the patch for 2.6.19-rc4-mm1 applies cleanly to 2.6.19?

There is no -hrt patch for 2.6.20.
Has it been completely merged?

Regards.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc4 gfs2 bug

[Steven Whitehouse]

Hi,

On Thu, 2007-01-25 at 00:07 -0500, Dan Merillat wrote:
> Running 2.6.20-rc4 _WITH_ the following patch: (Shouldn't be the issue,
> but just in case, I'm listing it here)
> 
> Date: Fri, 29 Dec 2006 21:03:57 +0100
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Subject: [patch] remove MAX_ARG_PAGES
> Message-ID: <[EMAIL PROTECTED]>
> 
> Linux fileserver 2.6.20-rc4MAX_ARGS #4 PREEMPT Fri Jan 12 03:58:25 EST 2007 
> x86_64 GNU/Linux
> 
> This happened when I started testing gfs2 for the first time.  I
> installed userspace from CVS, loaded the gfs2/dlm modules, mkfs.gfs2,
> then "mount -t gfs2 -v /dev/vg1/gfs2 /mnt/gfs"
> 
> This was the initial mount of the new filesystem.  I can create
> directories, but attempting a stress-test with bonnie seems to have
> deadlocked something.  (at "Start 'em", immediately.)
> 
> To clarify: the two oopses happened at first mount.  After that, I
> created files/directories, then attempted to stress it a bit with
> bonnie++.  No further oops/dmesg output.
> 
Are you in a position to test a kernel without preempt? I have a
sneeking suspicion that its related to that.

> For the GFS2 folks, latest CVS gfs_tool doesn't have lockdump, is there
> any way to examine what I'm stuck on?
> 
There isn't anything similar at the moment, however we do know about
that and there is a bugzilla entry relating to it, #221300. I don't
think that in this case it will help though since I think this is
something more fundamental in the locking code.

I'll see if I can reproduce something similar locally in the mean time,

Steve.


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

Re: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Martin Drab]

On Thu, 25 Jan 2007, Oleg Verych wrote:

> gmane.linux.kernel:
> > recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> > Intel 945 PM PCI-E Chipset, for details see attached log). After booting 
> > the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also with 
> > the 2.6.19.2, didn't try any other), some strange behaviour can be 
> > observed.
> 
> There were disscussions about mmconfig and what nightmare it brought to
> PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:
> 
> 
> > At first the following messages appear in the log:
> >
> > ...
> > [   40.303154] PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
> > [   40.303157] PCI: Not using MMCONFIG.
> >
> > (not sure whether this is really a problem)
> 
> I think it may be the major problem.

Hmm, it may be. Was there suggested any solution (or at least proposal) 
that I may try?

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

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Bodo Eggert]

Scott Preece <[EMAIL PROTECTED]> wrote:

> My own hot button is making sure that the definition of what
> constitutes user activity is managed in exactly one place, whether in
> the kernel or not. My naive model would be to put the response at user
> level, but to provide a single point of definition in the kernel (say,
> /dev/useractivity or the equivalent) that the user-level daemon could
> listen to.

Imagine one computer serving two users. Two monitors, two keyboards ...
-- 
Funny quotes:
38. Last night I played a blank tape at full blast. The mime next door went
nuts.
Friß, Spammer: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

que: How can we Eliminate the DMA Zone from the kernel?

[Seetharam Dharmosoth]

Hi,

Want to remove DMA zone the from the Linux Kernel.
(Don't want to use DMA Zone, because i am not
using ISA bus, am using PCI bus. So, I don't need
this)

Can you please give me suggestions in this regards.

Thanks
RAM





__
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.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: SATA hotplug from the user side ?

[Soeren Sonnenburg]

On Wed, 2007-01-24 at 13:37 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 24 Jan 2007, Soeren Sonnenburg wrote:
> > might be a good idea to power down the drive using hdparm -Y followed by
> > a scsiadd -r.
[...]
> > the disk or remove the disk from a dm setup). However it is recommended
> > to power down the drive using hdparm -Y followed by a scsiadd -r as
> > stated above. One can validate which disks are attached using ``scsiadd
> 
> Again, this might change soon.

Ok, I think someone more knowledgable than me in this area should do the
final polishing und put it in the docs.

I don't anymore see how/that I can help here.
Soeren
-- 
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] suspend debugging: simulate suspend-to-RAM

[Pavel Machek]

Hi!

> Subject: [patch] suspend debugging: simulate suspend-to-RAM
> From: Ingo Molnar <[EMAIL PROTECTED]>
> 
> most resume bugs are due to the kernel hanging or crashing while trying 
> to resume a specific device. It is extremely hard to debug such hangs 
> because often when the hang happens there's no console available
> yet.

While the functionality is useful, no I do not think this should be
configured by sysctl or kernel parameter.

Perhaps right interface is "echo fake-mem > /sys/power/state"? 

Pavel

> Index: linux/kernel/sysctl.c
> ===
> --- linux.orig/kernel/sysctl.c
> +++ linux/kernel/sysctl.c
> @@ -329,6 +329,14 @@ static ctl_table kern_table[] = {
>   .proc_handler   = &proc_dointvec,
>   },
>   {
> + .ctl_name   = CTL_UNNUMBERED,
> + .procname   = "futex_performance_hack",
> + .data   = &futex_performance_hack,
> + .maxlen = sizeof(int),
> + .mode   = 0644,
> + .proc_handler   = &proc_dointvec,
> + },
> + {
>   .ctl_name   = KERN_PANIC,
>   .procname   = "prof_pid",
>   .data   = &prof_pid,

Leftover hunk?


-- 
(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: How to get /dev entry created automaticly for dynamic major number?

[Markku Savela]

Solution found!

> On Thu, Jan 25, 2007 at 09:35:07AM +0200, Markku Savela wrote:
> > If want to write a loadable module which "implements" a char device
> > ("virtual", no real device present). How do I get the correct
> > "/dev/foo" to appear automaticly?

> From: Greg KH <[EMAIL PROTECTED]>

> If you look in the book, Linux Device Drivers, third edition, free
> online, there's a section on what is needed for udev to work properly.
> 
> The ideas are still the same, but the way to do it has changed since the
> book was written.  Just use a struct device and a class, and you will be
> fine.  Look at the misc device core or the mem code in
> drivers/char/mem.c for examples of what you need to do.

Thanks! The solution seems to work. The final *obstacle* was, that
class_* symbols were not available until I added the
LICENSE("GPL"). Here is the resulting template, maybe useful for
someone, and just for verification, that I got it right.

...
static int foo_major = 0;
static struct class *foo_class;
static struct class_device *foo_device;
...

static int __init foo_init(void)
  {
foo_major = 0;
foo_class = NULL;
foo_device = NULL;

foo_major = register_chrdev(foo_major, "foo", &foo_fops);
if (foo_major <= 0)
return -EIO;
foo_class = class_create(THIS_MODULE, "foo");
if (IS_ERR(foo_class))
   {
   return PTR_ERR(foo_class);
   }
foo_device = class_device_create(foo_class, NULL, MKDEV(foo_major, 0), 
NULL, "foo0");
if (IS_ERR(foo_device))
   {
   return PTR_ERR(foo_device);
   }
return 0;
}

static void __exit foo_exit(void)
{
if (foo_device && !IS_ERR(foo_device))
   class_device_del(foo_device);
if (foo_class && !IS_ERR(foo_class))
   class_destroy(foo_class);
if (foo_major > 0)
   unregister_chrdev(foo_major, "foo");
}

module_init(foo_init);
module_exit(foo_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Markku Savela");
MODULE_DESCRIPTION("Just fooling around");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[David Brownell]

On Wednesday 24 January 2007 8:47 pm, Hans-Peter Nilsson wrote:
> (Please CC me on replies, I'm not subscribed to LKML.  Thanks.)
> 
> Five SPI-related patches follow.
> 
> 1: bugfix for spi_bitbang: always call the setup_transfer
> function via the overridable pointer.
> 
> 2: Allow clocking SPI with chip-select inactive.
> 
> 3: Define the bit-value transmitted for SPI transfers with no tx_buf.
> 
> 4: Update of David B.'s (et al) kind-of-proof-of-concept
> MMC <-> SPI glue driver mmc_spi posted on Aug 1, found at e.g.
> http://www.gossamer-threads.com/lists/linux/kernel/671939#671939>.
> 
> 5: SPI cleanup should not have const on its argument.

Cool ... two of those (#1, #5) seem ok to merge right now, and
I expect that #2 can go in with only minor tweaks.

#3 needs more attention (see my response) and I'll have to look
at #4 soon.

Thanks for looking at this.  I know various folk have needed to
have MMC/SD working over SPI for some time, and was hoping that
someone else would make time to take that code the next few steps
on the way.  Just like you did!

So to summarize ... you now have MMC-over-SPI working on CRIS
hardware, with these patches?   Can you yet run filesystem
stress tests with ext3 on such an MMC card, or is this more at
the level of everything working with light/early test loads,
so it's time to see if other folk can reproduce your results?

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

Re: [PATCH] 4/5: Updates to SPI and mmc_spi: mmc_spi updated, kernel 2.6.19

[David Brownell]

Whew, you clearly put enough work into this to get it working!  Thanks.
I look forward to trying it at some point.  (I have some new hardware
in hand that should make that possible.)


On Wednesday 24 January 2007 8:53 pm, Hans-Peter Nilsson wrote:
> (Please CC me on replies, I'm not subscribed to LKML or the SPI list.  
> Thanks.)
> 
> I see no signed-off-by line on
> http://www.gossamer-threads.com/lists/linux/kernel/671939#671939>
> or the linked message.  I hope and believe that's just an
> oversight.  David Brownell and Mike Lavender, do you know if all
> is clear and you can sign-off on that patch retroactively?

My 'signed off' was omitted intentionally, because I wasn't
actually submitting the patch.  It needed work.  :)

Can't speak for Mike, but what he seeded me with was a
tarball that worked with a preliminary version of the SPI
stack on a ColdFire uClinux package.   Not a patch.


> Changes from the previously posted version, above:
> 
> Updated to fit 2.6.19.  Nothing big; a few includes, changing
> pr_debug to dev_dbg, adjusting the arguments to one
> supposedly-irq-function and using mrq->data->blksz instead of
> mrq->data->blksz_bits.

Yeah, I have such changes in my updated version too.


> I removed those spi_claim calls; they don't compile.  There's no
> such thing as spi_claim, and no "claim" seems to be needed;
> chip-select is asserted at the start of each spi-message and
> deasserted afterwards.  Maybe this was something that escaped
> from other work-in-progress or remnants of some older interface?

You should have asked for the implementation.  The idea was
that I'd find out who was working with that code!  ISTR posting
both patches a while back.

The claim is necessary, because otherwise there's no way to
ensure that the chipselect stays active in various parts of
the protocol that require it.  A given MMC transaction can
require multiple spi_message invocations, and without the
claim there is no way to _guarantee_ that the chipselect is
not dropped ... the bus could be given for example to some
other SPI device while the MMC-over-SPI driver was figuring
out the next transaction to issue.

 
> I noticed the hard way that mmc_spi_setup_message left most of
> the main message "t" transfer initialized due to a missing "*".
> This'd leave rx_buf and dma addresses with values from the
> previous message...

That could be a problem.  :)

 
> Basing critical timeouts in busy-loops on counting "jiffies" is
> bad, if you're prone to be scheduled out.  When putting a system
> using bitbanged GPIO or "shiftregister" SPI under load, I
> noticed the mmcqd thread being scheduled out (supposedly a
> penalty for being a CPU hog), and it didn't get back in until
> the timeout.  Presto, read and write errors.  Better base the
> timeout on the number of bytes that can theoretically be scanned
> in the time before the timeout.  The real timeout will then be
> much larger on a system under load, but I don't see how that can
> be worse than either playing tricks with the scheduler or
> suffering timeouts.  Alternatively, the timeout could stay
> jiffies-based, but having one more scan when the timeout is
> reached, but that'd be just a little more complicated code (two
> paths; one normal and one normal-after-timeout) for no apparent
> gain.  To somewhat help a system using bitbanged SPI, I tried
> putting schedule() calls right before the read-block and
> write-block mmc_spi_scanbyte calls, when delays are expected
> anyways.  There was no change in performance for a truly
> bitbanged SPI nor shiftregister SPI, but at least I tried that,
> as well as msleep in mmc_spi_busy (see the comment).

Yeah, that timeout mechanism was more of a "write one quick"
than something that handled all the necessary corner cases.

 
> The "stop"-part of an MMC-request wasn't handled.  My only guess
> how this could have worked is that the MMC stack for some reason
> didn't issue read-multiple commands to mmc_spi before.

ISTR not reliably getting to the point where STOP would be issued.
You must have fixed at least some of the issues in the way ... :)


> Sending the SPI_TOKEN_STOP_TRAN after a multi-block write wasn't
> implemented, just as a FIXME.  As for read commands, I guess
> mmc_spi just didn't see them before.

Likewise.  I translated Mike's code to the newer version of the
SPI framework, added a generalizable solution to that claim/release
problem (he had one specific to his ColdFire system), and made it
get part way through enumeration.  At that point, I expected it
would be best if some other folk helped, as you've done!

 
> The MMC_SEND_CID command apparently never had showed before and
> I don't know how card status changes were noticed.

It's been some time since I looked at that, but ISTR that there
was special casing to handle that.  Isn't that one of the commands
that doesn't make sense over SPI, but which the MMC core insists
on issuing anyway?


> The check for data response after (single and multi

Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19

[David Brownell]

On Wednesday 24 January 2007 8:50 pm, Hans-Peter Nilsson wrote:
> +* some cards seemed happier if they were initialized first
> +* by the native MMC stack, not SPI ... and in other cases
> +* rmmod/modprobe of mmc_spi helped the card work better,
> +* even without power cycling
> +*
> +* FIXME find out what that important state is, which is
> +* not reset here... and makes robustness problems
> 
> I think I've spotted the problem, or at least a problem with a
> solution that fits the description.

Good, that was nasty ...

>   What's missing is "at least 
> 74 SD clocks to the SD card with keeping CMD line to high. In
> case of SPI mode, CS shall be held to high during 74 clock
> cycles" (from Section 6.4.1, in "Simplified Physical Layer
> Specification 2.0").  This is to happen before sending CMD0.  I
> have only one card (of 7) where this fails, a Viking Interworks
> 256 MB card.  It matches the description in the comment; it
> never initializes, gives invalid replies (with bit 7 set)
> without this, but works fine with it.

That rings a bell.


> The gotcha is that the SPI framework didn't have a way to
> express transfers with chip-select inactive.  Sure, you can set
> chip-select to inactive for a period of *time*, but never while
> also toggling the clock.  So here's an implementation for that.

Just so we don't lose count here:  this is the *third* example of
an SPI protocol tweaking option that seems to be needed just to
support an MMC-over-SPI stack:

 - Claiming the SPI bus so that chipselect can stay high even
   between spi_message interactions (although you seemed not to
   run into that one);

 - Efficiency in the routine "poll for status" operation, where
   data must be read over MISO (CS high) until 0xff bytes stop;

 - This issue, where a deselected device must be clocked.

I knew that not every SPI controller driver would be able to
support that particular stack...

 
> I made this functionality optional, with the updated mmc_spi
> driver trying anyway if the spi host doesn't provide the
> function.  So, no SPI drivers require updating, unless they
> really want to work with mmc_spi flawlessly with all cards.

At a first glance, this seems like a reasonable approach.
Let me think about it a bit.  The ability for a controller
driver to advertise a capability is reasonable, but so far
it hasn't been used with SPI.  (It ought to suffice just to
reject unsupported requests, modulo the issue of trying to
sort out exactly what was unsupported.)


> I initially thought the function important enough to warrant
> mandatory implementation for all SPI drivers, but it hasn't been
> needed before, so I reconsidered.

Right.  Unfortunately there's not a lot of protocol tweaking
support we can currently expect to be "mandatory".  Testing
such requirements would be problematic too.


> Also, some SPI drivers seem 
> to implement the chip-select function as optional, a clear hint
> to this being optional IMHO.

There's no "chip select" feature in the API.  It's only part of
the protocol described by messages delivered to the controller
driver.  Don't confuse the "bitbang" framework (which works with
more than just bitbanged hardware, of course) with the API; it's
just an implementation aid, and not one that all implementors
would choose to use.


> I looked at the existing drivers 
> and went as far as writing proof-of-concept patches for them,
> but as I can't test them, I'll just stop there and call that a
> feasibility study.  The spi_bitbang looked like it could have
> always can_cs_inactive = 1, but then I noticed what
> spi_mpc83xx.c does in its mpc83xx_spi_chipselect() (register
> writes only on BITBANG_CS_ACTIVE supposedly controlling the
> clock) and so I think setting the capability is better be left
> to the respective caller (typically just before its call to
> spi_bitbang_start), and just adjust the various chipselect calls
> i spi_bitbang.

Sounds fair. 

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

Re: [PATCH] 3/5: Updates to SPI and mmc_spi: tx_default, kernel 2.6.19

[David Brownell]

On Wednesday 24 January 2007 8:52 pm, Hans-Peter Nilsson wrote:
> (Please CC me on replies, I'm not subscribed to LKML or the SPI list.  
> Thanks.)
> 
> The SD/MMC SPI-based protocol isn't really duplex.  In the
> normal case there's either information transmitted or received,
> not both simultaneously.  The unused data is always 0xff; ones.
> Unfortunately, the SPI framework leaves outgoing data for a
> left-out tx_buf just as "undefined"

In current kernels that's actually changed.  The value to be shifted
out is now specified ... as all-zeroes, which is what various chips
need to receive, and various (half-duplex/Microwire) controllers seem
to be doing in any case.

If that's an issue -- and MMC-over-SPI needs to specify some other
value -- then please re-issue this patch against 2.6.20, including
the update to the bitbang driver ("reference implementation").

I think a better way to package this would be to define a new
flag for spi->mode, since controller drivers are already supposed
to be checking that to make sure they handle all the options which
have been specified.  That flag could work in conjunction with
a byte provided in the spi_device, that would be used instead of
zero.  (Some folk have noted that when debugging, it's easier if
the pattern there is neither all-ones nor all-zeroes ... something
that a digital scope will show is easier to work with.)

- Dave



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

Re: How to get /dev entry created automaticly for dynamic major number?

[Markku Savela]

Oops!

The error exits are not right in foo_init (need to release anything
succesfully created, if later operations fail). Probably need to make
the current foo_exit into foo_cleanup and call it in real foo_exit and
in any errors at foo_init.

But, again thanks for the help. I consider the "case closed" now.

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

[ANNOUNCE] System Inactivity Notifier v1.6

[Alessandro Di Marco]

Hi all,

I've attached the final version of SIN, a user inactivity monitor posted few
days ago on this list.  Since then a couple of things have been improved. For
example, the acpi events have been substituted by _uevents_ (thanks Arjan for
the hint!), _sysfs_ has been preferred to procfs and the event triggering logic
has been optimized. Moreover, this version takes advantage from the PM
callbacks, in order to correctly preserve the state among several
suspend/resume cycles.  The patch also contains what is needed to test
conveniently the driver with udev-103. Thanks to all for the support.

Best,
Alessandro

diff -ur --new-file SIN/Makefile SIN-NEW/Makefile
--- SIN/Makefile	1970-01-01 01:00:00.0 +0100
+++ SIN-NEW/Makefile	2007-01-25 14:07:44.0 +0100
@@ -0,0 +1,43 @@
+MODLPATH = kernel/drivers/char
+
+#DEBUG="-D SIN_DEBUG"
+
+MODL = sinmod
+OBJS = sin.o sysfs.o table.o input_enumerator.o
+
+SRCS := $(patsubst %.o,%.c,$(OBJS))
+HDRS := $(patsubst %.o,%.h,$(OBJS))
+CMDS := $(patsubst %.o,.%.o.cmd,$(OBJS))
+
+ifneq ($(KERNELRELEASE),)
+	EXTRA_CFLAGS := $(DEBUG)
+	obj-m := $(MODL).o
+	$(MODL)-objs := $(OBJS)
+else
+	KDIR := /lib/modules/$(shell uname -r)/build
+	PWD := $(shell pwd)
+
+all:	$(MODL).ko
+
+$(MODL).ko:	$(SRCS) $(HDRS)
+	@$(MAKE) -C $(KDIR) M=$(PWD) modules
+
+im:	$(MODL).ko
+	@sudo insmod $(MODL).ko
+
+rm:
+	@sudo rmmod $(MODL)
+
+rmf:
+	@sudo rmmod -f $(MODL)
+
+install:
+	@sudo $(MAKE) INSTALL_MOD_DIR=$(MODLPATH) -C $(KDIR) M=$(PWD) modules_install
+
+modules_install:
+	@$(MAKE) INSTALL_MOD_DIR=$(MODLPATH) -C $(KDIR) M=$(PWD) modules_install
+
+clean:
+	@$(MAKE) -C $(KDIR) M=$(PWD) clean
+	@rm -f Module.symvers
+endif
diff -ur --new-file SIN/debug.h SIN-NEW/debug.h
--- SIN/debug.h	1970-01-01 01:00:00.0 +0100
+++ SIN-NEW/debug.h	2007-01-25 14:07:39.0 +0100
@@ -0,0 +1,36 @@
+/*
+ *  Copyright (C) 2007 Alessandro Di Marco
+ */
+
+/*
+ *  This file is part of SIN.
+ *
+ *  SIN is free software; you can redistribute it and/or modify it under the
+ *  terms of the GNU General Public License as published by the Free Software
+ *  Foundation; version 2 of the License.
+ *
+ *  SIN is distributed in the hope that it will be useful, but WITHOUT ANY
+ *  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ *  FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
+ *  details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with SIN; if not, write to the Free Software Foundation, Inc., 51 Franklin
+ *  St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef DEBUG_H
+#define DEBUG_H
+
+#ifdef SIN_DEBUG
+extern int debug;
+#define set_debug(val) debug = (val)
+#define printd(fmt...) if (unlikely(debug)) { printk("SIN: " fmt); }
+#else
+#define SORRY "SIN: debugging support was disabled at compile time, sorry!\n"
+
+#define set_debug(val) if (val) { printk(KERN_DEBUG SORRY); }
+#define printd(fmt...)
+#endif
+
+#endif /* DEBUG_H */
diff -ur --new-file SIN/etc/sin/rules.sh SIN-NEW/etc/sin/rules.sh
--- SIN/etc/sin/rules.sh	1970-01-01 01:00:00.0 +0100
+++ SIN-NEW/etc/sin/rules.sh	2007-01-25 14:16:30.0 +0100
@@ -0,0 +1,43 @@
+#!/bin/bash
+
+set $*
+
+case "${HINT}" in
+resume)
+#	if [ -f /dev/shm/blanked ] ; then
+#	XAUTHORITY=/home/`/bin/ps x | /bin/grep tty11 | /bin/grep auth | /usr/bin/cut -d / -f 3`/.Xauthority xset -display :0 dpms force on
+#	/usr/bin/smartdimmer -f `cat /dev/shm/light` -e ${UNBLANK_SPEED}
+#	rm -f /dev/shm/light
+#	rm -f /dev/shm/blanked
+#	else
+#	/usr/bin/smartdimmer -f `cat /dev/shm/light` -e ${FADING_SPEED}
+#	rm -f /dev/shm/light
+#	fi
+
+	logger "resuming..."
+	;;
+
+dim)
+#	/usr/bin/smartdimmer -g | /usr/bin/cut -d ':' -f 2 > /dev/shm/light
+#	/usr/bin/smartdimmer -f 1 -e ${FADING_SPEED}
+
+	logger "dimming..."
+	;;
+
+blank)
+#	XAUTHORITY=/home/`/bin/ps x | /bin/grep tty11 | /bin/grep auth | /usr/bin/cut -d / -f 3`/.Xauthority xset -display :0 dpms force off
+#	touch /dev/shm/blanked
+
+	logger "blanking..."
+	;;
+
+sleep)
+#	echo mem >/sys/power/state
+
+	logger "suspending..."
+	;;
+
+*)
+	logger "SIN hint unhandled: ${HINT}"
+	;;
+esac
diff -ur --new-file SIN/etc/sin/setup.sh SIN-NEW/etc/sin/setup.sh
--- SIN/etc/sin/setup.sh	1970-01-01 01:00:00.0 +0100
+++ SIN-NEW/etc/sin/setup.sh	2007-01-25 14:13:59.0 +0100
@@ -0,0 +1,11 @@
+#!/bin/bash
+
+set $*
+
+STATE="`cat /proc/acpi/ac_adapter/ACAD/state | grep off-line`"
+
+if [ -n "${STATE}" ] ; then
+cat /etc/sin/table.bat >/sys/class/misc/sin/table
+else
+cat /etc/sin/table.ac >/sys/class/misc/sin/table
+fi
diff -ur --new-file SIN/etc/sin/table.ac SIN-NEW/etc/sin/table.ac
--- SIN/etc/sin/table.ac	1970-01-01 01:00:00.0 +0100
+++ SIN-NEW/etc/sin/table.ac	2007-01-25 14:14:15.0 +0100
@@ -0,0 +1,8 @@
+0
+2 3
+0 1
+0
+resume
+1200 dim
+3500 blank
+27000 sleep
diff -ur --new-file SIN/etc/sin/table.bat SIN-NEW/etc/sin/table.bat
---

Sub - Excessive printks increase top mem usage?

[yogeshwar sonawane]

Hi all,
I am running a user application which will just open/close my driver
(simple one, empty functions with only printks) infinitely.
A massive use of printk can slow down the system noticeably OR it can
affect some time calculations.
Apart from this, it was increasing top mem usage also. After closing
the application, the memory consumption was not coming down(not
freeing mem). Is this the expected behaviour? OR i am missing
something?

Can anybody help me in guiding the reason for this? Any help/links plz.

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

Re: Excessive printks increase top mem usage?

[yogeshwar sonawane]

Subject is updated

On 1/25/07, yogeshwar sonawane <[EMAIL PROTECTED]> wrote:

Hi all,
I am running a user application which will just open/close my driver
(simple one, empty functions with only printks) infinitely.
A massive use of printk can slow down the system noticeably OR it can
affect some time calculations.
Apart from this, it was increasing top mem usage also. After closing
the application, the memory consumption was not coming down(not
freeing mem). Is this the expected behaviour? OR i am missing
something?

Can anybody help me in guiding the reason for this? Any help/links plz.

Thanks in advance,
Yogeshwar


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] suspend debugging: simulate suspend-to-RAM

[Rafael J. Wysocki]

On Thursday, 25 January 2007 14:07, Pavel Machek wrote:
> Hi!
> 
> > Subject: [patch] suspend debugging: simulate suspend-to-RAM
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> > 
> > most resume bugs are due to the kernel hanging or crashing while trying 
> > to resume a specific device. It is extremely hard to debug such hangs 
> > because often when the hang happens there's no console available
> > yet.
> 
> While the functionality is useful, no I do not think this should be
> configured by sysctl or kernel parameter.
> 
> Perhaps right interface is "echo fake-mem > /sys/power/state"? 

Yes, the "test" and "testproc" debug modes are started via /sys/power/state,
so let's make it consistent.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] suspend debugging: simulate suspend-to-RAM

[Pavel Machek]

On Thu 2007-01-25 14:29:24, Rafael J. Wysocki wrote:
> On Thursday, 25 January 2007 14:07, Pavel Machek wrote:
> > Hi!
> > 
> > > Subject: [patch] suspend debugging: simulate suspend-to-RAM
> > > From: Ingo Molnar <[EMAIL PROTECTED]>
> > > 
> > > most resume bugs are due to the kernel hanging or crashing while trying 
> > > to resume a specific device. It is extremely hard to debug such hangs 
> > > because often when the hang happens there's no console available
> > > yet.
> > 
> > While the functionality is useful, no I do not think this should be
> > configured by sysctl or kernel parameter.
> > 
> > Perhaps right interface is "echo fake-mem > /sys/power/state"? 
> 
> Yes, the "test" and "testproc" debug modes are started via /sys/power/state,
> so let's make it consistent.

Ok, so this one should be "testmem".
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: How to get /dev entry created automaticly for dynamic major number?

[Jiri Kosina]

On Thu, 25 Jan 2007, Markku Savela wrote:

> Thanks! The solution seems to work. The final *obstacle* was, that
> class_* symbols were not available until I added the
> LICENSE("GPL"). Here is the resulting template, maybe useful for
> someone, and just for verification, that I got it right.
> static struct class_device *foo_device;
[...]
> foo_device = class_device_create(foo_class, NULL, MKDEV(foo_major, 0), 
> NULL, "foo0");
[...]

You should probably rather move away from struct class_device and 
class_device_create() and use struct device and device_create() instead 
(all the drivers using class_device are currently being converted this 
way, so that class_device could go away), so that your driver is using the 
new kernel driver core API.

The conversion should be really very simple.

-- 
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: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Oleg Verych]

On Thu, Jan 25, 2007 at 01:28:56PM +0100, Martin Drab wrote:
> On Thu, 25 Jan 2007, Oleg Verych wrote:
> 
> > gmane.linux.kernel:
> > > recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> > > Intel 945 PM PCI-E Chipset, for details see attached log). After booting 
> > > the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also 
> > > with 
> > > the 2.6.19.2, didn't try any other), some strange behaviour can be 
> > > observed.
> > 
> > There were disscussions about mmconfig and what nightmare it brought to
> > PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:
> > 
> > 
> > > At first the following messages appear in the log:
> > >
> > > ...
  [   40.303154] PCI: BIOS *Bug*: MCFG area at e000 is not E820-reserved
> > > [   40.303157] PCI: Not using MMCONFIG.
> > >
> > > (not sure whether this is really a problem)
> > 
> > I think it may be the major problem.
> 
> Hmm, it may be. Was there suggested any solution (or at least proposal) 
> that I may try?

Try fix BIOS bugs: 

> Martin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] alsa: correct nonsensical sysfs device symlinks

[Christopher \"Monty\" Montgomery]

On 1/24/07, Greg KH <[EMAIL PROTECTED]> wrote:

I don't understand, where does the symlink currently point to?  It looks
correct to me on my machines:


My machines and the fedora rawhide machines using the 2.6.20-rcX
releases look nothing like what you pasted.  If they did, hald would
be working...  (I'll note that bugs have also been logged against
Pulse and HAL by users having trouble, so it's not just us.)

What you said you have:


$ tree /sys/class/sound/
/sys/class/sound/
|-- card0 -> ../../devices/pci:00/:00:1b.0/card0
|-- controlC0 -> ../../devices/pci:00/:00:1b.0/card0/controlC0
|-- pcmC0D0c -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D0c
|-- pcmC0D0p -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D0p
|-- pcmC0D2c -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D2c
|-- pcmC0D6c -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D6c
|-- pcmC0D6p -> ../../devices/pci:00/:00:1b.0/card0/pcmC0D6p
`-- timer -> ../../devices/virtual/sound/timer


What we actually have here:
/sys/class/sound/
|-- adsp
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- audio
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- audio1
|   |-- dev
|   |-- device -> ../../../class/sound/card1
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- card0
|   |-- 0-0:AD1981B
|   |   |-- bus -> ../../../../bus/ac97
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem -> ../../../../bus/ac97
|   |   `-- uevent
|   |-- device -> ../../../devices/pci:00/:00:1f.5
|   |-- power
|   |   `-- wakeup
|   |-- sound:adsp -> ../../../class/sound/adsp
|   |-- sound:audio -> ../../../class/sound/audio
|   |-- sound:controlC0 -> ../../../class/sound/controlC0
|   |-- sound:dsp -> ../../../class/sound/dsp
|   |-- sound:mixer -> ../../../class/sound/mixer
|   |-- sound:pcmC0D0c -> ../../../class/sound/pcmC0D0c
|   |-- sound:pcmC0D0p -> ../../../class/sound/pcmC0D0p
|   |-- sound:pcmC0D1c -> ../../../class/sound/pcmC0D1c
|   |-- sound:pcmC0D2c -> ../../../class/sound/pcmC0D2c
|   |-- sound:pcmC0D3c -> ../../../class/sound/pcmC0D3c
|   |-- sound:pcmC0D4p -> ../../../class/sound/pcmC0D4p
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- card1
|   |-- 1-1:unknown codec
|   |   |-- bus -> ../../../../bus/ac97
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem -> ../../../../bus/ac97
|   |   `-- uevent
|   |-- device -> ../../../devices/pci:00/:00:1f.6
|   |-- power
|   |   `-- wakeup
|   |-- sound:audio1 -> ../../../class/sound/audio1
|   |-- sound:controlC1 -> ../../../class/sound/controlC1
|   |-- sound:dsp1 -> ../../../class/sound/dsp1
|   |-- sound:mixer1 -> ../../../class/sound/mixer1
|   |-- sound:pcmC1D0c -> ../../../class/sound/pcmC1D0c
|   |-- sound:pcmC1D0p -> ../../../class/sound/pcmC1D0p
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- controlC0
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- controlC1
|   |-- dev
|   |-- device -> ../../../class/sound/card1
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- dsp
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- dsp1
|   |-- dev
|   |-- device -> ../../../class/sound/card1
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- mixer
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- mixer1
|   |-- dev
|   |-- device -> ../../../class/sound/card1
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D0c
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- pcm_class
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D0p
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- pcm_class
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D1c
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- pcm_class
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D2c
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- pcm_class
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D3c
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|   |-- pcm_class
|   |-- power
|   |   `-- wakeup
|   |-- subsystem -> ../../../class/sound
|   `-- uevent
|-- pcmC0D4p
|   |-- dev
|   |-- device -> ../../../class/sound/card0
|

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Dirk Hohndel]

On 1/23/07 9:57 AM, "David Miller" <[EMAIL PROTECTED]> wrote:
>> Definitely disagree with that. I'd like to see the conference somewhere
>> else different this time - perhaps Czech Republic, or somewhere else more
>> easterly and Linux active (or even Finland...)
> 
> This is my position as well.
> 
> If the kernel summit is important enough, all the bean counters will
> find a way to get their constituents to the event, it's as simple as
> that.

Actually, it isn't.

Within the Northern Hemisphere and with locations that are reasonably
cheaply to reach from most of Europe and North America, yes, at the end of
the day people will be able to come.

We seem to have two different types of motivation for proposed locations in
this discussion. Some of us are looking for a convenient location. Some of
us are proposing locations as a political statement. I believe the latter
isn't a good idea. The kernel summit is by invitation only. It therefore is
a very bad forum to bring Linux to a place.

Add to that that locations like Brazil or India will add thousands of
dollars of cost per person and add much more problems with jet lag for many
people I think they'll be very hard to justify.

> For the first time in many years I'm strongly considering actually
> going to the kernel summit, however if it goes back to Ottawa I
> definitely will stop going again.

Is that specific to Ottawa, or is this any North American location? I
strongly believe that it's a good idea to alternate between locations in
North America and Europe. That's were most of the attendees live. Just as it
was a bad idea to keep it in North America all the time, it would be a bad
idea to keep it in Europe.

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

Re: Strange problem with tty layer

[Russell King]

On Wed, Jan 24, 2007 at 04:34:47PM -0500, Lennart Sorensen wrote:
> I am using the GPIO lines too, and didn't want to mess with the 8250
> driver (since I use that for a serial console on a 16550 UART), plus
> being able to use the 64byte fifo rather than 16byte 16550 mode fifo
> seems nicer.

Note that 8250 will use the deeper fifos if it knows how to.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Limit the size of the pagecache

[Bodo Eggert]

Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
>> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:

>> > He wants to make a nommu system act like a mmu system; this will just
>> > never ever work.
>> 
>> Nope. Actually my nommu system works great with some of patches made by us.
>> What let you think this will never work?
> 
> Because there are perfectly valid things user-space can do to mess you
> up. I forgot the test-case but it had something to do with opening a
> million files, this will scatter slab pages all over the place.

a) Limit the number of open files.
b) Don't do that then.

> Also, if you cycle your large user-space allocations a bit unluckily
> you'll also fragment it into oblivion.
> 
> So you can not guarantee it will not fragment into smithereens stopping
> your user-space from using large than page size allocations.

Therefore you should purposely increase the mess up to the point where the
system is guaranteed not to work? IMO you should rather put the other issues
onto the TODO list.

BTW: I'm not sure a hard limit is the right thing to do for mmu systems,
I'd rather implement high and low watermarks; if one pool is larger than
it's high watermark, it will be next get it's pages evicted, and it won't
lose pages if it's at the lower watermark.

> If your user-space consists of several applications that do dynamic
> memory allocation of various sizes its a matter of (run-) time before
> things will start failing.
> 
> If you prealloc a large area at boot time (like we now do for hugepages)
> and use that for user-space, you might 'reset' the status quo by cycling
> the whole of userspace.

Preallocating the page cache (and maybe the slab space?) may very well be
the right thing to do for nommu systems. It worked quite well in DOS times
and on old MACs.
-- 
Funny quotes:
30. Why is a person who plays the piano called a pianist but a person who
drives a race car not called a racist?
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Alan]

Fixes bogus accesses to ports 0-15 with a non DMA capable controller.
This I think should go in for 2.6.20

Arguably it shouldn't be called for PIO commands at all but thats a
matter for Jeff to decide 

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 
linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-22 
16:26:50.0 +
+++ linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-24 
17:31:40.0 +
@@ -827,7 +827,8 @@
  */
 void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
 {
-   ata_bmdma_stop(qc);
+   if (qc->ap->ioaddr.bmdma_addr)
+   ata_bmdma_stop(qc);
 }
 
 #ifdef CONFIG_PCI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Retransmission and packet handling in the TCP-code

[kristrev]

> Can you _PLEASE_ not send this independantly to 3 different linux
> mailing lists?

I am sorry, it will not happen again.

-Kristian


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] namespaces: fix race at task exit

[Serge E. Hallyn]

In do_exit(), the exit_task_namespaces() was placed after
exit_notify() because exit_notify ends up using the pid
namespace both to access the reaper, and for detaching the
pid.  However, this placement allows an nfs server to reap
the task before exit_task_namespaces() completes.

This patch moves the exit_task_namespaces() into release_task,
below release_thread() which puts the pids(), and just above
the call_rcu(delayed_put_task_struct).  I believe this should
solve both problems.

Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>

---

 kernel/exit.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

765277a4170d7bbd1c4613de661ec6ac64d5580a
diff --git a/kernel/exit.c b/kernel/exit.c
index 3540172..ab9ae30 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -174,6 +174,7 @@ repeat:
write_unlock_irq(&tasklist_lock);
proc_flush_task(p);
release_thread(p);
+   exit_task_namespaces(p);
call_rcu(&p->rcu, delayed_put_task_struct);
 
p = leader;
@@ -939,7 +940,6 @@ fastcall NORET_TYPE void do_exit(long co
tsk->exit_code = code;
proc_exit_connector(tsk);
exit_notify(tsk);
-   exit_task_namespaces(tsk);
 #ifdef CONFIG_NUMA
mpol_free(tsk->mempolicy);
tsk->mempolicy = NULL;
-- 
1.1.6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] alsa: correct nonsensical sysfs device symlinks

[Pierre Ossman]

Christopher "Monty" Montgomery wrote:
> 
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted.  If they did, hald would
> be working...  (I'll note that bugs have also been logged against
> Pulse and HAL by users having trouble, so it's not just us.)

On my vanilla 2.6.20-rc5, I get the same structure as Greg. Yet hal
still doesn't pick stuff up as it should.

Rgds
Pierre




signature.asc
Description: OpenPGP digital signature

Re: Strange problem with tty layer

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 03:20:53PM -0600, Paul Fulghum wrote:
> In 2.6.16 the tty buffering pushes data to the line
> discipline without regard to tty->receive_room.
> If the line discipline can't keep up, the data gets dropped.
> I observed this data loss at higher speeds when
> placing the system under heavy load.
> 
> 2.6.18 added code to respect tty->receive_room.
> 
> This may or may not be your problem, but you should
> be able to check by adding a conditional printk
> to drivers/char/tty_io.c:flush_to_ldisc()
> 
> If tty->receive_room is less than the size of the buffer
> passed to disc->receive_buf() then you are losing data.

I am now trying this, which so far seem to help (I had a printk in there
earlier and managed to trigger that).

--- ori/drivers/char/tty_io.c   2007-01-24 18:02:48.0 -0500
+++ new/drivers/char/tty_io.c   2007-01-25 09:50:02.0 -0500
@@ -2774,6 +2778,14 @@
spin_lock_irqsave(&tty->buf.lock, flags);
while((tbuf = tty->buf.head) != NULL) {
while ((count = tbuf->commit - tbuf->read) != 0) {
+   if (!tty->receive_room) {
+   schedule_delayed_work(&tty->buf.work, 1);
+   spin_unlock_irqrestore(&tty->buf.lock, flags);
+   goto out;
+   }
+   if (count > tty->receive_room) {
+   count = tty->receive_room;
+   }
char_buf = tbuf->char_buf_ptr + tbuf->read;
flag_buf = tbuf->flag_buf_ptr + tbuf->read;
tbuf->read += count;

This appeared to be (essentially) the key change in 2.6.18 related to
the check of tty->receive_room.

I will now run a bunch more tests to see if it manages to keep it from
having any more character losses.

Thank you for the suggestion of where to look.

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

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Scott Preece]

On 1/25/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:

Scott Preece <[EMAIL PROTECTED]> wrote:

> My own hot button is making sure that the definition of what
> constitutes user activity is managed in exactly one place, whether in
> the kernel or not. My naive model would be to put the response at user
> level, but to provide a single point of definition in the kernel (say,
> /dev/useractivity or the equivalent) that the user-level daemon could
> listen to.

Imagine one computer serving two users. Two monitors, two keyboards ...

---

Good point! Of late I've been working on single-user systems, so it
was not at the front of my brain, despite years of building and using
multi-user systems.

It's a point that multi-user systems have struggled with forever (when
somebody inserts a CR in the drive mounted in the system box, which
user do you pop up a media player for?).

I tend to think it's not a kernel-vs-user-space issue, though. To
solve it you need, somewhere, a notion of a "user session" and you
need some way to separate system-level issues (like low-battery) from
user-level issues (like activiating user X's screensaver).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] namespaces: fix race at task exit

[Cedric Le Goater]

Serge E. Hallyn wrote:
> In do_exit(), the exit_task_namespaces() was placed after
> exit_notify() because exit_notify ends up using the pid
> namespace both to access the reaper, and for detaching the
> pid.  However, this placement allows an nfs server to reap
> the task before exit_task_namespaces() completes.
> 
> This patch moves the exit_task_namespaces() into release_task,
> below release_thread() which puts the pids(), and just above
> the call_rcu(delayed_put_task_struct).  I believe this should
> solve both problems.
> 
> Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>

I've run some tests on x86 and x86_64: mounted a NFS share after 
having unshare(CLONE_NEWNS) and I didn't reproduce the bug Daniel 
had found. 

it looks safe.

C.
 

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

unfixed regression in 2.6.20-rc6 (since 2.6.19)

[Rainer Weikusat]

2.6.19 introduced changes to the UHCI handling of interrupt URBs that
caused at least some keyspan USB-to-serial converters to fail, because
the driver code incorrectly assumes that all URBs of the device are
bulk URBs, while some of them (in the default configuration) are
actually interrupt URBs. This has been reported via kernel bugzilla as
bug 7544 on 2006/11/17:

http://bugzilla.kernel.org/show_bug.cgi?id=7544

I happen to use such a device, but I didn't have the time to deal with
this issue until end of december. A fix for this regression has been
available at least since 2006/12/26. The patch available via bugzilla
has been reworked by me because of comments from Mr. Kroah-Hartmann,

http://marc.theaimsgroup.com/?l=linux-kernel&m=116783507105717&w=2

It has been part of the -mm tree until about three days ago and was
then dropped by Andrew Morton because Mr Kroah-Hartmann added a
structurally identical and functionally neutral (or slightly worse)
rewritten-by-him version of it to something called 'gregkh-2.6',
presumably, judging from the age of other patches in this particular
tree (back until 2006/09/19), to never see the light of the day again.

If this issue is not going to be fixed for some reason, it would at
least be appropriate to close the bugzilla entry with something like
WILL_NOT_FIX, because that appears to be the situation at present and
for an indefinite time to come.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: +1 4 cz (Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit)

[Vojtech Pavlik]

On Tue, Jan 23, 2007 at 07:18:46PM +, Oleg Verych wrote:

> >> Ditto..
> >> 
> >> Definitely disagree with that. I'd like to see the conference somewhere
> >> else different this time - perhaps *Czech Republic*, or somewhere else more
> >> easterly and Linux active (or even Finland...)
> >
> > This is my position as well.
> > 
> > For the first time in many years I'm strongly considering actually
> > going to the kernel summit, however if it goes back to Ottawa I
> > definitely will stop going again.
> 
> It would be interesting. Thank you Alan, David!

I (and SUSE/Novell) would be happy to help organizing the Kernel Summit
in Czech Republic.

-- 
Vojtech Pavlik
Director SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.20-rc6][MIPS]Malta: trivial compile error fix

[Jan Altenberg]

Hi Ralf,

the following patch should fix a compile error for MIPS_MALTA, when
CONFIG_MTD is disabled.

regards,
JAN

---

- Fix a compile error for MIPS_MALTA, when CONFIG_MTD is disabled.

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

---
 arch/mips/mips-boards/malta/Makefile |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/mips/mips-boards/malta/Makefile
===
--- linux-2.6.orig/arch/mips/mips-boards/malta/Makefile
+++ linux-2.6/arch/mips/mips-boards/malta/Makefile
@@ -19,5 +19,6 @@
 # under Linux.
 #
 
-obj-y := malta_int.o malta_mtd.o malta_setup.o
+obj-y := malta_int.o malta_setup.o
+obj-$(CONFIG_MTD) += malta_mtd.o
 obj-$(CONFIG_SMP) += malta_smp.o


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

Re: [PATCH 7/8] user ns: handle file sigio

[Serge E. Hallyn]

Quoting Andrew Morton ([EMAIL PROTECTED]):
> On Wed, 24 Jan 2007 12:58:45 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> 
> > > If we need to I can see doing something special if the process setting
> > > fown has CAP_KILL
> > 
> > Obviously CAP_KILL is insufficient :)  I assume you mean a new
> > CAP_XNS_CAP_KILL?
> > 
> > > and bypassing the security checks that way, but
> > > hard coding rules like that when it doesn't appear we have any
> > > experience to indicate we need the extra functionality looks
> > > premature.
> > 
> > Ok, in this case actually I suspect you're right and we can just ditch
> > the exception.  But in general the security discussion is one we should
> > still have.
> 
> People like security.
> 
> Where do we now stand with this patch, and with "[PATCH 4/8] user ns: hook 
> permission"?

Later today I can send a patch against this set which removes the
the init_task exceptions (out of patch 3 and patch 7), but I'd prefer
to leave the MS_SHARED_NS option (patch 6) in.

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] nfs: fix congestion control -v4

[Peter Zijlstra]

Hopefully the last version ;-)


---
Subject: nfs: fix congestion control

The current NFS client congestion logic is severly broken, it marks the backing
device congested during each nfs_writepages() call but doesn't mirror this in
nfs_writepage() which makes for deadlocks. Also it implements its own waitqueue.

Replace this by a more regular congestion implementation that puts a cap on the
number of active writeback pages and uses the bdi congestion waitqueue.

Also always use an interruptible wait since it makes sense to be able to 
SIGKILL the process even for mounts without 'intr'.

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Trond Myklebust <[EMAIL PROTECTED]>
---
 fs/nfs/super.c  |4 -
 fs/nfs/sysctl.c |8 +++
 fs/nfs/write.c  |  116 
 include/linux/backing-dev.h |1 
 include/linux/nfs_fs.h  |1 
 include/linux/nfs_fs_sb.h   |1 
 mm/backing-dev.c|   16 ++
 7 files changed, 103 insertions(+), 44 deletions(-)

Index: linux-2.6-git/fs/nfs/write.c
===
--- linux-2.6-git.orig/fs/nfs/write.c   2007-01-25 16:07:03.0 +0100
+++ linux-2.6-git/fs/nfs/write.c2007-01-25 16:10:48.0 +0100
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -78,7 +79,7 @@ static struct nfs_page * nfs_update_requ
struct page *,
unsigned int, unsigned int);
 static void nfs_mark_request_dirty(struct nfs_page *req);
-static int nfs_wait_on_write_congestion(struct address_space *, int);
+static int nfs_wait_on_write_congestion(struct address_space *);
 static int nfs_wait_on_requests(struct inode *, unsigned long, unsigned int);
 static long nfs_flush_mapping(struct address_space *mapping, struct 
writeback_control *wbc, int how);
 static const struct rpc_call_ops nfs_write_partial_ops;
@@ -89,8 +90,6 @@ static struct kmem_cache *nfs_wdata_cach
 static mempool_t *nfs_wdata_mempool;
 static mempool_t *nfs_commit_mempool;
 
-static DECLARE_WAIT_QUEUE_HEAD(nfs_write_congestion);
-
 struct nfs_write_data *nfs_commit_alloc(void)
 {
struct nfs_write_data *p = mempool_alloc(nfs_commit_mempool, GFP_NOFS);
@@ -245,6 +244,39 @@ static int wb_priority(struct writeback_
 }
 
 /*
+ * NFS congestion control
+ */
+
+int nfs_congestion_kb;
+
+#define NFS_CONGESTION_ON_THRESH   (nfs_congestion_kb >> (PAGE_SHIFT-10))
+#define NFS_CONGESTION_OFF_THRESH  \
+   (NFS_CONGESTION_ON_THRESH - (NFS_CONGESTION_ON_THRESH >> 2))
+
+static inline void nfs_set_page_writeback(struct page *page)
+{
+   if (!test_set_page_writeback(page)) {
+   struct inode *inode = page->mapping->host;
+   struct nfs_server *nfss = NFS_SERVER(inode);
+
+   if (atomic_inc_return(&nfss->writeback) > 
NFS_CONGESTION_ON_THRESH)
+   set_bdi_congested(&nfss->backing_dev_info, WRITE);
+   }
+}
+
+static inline void nfs_end_page_writeback(struct page *page)
+{
+   struct inode *inode = page->mapping->host;
+   struct nfs_server *nfss = NFS_SERVER(inode);
+
+   end_page_writeback(page);
+   if (atomic_dec_return(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH) {
+   clear_bdi_congested(&nfss->backing_dev_info, WRITE);
+   congestion_end(WRITE);
+   }
+}
+
+/*
  * Find an associated nfs write request, and prepare to flush it out
  * Returns 1 if there was no write request, or if the request was
  * already tagged by nfs_set_page_dirty.Returns 0 if the request
@@ -281,7 +313,7 @@ static int nfs_page_mark_flush(struct pa
spin_unlock(req_lock);
if (test_and_set_bit(PG_FLUSHING, &req->wb_flags) == 0) {
nfs_mark_request_dirty(req);
-   set_page_writeback(page);
+   nfs_set_page_writeback(page);
}
ret = test_bit(PG_NEED_FLUSH, &req->wb_flags);
nfs_unlock_request(req);
@@ -336,13 +368,8 @@ int nfs_writepage(struct page *page, str
return err; 
 }
 
-/*
- * Note: causes nfs_update_request() to block on the assumption
- *  that the writeback is generated due to memory pressure.
- */
 int nfs_writepages(struct address_space *mapping, struct writeback_control 
*wbc)
 {
-   struct backing_dev_info *bdi = mapping->backing_dev_info;
struct inode *inode = mapping->host;
int err;
 
@@ -351,11 +378,6 @@ int nfs_writepages(struct address_space 
err = generic_writepages(mapping, wbc);
if (err)
return err;
-   while (test_and_set_bit(BDI_write_congested, &bdi->state) != 0) {
-   if (wbc->nonblocking)
-   return 0;
-   nfs_wait_on_write_congestion(mapping, 0);
-   }
err = nfs_flush_mapping(mapping, wbc, wb_priority(wbc));
if (err < 0)
g

Re: que: How can we Eliminate the DMA Zone from the kernel?

[Kyle McMartin]

On Thu, Jan 25, 2007 at 12:56:30PM +, Seetharam Dharmosoth wrote:
> Hi,
> 
> Want to remove DMA zone the from the Linux Kernel.
> (Don't want to use DMA Zone, because i am not
> using ISA bus, am using PCI bus. So, I don't need
> this)
> 

Just because you don't need ISA, doesn't mean you don't need
ZONE_DMA. Various PCI cards have limitations on what addresses they
can DMA to (24 bits on some old PCI sound cards iirc, and more recently
a 30 bit DMA limitation on some Broadcom networking equipment.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] alsa: correct nonsensical sysfs device symlinks

[Christopher \"Monty\" Montgomery]

On 1/25/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:

Christopher "Monty" Montgomery wrote:
>
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted.  If they did, hald would
> be working...  (I'll note that bugs have also been logged against
> Pulse and HAL by users having trouble, so it's not just us.)

On my vanilla 2.6.20-rc5, I get the same structure as Greg. Yet hal
still doesn't pick stuff up as it should.


Interesting to know.  Looking more closely, it looks like machines
here are split between the messed up output I forwarded previously and
the output that is expected.  All of my personal boxes are messed up.

Having looked at HAL earlier, it appeared to have code to parse the
new format but if it desn't work, it doesn't work.  Updating HAL is
relatively easy but I can't test the changes on my own boxes because
they have the messed up /sys/class/sound structure.

Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc5: known unfixed regressions (v3) (part 2)

[Gerhard Dirschl]

Am Mittwoch 24 Januar 2007 21:45 schrieb Peter Osterlund:
> > Subject: pktcdvd fails with pata_amd
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=7810
> > Submitter  : [EMAIL PROTECTED]
> > Status : unknown
> Does reverting this patch help?
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=406c9b605cbc45151c03ac9a3f95e9acf050808c
No, the machine locks up as described in
http://bugzilla.kernel.org/show_bug.cgi?id=7667
But it worked after additional reverting of
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3b00315799d78f76531b71435fbc2643cd71ae4c
(testted with 2.6.20-rc6).

-- 
Gerhard DirschlPGP-Key-ID: 0x7B95AE94
Karlsruhe
Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] alsa: correct nonsensical sysfs device symlinks

[Pierre Ossman]

Christopher "Monty" Montgomery wrote:
> 
> Interesting to know.  Looking more closely, it looks like machines
> here are split between the messed up output I forwarded previously and
> the output that is expected.  All of my personal boxes are messed up.
> 

There is some option about deprecated sysfs stuff. Perhaps this is the
cause of your twisted tree. It's off here:

# CONFIG_SYSFS_DEPRECATED is not set

Rgds
Pierre




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Alessandro Di Marco]

"Scott Preece" <[EMAIL PROTECTED]> writes:

   On 1/25/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
   > Imagine one computer serving two users. Two monitors, two keyboards ...
   ---

   Good point! Of late I've been working on single-user systems, so it
   was not at the front of my brain, despite years of building and using
   multi-user systems.

   It's a point that multi-user systems have struggled with forever (when
   somebody inserts a CR in the drive mounted in the system box, which user do
   you pop up a media player for?).

sed s/user X's screensaver/suspend to disk/g 

Re: O_DIRECT question

[Phillip Susi]

Denis Vlasenko wrote:

I will still disagree on this point (on point "use O_DIRECT, it's faster").
There is no reason why O_DIRECT should be faster than "normal" read/write
to large, aligned buffer. If O_DIRECT is faster on today's kernel,
then Linux' read()/write() can be optimized more.


Ahh but there IS a reason for it to be faster: the application knows 
what data it will require, so it should tell the kernel rather than ask 
it to guess.  Even if you had the kernel playing vmsplice games to get 
avoid the copy to user space ( which still has a fair amount of overhead 
), then you still have the problem of the kernel having to guess what 
data the application will require next, and try to fetch it early.  Then 
when the application requests the data, if it is not already in memory, 
the application blocks until it is, and blocking stalls the pipeline.



(I hoped that they can be made even *faster* than O_DIRECT, but as I said,
you convinced me with your "error reporting" argument that reads must still
block until entire buffer is read. Writes can avoid that - apps can do
fdatasync/whatever to make sync writes & error checks if they want).



fdatasync() is not acceptable either because it flushes the entire file. 
 This does not allow the application to control the ordering of various 
writes unless it limits itself to a single write/fdatasync pair at a 
time.  Further, fdatasync again blocks the application.


With aio, the application can keep several read/writes going in 
parallel, thus keeping the pipeline full.  Even if the io were not 
O_DIRECT, and the kernel played vmsplice games to avoid the copy, it 
would still have more overhead, complexity and I think, very little gain 
in most cases.



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

Re: + make-good_sigevent-non-static.patch added to -mm tree

[Oleg Nesterov]

SИbastien DuguИ wrote:
>
> +struct task_struct *good_sigevent(sigevent_t *event)
> +{
> + struct task_struct *task = current->group_leader;
> +
> + if ((event->sigev_notify & SIGEV_THREAD_ID) == SIGEV_THREAD_ID) {
> + task = find_task_by_pid(event->sigev_notify_thread_id);
> +
> + if (!task || task->tgid != current->tgid)
> + return NULL;
> + } else if (event->sigev_notify == SIGEV_SIGNAL) {

No, no, we can't use "else" here,

> + if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)

because we skip the check above in SIGEV_THREAD_ID case.

This way any user can crash the kernel with a minimal effort.

Oleg.

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

Re: How to get /dev entry created automaticly for dynamic major number?

[Greg KH]

On Thu, Jan 25, 2007 at 03:11:15PM +0200, Markku Savela wrote:
> Solution found!
> 
> > On Thu, Jan 25, 2007 at 09:35:07AM +0200, Markku Savela wrote:
> > > If want to write a loadable module which "implements" a char device
> > > ("virtual", no real device present). How do I get the correct
> > > "/dev/foo" to appear automaticly?
> 
> > From: Greg KH <[EMAIL PROTECTED]>
> 
> > If you look in the book, Linux Device Drivers, third edition, free
> > online, there's a section on what is needed for udev to work properly.
> > 
> > The ideas are still the same, but the way to do it has changed since the
> > book was written.  Just use a struct device and a class, and you will be
> > fine.  Look at the misc device core or the mem code in
> > drivers/char/mem.c for examples of what you need to do.
> 
> Thanks! The solution seems to work. The final *obstacle* was, that
> class_* symbols were not available until I added the
> LICENSE("GPL"). Here is the resulting template, maybe useful for
> someone, and just for verification, that I got it right.

Your code _is_ licensed under the GPL, right?

> ...
> static int foo_major = 0;
> static struct class *foo_class;
> static struct class_device *foo_device;
> ...
> 
> static int __init foo_init(void)
>   {
> foo_major = 0;
> foo_class = NULL;
> foo_device = NULL;
> 
> foo_major = register_chrdev(foo_major, "foo", &foo_fops);
> if (foo_major <= 0)
> return -EIO;
> foo_class = class_create(THIS_MODULE, "foo");
> if (IS_ERR(foo_class))
>{
>return PTR_ERR(foo_class);
>}
> foo_device = class_device_create(foo_class, NULL, MKDEV(foo_major, 0), 
> NULL, "foo0");
> if (IS_ERR(foo_device))
>{
>return PTR_ERR(foo_device);
>}
> return 0;
> }
> 
> static void __exit foo_exit(void)
> {
> if (foo_device && !IS_ERR(foo_device))
>class_device_del(foo_device);
> if (foo_class && !IS_ERR(foo_class))
>class_destroy(foo_class);
> if (foo_major > 0)
>unregister_chrdev(foo_major, "foo");
> }

Yes, this should work just fine.  But as others said, try just using
'device_create' instead, so I don't have to go changing your code in the
next few months when 'struct class_device' finally goes away (it is
being replaced.)

thanks,

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

Re: [PATCH] alsa: correct nonsensical sysfs device symlinks

[Christopher \"Monty\" Montgomery]

On 1/25/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:


There is some option about deprecated sysfs stuff. Perhaps this is the
cause of your twisted tree. It's off here:

# CONFIG_SYSFS_DEPRECATED is not set


It is set.  It is also set in the default config, so plently of people
are running with a broken sysfs tree.

I assume we agree that even if that's set, the tree should not be
outright broken like it is (the compatability mode should actually be
compatable, ie, work, right? :-)  Given that, is my patch correct?
What was there (plugging the old 'dev' arg into the new call's
'parent' makes no sense) is clearly wrong.

And it's clear my pacth is incomplete, as it doesn't correct the
device entries for the other entries.

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

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Scott Preece]

On 1/25/07, Alessandro Di Marco <[EMAIL PROTECTED]> wrote:

"Scott Preece" <[EMAIL PROTECTED]> writes:

   On 1/25/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
   > Imagine one computer serving two users. Two monitors, two keyboards ...
   ---

   Good point! Of late I've been working on single-user systems, so it
   was not at the front of my brain, despite years of building and using
   multi-user systems.

   It's a point that multi-user systems have struggled with forever (when
   somebody inserts a CR in the drive mounted in the system box, which user do
   you pop up a media player for?).

sed s/user X's screensaver/suspend to disk/g <
---

Well, a screensaver is associated with a particular user (and screen),
but suspend-to-disk is a system-wide activity that would affect all
the users. So you need to be able to separate those notions in
deciding what actions to take.

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

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Woodhouse]

On Thu, 2007-01-25 at 15:09 +, Alan wrote:
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude 
> linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 
> linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
> --- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-22 
> 16:26:50.0 +
> +++ linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-24 
> 17:31:40.0 +
> @@ -827,7 +827,8 @@
>   */
>  void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
>  {
> -   ata_bmdma_stop(qc);
> +   if (qc->ap->ioaddr.bmdma_addr)
> +   ata_bmdma_stop(qc);
>  }

But what if the bmdma_addr _is_ zero? Please, let's not allow the "zero
is not a valid number" braindamage to spread any further than the IRQ
setup it's already broken.

All the world is not a PeeCee.

-- 
dwmw2

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

[Rik van Riel]

Vaidyanathan Srinivasan wrote:

Rik van Riel wrote:



There are a few databases out there that mmap the whole
thing.  Sleepycat for one...


That is why my suggestion would be not to touch mmapped pagecache
pages in the current pagecache limit code.  The limit should concern
only unmapped pagecache pages.


So you want to limit how much data the kernel caches for mysql
or postgresql, but not limit how much of the rpm database is
cached ?!

IMHO your proposal does the exact opposite of what would be
right for my systems :)

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/09] atomic.h : standardizing atomic primitives

[Mathieu Desnoyers]

atomic.h : standardizing atomic primitives

It mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add
unless. Therefore, principally 64 bits architectures are targeted by these
patches. It also adds the complete list of atomic operations on the atomic_long
type.

These patches apply on 2.6.20-rc5-git4.

Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]>

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

[PATCH 04/09] atomic.h : Add atomic64 cmpxchg, xchg and add_unless to ia64

[Mathieu Desnoyers]

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to ia64

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

--- a/include/asm-ia64/atomic.h
+++ b/include/asm-ia64/atomic.h
@@ -88,12 +88,17 @@ ia64_atomic64_sub (__s64 i, atomic64_t *v)
return new;
 }
 
-#define atomic_cmpxchg(v, old, new) ((int)cmpxchg(&((v)->counter), old, new))
+#define atomic_cmpxchg(v, old, new) \
+   ((__typeof__((v)->counter))cmpxchg(&((v)->counter), old, new))
 #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
 
+#define atomic64_cmpxchg(v, old, new) \
+   ((__typeof__((v)->counter))cmpxchg(&((v)->counter), old, new))
+#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
+
 #define atomic_add_unless(v, a, u) \
 ({ \
-   int c, old; \
+   __typeof__(v->counter) c, old;  \
c = atomic_read(v); \
for (;;) {  \
if (unlikely(c == (u))) \
@@ -107,6 +112,22 @@ ia64_atomic64_sub (__s64 i, atomic64_t *v)
 })
 #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
 
+#define atomic64_add_unless(v, a, u)   \
+({ \
+   __typeof__(v->counter) c, old;  \
+   c = atomic64_read(v);   \
+   for (;;) {  \
+   if (unlikely(c == (u))) \
+   break;  \
+   old = atomic64_cmpxchg((v), c, c + (a));\
+   if (likely(old == c))   \
+   break;  \
+   c = old;\
+   }   \
+   c != (u);   \
+})
+#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+
 #define atomic_add_return(i,v) \
 ({ \
int __ia64_aar_i = (i); \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/10] local_t : i386 extension

[Mathieu Desnoyers]

local_t : i386 extension

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/include/asm-i386/local.h
+++ b/include/asm-i386/local.h
@@ -2,47 +2,198 @@
 #define _ARCH_I386_LOCAL_H
 
 #include 
+#include 
+#include 
 
 typedef struct
 {
-   volatile long counter;
+   atomic_long_t a;
 } local_t;
 
-#define LOCAL_INIT(i)  { (i) }
+#define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
 
-#define local_read(v)  ((v)->counter)
-#define local_set(v,i) (((v)->counter) = (i))
+#define local_read(l)  atomic_long_read(&(l)->a)
+#define local_set(l,i) atomic_long_set(&(l)->a, (i))
 
-static __inline__ void local_inc(local_t *v)
+static __inline__ void local_inc(local_t *l)
 {
__asm__ __volatile__(
"incl %0"
-   :"+m" (v->counter));
+   :"+m" (l->a.counter));
 }
 
-static __inline__ void local_dec(local_t *v)
+static __inline__ void local_dec(local_t *l)
 {
__asm__ __volatile__(
"decl %0"
-   :"+m" (v->counter));
+   :"+m" (l->a.counter));
 }
 
-static __inline__ void local_add(long i, local_t *v)
+static __inline__ void local_add(long i, local_t *l)
 {
__asm__ __volatile__(
"addl %1,%0"
-   :"+m" (v->counter)
+   :"+m" (l->a.counter)
:"ir" (i));
 }
 
-static __inline__ void local_sub(long i, local_t *v)
+static __inline__ void local_sub(long i, local_t *l)
 {
__asm__ __volatile__(
"subl %1,%0"
-   :"+m" (v->counter)
+   :"+m" (l->a.counter)
:"ir" (i));
 }
 
+/**
+ * local_sub_and_test - subtract value from variable and test result
+ * @i: integer value to subtract
+ * @l: pointer of type local_t
+ * 
+ * Atomically subtracts @i from @l and returns
+ * true if the result is zero, or false for all
+ * other cases.
+ */
+static __inline__ int local_sub_and_test(long i, local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   "subl %2,%0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
+   return c;
+}
+
+/**
+ * local_dec_and_test - decrement and test
+ * @l: pointer of type local_t
+ * 
+ * Atomically decrements @l by 1 and
+ * returns true if the result is 0, or false for all other
+ * cases.
+ */ 
+static __inline__ int local_dec_and_test(local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   "decl %0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
+   return c != 0;
+}
+
+/**
+ * local_inc_and_test - increment and test 
+ * @l: pointer of type local_t
+ * 
+ * Atomically increments @l by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.
+ */ 
+static __inline__ int local_inc_and_test(local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   "incl %0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
+   return c != 0;
+}
+
+/**
+ * local_add_negative - add and test if negative
+ * @l: pointer of type local_t
+ * @i: integer value to add
+ * 
+ * Atomically adds @i to @l and returns true
+ * if the result is negative, or false when
+ * result is greater than or equal to zero.
+ */ 
+static __inline__ int local_add_negative(long i, local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   "addl %2,%0; sets %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
+   return c;
+}
+
+/**
+ * local_add_return - add and return
+ * @l: pointer of type local_t
+ * @i: integer value to add
+ *
+ * Atomically adds @i to @l and returns @i + @l
+ */
+static __inline__ long local_add_return(long i, local_t *l)
+{
+   long __i;
+#ifdef CONFIG_M386
+   unsigned long flags;
+   if(unlikely(boot_cpu_data.x86==3))
+   goto no_xadd;
+#endif
+   /* Modern 486+ processor */
+   __i = i;
+   __asm__ __volatile__(
+   "xaddl %0, %1;"
+   :"+r" (i), "+m" (l->a.counter)
+   : : "memory");
+   return i + __i;
+
+#ifdef CONFIG_M386
+no_xadd: /* Legacy 386 processor */
+   local_irq_save(flags);
+   __i = local_read(l);
+   local_set(l, i + __i);
+   local_irq_restore(flags);
+   return i + __i;
+#endif
+}
+
+static __inline__ long local_sub_return(long i, local_t *l)
+{
+   return local_add_return(-i,l);
+}
+
+#define local_inc_return(l)  (local_add_return(1,l))
+#define local_dec_return(l)  (local_sub_return(1,l))
+
+#define local_cmpxchg(l, o, n) \
+   ((long)cmpxchg_local(&((l)->a.counter), (o), (n)))
+/* Always has a lock prefix anyway */
+#define local_xchg(l, new) (xchg(&((l)->a.counter), new))
+
+/**
+ * local_add_unless - add unless the number is a given value
+ * @l: pointer of type local_t
+ * @a: the amount to add to l...
+ * @u: ...unless l is equal to u.
+ *
+ * Atomically a

[PATCH 00/10] local_t : adding and standardising local atomic primitives

[Mathieu Desnoyers]

local_t : adding and standardising local atomic primitives

These patches extend and standardise local_t operations on each architectures,
allowing a rich set of atomic operations to be done on per-cpu data with
minimal performance impact. On architectures where there seems to be no
difference between the SMP and UP operation (same memory barriers, same
LOCKing), local.h simply includes asm-generic/local.h, which removes duplicated
code from the current kernel tree.

These patches apply on 2.6.20-rc5-git4.
It depends on the patch "atomic.h : standardising atomic primitives"

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

Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[Jeff Garzik]

David Woodhouse wrote:

On Thu, 2007-01-25 at 15:09 +, Alan wrote:

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c 
linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-22 
16:26:50.0 +
+++ linux-2.6.20-rc4-mm1/drivers/ata/libata-sff.c   2007-01-24 
17:31:40.0 +
@@ -827,7 +827,8 @@
  */
 void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
 {
-   ata_bmdma_stop(qc);
+   if (qc->ap->ioaddr.bmdma_addr)
+   ata_bmdma_stop(qc);
 }


But what if the bmdma_addr _is_ zero? Please, let's not allow the "zero
is not a valid number" braindamage to spread any further than the IRQ
setup it's already broken.


Read the code...  This test is already widely in use in libata.

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] libata-sff: Don't call bmdma_stop on non DMA capable controllers

[David Woodhouse]

On Thu, 2007-01-25 at 11:17 -0500, Jeff Garzik wrote:
> Read the code...  This test is already widely in use in libata. 

That doesn't make it correct; it just means it's your fault not Alan's,
right? :)

-- 
dwmw2

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

[PATCH 02/09] atomic.h : Complete atomic_long operations in asm-generic

[Mathieu Desnoyers]

atomic.h : Complete atomic_long operations in asm-generic

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

--- a/include/asm-generic/atomic.h
+++ b/include/asm-generic/atomic.h
@@ -66,6 +66,90 @@ static inline void atomic_long_sub(long i, atomic_long_t *l)
atomic64_sub(i, v);
 }
 
+static inline int atomic_long_sub_and_test(long i, atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_sub_and_test(i, v);
+}
+
+static inline int atomic_long_dec_and_test(atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_dec_and_test(v);
+}
+
+static inline int atomic_long_inc_and_test(atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_inc_and_test(v);
+}
+
+static inline int atomic_long_add_negative(long i, atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_add_negative(i, v);
+}
+
+static inline long atomic_long_add_return(long i, atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_add_return(i, v);
+}
+
+static inline long atomic_long_sub_return(long i, atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_sub_return(i, v);
+}
+
+static inline long atomic_long_inc_return(atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_inc_return(v);
+}
+
+static inline long atomic_long_dec_return(atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_dec_return(v);
+}
+
+static inline long atomic_long_add_unless(atomic_long_t *l, long a, long u)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_add_unless(v, a, u);
+}
+
+static inline long atomic_long_inc_not_zero(atomic_long_t *l)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_inc_not_zero(v);
+}
+
+static inline long atomic_long_cmpxchg(atomic_long_t *l, long old, long new)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_cmpxchg(v, old, new);
+}
+
+static inline long atomic_long_xchg(atomic_long_t *l, long new)
+{
+   atomic64_t *v = (atomic64_t *)l;
+   
+   return (long)atomic64_xchg(v, new);
+}
+
 #else  /*  BITS_PER_LONG == 64  */
 
 typedef atomic_t atomic_long_t;
@@ -113,6 +197,90 @@ static inline void atomic_long_sub(long i, atomic_long_t 
*l)
atomic_sub(i, v);
 }
 
+static inline int atomic_long_sub_and_test(long i, atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return atomic_sub_and_test(i, v);
+}
+
+static inline int atomic_long_dec_and_test(atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return atomic_dec_and_test(v);
+}
+
+static inline int atomic_long_inc_and_test(atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return atomic_inc_and_test(v);
+}
+
+static inline int atomic_long_add_negative(long i, atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return atomic_add_negative(i, v);
+}
+
+static inline long atomic_long_add_return(long i, atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_add_return(i, v);
+}
+
+static inline long atomic_long_sub_return(long i, atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_sub_return(i, v);
+}
+
+static inline long atomic_long_inc_return(atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_inc_return(v);
+}
+
+static inline long atomic_long_dec_return(atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_dec_return(v);
+}
+
+static inline long atomic_long_add_unless(atomic_long_t *l, long a, long u)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_add_unless(v, a, u);
+}
+
+static inline long atomic_long_inc_not_zero(atomic_long_t *l)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_inc_not_zero(v);
+}
+
+static inline long atomic_long_cmpxchg(atomic_long_t *l, long old, long new)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_cmpxchg(v, old, new);
+}
+
+static inline long atomic_long_xchg(atomic_long_t *l, long new)
+{
+   atomic_t *v = (atomic_t *)l;
+   
+   return (long)atomic_xchg(v, new);
+}
+
 #endif  /*  BITS_PER_LONG == 64  */
 
 #endif  /*  _ASM_GENERIC_ATOMIC_H  */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/09] atomic.h : Add atomic64 cmpxchg, xchg and add_unless to parisc

[Mathieu Desnoyers]

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to parisc

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

--- a/include/asm-parisc/atomic.h
+++ b/include/asm-parisc/atomic.h
@@ -163,7 +163,8 @@ static __inline__ int atomic_read(const atomic_t *v)
 }
 
 /* exported interface */
-#define atomic_cmpxchg(v, o, n) ((int)cmpxchg(&((v)->counter), (o), (n)))
+#define atomic_cmpxchg(v, o, n) \
+   ((__typeof__((v)->counter))cmpxchg(&((v)->counter), (o), (n)))
 #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
 
 /**
@@ -177,7 +178,7 @@ static __inline__ int atomic_read(const atomic_t *v)
  */
 #define atomic_add_unless(v, a, u) \
 ({ \
-   int c, old; \
+   __typeof__((v)->counter) c, old;
\
c = atomic_read(v); \
while (c != (u) && (old = atomic_cmpxchg((v), c, c + (a))) != c) \
c = old;\
@@ -270,6 +271,31 @@ atomic64_read(const atomic64_t *v)
 #define atomic64_dec_and_test(v)   (atomic64_dec_return(v) == 0)
 #define atomic64_sub_and_test(i,v) (atomic64_sub_return((i),(v)) == 0)
 
+/* exported interface */
+#define atomic64_cmpxchg(v, o, n) \
+   ((__typeof__((v)->counter))cmpxchg(&((v)->counter), (o), (n)))
+#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
+
+/**
+ * atomic64_add_unless - add unless the number is a given value
+ * @v: pointer of type atomic64_t
+ * @a: the amount to add to v...
+ * @u: ...unless v is equal to u.
+ *
+ * Atomically adds @a to @v, so long as it was not @u.
+ * Returns non-zero if @v was not @u, and zero otherwise.
+ */
+#define atomic64_add_unless(v, a, u)   \
+({ \
+   __typeof__((v)->counter) c, old;
\
+   c = atomic64_read(v);   \
+   while (c != (u) && (old = atomic64_cmpxchg((v), c, c + (a))) != c) \
+   c = old;\
+   c != (u);   \
+})
+#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+
+
 #endif /* __LP64__ */
 
 #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/