Hello,
I understand there are currently no active maintainers of parport and
friends - unless that has changed recently.
We are heavy users of parport devices, and so I am offering to begin
maintaining the parport drivers. I have spent some time studying the
drivers closely, and I've read
On Monday 16 July 2007 9:17:28 pm H. Peter Anvin wrote:
> Tim Bird wrote:
> > Oooh! That's nice! I didn't notice the "nicely split up" part earlier.
> > Any chance we can get the original docbook inputs that OLS uses
> > for paper submissions? Have you asked Andrew or Craig about this?
>
> OLS
On Tue, 17 Jul 2007, Jeff Dike wrote:
> On Tue, Jul 17, 2007 at 03:22:16PM +0200, Geert Uytterhoeven wrote:
> > I saw this patch went in.
> >
> > iomap_copy.o ues the raw I/O memory accessors, so it truly depends on
> > CONFIG_HAS_IOMEM.
>
> This works for UML.
Of course. UML (and s390) doesn't
On Tue, Jul 17, 2007 at 05:40:15PM +0200, Takashi Iwai wrote:
> At Tue, 17 Jul 2007 17:32:36 +0200,
> Sam Ravnborg wrote:
> >
> > On Tue, Jul 17, 2007 at 05:16:13PM +0200, Takashi Iwai wrote:
> > > At Tue, 17 Jul 2007 17:14:32 +0200,
> > > Sam Ravnborg wrote:
> > > >
> > > > On Tue, Jul 17, 2007
John Blackwood wrote:
> I was doing some tests that attempt to read the VDSO area of a
> task through either the /proc/pid/mem or ptrace(PTRACE_PEEKTEXT,
> ...) interfaces, and it seems that when the CONFIG_COMPAT_VDSO kernel
> parameter is enabled, we can no longer successfully read the VDSO area
Linus,
I fixed the issue with the previous patchset. Please provide further feedback,
or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
This contains kvm updates for the 2.6.23 merge window, including
- performance improvements
- suspend/resume fixes
-
On 07/17/2007 06:14 PM, Shawn Bohrer wrote:
I can't speak for Fedora, but RHEL disables XFS in their kernel likely
because it is known to cause problems with 4K stacks.
Okay. So is it fair to say it's largely XFS that's the problem? No problems
with LVM/MD and say plain ext? If that's the
On Tue, 17 Jul 2007 12:09:16 -0400 Mike Sharkey wrote:
> Hello,
>
> I understand there are currently no active maintainers of parport and
> friends - unless that has changed recently.
>
> We are heavy users of parport devices, and so I am offering to begin
> maintaining the parport drivers. I
* Olaf Kirch <[EMAIL PROTECTED]> wrote:
> Can you try what happens if you change netif_rx_complete to something
> like this:
>
> if (test_bit(__LINK_STATE_POLL_LIST_FROZEN, >state)) {
> dev->quota = dev->weight;
> return;
> }
>
> This is just a hack to
At some point in the past, I wrote:
>> If at some point one of the pro-4k stacks crowd can prove that all
>> code paths are safe, or introduce another viable alternative (such as
>> Matt's idea for extending the stack dynamically), then removing the 8k
>> stacks option makes sense.
On Mon, Jul
On Tue, 2007-07-17 at 17:07 +0400, Oleg Nesterov wrote:
> I think we can make a simpler patch,
>
> --- posix-timers.c~ 2007-06-29 14:45:04.0 +0400
> +++ posix-timers.c2007-07-17 16:59:45.0 +0400
> @@ -449,6 +449,9 @@ static void release_posix_timer(struct k
>
At Tue, 17 Jul 2007 18:48:46 +0200,
Sam Ravnborg wrote:
>
> On Tue, Jul 17, 2007 at 05:40:15PM +0200, Takashi Iwai wrote:
> > At Tue, 17 Jul 2007 17:32:36 +0200,
> > Sam Ravnborg wrote:
> > >
> > > On Tue, Jul 17, 2007 at 05:16:13PM +0200, Takashi Iwai wrote:
> > > > At Tue, 17 Jul 2007 17:14:32
* Markus <[EMAIL PROTECTED]> wrote:
> > > Nothing is printed for a disapeared app for me.
> > >
> > > Is there anything more I can try?
> >
> > sure - could you start one of those apps via:
> >
> > strace -ttt -TTT -o trace.log -f
> >
> > and wait for it to "disappear"? Then compress
* "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's
> better to backport -ck1 for 2.6.22 to 2.6.20?
fyi, http://article.gmane.org/gmane.linux.kernel.ck/7850
--
left blank, right bald
pgpZWtSASam7s.pgp
Description: PGP
On Tue, Jul 17, 2007 at 09:58:15AM -0700, Randy Dunlap wrote:
> On Tue, 17 Jul 2007 12:09:16 -0400 Mike Sharkey wrote:
>
> > Hello,
> >
> > I understand there are currently no active maintainers of parport and
> > friends - unless that has changed recently.
> >
> > We are heavy users of
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i think it fails here due to some IO error:
>
> 9173 1184675906.674610 write(2, "konqueror: Fatal IO error:
> clien"..., 41) = 41 <0.07>
oh, and i missed the obvious request: could you start konqueror from a
terminal and see what it prints
On 07/17, Linus Torvalds wrote:
>
> On Tue, 17 Jul 2007, Oleg Nesterov wrote:
> >
> > I am really puzzled by set_fs(USER_DS) in setup_frame/setup_rt_frame.
> >
> > How is it possible that current->addr_limit != USER_DS ? If this _is_
> > possible, how can can we trust the result of access_ok()
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 17:29, [EMAIL PROTECTED] wrote:
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
On Tuesday, 17 July 2007 16:15, Alan Stern wrote:
On Mon, 16 Jul 2007 [EMAIL PROTECTED] wrote:
I agree, it would be good to have a
* Ian Kent <[EMAIL PROTECTED]> wrote:
> > ah! It passes in a low-res time source into a high-res time interface
> > (pthread_cond_timedwait()). Could you change the time(NULL) + 1 to
> > time(NULL) + 2, or change it to:
> >
> > gettimeofday(, NULL);
> > wait.tv_sec++;
>
> OK, I'm
On Tue, 17 Jul 2007 17:49:34 +0200 Ingo Molnar wrote:
>
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> > > Subject: softlockup: fix Xen bogosity
> > > From: Ingo Molnar <[EMAIL PROTECTED]>
> > >
> > > this Xen related commit:
> > >
> >
> > Well, not just Xen.
> So it is natural to deliver CPU_UP_CANCELED event only to the functions
> that have returned NOTIFY_OK with CPU_UP_PREPARE event and not to call
> the function that have returned NOTIFY_BAD. This is what this patch is doing.
Yes, this makes sense.
Thank you for making sure of it.
[...]
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check that the refcount is zero
> and free the container structure.
Not just theory ... I've debugged crashes from
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > + if ((print_timestamp >= touch_timestamp &&
> > + print_timestamp < (touch_timestamp + 1)) ||
> > + did_panic || !per_cpu(watchdog_task, this_cpu)) {
> > return;
> > + }
> >
> > /* do not
On Tue, 17 Jul 2007, Andrew Morton wrote:
> On Tue, 17 Jul 2007 16:04:54 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 12 Jul 2007, Andrew Morton wrote:
> > >
> > > It'd be much better to fix the race within alloc_fresh_huge_page(). That
> > > function is pretty pathetic.
>
[PATCH] serial: add back early_serial_setup back to head file
early_serial_setup is removed from serial.h, but foget to put in
serial_8250.h
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
index c1c32e4..a74c087 100644
---
On Tue, 17 Jul 2007, Dave Airlie wrote:
>
> Could you re-pull?
>
> There are two patches, one fixes a missed typedef for Sis and one adds the
> idr_init that fell out of the drawable changeset.. which should fix any
> hangs..
Yup, hang fixed. Thanks,
Linus
-
To unsubscribe
On Tue, 2007-07-17 at 15:03 +0200, Johannes Berg wrote:
> Hi,
>
> Good stuff :)
>
> > + int idlecount; /* number of empty packets */
>
> should probably use tabs here.
fixed.
> > + size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> > +
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
> >Encryption is possible with both the userland hibernation (aka uswsusp) and
> >TuxOnIce (formerly known as suspend2). Still, I don't consider it as a
> >"must
> >have" feature for a framework to be
Paul (??) Menage wrote:
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds container_mutex) could check that the refcount is zero
> and free the container structure.
>
Hi, Paul,
That
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
That sounds correct. I wonder now if the solution should be some form
of delegation for deletion of unreferenced containers (HINT: work queue
or kernel threads).
What a great idea. In fact, that's exactly what the release agent
patch already
On Tue, 2007-07-17 at 18:52 +0200, Rene Herman wrote:
> On 07/17/2007 06:14 PM, Shawn Bohrer wrote:
>
> > I can't speak for Fedora, but RHEL disables XFS in their kernel likely
> > because it is known to cause problems with 4K stacks.
>
> Okay. So is it fair to say it's largely XFS that's the
On Sat, Jul 07, 2007 at 01:52:28AM +0200, Andrea Arcangeli wrote:
> BTW, in a parallel thread (the thread where I've been suggested to
> post this), Rik rightfully mentioned Bill once also tried to get this
> working and basically asked for the differences. I don't know exactly
> what Bill did, I
Oleg Nesterov [EMAIL PROTECTED] wrote:
| On 07/16, [EMAIL PROTECTED] wrote:
| >
| > Oleg Nesterov [EMAIL PROTECTED] wrote:
| > |
| > | Could you please give more details why we need this change?
| >
| > Well, with multiple pid namespaces, we may need to allocate a new
| > 'struct pid_namespace'
Jun'ichi Nomura wrote:
>>>From: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>>>
>>>bio_alloc_bioset() will return NULL if 'num_vecs' is too large.
>>>Use bio_get_nr_vecs() to get estimation of maximum number.
>>>
>>>Signed-off-by: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>>>Signed-off-by: Alasdair G Kergon
On Tue, 17 Jul 2007, Ingo Molnar wrote:
>
> i've got a new observation: changing CONFIG_HZ from 250 to 1000 makes
> the problem go away. So it's somehow also related to jiffies.
No, I suspect it's just related to timing: you need to hit that window
when the LIST_FROZEN bit is set, and since
On Tuesday 17 July 2007 18:47:56 Jeremy Fitzhardinge wrote:
> John Blackwood wrote:
> > I was doing some tests that attempt to read the VDSO area of a
> > task through either the /proc/pid/mem or ptrace(PTRACE_PEEKTEXT,
> > ...) interfaces, and it seems that when the CONFIG_COMPAT_VDSO kernel
> >
Andi Kleen wrote:
> On Tuesday 17 July 2007 18:47:56 Jeremy Fitzhardinge wrote:
>
>> John Blackwood wrote:
>>
>>> I was doing some tests that attempt to read the VDSO area of a
>>> task through either the /proc/pid/mem or ptrace(PTRACE_PEEKTEXT,
>>> ...) interfaces, and it seems that when
> Here's some anecdotal evidence :)
> http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB
> That sounds correct. I wonder now if the solution should be some form
> of delegation for deletion of unreferenced containers (HINT: work queue
> or kernel threads).
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel
> Well, the only issue I recall is about the # of EQs we want to allocate.
> Was there something else?
Yes, some ideas about how applications should pick which EQ to use.
And how to handle CPU affinity. And whether we want to try to do
something NUMA-aware.
- R.
-
To unsubscribe from this
On Wednesday 04 July 2007 08:33:24 Jan Beulich wrote:
Sorry for late feedback.
> +#ifdef CONFIG_DEBUG_RODATA
> +
> +#ifdef CONFIG_X86_32
> +#include
> +#define MODULES_VADDR VMALLOC_START
> +#endif
> +
> +static inline void make_writable(const void *instr, unsigned int len)
> +{
> +
Paul M wrote:
> In fact, that's exactly what the release agent
> patch already does.
I'm feeling lazy ;) What's the Subject of that
patch, for my easy searching?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel does not remove
cpusets; it runs a user program, /sbin/cpuset_release_agent. That
program might choose to rmdir the
On Tue, 17 Jul 2007, Dr. David Alan Gilbert wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
Encryption is possible with both the userland hibernation (aka uswsusp) and
TuxOnIce (formerly known as suspend2). Still, I don't consider it as a
>
> Ah, yes. For some reason I can't find it in my archives. Do you have
> it queued up?
Yes
-Andi
-
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
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Paul M wrote:
> In fact, that's exactly what the release agent
> patch already does.
I'm feeling lazy ;) What's the Subject of that
patch, for my easy searching?
"Support for automatic userspace release agents"
Paul
-
To unsubscribe from
Jan Beulich wrote:
> + if (va < MODULES_VADDR) {
> + change_page_attr(virt_to_page(instr),
> + PFN_UP(va + len) - PFN_DOWN(va),
> +#ifdef CONFIG_X86_64
> + PAGE_KERNEL_RO);
> +#else
> +
Paul M wrote:
> Right, that's what the release agent patch for process containers does
> - there's a file in the hierarchy root called "release_agent" that
> contains the path to the program to run if a notify_on_release
> container goes idle. When you mount the "cpuset" filesystem, it
>
On Tue, 17 Jul 2007, Geert Uytterhoeven wrote:
>
> M68k uses I/O memory for all I/O (hence it sets CONFIG_HAS_IOMEM), but
> many m68k machines don't have PCI or ISA (hence it doesn't set
> CONFIG_PCI resp. CONFIG_ISA).
It doesn't matter whether the machine has PCI or ISA. The only thing that
> We are working on IPoIB to use multiple EQ for multiple
> links/connetions scalability. Does this mean this will wait for 2.6.24?
I think so -- I don't want to merge something that first appears in
the last few days of the merge window. The idea is to get your stuff
queued up
Hi Ingo,
On Tuesday 17 July 2007 18:57, Ingo Molnar wrote:
> i've done the patch below, but it did not change the timeouts nor did it
> solve the 'no network' problem. netconsole output hung earlier as well.
Hm, pity.
To rule out any e1000 problem, can you try the the following please,
both
> - Take a look at Sean's local SA caching patches. I merged
>everything else from Sean's tree, but I'm still undecided about
>these. I haven't read them carefully yet, but even aside from that
>I don't have a good feeling about whether there's consensus about
>this yet.
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Tue, 17 Jul 2007 00:37:18 +0200
>
> > I think if you leaned back and thought it through, and if you
> > applied this scenario to a bad scheduler commit from me that broke
> > your box, you'd readily
Fixes the following build error:
CC sound/pci/mixart/mixart_hwdep.o
sound/pci/mixart/mixart_hwdep.c: In function ‘mixart_hwdep_dsp_load’:
sound/pci/mixart/mixart_hwdep.c:610: error: implicit declaration of function
‘vmalloc’
sound/pci/mixart/mixart_hwdep.c:617: error: implicit declaration
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>> That sounds correct. I wonder now if the solution should be some form
>> of delegation for deletion of unreferenced containers (HINT: work queue
>> or kernel threads).
>
> What a great idea. In fact, that's
From: Márton Németh <[EMAIL PROTECTED]>
Export the i8042_command() function which manages the mutual exclusion
with the help of the i8042_lock spinlock. This lets possible to use the
i8042 hardware safely from other part of the kernel, too.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
From: Márton Németh <[EMAIL PROTECTED]>
Extends the leds subsystem with a blink_set() callback function which can
optionally implemented by a LED driver. If implemented, the driver can use the
hardware acceleration for blinking a LED.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
diff
From: Márton Németh <[EMAIL PROTECTED]>
The driver supports the mail LED commonly found on different Clevo notebooks.
The driver access the LED through the i8042 hardware and implements the support
for
hardware accelerated blink function.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
On Tue, 17 Jul 2007, Randy Dunlap wrote:
>
> > + if ((print_timestamp >= touch_timestamp &&
> > + print_timestamp < (touch_timestamp + 1)) ||
> > + did_panic || !per_cpu(watchdog_task, this_cpu)) {
> > return;
> > + }
> >
> > /* do not
On 17/07/07 17:40 +0200, Takashi Iwai wrote:
> At Tue, 17 Jul 2007 17:32:36 +0200,
> Sam Ravnborg wrote:
> >
> > On Tue, Jul 17, 2007 at 05:16:13PM +0200, Takashi Iwai wrote:
> > > At Tue, 17 Jul 2007 17:14:32 +0200,
> > > Sam Ravnborg wrote:
> > > >
> > > > On Tue, Jul 17, 2007 at 04:52:12PM
On Tue, 2007-07-17 at 11:01 -0400, Dmitry Torokhov wrote:
> Hi,
>
> On 7/17/07, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
> >
> > err_free_buffer:
> > @@ -656,6 +699,7 @@ static void atp_disconnect(struct usb_interface *iface)
> >
> >usb_set_intfdata(iface, NULL);
> >if (dev)
* Olaf Kirch <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> On Tuesday 17 July 2007 18:57, Ingo Molnar wrote:
> > i've done the patch below, but it did not change the timeouts nor did it
> > solve the 'no network' problem. netconsole output hung earlier as well.
> Hm, pity.
>
> To rule out any
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
without too much knowledge of each other. BTW, what are the semantics
of css_put() is it expected to free the container/run the release agent
when the reference count of the container_subsys_state drops to zero?
If you css_put() the last
Krzysztof Halasa wrote:
William Montgomery <[EMAIL PROTECTED]> writes:
I am using a PCI analyzer and it shows the bus in an idle state after
the lockup. The PCI transactions just prior to the lockup show a
couple of interrupts from the card which appear to be handled
correctly. Anything
On Tue, 17 Jul 2007, Ingo Molnar wrote:
nice one! The race looks pretty narrow - Jeremy, does your Xens have
hyperthreading? (or are there any heavy SMI sources perhaps that could
open up this race.) If not then there might be some other bug lurking in
there as well.
Affirmative. 2 cores, 2
On Tue, 17 Jul 2007, Rafael J. Wysocki wrote:
> I'm afraid of one thing, though.
>
> If we create a framework without ACPI (well, ACPI needs to be enabled in the
> kernel anyway for other reasons, like the ability to suspend to RAM) and then
> it turns out that we have to add some ACPI hooks to
From: Horst H. von Brand <[EMAIL PROTECTED]>
Signed-off-by: Horst H. von Brand <[EMAIL PROTECTED]>
---
fs/9p/v9fs.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 45c3598..72ad365 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -131,7
On Tuesday 17 July 2007 20:18, Ingo Molnar wrote:
> (one is HZ=100, the other HZ=1000. HZ=100 produces a hung network just
> like HZ=250.)
>
> no 'rx_sched set' messages in either case. Network still hung for
> HZ=100, and is working for HZ=1000.
Is this from dmesg or the netconsole output? I
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. The patch has been tested for several weeks
on my local system and has been in the linuxconsole repository
for some time. Please apply.
Signed-Off: James Simmons <[EMAIL PROTECTED]>
diff --git
Hi;
17 Tem 2007 Sal tarihinde, Avi Kivity şunları yazmıştı:
> I fixed the issue with the previous patchset. Please provide further
> feedback, or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
>
> This contains kvm updates for the 2.6.23 merge window,
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
Jeremy Katz experienced a posix-timer related bug on 2.6.14. This is
caused by a subtle race, which is there since the original posix timer
commit and persists until today.
timer_delete does:
lock_timer();
timer->it_process = NULL;
unlock_timer();
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
> - schedule_delayed_work(>buf.work, 0);
It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ;
could that matter?
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote:
> > > Since Linus is happily snoring by now, could you test and see if the
> > > tree works for you?
> >
> > It works for me. I'll submit some minor patches against your bsg
> > branch to scsi-ml. Can you push them together?
>
> Certainly,
William Montgomery wrote:
Krzysztof Halasa wrote:
William Montgomery <[EMAIL PROTECTED]> writes:
I am using a PCI analyzer and it shows the bus in an idle state after
the lockup. The PCI transactions just prior to the lockup show a
couple of interrupts from the card which appear to be
* Olaf Kirch <[EMAIL PROTECTED]> wrote:
> On Tuesday 17 July 2007 20:18, Ingo Molnar wrote:
> > (one is HZ=100, the other HZ=1000. HZ=100 produces a hung network just
> > like HZ=250.)
> >
> > no 'rx_sched set' messages in either case. Network still hung for
> > HZ=100, and is working for
On Tue, 17 Jul 2007 18:26:14 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jul 2007, Andrew Morton wrote:
> > On Tue, 17 Jul 2007 16:04:54 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]>
> > wrote:
> > > On Thu, 12 Jul 2007, Andrew Morton wrote:
> > > >
> > > > It'd be much
The following patch deletes an assignment to the variable p9_debug_level,
which is never defined and isn't used anywhere else I can see.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi Dmitry,
Am Montag, 16. Juli 2007 16:49 schrieb Dmitry Torokhov:
> Hi Christoph,
>
> On 7/13/07, Christoph Pfister <[EMAIL PROTECTED]> wrote:
> > Am Freitag, 13. Juli 2007 22:49 schrieb Christoph Pfister:
> > > Hi,
> > >
> > > After a kernel update I recognised that my keyboard sometimes didn't
On Tue, Jul 17, 2007 at 02:26:06PM -0400, Horst H. von Brand wrote:
> From: Horst H. von Brand <[EMAIL PROTECTED]>
>
> Signed-off-by: Horst H. von Brand <[EMAIL PROTECTED]>
> ---
> fs/9p/v9fs.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/fs/9p/v9fs.c
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> try_to_wake_up:
>
> if (p->se.on_rq)
> goto out_running;
>
> ...
>
> if (unlikely(task_running(rq, p)))
> goto out_activate;
>
> How it possible that rq->curr has on_rq == 0 ?
>
> AFAICS, this
S.Çağlar Onur wrote:
>
> If i'm not wrong X86_CMPXCHG64 depends on CONFIG_X86_PAE which depends on
> HIGHMEM64 and again if i'm not wrong this means distributions who wants to
> provide KVM must enable CONFIG_X86_PAE and CONFIG_HIGHMEM64G from now on?
>
X86_PAE should depend on X86_CMPXCHG64,
On Tue, 2007-07-17 at 15:29 +0530, Kalpak Shah wrote:
> On Mon, 2007-07-16 at 17:49 -0700, Mingming Cao wrote:
> > On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> > > On Sun, 01 Jul 2007 03:36:56 -0400
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > > > +static inline __le32
On Tue, Jul 17, 2007 at 05:25:17AM -0400, Jeff Garzik wrote:
> This patch
>
> * removes struct members that duplicate pci_dev members
> * replaces ha->stype usage with ha->pdev->device usage where feasible
These two bits look nice.
> * removes PCI IDs that are already in include/linux/pci_ids.h
On Tue, 17 Jul 2007, H. Peter Anvin wrote:
>
> S.Çağlar Onur wrote:
> >
> > If i'm not wrong X86_CMPXCHG64 depends on CONFIG_X86_PAE which depends on
> > HIGHMEM64 and again if i'm not wrong this means distributions who wants to
> > provide KVM must enable CONFIG_X86_PAE and CONFIG_HIGHMEM64G
> James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
> > - schedule_delayed_work(>buf.work, 0);
>
> It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ;
> could that matter?
I did not detect any regressions.
On Tue, 17 Jul 2007, Davi Arnaut wrote:
> Michael Kerrisk wrote:
> >
> > Hi Davide,
> >
> > While writing a test program to incorporate into the timerfd.2 man page, I
> > think I've found a bug. It looks like only the least significant byte of
> > ticks is being returned from read(2), even
On Tue, Jul 17, 2007 at 01:36:35AM -0700, Andrew Morton wrote:
> On Fri, 13 Jul 2007 16:01:48 +1000 "Lindsay Roberts" <[EMAIL PROTECTED]>
> wrote:
>
> > * Increases romfs partition size limit from 2GB to 4GB.
That seems worthwhile.
> > * Adds new derivative of romfs filesystem (rom2fs) with
>
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes the following unused exports:
> - EXPORT_SYMBOL(cond_resched_softirq);
> - EXPORT_SYMBOL_GPL(__wake_up_sync);
these are there for API completeness - their counterparts are exported.
Ingo
-
To unsubscribe from this list: send
[ Alan added to participants list, since he's in charge of tty code ]
On Tue, 17 Jul 2007, James Simmons wrote:
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index de37ebc..34894e5 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -559,7 +559,7 @@ void
On Tue, 17 Jul 2007 08:38:11 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote:
> > In terms of presentation: this code hit the tree as base patch plus what
> > appear to be 20 bugfixes, none of which are really interesting or relevant
> > to mainline. Personally I think it would be nicer if all that
Linus Torvalds wrote:
>
> Actually, I think the *real* solution would be:
>
> - add a X86_HAS_CMPXCHG8B config option, and set it for the appropriate
>CPU selection (P6 and up, or whatever the rule is)
>
> - make KVM depend on it
>
> - make KVM and HIGHMEM64 _select_ another config
On Tue, Jul 17, 2007 at 12:59:03PM +0200, Jan Engelhardt wrote:
>
> On Jul 15 2007 14:00, Jonathan Campbell wrote:
> >
> > These patches were written against the vanilla 2.6.21.1 kernel. They will
> > have
> > no effect UNLESS you make menuconfig and explicitly enable them there.
> >
> >
>
On Thu, Jul 12, 2007 at 11:58:06PM -0700, Christoph Lameter wrote:
> cpu_core_map is currently an array defined using NR_CPUS. This means that
> we overallocate since we will rarely really use the maximum
> number of configured cpus. This may become a problem when we need to
> increase the
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> I do get flash 9 (I know, not the best example) and tomboy to hang as
> reported by one of my Planet CCRMA users - flash 9 tested working on
> stock fedora 7 kernel - and both seem to hang in the same system call:
>
>
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
> You may rest assured that it's technically feasible. It's been done.
> The larger obstacles to all this are nontechnical.
Back then there was no variable order page size proposal, no slub,
generally nothing of that kind.
I
>From 32f86740d27ef77160e438cd7dc4fcd5df159dd0 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 15:28:17 -0400
Subject: [PATCH 1/1] user namespace: fix copy_user_ns return value
When a CONFIG_USER_NS=n and a user tries to unshare some
namespace other than
From: Oleg Nesterov <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 21:15:35 +0400
> Also, sparc does something strange with do_sigaltstack(). It first copies
> stack_t to the local variable, then sets KERNEL_DS to access it from
> do_sigaltstack().
>
> IOW, what's wrong with the patch below? Why
Davi fixed a missing cast in the __put_user(), that was making timerfd
return a single byte instead of the full value.
Talking with Michael about the timerfd man page, we think it'd be better
to use a u64 for the returned value, to align it with the eventfd
implementation.
Signed-off-by:
On Jul 17 2007 01:51, Shawn Rutledge wrote:
>
> I'm messing around with framebuffer graphics stuff and trying to write
> a keyboard driver similar to the one in X, which will allow you to
> start up the graphics system from any tty (not just a virtual
> console),
right, I can start X these days
Kok, Auke wrote:
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to
PCI Bridge (rev 82) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr-
1001 - 1100 of 1345 matches
Mail list logo
