>>> On Thu, Feb 14, 2008 at 10:57 AM, in message
<[EMAIL PROTECTED]>, Peter Zijlstra <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Here the current patches that rework load_balance_monitor.
>
> The main reason for doing this is to eliminate the wakeups the thing
> generates,
> esp. on an idle system.
On Thu, Feb 14, 2008 at 8:03 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > The "flags" argument could be the same as for regular mount, and
> > contain the mnt_flags - so the extra argument could maybe usefully be
> > a "mnt_flags_mask", to indicate which flags we actually care about
> >
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> --- linux.orig/arch/x86/kernel/efi.c
> +++ linux/arch/x86/kernel/efi.c
> @@ -413,17 +413,31 @@ void __init efi_enter_virtual_mode(void)
>
> efi.systab = NULL;
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> +
On Thu, 2008-02-14 at 13:58 +0200, Boaz Harrosh wrote:
> This is a bugfix for the 2.6.24.x stable releases.
>
> gdth_exit would first remove all cards then stop the timer
> and would not sync with the timer function. This caused a crash
> in gdth_timer() when module was unloaded.
> So
> On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > For recursive bind mounts, only the root of the tree being bound
> > > inherits the per-mount flags from the mount() arguments; sub-mounts
> > > inherit their per-mount flags from the source tree as usual.
> >
>
The biggest issue with load_balance_monitor atm is that it never goes
to sleep, and generates a huge amount of wakeups, even on idle systems.
I tried doing a simple interruptible sleep on idle, but wake_up_process
can't be used while holding the rq lock, so that didn't quite work out.
The next
Hi,
> The functions time_before, time_before_eq, time_after, and time_after_eq are
> more robust for comparing jiffies against other values.
>
> So following patch implements usage of the time_after() macro, defined at
> linux/jiffies.h, which deals with wrapping correctly
>
> Cc: [EMAIL
Hi,
Here the current patches that rework load_balance_monitor.
The main reason for doing this is to eliminate the wakeups the thing generates,
esp. on an idle system. The bonus is that it removes a kernel thread.
Paul, Gregory - the thing that bothers me most atm is the lack of
is no nice name for the real
base point for your merges anyhow.
I guess there are a couple of sensible names for these. Either a simple
date or using the nearest sane tag.
So either:
next-20080214
or:
v2.6.25-rc1-next1
Where the "base" version would be determinable from:
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> - if (ioremap_change_attr(vaddr, size, mode) < 0) {
> + /* Fix up the direct mapping for the new cache attributes */
> + err = ioremap_change_attr((unsigned long)__va(phys_addr),
> + size + offset, mode);
Ugh.
On Wed, Feb 13 2008 at 21:38 +0200, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Feb 13 2008 11:03, Boaz Harrosh wrote:
>>> I've tested this patch now - and it works fine. Now rmmod, halt and
>>> reboot also works.
>>>
>>> Stefan Priebe
>>>
>> This is grate news Stefan. Thank you very much for
On Thu, Feb 14, 2008 at 06:10:19PM +0300, Dmitry wrote:
> 2008/2/13, Mark Brown <[EMAIL PROTECTED]>:
> > +#define WM97XX_ADCSEL_X0x1000 /* x coord measurement */
> > +#define WM97XX_ADCSEL_Y0x2000 /* y coord measurement */
> > +#define WM97XX_ADCSEL_PRES
On Thu, Feb 14, 2008 at 09:09:08AM -0600, Steve Wise wrote:
> Note that for T3, this involves suspending _all_ rdma connections that are
> in the same PD as the MR being remapped. This is because the driver
> doesn't know who the application advertised the rkey/stag to. So without
Is there a
On Fri, 2008-02-15 at 02:00 +1100, Stephen Rothwell wrote:
> I would prefer that the trees be added by the subsystem maintainers and
> they can tell me which branch represents their expectations for the next
> kernel release (in this case 2.6.26). But thanks, hopefully you will have
> prodded
I recently purchased a USB->Com Port serial cable from Radio Shack
(Model number 26-183) which did no seem to want to work. After looking
into it I discovered that it is based on the Prolific chipset using the
PL2303 driver.
I then checked the Vendor and Product ID against the list in the drive
On Fri, Feb 15, 2008 at 02:00:19AM +1100, Stephen Rothwell wrote:
> Hi Rafael,
>
> On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
> >
> > Perhaps you can add:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
>
> I would prefer
On Thu, 2008-02-14 at 13:07 +0100, Bartlomiej Zolnierkiewicz wrote:
> > I worry that another git-bisect session will be needed unless SCSI
> > developers are already aware of the problem source.
>
> Yinghai Lu noticed that it may be actually a SES problem:
>
> http://lkml.org/lkml/2008/2/14/88
>
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: Ingo Molnar <[EMAIL
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patchset implements usage of the time_* macros, defined at
linux/jiffies.h, which deals with wrapping correctly
arch/alpha/kernel/traps.c
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: Richard Henderson <[EMAIL
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() & time_before() macros,
defined at linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
The functions time_before, time_before_eq, time_after, and time_after_eq are
more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at
linux/jiffies.h, which deals with wrapping correctly
Cc: [EMAIL PROTECTED]
Taking a step back, I went to a very simple test environment:
o 4-way IA64
o 2 disks (on separate RAID controller, handled by separate ports on the same
FC HBA - generates different IRQs).
o Using write-cached tests - keep all IOs inside of the RAID controller's
cache, so no perturbations
Am Thu, 14 Feb 2008 16:23:37 +0100 (CET)
schrieb Jan Engelhardt <[EMAIL PROTECTED]>:
>
> On Feb 14 2008 16:19, Hans-Jürgen Koch wrote:
> >>
> >> Q: What if a program attempts to mkdir /dev/nullmnt/foo to just
> >>create a file /dev/nullmnt/foo/barfile?
> >> A: /dev/nullmnt/foo must continue
On Fri, 2008-02-15 at 02:00 +1100, Stephen Rothwell wrote:
> I would prefer that the trees be added by the subsystem maintainers and
> they can tell me which branch represents their expectations for the next
> kernel release (in this case 2.6.26). But thanks, hopefully you will have
> prodded them
Hello,
Uwe Kleine-König wrote:
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index 6c0a9c4..76ddcf3 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -79,6 +79,10 @@ static int gpio_led_probe(struct platform_device *pdev)
> cur_led
On Feb 14 2008 16:19, Hans-Jürgen Koch wrote:
>>
>> Q: What if a program attempts to mkdir /dev/nullmnt/foo to just
>>create a file /dev/nullmnt/foo/barfile?
>> A: /dev/nullmnt/foo must continue to exist or be accepted for a while,
>>or perhaps for eternity.
>
>Well, the problem seems to
[ cc: linux-fsdevel ]
On Thu, Feb 14, 2008 at 7:22 AM, Paul Menage <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > I think this concept is reasonable, but I don't think MS_BIND_FLAGS
> > is a descriptive name for this flag.
On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> I think this concept is reasonable, but I don't think MS_BIND_FLAGS
> is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better
> but still isn't optimal.
>
MS_BIND_FLAGS_OVERRIDE ?
Paul
--
To
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > Thomas Gleixner (1):
> > x86: EFI: fix use of unitialized variable and the cache logic
>
> Your honor, I would like to register a differing opinion...
As i mentioned it (in the portion of my email
Am Thu, 14 Feb 2008 16:00:06 +0100 (CET)
schrieb Jan Engelhardt <[EMAIL PROTECTED]>:
>
> On Feb 14 2008 10:46, Andi Kleen wrote:
> >Jasper Bryant-Greene <[EMAIL PROTECTED]> writes:
> >>
> >> This could be done fairly trivially with FUSE, and IMHO is a good
> >> use for FUSE because since you're
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > For recursive bind mounts, only the root of the tree being bound
> > inherits the per-mount flags from the mount() arguments; sub-mounts
> > inherit their per-mount flags from the source tree as usual.
>
> This is
In each case below, I have followed the original semantics, but in
drivers/atm/eni.c and drivers/atm/horizon.c, I have some doubts as to
whether the original semantics is correct. In drivers/atm/eni.c, is the
division intended to be by div or by div-1? In drivers/atm/horizon.c, it
seems strange
From: Julia Lawall <[EMAIL PROTECTED]>
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
From: Julia Lawall <[EMAIL PROTECTED]>
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
From: Julia Lawall <[EMAIL PROTECTED]>
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
From: Julia Lawall <[EMAIL PROTECTED]>
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
Hi Jiri,
On Thu, 14 Feb 2008 16:08:06 +0100 (CET) Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> The daily snapshots are not tagged in Linus' tree, right? So I don't think
> this would suffice.
Its ok, I know how to convert them to SHA1s.
--
Cheers,
Stephen Rothwell[EMAIL
From: Julia Lawall <[EMAIL PROTECTED]>
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
Hi,
2008/2/13, Mark Brown <[EMAIL PROTECTED]>:
> diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h
> new file mode 100644
> index 000..f0d9fc0
> --- /dev/null
> +++ b/include/linux/wm97xx.h
> @@ -0,0 +1,308 @@
...
> +#define WM97XX_POLL0x8000 /* initiate a
Felix Marti wrote:
That is correct, not a change we can make for T3. We could, in theory,
deal with changing mappings though. The change would need to be
synchronized though: the VM would need to tell us which mapping were
about to change and the driver would then need to disable DMA to/from
On Thu, 14 Feb 2008, Jean Delvare wrote:
> > To make my life easier, can I ask that the series file for any quilt
> > trees in the linux-next tree have a comment at the top to identify
> > their base (either a SHA1 or some other ref in Linus' tree). Like
> > this:
> > # BASE
> Done. Right
Harvey Harrison :
> arch/x86/kernel/kprobes.c:584:16: warning: symbol
> 'kretprobe_trampoline_holder' was not declared. Should it be static?
> arch/x86/kernel/kprobes.c:676:6: warning: symbol 'trampoline_handler' was not
> declared. Should it be static?
>
> Make them static and add the __used
Hi Jean,
On Thu, 14 Feb 2008 16:04:42 +0100 Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> Done. Right now it says:
>
> # BASE 2.6.25-rc1-git3
>
> Is it OK with you?
That is great. Thanks.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
On 02/14/2008 03:50 PM, James Bottomley wrote:
On Wed, 2008-02-13 at 23:43 -0500, Jeff Garzik wrote:
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
Commit:
On Thu, 14 Feb 2008, Mika Lawando wrote:
> Jasper Bryant-Greene schrieb:
>> On Thu, 2008-02-14 at 10:30 +0100, rzryyvzy wrote:
>>
>>> /dev/null is often very useful, specially if programs force to save data in
>>> some file. But some programs like to creates different temporary file
>>> names,
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
> Please note the lastest git commit is missing one part (which was in Jozsef's
> original patch).
Sorry everyone, that's my fault: the patch I sent for the stable branch
was correct, however I mistyped a state in the patch for the newest
git tree -
On 02/14/2008 03:47 PM, Jiri Slaby wrote:
On 02/14/2008 03:44 PM, Jiri Slaby wrote:
commit
99109301d103fbf0de43fc5a580a406c12a501e0
in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci
[...]
BTW if you have more than one card, you protected the driver from no
race, since you
Hi Stephen,
On Fri, 15 Feb 2008 01:42:10 +1100, Stephen Rothwell wrote:
> To make my life easier, can I ask that the series file for
> any quilt trees in the linux-next tree have a comment at the
> top to identify their base (either a SHA1 or some other ref
> in Linus' tree). Like this:
>
> #
Hi Rafael,
On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
>
> Perhaps you can add:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
I would prefer that the trees be added by the subsystem maintainers and
they can tell me which branch
On 02/14/2008 03:47 PM, Jiri Slaby wrote:
On 02/14/2008 03:44 PM, Jiri Slaby wrote:
Hi,
commit
99109301d103fbf0de43fc5a580a406c12a501e0
in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci
refcount on exit. Also you do not so on fail paths... I wonder why
these mistakes happen
On Feb 14 2008 10:46, Andi Kleen wrote:
>Jasper Bryant-Greene <[EMAIL PROTECTED]> writes:
>>
>> This could be done fairly trivially with FUSE, and IMHO is a good use
>> for FUSE because since you're just throwing most data away, performance
>> is not a concern.
There is a much more interesting
On Wed, Feb 13, 2008 at 05:25:28PM +0100, Frank van Maarseveen wrote:
> On at least two Dell optiplex 755 systems with a Core 2 Duo I get
s/two/three/
>
> Feb 13 15:14:01 inari CPU 1: Machine Check Exception: 0004
> Feb 13 15:14:01 inari CPU 0: Machine Check Exception:
On Wed, 2008-02-13 at 23:43 -0500, Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> > Gitweb:
> > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
> > Commit: 99109301d103fbf0de43fc5a580a406c12a501e0
> >
On Thursday, 14 of February 2008, Stephen Rothwell wrote:
> Hi all,
>
> I have created the first cut of the linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
>
> Things to know about this tree:
>
> It has two branches - master and stable. Stable is
On 02/14/2008 03:44 PM, Jiri Slaby wrote:
Hi,
commit
99109301d103fbf0de43fc5a580a406c12a501e0
in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci
refcount on exit. Also you do not so on fail paths... I wonder why these
mistakes happen every second time somebody tries to do
Hi all,
To make my life easier, can I ask that the series file for any quilt trees in
the linux-next tree have a comment at the top to identify their base (either a
SHA1 or some other ref in Linus' tree). Like this:
# BASE
Also, if you only want a subset of the series file included, you can
On Thu, 14 Feb 2008 15:06:28 +0100 (CET) Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> On Fri, 15 Feb 2008, Stephen Rothwell wrote:
>
> > The tree consists of subsystem git and quilt trees. Currently, the
> > quilt trees are integrated by importing them into appropriately based
> > git branches
On Donnerstag, 14. Februar 2008, Jeff Dike wrote:
> On Thu, Feb 14, 2008 at 12:13:09PM +0100, Ph. Marek wrote:
> > make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
> >
> > make[2]: *** No rule to make target `bzImage'. Stop.
>
> This seems pretty clear, no?
>
> bzImage is a
If you have GPIO_LIB gpio_cansleep oopses on an invalid
gpio. So better gpio_request your pin first.
Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]>
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Raphael Assenat <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
---
Hello,
I currently
On Thu, Feb 14, 2008 at 08:32:44AM -0500, Mathieu Desnoyers wrote:
> * Paul Mundt ([EMAIL PROTECTED]) wrote:
> > CC kernel/marker.o
> > kernel/marker.c: In function 'marker_update_probes':
> > kernel/marker.c:627: error: too few arguments to function
> > 'module_update_markers'
> >
Andrew Morton wrote:
On Wed, 13 Feb 2008 10:30:48 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
Enough bug fixes and changes that we need a new driver version.
Are none of them serious enough to warrant a 2.6.24.x backport?
No, nothing really terribly urgent. Just minor stuff.
Am Donnerstag, 14. Februar 2008 schrieb Arnd Hannemann:
> Hans-Peter Jansen wrote:
> > I'm suffering from a strange SysRq problem:
> >
> > syslog shows haphazardly "SysRq : HELP" lines, while I definitely
> > didn't triggered them, neither via (PS/2) keyboard, nor via
> > /proc/sysrq-trigger. This
On Thu, Feb 14, 2008 at 12:13:09PM +0100, Ph. Marek wrote:
> make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
> make[2]: *** No rule to make target `bzImage'. Stop.
This seems pretty clear, no?
bzImage is a x86-ism. Just leave it off, and you'll get linux and vmlinux.
Sorry about the noise ...
Going to another machine with a recent gcc, and re-applying the config file
seems to work, I now got a image.
Just have to get it working now ...
Gabriel: I just got it working.
That was a plain 2.6.24.2 untar - but the "make ARCH=um bzImage" seems to make
a mess.
Ph. Marek wrote:
> Hello everybody,
Hi,
>
> On Donnerstag, 14. Februar 2008, Ph. Marek wrote:
>> I'm trying to compile an UML binary from 2.6.24.
>>
>> make ARCH=um O=... bzImage
>>
>> gives
>>
>> make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
>> make[1]: Entering directory
Hi Paul,
> The following adds one more bitmap operator, with the usual
> cpumask and nodemask wrappers. This operator computes one
> bitmap relative to another. If the n-th bit in the origin
> mask is set, then the m-th bit of the destination mask will
> be set, where m is the position of
On Fri, 15 Feb 2008, Stephen Rothwell wrote:
> The tree consists of subsystem git and quilt trees. Currently, the
> quilt trees are integrated by importing them into appropriately based
> git branches and then merging those branches.
Now, would it be possible to have somewhere listed the
On Wed, 13 Feb 2008, Kevin Hilman wrote:
> The smc_special_locks should also be used when either softIRQs or hard
> IRQs are preempted which may lead to the same problems as under SMP.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Acked-by: Nicolas Pitre <[EMAIL PROTECTED]>
>
> ---
>
On Tue, Oct 16, 2007 at 10:12 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> just found my on hand ck804, and mcp55 based AMD servers:
> nmi_watchdog=1 doesn't work
> but nmi_watchdog=2 does work
>
> =1, it say: IOAPIC 8259A virtual wire mode...
>
> Did nmi_watchdog=1 work on any other amd64
[removing lots of people from Cc]
On Wed, 13 Feb 2008 19:30:51 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > +static int req_dbg_open(struct inode *inode, struct file *file)
> > +{
>
> And this should go into the core.
I've started working on this, but I've run into a problem: The mmc
Linus,
could you please pull from 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to receive fixes for HID layer.
There is one important fix for hid <-> input mapping processing. The rest
are just addidions of new device ids that came after
On 2/14/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> On Thursday 14 February 2008, Borislav Petkov wrote:
> > On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
> >
> > [Added Bart to CC]
> >
> > > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > > On Tue,
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Tue, Feb 12, 2008 at 06:56:50PM -0500, Mathieu Desnoyers wrote:
> > Update spufs to the new linux kernel markers API, which supports connecting
> > more than one probe to a single marker.
>
> Compiles and works for me. But saying I like the odd
Hi all,
I have created the first cut of the linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
Things to know about this tree:
It has two branches - master and stable. Stable is currently just Linus'
tree and will never rebase. Master will rebase on an almost
Hi Alan,
> It's certainly possible to add one but the first question would be "why
> do you need it - what sort of API are you trying to build"
>
The protocol works in adhoc wireless mode, so when I send a packet,
I've to wait a while before I send it again, like TCP timeout
retransmistions
Hello everybody,
On Donnerstag, 14. Februar 2008, Ph. Marek wrote:
> I'm trying to compile an UML binary from 2.6.24.
>
> make ARCH=um O=... bzImage
>
> gives
>
> make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
> make[1]: Entering directory `output_path/linux-2.6.24.2'
> GEN
* Roland McGrath ([EMAIL PROTECTED]) wrote:
>
> The samples/ subdirectory contains only modules.
> But the only make run done there is in commands for vmlinux.
> I can't see why this was ever done in this nonstandard fashion.
> As things stand, the modules don't get built by 'make modules'.
>
>
* Paul Mundt ([EMAIL PROTECTED]) wrote:
> CC kernel/marker.o
> kernel/marker.c: In function 'marker_update_probes':
> kernel/marker.c:627: error: too few arguments to function
> 'module_update_markers'
> make[1]: *** [kernel/marker.o] Error 1
> make: *** [kernel] Error 2
>
>
Fix left over EFI cache mapping problems
[History: this was originally part of a larger patch that got
partially added earlier. This patch fixes the left-over bugs
and also fixes another bug I noticed while revising this]
cpa/set_memory_* does not properly support ioremap or fixmap
(efi_ioremap
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide: mark "ide=reverse" option as obsolete
- it is valid only if "Probe IDE PCI devices in the PCI bus order
(DEPRECATED)" config option is used
- Greg needs to remove pci_get_device_reverse() for PCI core changes
Cc:
On Thu, 2008-02-14 at 09:30 +0100, Miklos Szeredi wrote:
> And this is where we usually conclude, that a new userspace mount API
> is long overdue. So for starters, how about a new syscall for bind
> mounts:
>
> int mount_bind(const char *src, const char *dst, unsigned flags,
>
On Thu 14. Feb - 13:40:48, Holger Macht wrote:
> If a device/bay is inside a docking station, we need to register for dock
> events additionally to bay events. If a dock event occurs, the dock driver
> will call the appropriate handler (ata_acpi_ap_notify() or
> ata_acpi_dev_notify()) for us.
>
>
Adrian wrote:
> This patch makes the following needlessly global functions static:
> - cpuset_test_cpumask()
> - cpuset_change_cpumask()
> - cpuset_do_move_task()
Thanks.
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
--
I won't rest till it's the best ...
On Thu, 14 Feb 2008, Shi Weihua wrote:
> Fix the following compile warning without CONFIG_PREEMPT_RT:
> kernel/timer.c:937: warning: ‘count_active_rt_tasks’ defined but not used
>
> Signed-off-by: Shi Weihua <[EMAIL PROTECTED]>
Thanks, applied.
-- Steve
--
To unsubscribe from this list: send
On Mon 11. Feb - 22:11:32, Tejun Heo wrote:
> Holger Macht wrote:
> >> It should be called via ata_acpi_{ap|dev}_notify() callbacks installed
> >> via acpi_install_notify_handler(). Can you add dump_stack() in the
> >> function and verify that it actually is being called? It could be that
> >>
If a device/bay is inside a docking station, we need to register for dock
events additionally to bay events. If a dock event occurs, the dock driver
will call the appropriate handler (ata_acpi_ap_notify() or
ata_acpi_dev_notify()) for us.
Signed-off-by: Holger Macht <[EMAIL PROTECTED]>
---
diff
From: Paul Jackson <[EMAIL PROTECTED]>
[Beware - never tested, never booted.]
The following adds one more bitmap operator, with the usual
cpumask and nodemask wrappers. This operator computes one
bitmap relative to another. If the n-th bit in the origin
mask is set, then the m-th bit of the
I had taken a vow of silence on this one, but couldn't resist one more
round.
David wrote:
> My preference (both mode and flags stored in the same member of struct
> mempolicy):
>
>Advantages:
>
> - completely consistent with the userspace API of passing modes
> and flags
Hans-Peter Jansen wrote:
> I'm suffering from a strange SysRq problem:
>
> syslog shows haphazardly "SysRq : HELP" lines, while I definitely didn't
> triggered them, neither via (PS/2) keyboard, nor via /proc/sysrq-trigger.
> This is accompanied with stalls of about 15-60 secs.
Any chance
401 - 500 of 1108 matches
Mail list logo
