Rather than copy in IDT, GDT and TSS every time, we only need do it
when something has changed (ie. guest IDT/GDT/TSS has changed, or
guest has changed CPU, or CPU has just run another guest).
For the registers, we simply allocate them an entire page and map that
over the stack page in the guest.
"handle" NMI by ignoring it. Can't have been important, right? As the
lguest64 hackers explained, handling NMI is a PITA. Now oprofile does
not crash machine.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 5beeb29ed3a3 arch/i386/lguest/hypervisor.S
---
Hi,
> Most system calls seem to get added to i386 first. This patch
> automatically generates a warning for any new system call which is
> implemented on i386 but not the architecture currently being compiled.
> On PowerPC at the moment, for example, it results in these warnings:
Love it!
...
Hi , all .
Add an RTC driver for Ricoh RS5C313 RTC chip.
Please apply.
regards,
Nobuhiro
Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 95826b9..cc3c0b2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -354,4
Robert P. J. Day wrote:
> i asked about this a while back, but i still haven't heard a
> definitive response as to whether it's acceptable.
Maybe you get response if you post a complete patch.
--
Stefan Richter
-=-=-=== --== -=--=
http://arcgraph.de/sr/
-
To unsubscribe from this list:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luong Ngo
Sent: Friday, March 09, 2007 8:54 AM
To: Robert Hancock
Cc: linux-kernel; [EMAIL PROTECTED]
Subject: Re: Sleeping thread not receive signal until it wakes up
On 3/8/07, Robert Hancock <[EMAIL
Linus Torvalds wrote:
On Mon, 5 Mar 2007, Ed Tomlinson wrote:
The patch _does_ make a difference. For instance reading mail with freenet working
hard (threaded java application) and gentoo's emerge triggering compiles to update the
box is much smoother.
Think this scheduler needs serious
On 3/8/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
Hi Brian,
Thanks for the quick update.
> +
> + rc = (iface->result >= 0) ? 0 : -1;
> +
> + /* Release mutex */
> + mutex_unlock(>twi_lock);
> +
> + return rc;
> +}
i2c-core can emulate SMBus transactions using master_xfer,
Con Kolivas wrote:
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
With luck I'll get to shake out that patch in combination with kvm later
today.
Great thanks!. I've appreciated all the feedback so far.
I did try, the 2.6.21-rc3-git3 doesn't want to kvm for me, and your
patch may
Anton Blanchard wrote:
Hi,
I might be missing something but doesn't this break every
SWAP partition that was created with something other than
MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
> Anton Blanchard wrote:
> > The other option is to create a v3 swap format that doesnt use any
> > PAGE_SIZE parameters.
>
> The best thing to do would be to look for the magic both at PAGE_SIZE
> (for
In attempting to fix some issues with my system, I was pulling patches from
the kernel git tree, and I discovered that this patch (
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fe69933652562f093ccde600cecf234930c01932
)
is malformed on i386, specifically the
David Miller wrote:
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
Anton Blanchard wrote:
The other option is to create a v3 swap format that doesnt use any
PAGE_SIZE parameters.
The best thing to do would be to look for the magic both at PAGE_SIZE
(for
Hello Andrew,
I found a little "hickup" in the mm kernel series since 2.6.21-rc2-mm1/mm2.
1.) appeared while boot (no VFS mounted at time)
BUG: at arch/i386/mm/highmem.c:61 kmap_atomic()
[] [] [] [] []
[] [] [] [] []
[] [] [] [] []
[] [] [] []
===
BUG: at
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:31:05 -0800
> The advantage would be that it wouldn't require a v3 for platforms for
> which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
> percentage of systems.
>
> You still have to look for the darn magic
albcamus wrote:
your kthread IS preemptible unless you call preempt_disable or some
locking functions explicitly .
I think he's trying to go the other way, make his thread the highest
priority to blow anything else in the system out of the water. See his
previous post "how to make kernel
This is a request for comments for a new Integrity Based Access
Control(IBAC) LSM module which bases access control decisions
on the new integrity framework services.
(Hopefully this will help clarify the interaction between an LSM
module and LIM module.)
Index:
On Thu, 08 Mar 2007 17:58:16 -0500 Mimi Zohar wrote:
> This is a request for comments for a new Integrity Based Access
> Control(IBAC) LSM module which bases access control decisions
> on the new integrity framework services.
>
> (Hopefully this will help clarify the interaction between an LSM
On Thu 8 Mar 2007 15:40, Russell King pondered:
> On Thu, Mar 08, 2007 at 03:23:39PM -0500, Robin Getz wrote:
> > Right - We both agree - And setting console=/dev/null in the bootargs
> > still does not help.
>
> Ok, good.
>
> > When the kernel initializes the UART Port, it asserts RTS - which
> >
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get various post-rc3 fixes:
David Miller
On 19:46, Jens Axboe wrote:
> On Wed, Feb 28 2007, Andre Noll wrote:
> > On 16:18, Andre Noll wrote:
> >
> > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However,
> > > writing to both raid systems at the same time via lvm still locks up
> > > the system within minutes.
> >
> >
On Thu, Mar 08 2007, Andre Noll wrote:
> On 19:46, Jens Axboe wrote:
> > On Wed, Feb 28 2007, Andre Noll wrote:
> > > On 16:18, Andre Noll wrote:
> > >
> > > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However,
> > > > writing to both raid systems at the same time via lvm still
While a scsi device hw error occured, device's status maybe setting
to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking
if device have offline, if yes, do nothing and just return error to
user directly.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--
---
On 10:02, Jens Axboe wrote:
> Do you still have the vmlinux? It'd be interesting to see what
>
> $ gbd vmlinux
> (gdb) l *cfq_dispatch_insert+0x28
>
> says,
The vmlinux in the kernel dir is dated March 5 and my bug report
was Feb 28. So I'm afraid it's gone. I tried the gdb command anyway
but
On Thu, Mar 08 2007, Andre Noll wrote:
> On 10:02, Jens Axboe wrote:
> > Do you still have the vmlinux? It'd be interesting to see what
> >
> > $ gbd vmlinux
> > (gdb) l *cfq_dispatch_insert+0x28
> >
> > says,
>
> The vmlinux in the kernel dir is dated March 5 and my bug report
> was Feb 28.
On 10:36, Jens Axboe wrote:
> - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom)
> - make oldconfig
> - rm block/cfq-iosched.o
> - make block/cfq-iosched.o
> - gdb block/cfq-iosched.o
>
> (gdb) l *cfq_dispatch_insert+0x28
>
> and see what that says. Should not take you more than a
On Thu, Mar 08 2007, Andre Noll wrote:
> On 10:36, Jens Axboe wrote:
> > - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom)
> > - make oldconfig
> > - rm block/cfq-iosched.o
> > - make block/cfq-iosched.o
> > - gdb block/cfq-iosched.o
> >
> > (gdb) l *cfq_dispatch_insert+0x28
> >
> >
On Thu, 2007-03-08 at 17:22 +0800, Joe Jin wrote:
> While a scsi device hw error occured, device's status maybe setting
> to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking
> if device have offline, if yes, do nothing and just return error to
> user directly.
What's the error
Bino, James,
Please review, sign-off and forward upstream.
--linas
If a PCI error is detected that cannot be recovered from, there
will be a double call of lpfc_pci_remove_one(), with the second call
resulting in a null-pointer dereference. The first call occurs in
lpfc_io_error_detected(),
> What's the error you're trying to fix? scsi_dispatch_cmd() is only
> called from scsi_request_fn() which already has an equivalent of this
> check in it just prior to calling dispatch.
Yeah, I have saw the cheking at scsi_request_fn(), recently we got a crash
info as following at rhel4
[cc'ing Greg, Hi]
Kok, Auke wrote:
>
> Attached dmesg. config.gz. here's the OOPS part.
>
> ata_piix :00:1f.2: version 2.10
> ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
> ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> ata: 0x1F0 IDE port busy
> ata: conflict with
Tejun Heo wrote:
[cc'ing Greg, Hi]
Kok, Auke wrote:
Attached dmesg. config.gz. here's the OOPS part.
ata_piix :00:1f.2: version 2.10
ata_piix :00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
ata: 0x1F0 IDE port busy
ata: conflict with
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery is using WIN_IDLEIMMEDIATE which was only valid
for
IDE V1 and IDE V2. Modern drives will not be able to recover using
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
>
> On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
>
> >
> > Hi,
> >
> > (sorry for the long delay)
> >
> > On Wednesday 21 February 2007, Suleiman Souhlal wrote:
> >> IDE error recovery is using WIN_IDLEIMMEDIATE which was
On Mar 8, 2007, at 12:34 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Thursday 08 March 2007, Suleiman Souhlal wrote:
On Mar 7, 2007, at 1:16 PM, Bartlomiej Zolnierkiewicz wrote:
Hi,
(sorry for the long delay)
On Wednesday 21 February 2007, Suleiman Souhlal wrote:
IDE error recovery is
Commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a added support for using the
ADMA notifier bits to determine which commands to check for completion.
However there have been reports that this causes command timeouts in certain
cases. This is still being investigated. In addition, apparently the
On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said:
> This is a request for comments for a new Integrity Based Access
> Control(IBAC) LSM module which bases access control decisions
> on the new integrity framework services.
>
> (Hopefully this will help clarify the interaction between an LSM
>
Fix atomicity of TIF update in flush_thread() for x86_64
Race :
parent process executing :
sys_ptrace()
(lock_kernel())
(ptrace_get_task_struct(pid))
arch_ptrace()
ptrace_detach()
ptrace_disable(child);
clear_singlestep(child);
clear_tsk_thread_flag(child,
Fix sparc TIF_USEDFPU flag atomicity
Non atomic update of TIF can be very dangerous, except at thread structure
creation time. Here I standardize the TIF_USEDFPU usage of the sparc arch.
Applies on 2.6.20.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/arch/sparc/kernel/process.c
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> s/do/will (smpboot.c)
Well the current Xen mechanism rather dodges all of that (for bits like
IPI apicid).
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Our code is in the tree now, and any attempts to break it using such
> justifications as easing maintenance for kernel developers in future
> releases are flat out false and improper.
That's not quite accurate. This is what Ingo was complaining
Chris Wright wrote:
* Daniel Arai ([EMAIL PROTECTED]) wrote:
There's no good way to override __send_IPI_shortcut. I suppose we could add
paravirt ops for __send_IPI_shortcut and every other op that touches the APIC.
While that's basically what we did in Xen, it would make more sense to
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > Chris, would you like to work together on this? I don't know what
> > Xen's requirements are for the APIC interface. Do you think we
> > could come up with something that would fit both of our needs, and
> > maybe also be usable for some of the
* Daniel Arai ([EMAIL PROTECTED]) wrote:
> Chris, would you like to work together on this? I don't know what Xen's
> requirements are for the APIC interface. Do you think we could come up
> with something that would fit both of our needs, and maybe also be usable
> for some of the
Chris Wright wrote:
> * Daniel Arai ([EMAIL PROTECTED]) wrote:
>
>> There's no good way to override __send_IPI_shortcut. I suppose we could add
>> paravirt ops for __send_IPI_shortcut and every other op that touches the
>> APIC.
>>
>
> While that's basically what we did in Xen, it
Chris Wright wrote:
> I agree with that, but I think that's esp. for things like create and launch
> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> as well.
>
Well, native would fall back to using the existing arch/i386 versions of
those functions, so that's
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > While that's basically what we did in Xen, it would make more sense
> > to build it into genapic which would give us one common abstraction
> > to base from. We should avoid adding pv_ops when existing
> > infrastructure exists.
>
> I was
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > * Daniel Arai ([EMAIL PROTECTED]) wrote:
> >
> >> There's no good way to override __send_IPI_shortcut. I suppose we could
> >> add
> >> paravirt ops for __send_IPI_shortcut and every other op that touches the
> >>
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > I agree with that, but I think that's esp. for things like create and launch
> > new vcpu. The IPI bit I'm not as clear on, nor running this all on native
> > as well.
> >
>
> Well, native would fall back to using the
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Chris Wright wrote:
>>
>>> I agree with that, but I think that's esp. for things like create and launch
>>> new vcpu. The IPI bit I'm not as clear on, nor running this all on native
>>> as well.
>>>
>>>
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
>> that's a concern, but maybe we can tease it apart in a sensible way.
>>
>
> Yes, that's exactly what I'm saying. Same with above (the
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes,
> that's a concern, but maybe we can tease it apart in a sensible way.
Yes, that's exactly what I'm saying. Same with above (the native stuff), since
we don't want a bunch
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>
>> Maybe hooking into genapic is the right way to mop up all the uses of
>> send_IPI and its variants. But from a quick grep it doesn't look like
>> they get called from too many places... Most of the callers seem to be
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants. But from a quick grep it doesn't look like
> they get called from too many places... Most of the callers seem to be
> in arch/i386/kernek/smp.c,
Zachary Amsden wrote:
> We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> > We faithfully emulate lapic, io_apic, the pit, pic, and a normal
> > interrupt subsystem.
>
> Can you not just use the apic clock driver directly then? Do you need
> to do anything special?
exactly. There are only
On Thursday 08 March 2007 21:46, Zachary Amsden wrote:
> Thomas Gleixner wrote:
> > On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
> >
> The correct solution here is to properly separate the APIC, SMP, and
> timer code so the logic of it which we want to reuse is separated
> what we do _NOT_ want is some mixture of 'simplified' and 'hardwired'
> native hardware access mixed with hypercalls that somehow ends up
> creating a Frankenstein mixture of 'virtual silicon', is specified
> nowhere else but in VMWare's proprietary hypervisor source code that we
> have no
>
> Maybe hooking into genapic is the right way to mop up all the uses of
> send_IPI and its variants.
It is. More hooks in this are wouldn't be appreciated.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
The apic clock driver is going to program the
Andi Kleen wrote:
At least in Linux we don't really work with deadlines; if there
are issues they need to be fixed even if it takes longer. I don't
expect the version in .21 to be really usable anyways; it is clearly
still in development.
It was working, and I expect to have it working
Ingo Molnar wrote:
> - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
>quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
lower-level ones, so that guests can meaningfully participate in their
own
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as its
being used in a way that's consistent with its intended
On Thu, 2007-03-08 at 15:39 -0800, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > - /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
> >quite advanced on this front.
>
> At last! Some love!
>
> The Xen approach has always been to prefer high-level interfaces over
Zachary Amsden wrote:
> For APICs, we have two operations - APICRead and APICWrite. It is
> nice and clean, and plugs in very easily to the APIC accessors
> available in Linux.
>
> Is this not clean?
Sure, that's clean, From that perspective the apic is a bunch of
registers backed by a state
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
> > No, but I'm not prejudiced against virtual hardware. If we have a piece
> > of code that thinks its talking to an apic, then I think its OK to use
> > that code whether its a real apic or a virtual one, _so
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
>
> We just don't drive the local timer interrupts through the APIC, we make
> hypercalls to schedule local timer alarms. Which is something we must
> do for UP kernels as well, which use the PIT / PIC. So there is a need
> for having
[ I don't really want to be involved too much in this particular
discussion, but I'll pipe up quickly anyway.. ]
On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > For APICs, we have two operations - APICRead and APICWrite. It is
> > nice and clean, and plugs in very
Thomas Gleixner wrote:
> Once you are there, you are near the point where you created a virtual
> architecture, which could run on any real architecture which gets
> supported by a hypervisor backend.
>
> I'd love that :)
>
Sure. But not even hypervisors. Once we sort out pv_ops's SMP
On Mon, Feb 12, 2007 at 12:15:24AM -0800, [EMAIL PROTECTED] wrote:
> +static struct container_group *find_container_group(
> + struct container_group *oldcg, struct container *cont)
> +{
> + struct container_group *res;
> + struct container_subsys *ss;
> + int h = cont->hierarchy;
On Thu, Mar 08, 2007 at 01:10:24AM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> > Please next time this kind of patch is posted add a description of
> > what is happening and why. I have yet to see people explain why
> > this is a good idea. Why the
On Thu, Mar 08, 2007 at 03:43:47PM +0530, Srivatsa Vaddagiri wrote:
> On Wed, Mar 07, 2007 at 08:12:00PM -0700, Eric W. Biederman wrote:
> > The review is still largely happening at the why level but no
> > one is addressing that yet. So please can we have a why.
>
> Here's a brief summary of
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
> "Paul Menage" <[EMAIL PROTECTED]> writes:
>
>> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>> But "namespace" has well-established historical semantics too - a way
>>> of changing the mappings of local * to global objects.
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Pretty much. For most of the other cases I think we are safe
>> referring to them as resource controls or resource limits. I know
>> that roughly covers what cpusets and
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
> Matt Helsley <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
> >
> > +ADw-snip+AD4
> >
> > +AD4 Kirill, 06032418:36+-03:
> > +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> > +AD4
On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> > 7. resource namespaces
>
> It should be. Imagine giving 20% bandwidth to a user X. X wants to
> divide this bandwidth further between multi-media (10%), kernel
>
Herbert wrote:
> why is the filesystem approach so favored for this
> kind of manipulations?
I don't have any clear sense of whether the additional uses of file
systems being considered here are a good idea or not, but the use of a
file system for cpusets has turned out quite well, in my (vain
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local * to global objects. This
> accurately describes things liek resource controllers, cpusets, resource
> monitoring, etc.
No!
Cpusets don't rename or change the mapping of objects.
I
> The real trick is that I believe these groupings are designed to be something
> you can setup on login and then not be able to switch out of. Which means
> we can't use sessions and process groups as the grouping entities as those
> have different semantics.
Not always on login. For big
Matt wrote:
> It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
Daniel Drake wrote:
> Andrew Johnson wrote:
> > When the console is in VT_AUTO/KD_GRAPHICS mode, switching to the
> > SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting
indefinately
> > or until the task is interrupted. The following patch tests if a
> > console switch can occur in
On Thu, Mar 08, 2007 at 06:29:02PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > it tests whether the SA_RESTART flag works for the sem_wait operation.
> >
> > I see
On Thursday 08 March 2007 13:54, Andrew Morton wrote:
> On Wed, 7 Mar 2007 17:43:45 -0800 Andrew Morton <[EMAIL PROTECTED]>
wrote:
> > On Wed, 7 Mar 2007 12:26:42 +1100
> >
> > Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > What follows is the same patch series that constitutes the RDSL
> > >
On Fri, Mar 09, 2007 at 12:02:31AM +0100, Thomas Gleixner wrote:
> On Thu, 2007-03-08 at 18:29 +0100, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Ingo,
> > >
> > > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > > it tests whether the
On Wed, Feb 21, 2007 at 02:36:40PM +0100, Stefan Richter wrote:
> Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.19.5 release.
> >
> > This will probably be the last release of the 2.6.19-stable series, so
> > if there are patches that you feel should be applied to
First off, let me say that I think your approach has great promise,
but I'm afraid it doesn't work so well here yet.
Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
test load.
With 2.6.21-rc2-mm2, I get slightly sluggish response for opening new
terminals, scrolling in
Michael K. Edwards a écrit :
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool
might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call.
__builtin_types_compatible_p() has been around since gcc 2.95, and we
don't use it anywhere. This patch quietly fixes that.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r f0ff8138f993 include/linux/kernel.h
--- a/include/linux/kernel.hFri Mar 09 16:40:25 2007 +1100
+++
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
-
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
Mockern a écrit :
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
Welcome Andy
Since your messages always make me wonder if you are some kind of robot, able
to post one "one line" message to lkml everyday, I have one suggestion :
Try next times
On Fri, 09 Mar 2007 16:56:32 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
After staring at this for about 2 minutes, how about a commit message like:
Make
On Friday 09 March 2007 16:39, Matt Mackall wrote:
> First off, let me say that I think your approach has great promise,
> but I'm afraid it doesn't work so well here yet.
>
> Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
> test load.
>
> With 2.6.21-rc2-mm2, I get slightly
On Thu, 8 Mar 2007, Bill Davidsen wrote:
>
> Please, could you now rethink plugable scheduler as well? Even if one had to
> be chosen at boot time and couldn't be change thereafter, it would still allow
> a few new thoughts to be included.
No. Really.
I absolutely *detest* pluggable
On Fri, 9 Mar 2007, Rusty Russell wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
Whee.
Rusty, that's a work of art.
However, I would suggest that you never show it to anybody ever again. I'm
sure that
On Wednesday 07 March 2007 3:48 pm, Chris Lesiak wrote:
> From: Chris Lesiak <[EMAIL PROTECTED]>
>
> This patch fixes a bug in the cleanup of an spi_bitbang bus.
It's nearly right, but see below.
> @@ -505,28 +499,10 @@ EXPORT_SYMBOL_GPL(spi_bitbang_start);
> */
> int
Hi!
> Pavel, I tried with your .config, and indeed the system came back to life
> after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test
On 068, 03 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95,
but it's not available in Intel C compiler IIRC :(
> and we don't use it anywhere. This patch quietly fixes that.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> That sounds like a rather fragile approach to avoiding a minimal amount of
> work. Debug exceptions don't occur very often, and when they do it won't
> matter too much if we go through some extra notifier-chain callouts.
When single-stepping occurs it happens repeatedly many times, and that
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> On Thu, 8 Mar 2007, Bill Davidsen wrote:
> > Please, could you now rethink plugable scheduler as well? Even if one had to
> > be chosen at boot time and couldn't be change thereafter, it would still
> > allow
> > a few new thoughts
901 - 1000 of 1073 matches
Mail list logo
