Thanks for your well worded response, Shailabh.
Others will have to make further comments and
decisions here. You have understood what I had
to say, and responded well. I have nothing to
add at this point that would help further.
--
I won't rest till it's the best ...
Paul Jackson wrote:
Sorry for the late response - I just saw this note.
Shailabh wrote:
So if the current CPU controller
implementation is considered too intrusive/unacceptable, it can be
reworked or (and we certainly hope not) even rejected in perpetuity.
It is certainly reasonable t
On Thu, Jul 28, 2005 at 02:50:24PM +0200, Helge Hafting wrote:
> I usually compile without module support. This time, I turned modules
> on in order to compile an external module.
>
> To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though
> no actual modules are selected in my .c
I usually compile without module support. This time, I turned modules
on in order to compile an external module.
To my surprise, drivers/scsi/qla2xxx/qla2xxx.ko were built even though
no actual modules are selected in my .config, and the source is
not patched at all except the mm1 patch.
Helge H
Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote:
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> On the Zaurus I'm seeing a couple of false "BUG: soft lockup detected on
> CPU#0!" reports. T
On Fri, 2005-07-15 at 01:36 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
On the Zaurus I'm seeing a couple of false "BUG: soft lockup detected on
CPU#0!" reports. These didn't show under 2.6.12-mm1 which was the last
-mm ker
> > if CKRM is just extensions, I think it should be an external patch.
> > if it provides a path towards unifying the many disparate RM mechanisms
> > already in the kernel, great!
>
> OK, so if it provides a path towards unifying these, what should happen
> to the old interfaces when they confli
On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote:
> > > actually, let me also say that CKRM is on a continuum that includes
> > > current (global) /proc tuning for various subsystems, ulimits, and
> > > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> > > being useful an
> > actually, let me also say that CKRM is on a continuum that includes
> > current (global) /proc tuning for various subsystems, ulimits, and
> > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> > being useful and fast enough to subsume the current global and per-proc
> >
On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:
> actually, let me also say that CKRM is on a continuum that includes
> current (global) /proc tuning for various subsystems, ulimits, and
> at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> being useful and fast enough
Shailabh wrote:
> So if the current CPU controller
> implementation is considered too intrusive/unacceptable, it can be
> reworked or (and we certainly hope not) even rejected in perpetuity.
It is certainly reasonable that you would hope such.
But this hypothetical possibility concerns me a
On Gwe, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:
> I imagine you, like me, are currently sitting in the Xen talk,
Out by a few thousand miles ;)
> and I don't believe they are or will do anything so dumb as to throw away
> or lose information. yes, in principle, the logic will need to be
Th
> > > the fast path slower and less maintainable. if you are really concerned
> > > about isolating many competing servers on a single piece of hardware, then
> > > run separate virtualized environments, each with its own user-space.
> >
> > And the virtualisation layer has to do the same job wit
On Fri, 22 Jul 2005 15:53:55 BST, Alan Cox wrote:
> On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote:
> > the fast path slower and less maintainable. if you are really concerned
> > about isolating many competing servers on a single piece of hardware, then
> > run separate virtualized environme
On Gwe, 2005-07-22 at 00:53 -0400, Mark Hahn wrote:
> the fast path slower and less maintainable. if you are really concerned
> about isolating many competing servers on a single piece of hardware, then
> run separate virtualized environments, each with its own user-space.
And the virtualisation
> of the various environments. I don't think you are one of those end
> users, though. I don't think I'm required to make everyone happy all
> the time. ;)
the issue is whether CKRM (in it's real form, not this thin edge)
will noticably hurt Linux's fast-path.
-
To unsubscribe from this list:
On Fri, 22 Jul 2005 00:53:58 EDT, Mark Hahn wrote:
> > > > yes, that's the crux. CKRM is all about resolving conflicting resource
> > > > demands in a multi-user, multi-server, multi-purpose machine. this is
> > > > a
> > > > huge undertaking, and I'd argue that it's completely inappropriate
> > > yes, that's the crux. CKRM is all about resolving conflicting resource
> > > demands in a multi-user, multi-server, multi-purpose machine. this is a
> > > huge undertaking, and I'd argue that it's completely inappropriate for
> > > *most* servers. that is, computers are generally so dam
Sorry - I didn't see Mark's original comment, so I'm replying to
a reply which I did get. ;-)
On Thu, 21 Jul 2005 23:59:09 EDT, Shailabh Nagar wrote:
> Mark Hahn wrote:
> >>I suspect that the main problem is that this patch is not a mainstream
> >>kernel feature that will gain multiple uses, but
Paul Jackson wrote:
Martin wrote:
No offense, but I really don't see why this matters at all ... the stuff
in -mm is what's under consideration for merging - what's in SuSE is ...
Yes - what's in SuSE doesn't matter, at least not directly.
No - we are not just considering the CKRM that is i
Mark Hahn wrote:
I suspect that the main problem is that this patch is not a mainstream
kernel feature that will gain multiple uses, but rather provides
support for a specific vendor middleware product used by that
vendor and a few closely allied vendors. If it were smaller or
less intrusive, su
On Fri, 22 Jul 2005 13:46:37 +1000, Peter Williams wrote:
> Gerrit Huizenga wrote:
> >>I imagine that the cpu controller is missing from this version of CKRM
> >>because the bugs introduced to the cpu controller during upgrading from
> >>2.6.5 to 2.6.10 version have not yet been resolved.
> >
>
Martin wrote:
> No offense, but I really don't see why this matters at all ... the stuff
> in -mm is what's under consideration for merging - what's in SuSE is ...
Yes - what's in SuSE doesn't matter, at least not directly.
No - we are not just considering the CKRM that is in *-mm now, but also
w
Gerrit Huizenga wrote:
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote:
Paul Jackson wrote:
Matthew wrote:
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releas
On Fri, 22 Jul 2005 11:06:14 +1000, Peter Williams wrote:
> Paul Jackson wrote:
> > Matthew wrote:
> >
> >>I don't see the large ifdefs you're referring to in -mm's
> >>kernel/sched.c.
> >
> >
> > Perhaps someone who knows CKRM better than I can explain why the CKRM
> > version in some SuSE rel
Paul Jackson wrote:
Matthew wrote:
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but
Paul Jackson wrote:
Matthew wrote:
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't.
Or perhaps I'm confused. There's a good chance
Matthew wrote:
> I don't see the large ifdefs you're referring to in -mm's
> kernel/sched.c.
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn
> >>
> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to
> >> lkml if
> >> it works.
> >>
> >
> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work
> > with 13-rc3.
>
Hmm no idea what could have broken it, I'm at OLS and don't have any
DRI cap
On Sun, 2005-07-17 at 08:20 -0700, Paul Jackson wrote:
> It is somewhat intrusive in the areas it controls, such as some large
> ifdef's in kernel/sched.c.
I don't see the large ifdefs you're referring to in -mm's
kernel/sched.c.
> The sched hooks may well impact the cost of maintaining the sch
On Thursday 21 July 2005 11:56, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> >> -- Forwarded Message --
> >>
> >> Subject: Re: Xorg and RADEON (dri disabled)
> >> Date: Wednesday 20 July 2005 21:25
> >> From: Ed Tomlinson <[EMAIL PROTECTED]>
> >> To: debia
Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
>> -- Forwarded Message --
>>
>> Subject: Re: Xorg and RADEON (dri disabled)
>> Date: Wednesday 20 July 2005 21:25
>> From: Ed Tomlinson <[EMAIL PROTECTED]>
>> To: debian-amd64@lists.debian.org
>> Cc: Michal Schmidt <[EMAIL PROTECTED]>
>>
Hi,
I just tried 13-rc2-mm1 and dri is working again. Its reported to also work
with
13-rc3. What in mm1 is apt to be breaking dri?
Thanks
Ed Tomlinson
-- Forwarded Message --
Subject: Re: Xorg and RADEON (dri disabled)
Date: Wednesday 20 July 2005 21:25
From: Ed Tomlinson
Well said, Mark. Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On 7/15/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>
> Changes since 2.6.13-rc2-mm2:
>
>
> git-drm.patch
> git-audit.patch
> git-input.patch
> git-kbuild.patch
make help br0ken, missing matching `'' for binrpm-pkg.
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
To unsubscribe from th
On Sat, Jul 16, 2005 at 09:32:49PM -0400, wrote:
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> >
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> > +suspend-update-documentation.patch
> > +swsusp-fix-printks-and-cleanups.pat
Hi!
> I'm getting this (on ppc32, though I don't think it matters):
>
> CC drivers/video/chipsfb.o
> drivers/video/chipsfb.c: In function `chipsfb_pci_suspend':
> drivers/video/chipsfb.c:465: error: invalid operands to binary ==
> drivers/video/chipsfb.c:467: error: invalid operands to
Hi,
> > What, in your opinion, makes it "obviously unmergeable"?
Controlling resource assignment, I think that concept is good.
But the design is another matter that it seems somewhat overkilled
with the current CKRM.
> I suspect that the main problem is that this patch is not a mainstream
> ker
On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
Apparently, mount does not work with partitions
On Saturday, 16 of July 2005 23:39, Andrew Morton wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
> > >
> > >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > >
> > > (http:
> I suspect that the main problem is that this patch is not a mainstream
> kernel feature that will gain multiple uses, but rather provides
> support for a specific vendor middleware product used by that
> vendor and a few closely allied vendors. If it were smaller or
> less intrusive, such as a d
Andrew, replying to Christoph, about CKRM:
> What, in your opinion, makes it "obviously unmergeable"?
Thanks to some earlier discussions on the relation of CKRM with
cpusets, I've spent some time looking at CKRM. I'm not Christoph,
but perhaps my notes will be of some use in this matter.
CKRM is
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> +suspend-update-documentation.patch
> +swsusp-fix-printks-and-cleanups.patch
> +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch
>
Le 15.07.2005 10:36, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
Hello,
I just got this oops :
Unable to handle kernel NULL pointer dereference at virtual address 0104
printing eip:
c016c7c4
*pde =
Oops: [#1]
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
> >
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> >
> > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> > k
On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
There seems to be a regression wrt 2.6.13-rc3 wh
Andrew Vasquez wrote:
> Yes, quite. How about the following to correct the intention.
>
>
>
> Add correct Kconfig option for ISP24xx support.
>
> Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig
> --- a/driver
Hi,
On Fri, 15 Jul 2005 16:23:49 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
> >
> > Hi Andrew
> >
> > I got the following error.
> >
> > make ARCH=mips oldconfig
> > scripts/kconfig/conf -o arch/mips/Kconfig
> > drivers/video/Kconfig:7:warning: type
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew
>
> I got the following error.
>
> make ARCH=mips oldconfig
> scripts/kconfig/conf -o arch/mips/Kconfig
> drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to
> 'tristate'
>
> file drivers/char/speakup/Kconfig already sc
Hi again,
On Sat, 16 Jul 2005 07:52:42 +0900
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
> Hi Andrew
>
> I got the following error.
>
> make ARCH=mips oldconfig
> scripts/kconfig/conf -o arch/mips/Kconfig
> drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to
> 'tristate'
>
>
Hi Andrew
I got the following error.
make ARCH=mips oldconfig
scripts/kconfig/conf -o arch/mips/Kconfig
drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to
'tristate'
file drivers/char/speakup/Kconfig already scanned?
make[1]: *** [oldconfig] Error 1
make: *** [oldconfig]
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> >
> > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> > ker
Hi, Matthias Urlichs wrote:
> Also GITtable, as soon as the mirrors' work is done:
>
> http://www.kernel.org/git/?p=linux/kernel/git/smurf/v2.6.13-rc3-mm1.git;a=summary
Moved to
http://www.kernel.org/git/?p=linux/kernel/git/smurf/linux-trees.git;a=summary
--
Matthias Urlichs | {M:U} IT De
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> +update-filesystems-for-new-delete_inode-behavior-fix.patch
>
> This needs to be, too.
Applied.
Joel
--
"There are only two ways to live your life. One is as though nothing
is a miracle. The other is as though everythi
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
>
>
> - Added the CKRM patches. This i
On Fri, 15 Jul 2005, Adrian Bunk wrote:
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.13-rc2-mm2:
> >...
> > git-scsi-misc.patch
> >...
> > Subsystem trees
> >...
>
...
> +obj-$(CONFIG_SCSI_QLA24XX) += qla2xxx.o
>
>
> I don't know what exactly y
Grant Coady <[EMAIL PROTECTED]> wrote:
>
> On Fri, 15 Jul 2005 01:36:53 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> Did _not_ break Yenta + CardBus on Toshiba ToPIC100:
> http://scatter.mi
On Fri, 15 Jul 2005 01:36:53 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
Did _not_ break Yenta + CardBus on Toshiba ToPIC100:
http://scatter.mine.nu/test/linux-2.6/tosh/dmesg-2.6.13-rc3-mm1a.gz
--G
Hi, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
Also GITtable, as soon as the mirrors' work is done:
http://www.kernel.org/git/?p=linux/kernel/git/smurf/v2.6.13-rc3-mm1.git;a=summary
... since people asked:
- trees from GIT
Russell King <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 15, 2005 at 01:56:29AM -0700, Andrew Morton wrote:
> > Russell King <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> > > > +uart_handle_sysrq_char-warning-fix.patch
> > > >
> > > > Fix a
On Fri, Jul 15, 2005 at 01:56:29AM -0700, Andrew Morton wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> > > +uart_handle_sysrq_char-warning-fix.patch
> > >
> > > Fix a warning
> >
> > Andrew, this requires a little more fi
Russell King <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> > +uart_handle_sysrq_char-warning-fix.patch
> >
> > Fix a warning
>
> Andrew, this requires a little more fixing than your simple patch.
> Several drivers omit 'regs' from the receive han
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> +uart_handle_sysrq_char-warning-fix.patch
>
> Fix a warning
Andrew, this requires a little more fixing than your simple patch.
Several drivers omit 'regs' from the receive handler when sysrq is
not enabled. Hence, this simple fix
63 matches
Mail list logo
