On 4/19/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov napsal(a):
> I have been thinking about this and I don't think that exporting motor
> data is a good idea, at least not in case of Phantom driver. The fact
> that there are 3 motors is a hardware implementation detail and it
> is
> In order to keep raising the standard for comparison for the alternative new
> scheduler developments, here is an updated version of the staircase deadline
> cpu scheduler.
I very much appreciate your continued work on SD.
Over the last days I had used 26.21-rc7-ck1 and -ck2. Today I have
On Thu, 19 Apr 2007, Ethan Solomita wrote:
> > H Sorry. I got distracted and I have sent them to Kame-san who was
> > interested in working on them.
> > I have placed the most recent version at
> > http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
> >
>
>Do you
Robert Hancock wrote:
> I've seen a lot of systems (including brand new Xeon-based servers from
> IBM and HP) that output messages on boot like:
>
> PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
> PCI: Not using MMCONFIG.
>
>
> So Microsoft is explicitly telling the BIOS developers
On Thu, 2007-04-19 at 10:50 -0500, Florin Iucha wrote:
> On Thu, Apr 19, 2007 at 11:17:28AM -0400, Trond Myklebust wrote:
> > On Thu, 2007-04-19 at 11:12 -0400, Chuck Lever wrote:
> > > Perhaps instead of looking at the number of bytes sent, the logic in the
> > > last hunk of this patch should
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 19, 2007 10:19 AM
> To: Miller, Mike (OS Dev)
> Cc: Hisashi Hifumi; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; Cameron, Steve
> Subject: RE:
Con Kolivas wrote:
On Thursday 19 April 2007 23:17, Mark Lord wrote:
Con Kolivas wrote:
s go ahead and think up great ideas for other ways of metering out cpu
bandwidth for different purposes, but for X, given the absurd simplicity
of renicing, why keep fighting it? Again I reiterate that
On Thu, 19 Apr 2007 09:19:32 +0200 Borislav Petkov wrote:
> A fixed version of the patch shutting up missing version warnings when
> building
> mandocs.
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt ::
Please include a full patch description/changelog in the future.
> +sub
Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok. I don't see any patches in -mm so I was assuming these patches have
> not been queued up anywhere.
They haven't been quite yet. Is it your intention to kill these features in
2.6.22?
David
-
To unsubscribe from this list: send the line
On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Start the reclaimer thread using kthread_run instead
> of a combination of kernel_thread and daemonize.
> The small amount of signal handling code is also removed
> as it makes no sense
On Thu, 2007-04-19 at 16:12 +, Miller, Mike (OS Dev) wrote:
> > > Nak. You still haven't told where you saw these warnings. What
> > > compiler are you using? I do not see these in my 32-bit environment.
> >
> > I think it's seen with CONFIG_LBD=n on 32 bits
> >
> > In that configuration,
On Thu, 2007-04-19 at 01:59 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> To start the nfsv4-delegreturn thread this patch uses
> kthread_run instead of a combination of kernel_thread
> and daemonize.
>
> In addition allow_signal(SIGKILL) is removed from
> the
Madhusudhan c wrote:
>
> The bus test procedure from this patch can be adopted to the MMCv4
> support in the MMC core with small changes to do bus testing procedure
> only if the host sets the capability to support 8-bit. That way we
> dont break the legacy code. What do you think?
>
Until
On Thu, 2007-04-19 at 01:59 -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Cc: Neil Brown <[EMAIL PROTECTED]>
> Cc: Trond Myklebust <[EMAIL PROTECTED]>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
> fs/nfs/nfs4state.c |2 --
> 1 files
> -Original Message-
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 19, 2007 11:22 AM
> To: Miller, Mike (OS Dev)
> Cc: Hisashi Hifumi; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; Cameron, Steve
> Subject: RE:
Something like
if (sizeof(blah) > 4) {
do all the assignments with shifts
}
might be slighly better since the CDB is already zeroed
by cmd_alloc() and doesn't need to be zeroed a 2nd time.
-- steve
-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]
Sent: Thu
Variable Order Page Cache Patchset
This patchset modifies the core VM so that higher order page cache pages
become possible. The higher order page cache pages are compound pages
and can be handled in the same way as regular pages.
The order of the pages is determined by the order set up in the
Variable Order Page Cache: Add order field in mapping
Add an "order" field in the address space structure that
specifies the page order of pages in an address space.
Set the field to zero by default so that filesystems not prepared to
deal with higher pages can be left as is.
Putting page order
Variable Order Page Cache: Add support to ramfs
The simplest file system to use is ramfs. Add a mount parameter that
specifies the page order of the pages that ramfs should use. If the
order is greater than zero then disable mmap functionality.
This could be removed if the VM would be changes to
Variable Order Page Cache: Account for higher order pages
NR_FILE_PAGES now counts pages of different order. Maybe we need to
account in base page sized pages? If so then we need to change
the way we update the counters. Note that the same would have to be
done for other counters.
Signed-off-by:
Variable Order Page Cache: Add basic allocation functions
Extend __page_cache_alloc to take an order parameter and
modify caller sites. Modify mapping_set_gfp_mask to set
__GFP_COMP if the mapping requires higher order allocations.
put_page() is already capable of handling compound pages. So
---
include/linux/pagemap.h | 27 +++
1 file changed, 27 insertions(+)
Index: linux-2.6.21-rc7/include/linux/pagemap.h
===
--- linux-2.6.21-rc7.orig/include/linux/pagemap.h 2007-04-18
Variable Order Page Cache: Fixup fallback functions
Fixup the fallback function in fs/libfs.c to be able to handle
higher order page cache pages.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/libfs.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Variable Order Page Cache: Fix up mm/filemap.c
Fix up the function in mm/filemap.c to use the variable page cache.
This is pretty straightforward:
1. Convert the constants to function calls.
2. Use the mapping flush function
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
Debugging patch
Show some output as to what is going on.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/ramfs/inode.c |1 +
mm/filemap.c |8
2 files changed, 9 insertions(+)
Index: linux-2.6.21-rc7/fs/ramfs/inode.c
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> >The error also happens in 2.6.19, same as in 2.6.18.
> >I extracted this from syslog:
> >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >ufs_check_page: bad entry
>
> Is this happened also with this patch:
>
On Thu, Apr 19, 2007 at 05:47:43PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2007-04-19 18:10:54 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote:
> > diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
> > index 5c0e979..dff842a 100644
> > --- a/include/scsi/scsi.h
> > +++ b/include/scsi/scsi.h
> >
James Morris wrote:
>On Wed, 18 Apr 2007, Crispin Cowan wrote:
>> How is it that you think a buffer overflow in httpd could allow an
>> attacker to break out of an AppArmor profile?
>
>Because you can change the behavior of the application and then bypass
>policy entirely by utilizing any
On Thu, 19 Apr 2007 18:57:41 +0400 "Vladimir V. Saveliev" <[EMAIL PROTECTED]>
wrote:
> > It's a bit odd that reiserfs is playing with file contents within
> > file_operations.release(): there could be other files open against that
> > inode. One would expect this sort of thing to be happening
On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
>
> thread_run is used intead of kernel_thread, daemonize, and mucking
> around blocking signals directly.
Please don't do incomplete transitions like that. We don't
On Thu, Apr 19, 2007 at 07:39:59PM +0300, Dan Aloni wrote:
> On Thu, Apr 19, 2007 at 05:47:43PM +0200, Jan-Benedict Glaw wrote:
> > Where's the user?
>
> A privately maintained kernel driver.
>
> Do we _must_ have in-tree users? I'd consider the change for completion's
> sake.
I agree with Dan
On Thu, 19 Apr 2007, Avi Kivity wrote:
>
> Please pull from the 'linus' branch of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
*please* put the branch-name after the git repo, so that I can
cut-and-paste without noticing only afterwards that the diffstat doesn't
match
On Thu, 19 Apr 2007, Tomasz Chmielewski wrote:
I also have recurrent problems with
NETDEV WATCHDOG: eth0: transmit timed out
If you search the list, you'll find several similar reports about the tulip
driver (NETDEV WATCHDOG: eth0: transmit timed out).
Adding nopaic/nolapic/noacpi options
On Thu, 19 Apr 2007, Mike Galbraith wrote:
> On Thu, 2007-04-19 at 09:09 +0200, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> >
> > > With a heavily reniced X (perfectly fine), that should indeed solve my
> > > daily usage pattern nicely (always need godmode for shells,
Marat Buharov wrote:
> from fs/udf/super.c:
> in function udf_fill_super
> sb->s_maxbytes = 1<<30; (1 GB)
>
> Why sb->s_maxbytes is not equal to MAX_LFS_FILESIZE?
>
Patches to fix that are in the -mm kernel already (and in
Fedora Core 6 latest update.)
-
To unsubscribe from this list: send the
Arjan van de Ven wrote:
> Andi Kleen wrote:
>> Rationale:
>> - It cannot be enabled in normal builds because all current lds
>> become very slow when they have to handle thousands of sections.
>>
>
> afaik this is only ever reported on SuSE; I've not heard it on any other
> distro...
It's
On Thu, Apr 19, 2007 at 01:54:52PM +0200, Andi Kleen wrote:
>
> Hallo,
>
> I'm thinking about dropping the x86-64 CONFIG_REORDER for 2.6.22.
> The function enabled -ffunction-sections and then tries to reorder
> the executable
>
> While that's in theory a worthy goal to save TLB/icache, in
On Thu, 19 Apr 2007 12:56:27 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> Marat Buharov wrote:
> > from fs/udf/super.c:
> > in function udf_fill_super
> > sb->s_maxbytes = 1<<30; (1 GB)
> >
> > Why sb->s_maxbytes is not equal to MAX_LFS_FILESIZE?
> >
>
> Patches to fix that are in the -mm
Jarek Poplawski wrote:
> Hi,
>
> IMHO cancel_rearming_delayed_work is dangerous place:
>
> - it assumes a work function always rearms (with no exception),
> which probably isn't explained enough now (but anyway should
> be checked in such loops);
>
> - probably possible (theoretical) scenario:
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote:
> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is
On Wed, 18 Apr 2007, David Miller wrote:
> > On Wed, 18 Apr 2007, Christoph Hellwig wrote:
> >
> > > I don't think a module option is a good idea at this point. The problem
> > > is you broke some so far perfectly working setups, which is not okay.
> > > The only first step can be printing a
Alan Cox wrote:
> On Thu, 19 Apr 2007 12:56:27 -0400
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
>> Marat Buharov wrote:
>>> from fs/udf/super.c:
>>> in function udf_fill_super
>>> sb->s_maxbytes = 1<<30; (1 GB)
>>>
>>> Why sb->s_maxbytes is not equal to MAX_LFS_FILESIZE?
>>>
>> Patches to fix
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
> I am still do not understand why this is needed. Would it not be
> simplier just to use a reference to struct device instead of embedding
> it in a larger structure if their lifetimes are different and one does
> not have a subsystem that takes care
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote:
> On Wed, 18 Apr 2007, James Morris wrote:
>
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg
On Wednesday 18 April 2007 20:35, Robert P. J. Day wrote:
> On Wed, 18 Apr 2007, Dave Jones wrote:
>
> > On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote:
> >
> > > > p.p.s. patch improvements that will let me avoid doing any of that
> > > > myself always welcome. :-)
> > >
> > >
On Thursday 19 April 2007, Ingo Molnar wrote:
>* Willy Tarreau <[EMAIL PROTECTED]> wrote:
>> Good idea. The machine I'm typing from now has 1000 scheddos running
>> at +19, and 12 gears at nice 0. [...]
>>
>> From time to time, one of the 12 aligned gears will quickly perform a
>> full quarter of
On Thursday 19 April 2007, Ingo Molnar wrote:
>* Willy Tarreau <[EMAIL PROTECTED]> wrote:
>> You can certainly script it with -geometry. But it is the wrong
>> application for this matter, because you benchmark X more than
>> glxgears itself. What would be better is something like a line
>>
In article <[EMAIL PROTECTED]> you wrote:
> Top (VCPU maybe?)
>User
>Process
>Thread
The problem with that is, that not all Schedulers might work on the User
level. You can think of Batch/Job, Parent, Group, Session or namespace
level. That would be IMHO a generic Top,
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote:
> James Morris wrote:
> >On Wed, 18 Apr 2007, Crispin Cowan wrote:
> >> How is it that you think a buffer overflow in httpd could allow an
> >> attacker to break out of an AppArmor profile?
> >
> >Because you can change the behavior of the
On 4/19/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
Variable Order Page Cache: Account for higher order pages
NR_FILE_PAGES now counts pages of different order. Maybe we need to
account in base page sized pages? If so then we need to change
the way we update the counters. Note that the
> Count per BDI unstable pages.
>
I'm wondering, is it really worth having this category separate from
per BDI brity pages?
With the exception of the export to sysfs, always the sum of unstable
+ dirty is used.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote:
> Karl MacMillan <[EMAIL PROTECTED]> writes:
>
> > No - the real fix is to change the applications or to run under a policy
> > that confines all applications. Most of the problems with resolv.conf,
> > mtab, etc. stem from admin processes
> +static inline unsigned long bdi_stat_delta(void)
> +{
> +#ifdef CONFIG_SMP
> + return NR_CPUS * FBC_BATCH;
Shouln't this be multiplied by the number of counters to sum? I.e. 3
if dirty and unstable are separate, and 2 if they are not.
Miklos
-
To unsubscribe from this list: send the line
On Thu, 19 Apr 2007, Nish Aravamudan wrote:
> > NR_FILE_PAGES,
> > + 1 << mappig->order);
>
> Typo? should be mapping->order?
Correct. Sigh. Why do these things creep in at the last minute before
posting???
-
To unsubscribe from this list: send the line
Stephen Clark wrote:
> Mark Lord wrote:
>
>> Mark Lord wrote:
>>
>>
>>> With the patch applied, I don't see *any* new activity in those
>>> S.M.A.R.T.
>>> attributes over multiple hibernates (Linux "suspend-to-disk").
>>>
>>
>> Scratch that -- operator failure. ;)
>> The patch makes no
Christoph Lameter wrote:
> On Thu, 19 Apr 2007, Nish Aravamudan wrote:
>
>
>>> NR_FILE_PAGES,
>>> + 1 << mappig->order);
>>>
>> Typo? should be mapping->order?
>>
>
> Correct. Sigh. Why do these things creep in at the last minute before
>
Hi,
Get an occasional Oops which can occur either when the device is in use,
or idle.. and it only usually happens after several hours of uptime with
the module and device loaded. The 'oops' seems to directly correlate
with the device appearing to disconnect and reconnect via USB (but
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems)
On Thu, 2007-04-19 at 19:49 +0200, Miklos Szeredi wrote:
> > +static inline unsigned long bdi_stat_delta(void)
> > +{
> > +#ifdef CONFIG_SMP
> > + return NR_CPUS * FBC_BATCH;
>
> Shouln't this be multiplied by the number of counters to sum? I.e. 3
> if dirty and unstable are separate, and 2 if
On Thu, 2007-04-19 at 19:44 +0200, Miklos Szeredi wrote:
> > Count per BDI unstable pages.
> >
>
> I'm wondering, is it really worth having this category separate from
> per BDI brity pages?
>
> With the exception of the export to sysfs, always the sum of unstable
> + dirty is used.
I guess
On Thursday 19 April 2007, Con Kolivas wrote:
[and I snipped a good overview]
>So yes go ahead and think up great ideas for other ways of metering out cpu
>bandwidth for different purposes, but for X, given the absurd simplicity of
>renicing, why keep fighting it? Again I reiterate that most
In article <[EMAIL PROTECTED]> you wrote:
> Perhaps -- until your httpd is compromised via a buffer overflow or
> simply misbehaves due to a software or configuration flaw, then the
> assumptions being made about its use of pathnames and their security
> properties are out the window.
Hu? Even
On Thursday 19 April 2007, Mark Lord wrote:
>Con Kolivas wrote:
>> On Thursday 19 April 2007 23:17, Mark Lord wrote:
>>> Con Kolivas wrote:
>>> s go ahead and think up great ideas for other ways of metering out cpu
>>>
bandwidth for different purposes, but for X, given the absurd simplicity
On Thursday 19 April 2007 1:05 am, Francis Moreau wrote:
> On 4/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
With regards to a userspace interface to GPIOs (rather than to
devices such as leds or switches they control):
> > In this case I'm not entirely sure how it'd work. I've seen a few
901 - 964 of 964 matches
Mail list logo
