On Sat, Sep 22, 2007 at 12:32:18AM +0200, Andi Kleen wrote:
>
> Also allow to set svm lock.
>
> TBD double check, documentation, i386 support
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Could we have this patch tagged with x86 instead of "Experimental" in subject.
Sam
-
To unsubs
On 9/21/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> On 9/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > From: Robert Hancock <[EMAIL PROTECTED]>
> >
> > This path adds validation of the MMCONFIG table against the ACPI reserved
> > motherboard resources. If the MMCONFIG table is found to be r
On Fri, Sep 21, 2007 at 06:45:39PM -0400, Dave Jones wrote:
> On Sat, Sep 22, 2007 at 12:32:02AM +0200, Andi Kleen wrote:
>
>
> > +Select this for:
> > + Pentiums (Pentium 4, Pentium D, Celeron, Celeron D) corename:
> > + -Willamette
> > + -Northwood
> > +
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c
On 9/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> From: Robert Hancock <[EMAIL PROTECTED]>
>
> This path adds validation of the MMCONFIG table against the ACPI reserved
> motherboard resources. If the MMCONFIG table is found to be reserved in
> ACPI, we don't bother checking the E820 table. T
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/md/raid6int8.c
This turned out to be a gcc bug -- I was using an old cross-compiler.
-
To unsubscribe from this list: send the line "unsubscri
Hi!
> I'm pleased to announce third release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
How is this different from raid0/1 over nbd? Or raid0/1 o
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/ata/pata_scc.c
http://lkml.org/lkml/2007/9/21/557
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hi!
> This adds the documentation for the extended crashkernel syntax into
> Documentation/kdump/kdump.txt.
Should you also update kernel-parameters.txt?
> +For example:
> +
> +crashkernel=512M-2G:64M,2G-:128M
> +
> +This would mean:
> +
> +1) if the RAM is smaller than 512M, then don't
Hi!
> > Ok, here we are. The bad one uses C2 which stops the local apic on the
> > VAIO. I suspect we end up in the suspend/resume with going into C2
> > without the broadcast active.
> >
> > Can you try to get the output of SysRq-Q during the "it needs help from
> > keyboard" period ?
> >
>
>
On 9/21/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> No. The requirement for 'hard' mounts is not that the server be up all
> the time. The server can go up and down as it pleases: the client can
> happily recover from that.
>
> The requirement is rather that nobody remove it permanently before
On Thu, Sep 20, 2007 at 12:06:10PM -0700, Stephen Hemminger wrote:
> Need to null terminate environment. Found by inspection
> while looking for similar problems to platform uevent bug
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Much thanks, git-applymbox'ed to battery-2.6.git. I sup
On Fri, Sep 21, 2007 at 11:39:36PM +0100, Alan Cox wrote:
> On Fri, 21 Sep 2007 17:15:16 -0500
> Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > Convert the io_req_t members to kio_addr_t, to allow use on machines with
> > more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc).
On Thursday 20 September 2007, Pavel Machek wrote:
> Hi!
>
> > ...should they be changed to 200? Or perhaps file should be readable?
No, mode 644 is fine. No reason to prevent "other" people from
reading the alarm time (is there?) and if you write a legal value,
that will work. So $SUBJECT is n
On 9/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Earlier patch added IO APIC setup into local APIC setup. This caused
> modpost warnings. Fix them by untangling setup_local_APIC() and splitting
> it into smaller functions. The IO APIC initialization is only called
> for the BP init.
>
> Also r
* Sat, 22 Sep 2007 00:32:11 +0200 (CEST)
[]
> - flush_map(&l);
> + flush_map(&arg);
+ flush_map(&arg.l);
CC arch/x86_64/mm/pageattr.o
arch/x86_64/mm/pageattr.c: In function 'global_flush_tlb':
arch/x86_64/mm/pageattr.c:274: warning: passing argument 1 of 'flush_map' from
inc
Hi,
Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet
weekend).
Anyway, it seems that radeonfb and my:
"01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M
5955 (PCIE)"
don't get along anymore, by:
a) X somehow fails to initialize the card and
Hi,
On Sat, 22 Sep 2007, Andi Kleen wrote:
>
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
>
> These build warnings:
>
> In file included from include/asm/thread_info.h:16,
> from include/linux/thread_info.h:21,
> from include/linux/preempt.h:9,
> from include/linux/spinlock.h:49,
> from includ
Mathieu Desnoyers writes:
> Make sure that at least cmpxchg64_local is available on all architectures to
> use
> for unsigned long long values.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "u
Hi,
There is a bug in os_free_irq_by_cb, when the first element
of active_fds list is free, the value of active_fds is not
updated, just value in stack is updated.
The intresting thing is that without this patch, a poweroff
in user mode linux guest will halt the host linux system.It
s
On Fri, 21 Sep 2007, Andrew Morton wrote:
>
> On Fri, 21 Sep 2007 13:39:06 +0400
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > Quite a few fields are zeroed during user_struct creation, so use
> > kmem_cache_zalloc() -- save a few lines and #ifdef. Also will help avoid
> > #ifdef CONFIG_
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note: this patch requires "[Patch 2/2] Relay reset consumed" is applied.
-
Tra
This patch allows relay channels to be reset i.e. unconsumed.
Basically allows a 'rewind' function for flight-recorder tracing.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
Signed-off-by: David Wilder <[EMAIL PROTECTED]>
---
Documentation/filesystems/relay.txt | 11 ++
include/linux/relay
On 09/20/2007 07:52 PM, Denys Vlasenko wrote:
On Sunday 02 September 2007 23:06, Rene Herman wrote:
Blah. Your message has:
Content-Type: TEXT/PLAIN; charset=iso-2022-jp
This apparently is caused by a combination of GCC using groovy UTF tickmarks
in its error messages when in a UTF
On Fri, Sep 21, 2007 at 10:56:56PM -0400, Steven Rostedt wrote:
>
> [ sneaks away from the family for a bit to answer emails ]
[ same here, now that you mention it... ]
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
> >
On Fri, Sep 21, 2007 at 11:15:42PM -0400, Steven Rostedt wrote:
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
> > > On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > > > On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrot
Looks good to me.
Joe
Acked-by: Joe Korty <[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/
Eyleme Cagri: Kardesime Dokunma, Olum Yasalari Kaldirilsin
Nijeryali gocmen Festus Okey'in oldurulmesi bu soruna karsi hicbirimizin
duyarsiz kalmamasi gerektigini gosterdi. Olum yasalarinin kaldirilmasi ve
gocmen kardeslerimizle dayanismak icin 23 Eylul Pazar gunu saat 14.00'de
Taksim Tramvay Durag
Mike,
Could you try this patch to see if it solves the latency problem?
tong
Changes:
1. Modified vruntime adjustment logic in set_task_cpu(). See comments in
code. This fixed the negative vruntime problem.
2. This code in update_curr() seems to be wrong:
if (unlikely(!curr))
ret
* Sat, 22 Sep 2007 00:32:05 +0200 (CEST)
[]
> Index: linux/Documentation/filesystems/proc.txt
>===
> --- linux.orig/Documentation/filesystems/proc.txt
> +++ linux/Documentation/filesystems/proc.txt
> @@ -347,7 +347,40 @@ connects the
[took off Ingo, because he has my ISP blacklisted, and I'm tired of
getting those return mail messages. He can read LKML or you can re-CC
him. Sad since this is a topic he should be reading. ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rost
Acked-by: Len Brown <[EMAIL PROTECTED]>
Sorry, i thought we fixed this earlier.
thanks,
-Len
On Friday 21 September 2007 16:44, Andi Kleen wrote:
>
> default m is near always wrong, like here. For some reason ACPI
> likes to reintroduce these and I like to immediately squash them again
> befor
[ sneaks away from the family for a bit to answer emails ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
> >
> > --
> > On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > > >
> > > > In any case, I will be looking at the scenarios
Hi,
On Thu, 20 Sep 2007, Alan Cox wrote:
>
> On Thu, 20 Sep 2007 14:13:15 +0100
> [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > doesn't show up on other arches because this driver is specific to the
> > architecture.
> >
* Sat, 22 Sep 2007 00:32:04 +0200 (CEST)
[]
> arch/i386/kernel/traps.c | 16
> arch/i386/mm/fault.c | 13 +++--
> 2 files changed, 11 insertions(+), 18 deletions(-)
It seems, like size can be reduced even more now:
[]
> report_bug(regs->eip, regs);
On Fri, Sep 21, 2007 at 10:33:56AM +0100, Dave Haywood wrote:
>Contents:
> ver_linux output
> Summary of compile warnings
> Full compile log
> .config
>
>
>
>Linux s1 2.6.23-rc7-g335fb8fc #9 SMP Fri Sep 21 09:31:01 BST 2007 i686 Pentium
>III (Cop
Fix may-be-used-uninitialized warnings.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
fs/isofs/namei.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc7/fs/isofs/namei.c
===
--- linux-2.6.23-rc7.o
Hi Linus,
Before 2.6.23, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
This restores some dmesg to what folks had in 2.6.22,
and prevents a possible system hang on video switching.
This will update the files shown below.
thanks!
-Len
ps. ind
On Thu, Sep 20, 2007 at 12:31:39PM +0100, Hugh Dickins wrote:
> On Wed, 19 Sep 2007, Peter Zijlstra wrote:
> > On Wed, 19 Sep 2007 21:03:19 +0100 (BST) Hugh Dickins
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 19 Sep 2007, Andy Whitcroft wrote:
> > > > Seems I have a case of a largish i386 NUM
On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> > > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
> > > > + /*
> > > > +
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote:
> From: Denys Vlasenko <[EMAIL PROTECTED]>
> Date: Fri, 21 Sep 2007 18:03:55 +0100
>
> > Do patches look ok to you?
>
> I'm travelling so I haven't looked closely yet :-)
>
> Michael can take a look and I'll try to do so as well
> tonight.
>
On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
>
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > >
> > > In any case, I will be looking at the scenarios more carefully. If
> > > it turns out that GP_STAGES can indeed be cranked down a bit, well,
> > > that is an easy chan
On Fri, Sep 21, 2007 at 04:15:39PM -0500, Rob Landley wrote:
[]
> > >Not all, but critical info, that must exist in human-readable form of
> > >course.
> >
> > I disagree. For a production product the you want minimal information
> > to reduce the communication bandwidth required between the remot
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> >
> > In any case, I will be looking at the scenarios more carefully. If
> > it turns out that GP_STAGES can indeed be cranked down a bit, well,
> > that is an easy change! I just fired off a POWER run with GP_STAGES
> > set to 3, will let you kn
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
>
> Covering the pieces that weren't in Peter's reply. ;-)
>
> And thank you -very- much for the careful and thorou
Siddha, Suresh B wrote:
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
So now I have this, which is pretty much
what
I wanted:
reg00: base=0x ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0x1
> From: Neil Brown [mailto:[EMAIL PROTECTED]
> On Friday September 21, [EMAIL PROTECTED] wrote:
> > On Thu, 20 Sep 2007 18:27:35 -0700
> > Dan Williams <[EMAIL PROTECTED]> wrote:
> >
> > > Fix a couple bugs and provide documentation for the async_tx api.
> > >
> > > Neil, please 'ack' patch #3.
> >
On Fri, Sep 21, 2007 at 04:03:43PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
> > Paul,
> >
> > Looking further into this, I still think this is a bit of overkill
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> default, my system boots up with these MTRR settings:
>
> reg00: base=0x
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Covering the pieces that weren't in Peter's reply. ;-)
And thank you -very- much for the careful and thorough review!!!
> > #endif /* __KERNEL__ */
> > #endif /*
On Friday September 21, [EMAIL PROTECTED] wrote:
> On Thu, 20 Sep 2007 18:27:35 -0700
> Dan Williams <[EMAIL PROTECTED]> wrote:
>
> > Fix a couple bugs and provide documentation for the async_tx api.
> >
> > Neil, please 'ack' patch #3.
> >
> > git://lost.foo-projects.org/~dwillia2/git/iop async
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote:
> > According to an earlier thread, dgrs was never really maintained,
> > written for hardware that was never really distributed widely, and very
> > likely hasn't had users in years... if ever.
> >
> > If that picture is accurate (it's a
Новый сотовый телефон по цене использованного.
Уважаемые господа,
Преглагаем Вашему вниманию “refurbished” (обновленные) мобильные телефоны.
Это означает, что мобильный телефон имеет:
б/у, но полностью функциональную материнскую плату
новый оригинальный корпус
новые аксессуары (зарядноеб акку
Kernel 2.6.22.6:
# echo "1" >/sys/devices/system/edac/pci/check_pci_parity
# dmesg | tail -14
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
Call Trace:
[] down_read+0x15/0x24
[] pci_get_subsys+0x81/0x113
[] schedule_timeout+0x85/0xad
Hi.
On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote:
> I think that in order for this to work, there would need to be some
> ABI whereby the resume-ing kernel can pass its entire ACPI state and
> a bunch of other ACPI-related device details to the resume-ed kernel,
> which I believ
On Fri, 21 Sep 2007 16:39:40 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-09-21 at 16:03 -0700, Andrew Morton wrote:
> > Dave Hansen <[EMAIL PROTECTED]> wrote:
> >
> > > Some ioctl()s can cause writes to the filesystem. Take
> > > these, and make them use mnt_want/drop_write() ins
On Fri, Sep 21, 2007 at 07:23:09PM -0400, Steven Rostedt wrote:
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > If you do a synchronize_rcu() it might well have to wait through the
> > following sequence of states:
> >
> > Stage 0: (might have to wait through part of this to get out of "
> > config MPSC
> > bool "Intel P4 / older Netburst based Xeon"
> > help
>
> sidenote: I always wondered what 'PSC' stood for ?
Produces Smoke and Cooks ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
Change the invocations of make in the output directory Makefile and the
main Makefile for seperate object trees to pass all goals to one $(MAKE)
via a new phony target "sub-make" and the existing target _all.
When compiling with seperate object directories, a seperate make is called
in the context
On Fri, 2007-09-21 at 16:03 -0700, Andrew Morton wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> > Some ioctl()s can cause writes to the filesystem. Take
> > these, and make them use mnt_want/drop_write() instead.
> >
> > We need to pass the filp one layer deeper in XFS, but
> > somebody _ju
David Howells <[EMAIL PROTECTED]> wrote:
> Peter Staubach <[EMAIL PROTECTED]> wrote:
>
> > Did I miss the section where the modified semantics about which
> > mounted file systems can use the cache and which ones can not
> > was implemented?
>
> Yes.
fs/nfs/super.c:
case Opt_sh
Threads also have an exit code on their own, so report it in
TASKSTATS_CMD_ATTR_PID.
For TASKSTATS_CMD_ATTR_TGID, instead of relying only on the exit code of the
leader, we use task->signal->group_exit_code if not null as suggested by
Oleg Nesterov.
Also, document that as of this patch, fill_thre
fill_thread_group() may want to know if it is filling TASKSTATS_CMD_ATTR_TGID
or TASKSTATS_CMD_ATTR_PID stats, so give it this information in the tg_stats
boolean.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonath
JBD2 naming cleanup
From: Mingming Cao <[EMAIL PROTECTED]>
change micros name from JBD_XXX to JBD2_XXX in JBD2/Ext4
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/extents.c |2 +-
fs/ext4/super.c |2 +-
fs/jbd2/commit.c |2 +-
fs/jbd2/journal.
TASKSTATS_CMD_ATTR_TGID used to return only the delay accounting stats, not
the basic and extended accounting. With this patch,
TASKSTATS_CMD_ATTR_TGID also aggregates the accounting info for all threads
of a thread group.
TASKSTATS_CMD_ATTR_PID output should be unchanged
TASKSTATS_CMD_ATTR_TGID
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> If you do a synchronize_rcu() it might well have to wait through the
> following sequence of states:
>
> Stage 0: (might have to wait through part of this to get out of "next" queue)
> rcu_try_flip_idle_state,/* "I" */
> rcu
Peter Staubach <[EMAIL PROTECTED]> wrote:
> Did I miss the section where the modified semantics about which
> mounted file systems can use the cache and which ones can not
> was implemented?
Yes.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote:
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
The ACPI platform firmware is allowed to preserve information
accross the hibernation-resume cycle, so this need not be the same.
All of my comments related to the case where S4 is not b
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> They are nonetheless in effect and (heaven forbid) should they be
> abused you don't want to hide the facts from concerned observers.
Because, I suspect, what the observer through /proc should see is what the
process thinks it is doing, not what is tra
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > This is used by CacheFiles to detect read completion on a page in the
> > backing filesystem so that it can then copy the data to the waiting netfs
> > page.
>
> Won't it in any case want to lock the page too?
No. Why would it? All it wants to do
Convert kmalloc to kzalloc() and get rid of the memset().
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext3/xattr.c |3 +--
fs/ext4/xattr.c |3 +--
fs/jbd/journal.c |3 +--
fs/jbd/transaction.c |2 +-
fs/jbd2/journal.c |3 +--
fs/jbd2/transactio
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> So why do you need a new address space operation? AFAICS the generic
> implementation will work for pretty much everyone who supports the
> existing prepare_write()/commit_write().
Because Christoph decreed that I wasn't allowed to call prepare_write()
On Fri, 2007-09-21 at 18:05 -0500, Rob Landley wrote:
> > from printks and defining something that modifies pr_.
> pr_level doesn't exist in mainline.
pr_info and pr_debug do.
pr_alert, pr_emerg, pr_crit, pr_err, and pr_warn could be added.
> > #define pr_info(fmt, arg) printk(KERN_INFO PR_FMT f
On Friday 21 September 2007 12:45:27 pm Joe Perches wrote:
> On Fri, 2007-09-21 at 13:16 -0400, [EMAIL PROTECTED] wrote:
> > What about something *really* hardcore ugly like:
> > #ifdef __FILE__
> > #undef __FILE__
> > #define __FILE__ ""
> > #endif
> > (or similar preprocessor blecherousness) if y
>
> https://bugzilla.redhat.com/show_bug.cgi?id=288421
>
> When running Fedora on a Dell 2950 w/ integrated LSI Perc5i
(megaraid), the
> system will not boot after upgrading to 2.6.22. The boot message
indicates the
> system is somehow seeing through RAID, cannot access logical volume.
This
> ca
On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> > +
> > +/*
> > + * PREEMPT_RCU data structures.
> > + */
> > +
> > +#define GP_STAGES 4
> > +struct rcu_data {
> > + spinlock_t lock; /* Protect rc
On Thu, 20 Sep 2007 12:52:57 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> Some ioctl()s can cause writes to the filesystem. Take
> these, and make them use mnt_want/drop_write() instead.
>
> We need to pass the filp one layer deeper in XFS, but
> somebody _just_ pulled it out in February becau
diff --git a/Makefile b/Makefile
index 3067f6a..12edea0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .6
+EXTRAVERSION = .7
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch
On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
With a bit more glue that would cause GCC to notice that for a
given qprintk_kmalloc the "qpk->type" is always zero because the
level is too high, and therefore it would optimize out *ALL*
Andi Kleen wrote:
Not needed on modern systems without external FPU
TBD on i386 it is only needed for true 386s. Could remove it there
TBD for >= 486
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/setup.c |2 --
1 file changed, 2 deletions(-)
Index: linux/arch/x86_6
We (the -stable team) are announcing the release of the 2.6.22.7 kernel.
It contains a single security bugfix for the x86_64 architecture.
There is potential for local privilege escalation, so all x86_64 users
are certainly encouraged to upgrade.
CVE-2007-4573: x86_64: Zero extend all registers af
On Sat, Sep 22, 2007 at 12:34:31AM +0200, Andi Kleen wrote:
> On Friday 21 September 2007 23:13, Dave Jones wrote:
> > On Fri, Sep 21, 2007 at 10:45:02PM +0200, Andi Kleen wrote:
> > > Kernel doesn't use SSE2, so it doesn't need 16 byte alignment. Also
> > > the stack can be already unaligned
Denys Vlasenko wrote:
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
On Fri, 21 Sep 2007, Denys Vlasenko wrote:
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
I plan to use gzip compression on following drivers
On Thu, 20 Sep 2007 14:30:05 -0700
[EMAIL PROTECTED] wrote:
> cpu_data is currently an array defined using NR_CPUS. This means that
> we overallocate since we will rarely really use maximum configured cpus.
> When NR_CPU count is raised to 4096 the size of cpu_data becomes
> 3,145,728 bytes.
This
On Fri, Sep 21, 2007 at 06:31:12PM -0400, Steven Rostedt wrote:
> On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
> > On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> >
>
On Sat, Sep 22, 2007 at 12:32:02AM +0200, Andi Kleen wrote:
> + Select this for:
> +Pentiums (Pentium 4, Pentium D, Celeron, Celeron D) corename:
> +-Willamette
> +-Northwood
> +-Mobile Pentium 4
> +-Mobile Pentium 4 M
> +
> According to an earlier thread, dgrs was never really maintained,
> written for hardware that was never really distributed widely, and very
> likely hasn't had users in years... if ever.
>
> If that picture is accurate (it's a story I was told), then I am
> definitely queueing up a deletion p
On 09/21/2007 06:32 PM, Andi Kleen wrote:
> From: Pavel Emelyanov <[EMAIL PROTECTED]>
>
> Typically the oops first lines look like this:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
>
> printing eip:
> c049dfbd
> *pde =
> Oops: 0002 [#1]
> PREEM
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
>
> On Fri, 21 Sep 2007, Denys Vlasenko wrote:
>
> > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote:
> >> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
> >>
> >>> I plan to use gzip compression on following drivers'
On Friday 21 September 2007 21:13, Andi Kleen wrote:
> Denys Vlasenko <[EMAIL PROTECTED]> writes:
> >
> > I plan to use gzip compression on following drivers' firmware,
> > if patches will be accepted:
> >
> >textdata bss dec hex filename
> > 17653 109968 240 127861
>-Original Message-
>From: Joe Perches [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 21, 2007 3:33 PM
>To: Gross, Mark
>Cc: Rob Landley; Oleg Verych; Alexey Dobriyan; Michael Opdenacker;
linux-
>[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>Subject: RE: Message codes (Re
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
> Use compiler tricks to remove ALL the static printk string from
> the kernel and replace the printk with something that outputs a
> decimal index followed by tuples, of zero to N, hex-strings on
> I proposed a mechanism for keeping all the pr
On Friday 21 September 2007 23:13, Dave Jones wrote:
> On Fri, Sep 21, 2007 at 10:45:02PM +0200, Andi Kleen wrote:
> > Kernel doesn't use SSE2, so it doesn't need 16 byte alignment. Also
> > the stack can be already unaligned so letting the compiler align
> > is useless. This may make some stack
Not needed on modern systems without external FPU
TBD on i386 it is only needed for true 386s. Could remove it there
TBD for >= 486
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/setup.c |2 --
1 file changed, 2 deletions(-)
Index: linux/arch/x86_64/kernel/setup.c
==
On Fri, 21 Sep 2007 17:15:16 -0500
Olof Johansson <[EMAIL PROTECTED]> wrote:
> Convert the io_req_t members to kio_addr_t, to allow use on machines with
> more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc).
What about the formatting and field widths ?
ulong would probably
Alan Cox wrote:
For example, bnx2 maintainer says that driver and
firmware are closely tied for his driver. IOW: you upgrade kernel
and your NIC is not working anymore.
Another argument is to make kernel be able to bring up NICs
without needing firmware images in initramfs/initrd/hard drive.
d
From: Andrey Mirkin <[EMAIL PROTECTED]>
Right now register edi is just cleared before calling do_exit.
That is wrong because correct return value will be ignored.
Value from rax should be copied to rdi instead of clearing edi.
AK: changed to 32bit move because it's strictly an int
Signed-off-by
Previously the data from before the exec was kept in there. Zero
them instead
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/ia32/ia32_aout.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/arch/x86_64/ia32/ia32_aout.c
=
From: "Jan Beulich" <[EMAIL PROTECTED]>
It doesn't seem to make sense to hide these, even if their counts
can't change at the point in time they're being displayed.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
arch/i386/kernel/irq.c | 18 +
From: "Jan Beulich" <[EMAIL PROTECTED]>
One more of these issues (which were considered fixed a few releases
back): Other than on x86-64, i386 allows set_fixmap() to replace
already present mappings. Consequently, on PAE, care must be taken to
not update the high half of a pte while the low half i
1 - 100 of 557 matches
Mail list logo
