On 05/28/2007 06:04 PM, [EMAIL PROTECTED] wrote:
> Kernel very often freezes when I watch TV on my card TV Leadtek Winfast
> PVR 2000 XP.
> When I watch TV in KdeTV, I got message like "problem with v4l2" and
> then no picture, only sound. (Some tv applications dont run at all).
> After that I can
On Thursday, 31 May 2007 17:29, Michal Piotrowski wrote:
> Hi,
>
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
>
> FYI suspend to disk doesn't work anymore on my box, system hangs after
> "Suspending console(s)" mess
> +#ifndef CONFIG_STABLE
> /*
>* We should return 0 if size == 0 (which would result in the
>* kmalloc caller to get NULL) but we use the smallest object
> @@ -81,6 +82,7 @@ static inline int kmalloc_index(size_t s
>* we can discover locations where we do 0 sized alloc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davide Libenzi wrote:
> What I meant, was that the vast majority of MT+exec
> apps wants all their fds (but an handfull, maybe)
You never listen when you are told something. Such a statement cannot
be made. The application doesn't know what the run
Below is a patch I would like to submit for limiting process private
memory allocations via setrlimit(RLIMIT_DATA).
Thanks,
Herbert van den Bergh.
This patch changes how the kernel limits memory allocations that are
controlled by setrlimit() using the RLIMIT_DATA resource. Currently the
kernel
On Thu, May 31 2007, [EMAIL PROTECTED] wrote:
> On Thu, 31 May 2007, Jens Axboe wrote:
>
> >On Thu, May 31 2007, Phillip Susi wrote:
> >>David Chinner wrote:
> >>>That sounds like a good idea - we can leave the existing
> >>>WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >>>
The RXBRK field in the AT91/AT32 USART status register has the
following definition according to e.g. the AT32AP7000 data sheet:
RXBRK: Break Received/End of Break
0: No Break received or End of Break detected since the last RSTSTA.
1: Break Received or End of Break detected since the
>+sub top_of_kernel_tree {
>+ if ((-f "COPYING") && (-f "CREDITS") && (-f "Kbuild") &&
>+ (-f "MAINTAINERS") && (-f "Makefile") && (-f "README") &&
>+ (-d "Documentation") && (-d "arch") && (-d "include") &&
>+ (-d "drivers") && (-d "fs") && (-d "init") && (-d "ipc"
On Do, 24.05.07 11:46 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
wrote:
>
> Hi,
>
> [...]
>
> Improved patch - this time the issue should be fixed for good (I was
> looking only at the RAID specific part of the fixups and I overlooked
> the fact that the original code was clearing too much o
On 05/31, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> > On 05/31, Mark Hounschell wrote:
> >>
> >> Basically the main RT-process (which is a CPU bound process on
> >> processor-2) signals a
> >> thread to do some I/O. That RT-thread (running on the other processor)
> >> does a simple
> >
On Thu, 31 May 2007, Jens Axboe wrote:
On Thu, May 31 2007, Phillip Susi wrote:
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour that only guarantees ordering. The filesystem can then
cho
On Thu, 31 May 2007, Jakub Jelinek wrote:
> On Thu, May 31, 2007 at 11:46:31AM -0700, Davide Libenzi wrote:
> > On Thu, 31 May 2007, Ulrich Drepper wrote:
> > > Davide Libenzi wrote:
> > > > Isn't this better be a global process flag? Default should be, for
> > > > legacy
> > > > reasons,
> > >
On Thu, May 31 2007, Hugh Dickins wrote:
> On Thu, 31 May 2007, Jens Axboe wrote:
> >
> > This patch removes the ->sendfile() hook from the file_operations
> > structure, and replaces the sys_sendfile() mechanism to be based on
> > ->splice_read() instead. There should be no functional changes.
>
On Thu, May 31 2007, Tom Zanussi wrote:
> On Thu, 2007-05-31 at 12:33 +0200, Jens Axboe wrote:
> > Hi,
> >
> > This patch removes the ->sendfile() hook from the file_operations
> > structure, and replaces the sys_sendfile() mechanism to be based on
> > ->splice_read() instead. There should be no f
On Thu, May 31, 2007 at 11:46:31AM -0700, Davide Libenzi wrote:
> On Thu, 31 May 2007, Ulrich Drepper wrote:
> > Davide Libenzi wrote:
> > > Isn't this better be a global process flag? Default should be, for legacy
> > > reasons,
> >
> > No. Policies are always wrong since it means code that cann
On Thu, May 31 2007, Phillip Susi wrote:
> David Chinner wrote:
> >That sounds like a good idea - we can leave the existing
> >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >behaviour that only guarantees ordering. The filesystem can then
> >choose which to use where appropr
> People will want perfom and oprofile in the same kernel, and we'd better
Yes.
> allow useage at the same time, so I'd be very much in favour of having
That would be nice, but is not imho critical.
> just one backend. Especially giving the huge amount of different
> performance counters we ha
On Thu, May 31 2007, Phillip Susi wrote:
> Jens Axboe wrote:
> >No Stephan is right, the barrier is both an ordering and integrity
> >constraint. If a driver completes a barrier request before that request
> >and previously submitted requests are on STABLE storage, then it
> >violates that principl
On 5/31/07, Thomas Renninger <[EMAIL PROTECTED]> wrote:
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
http://marc.info/?l=linux-kernel&m=113699535303722&w=2)
No, you're keepin
On Thu, 31 May 2007, Andrew Morton wrote:
> we're not disbling local irqs on the cpu hotplug path.
>
> Could do local_irq_disable() in slab_cpuup_callback(), I guess.
Ahh I see.
SLUB: Fix locking for hotplug callbacks.
Hotplug callbacks seem to be performed with interrupts enabled. Slub requi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/31/2007 Davide Libenzi wrote:
> I was talking for a broader usage, not only glibc centric. Most ppl
> writing MT+exec apps wants all but (eventually) and handfull of files
> leaking across the exec boundary.
Policies are not the answer. Using
On Thu, May 31, 2007 at 08:43:14PM +0200, Andi Kleen wrote:
> > I think the perform backend for oprofile is the right way to go.
> > I'd even go further and say we should merge the perfom backend with
> > oprofile as the only user first, because a) the current perfom user
> > interface is a complet
On Thu, 31 May 2007 11:41:22 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > Perhaps a suitable fix would be local_irq_disable() in flush_slab().
>
> As far as I can tell: Interrupts are always disabled when flush_slab is
> run.
>
> Sometimes we use spin_lock_irqsave for the list_
On 5/31/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> not really.
I'm sorry, I don't understand the point you're making.
Andrew's proposal was that we could add early_uart_ioremap to the list of
bt_ioremap and dmi_ioremap.
for i386, bt_ioremap is using fixmap, and it is temporary boot-time
On Thu, 31 May 2007, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Davide Libenzi wrote:
> > Isn't this better be a global process flag? Default should be, for legacy
> > reasons,
>
> No. Policies are always wrong since it means code that cannot change
> the policy
On Thu, 31 May 2007, Robert Hancock wrote:
Justin Piszcz wrote:
On Thu, 31 May 2007, Parag Warudkar wrote:
Robert Hancock wrote:
I think that mem=8832M would work as well, to make the kernel use only
the memory that is marked cacheable. (It looks like this parameter takes
the highest memo
[PATCH] x86_64: change early_ioremap to static
only dmi_scan_machine==>dmi_present==>dmi_table==>dmi_ioremap uses
early_ioremap outside of mm/init.c
dmi_scan_machine is called after init_memory_mappings, and could use
ioremap instead.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/ar
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Andrew Morton wrote:
>>> On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
>>> wrote:
>>>
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a singl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Davide Libenzi wrote:
> Isn't this better be a global process flag? Default should be, for legacy
> reasons,
No. Policies are always wrong since it means code that cannot change
the policy (e.g, all runtime libraries) have no access to the
functional
> I think the perform backend for oprofile is the right way to go.
> I'd even go further and say we should merge the perfom backend with
> oprofile as the only user first, because a) the current perfom user
> interface is a complete mess
Can you suggest concrete criticism/improvements/alternative
On Thu, 31 May 2007, Andrew Morton wrote:
> > l *0xc0181288
> > 0xc0181288 is in add_partial (/home/devel/linux-mm/mm/slub.c:1193).
> > 1188}
> > 1189
> > 1190static void add_partial(struct kmem_cache_node *n, struct page
> > *page)
> > 1191{
> > 1192spin_lock(&n->list_loc
Jens Axboe wrote:
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violates that principle. Look at the code and the various ordering
options.
On Thu, 31 May 2007 11:23:32 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I have a note here that it needs additional work. This discussion:
> >
> > http://lkml.org/lkml/2007/5/21/602
> >
> > seemed to peter out and go nowhere?
>
> The fi
On Thu, 31 May 2007, Ulrich Drepper wrote:
> I've brought this topic up before but didn't provide a patch. Well, here
> we go again, this time with a patch. I even throw in a test program.
>
> The problem is as follows: in multi-threaded code (or more correctly: all
> code using clone() with CL
On Thu, 31 May 2007 19:53:07 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisa__(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
>
> CPU hotplug test triggered this
>
> [ 4972.038008] CPU 1 is now offline
> [ 4972.0414
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicholas Miell wrote:
> O_CLOSEONEXEC, perhaps?
Then nobody would know this is equivalent to FD_CLOEXEC. I think the
name I propose is fine.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Ve
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour that only guarantees ordering. The filesystem can then
choose which to use where appropriate
So what if you want a synchronous write, b
On Thu, May 31, 2007 at 07:28:28PM +0200, Andi Kleen wrote:
> I would prefer if oprofile would still work. It doesn't need to work
> in parallel but it should be possible to use it when perfmon
> is not active, but compiled in. That shouldn't be that difficult,
> should it?
I think the perform bac
cachemiss_thread should explicitly return 0 or error instead of
task_ret_reg(current) (which is -ENOSYS anyway) because
async_thread_helper is careful to put the return value in eax anyway.
On x86_64, it looks like async_child_rip is similarly careful.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
On Thu, 2007-05-31 at 14:09 -0400, Ulrich Drepper wrote:
> diff --git a/include/asm-generic/fcntl.h b/include/asm-generic/fcntl.h
> index c154b9d..b847741 100644
> --- a/include/asm-generic/fcntl.h
> +++ b/include/asm-generic/fcntl.h
> @@ -48,6 +48,9 @@
> #ifndef O_NOATIME
> #define O_NOATIME
David Chinner wrote:
you are understanding barriers to be the same as syncronous writes. (and
therefor the data is on persistant media before the call returns)
No, I'm describing the high level behaviour that is expected by
a filesystem. The reasons for this are below
You say no, but then
i am using the GARMIN_GPS/usb driver to read a gps receiver.
In testing the ability of my software to recover from various errors, I
try this: unplug the gps/USB cable from the usb hub.
Interestingly enough the thread spins.
the SELECT() waits for something to happen, and I get one channel that
On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
I have a note here that it needs additional work. This discussion:
http://lkml.org/lkml/2007/5/21/602
seemed to peter out and go nowhere?
The first rev went in -mm needs work and the above url is the result
of feedback from Al Viro. He al
On 5/31/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
[...]
The author (Markus Oberhumer) of LZO provided these comments for this patch:
---
I've only briefly looked over it, but it's obvious that your version does not
work on architechtures which do not allow unaligned access (arm, mips, ...).
A
wait-sleep uses the async_exec mechanism to collect timer expirations
and child process wait status. It randomly fires off a number of
sleeps and forks, waiting for them to finish, and firing off something
new to replace anything that finishes.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
Mak
aio-read uses the async_exec mechanism to queue reads of pages of a
file. As completions come in, new reads are queued until all pages in
the file have requests queued or finished. When that has happened, it
just waits for the remaining completions to come in.
Signed-off-by: Jeff Dike <[EMAIL PR
Add a bunch of includes to sys.h and syslet.h to kill off compilation warnings.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
sys.h|7 +++
syslet.h |2 ++
2 files changed, 9 insertions(+)
Index: async-test-v5/sys.h
===
I've brought this topic up before but didn't provide a patch. Well, here
we go again, this time with a patch. I even throw in a test program.
The problem is as follows: in multi-threaded code (or more correctly: all
code using clone() with CLONE_FILES) we have a race when exec'ing.
thread #1
On Thu, 31 May 2007 09:51:36 -0700
"Ken Chen" <[EMAIL PROTECTED]> wrote:
> On 5/31/07, walt <[EMAIL PROTECTED]> wrote:
> > Ken Chen wrote:
> > > On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > ...
> > > tested, like this?
> >
> > Ken, your patch below works for me. Are you going to send this
Michal Piotrowski napisał(a):
> Andrew Morton napisał(a):
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>>
>
> CPU hotplug test triggered this
>
> [ 4972.038008] CPU 1 is now offline
> [ 4972.041411] lockdep: not fixing up alternatives.
> [ 4972.05155
On Thu, 2007-05-31 at 16:25 +0200, Jörn Engel wrote:
> --- linux-2.6.21logfs/fs/jfs/jfs_txnmgr.c~I_LOCK2007-05-07
> 10:28:55.0 +0200
> +++ linux-2.6.21logfs/fs/jfs/jfs_txnmgr.c 2007-05-29
> 13:10:32.0 +0200
> @@ -1286,7 +1286,14 @@ int txCommit(tid_t tid, /*
>
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Andrew Morton wrote:
>>> On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
>>> wrote:
>>>
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a singl
On Thu, 31 May 2007 14:35:43 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> > Would I be correct in guessing that pages which are on the
> > per-rss-container lists are also eligible for reclaim off the traditional
> > page LRUs? If so, how does that work? When a page gets freed off the
>
>
On Wed, 2007-05-30 at 13:09 -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley ([EMAIL PROTECTED]):
> > This patch avoids holding the mmap semaphore while walking VMAs in response
> > to
> > programs which read or follow the /proc//exe symlink. This also
> > allows us
> > to merge mmu and nommu
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
CPU hotplug test triggered this
[ 4972.038008] CPU 1 is now offline
[ 4972.041411] lockdep: not fixing up alternatives.
[ 4972.051553]
[ 4972.051555] ==
On Thu, May 31, 2007 at 07:37:52PM +0200, Christian Volkmann wrote:
> The SIS550 chip uses the mP6 core according to
> http://en.wikipedia.org/wiki/MP6
> May be this code can improve the capability of these SIS550 system on a chip
> ?
>
> But this should be a different story.
>From what I
On 05/28/2007 05:38 AM, Andrew Ruthven wrote:
> Just a follow-up to Marcel regarding Pavel's bluetooth oops. I've had
> the same issue with both 2.6.21 and 2.6.21.2 (skipped .1). I'm able to
> reproduce the oops.
>
> My scenario is connecting from a Treo650 via bluetooth to access the
> Internet
Cyrill Gorcunov wrote:
Eric, could you please try the following:
1) declare the spinlock in the top of inode.c as
DEFINE_SPINLOCK(udf_drop_lock);
2) replace in udf_drop_inode()
kernel_lock -> spin_lock(&udf_drop_lock);
kernel_unlock -> spin_unlock(&udf_drop_lock);
I'
[Eric Sandeen - Wed, May 30, 2007 at 05:22:23PM -0500]
| Eric Sandeen wrote:
|
| > Jan, something seems busted here. I'm getting lockups when testing udf
| > on a single cpu with this last patch in place...
| >
| > I think it's the BKL stumbling on itself.
|
| To demonstrate, try this:
|
| # B
The SIS550 chip uses the mP6 core according to http://en.wikipedia.org/wiki/MP6
May be this code can improve the capability of these SIS550 system on a chip ?
But this should be a different story.
Dave Jones wrote:
> On Thu, May 31, 2007 at 07:22:38AM +0200, Adrian Bunk wrote:
> > On Thu, May 17
On Thu, May 31, 2007 at 06:06:19PM +0100, Hugh Dickins wrote:
> Christoph already picked up on that, and it's of interest to shmem too:
> loop over tmpfs in 2.6 was relying on shmem_file_sendfile, for which
> the generic route is not good enough.
>
> If we're giving a .splice_read to everything wh
On Thu, May 31, 2007 at 10:16:17AM -0700, Stephane Eranian wrote:
> Andi,
>
> On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> > Stephane Eranian <[EMAIL PROTECTED]> writes:
> >
> > The interface looks very complicated. Is there anything
> > in there that you feel is not strictly ne
On 31/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Daniel J Blueman wrote:
> Hi Mark,
>
> Thanks for the reply; here is the raw identification data:
>
> # hdparm --Istdout /dev/sdb
>
> /dev/sdb:
[snip]
Ooops.. wrong drive. That's NOT a CF card. Try again?
Whoops, yes. Here is the expected d
On 5/30/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
But, the -rt kernel has pretty much the same code for the
futex_unlock_pi64, and it has the same bug.
Why would you use futex_unlock_pi64?
In fact, the whole 64-bit futex patch should be reviewed and cut down
to the bare minimum. I know, I
Andi,
On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote:
> Stephane Eranian <[EMAIL PROTECTED]> writes:
>
> The interface looks very complicated. Is there anything
> in there that you feel is not strictly needed and should be eliminated
> before merging? After merging it will be more di
Hello All,
I am seeing the following kernel assertion (BUG) trip whenever I run a
set of RPM commands. It is 100% reproducible, and occurs on a machine
running vmware.
The kernel is a FC5 2.6.20-1-2316 kernel recompiled to disable
CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP.
Is this a
On 05/31, Mark Hounschell wrote:
>
> Andrew Morton wrote:
> > On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
> >> have. I have tracked
> >> it down to a single line of code. When
On Thu, 31 May 2007, Jens Axboe wrote:
>
> This patch removes the ->sendfile() hook from the file_operations
> structure, and replaces the sys_sendfile() mechanism to be based on
> ->splice_read() instead. There should be no functional changes.
>
> Work to be done:
>
> - The ext2 xip support nee
Ingo Molnar wrote:
> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>
>> Ingo,
>>
>> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to
>> 2.6.21 but seems to contain stuff that is already in 2.6.21.3.
>
> yes - it includes all of 2.6.21.3.
>
> Ingo
>
So actually it is not re
[Eric Sandeen - Wed, May 30, 2007 at 05:22:23PM -0500]
| Eric Sandeen wrote:
|
| > Jan, something seems busted here. I'm getting lockups when testing udf
| > on a single cpu with this last patch in place...
| >
| > I think it's the BKL stumbling on itself.
|
| To demonstrate, try this:
|
| # B
On 5/31/07, walt <[EMAIL PROTECTED]> wrote:
Ken Chen wrote:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
...
> tested, like this?
Ken, your patch below works for me. Are you going to send this
on to Linus?
I think akpm will route this to Linus. andrew?
-
To unsubscribe from this list: s
The name of this patch is really "split ACPI function tracing
out of CONFIG_ACPI_DEBUG to a new Kconfig build option"
I agree that tracing should be its own build option.
I don't agree that enabling CONFIG_ACPI_DEBUG by default
is what you want to do in a production kernel, but that
isn't what th
>
>
> +static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff *skb,
> + struct iphdr **iph, struct tcphdr **tcph)
> +{
> + int ip_len;
> +
> + /* non tcp/udp packets */
> + if (!cqe->header_length)
> + return -1;
> +
> + /* non t
On Thu, 2007-05-31 at 16:55 +0200, Ingo Molnar wrote:
> * john stultz <[EMAIL PROTECTED]> wrote:
>
> > > > --- a/kernel/futex.c
> > > > +++ b/kernel/futex.c
> > > > @@ -2011,6 +2011,7 @@ pi_faulted:
> > > > attempt);
> > > > if (ret)
> > > >
Andi,
On Thu, May 31, 2007 at 04:38:52PM +0200, Andi Kleen wrote:
> Stephane Eranian <[EMAIL PROTECTED]> writes:
>
> > + /* test IA32_PMC0, IA32_PMC1 */
> > + for (i=4; i < 6; i++) {
> > + if (avail_to_resrv_perfctr_nmi(pfm_core_pmd_desc[i].hw_addr))
> > + continue
On Thursday 31 May 2007 10:32:42 am Yinghai Lu wrote:
> On 5/31/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Wednesday 30 May 2007 10:48:59 pm Andrew Morton wrote:
> > > You could require that the architecture implement some specific function
> > > for mapping the early-uart.
> >
> > We coul
Hi,
On Thu, May 31, 2007 at 04:46:56PM +0100, Richard Hughes wrote:
+ if (!hotkeys_over_input) {
+ if (!key_event_valid) {
+ hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+
On Wed, May 30, 2007 at 10:03:01AM -0700, Linus Torvalds wrote:
> > and that's where all the problems started - sleepers needing to take that
> > mutex
> > recursively (which we did/do not support).
> >
> > foo() takes cpu_bitmask_lock and calls
> > foo_bar() which also needs cpu_bitma
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/buffer.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index c6b58e8..ad9270b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1029,11 +1029,6 @@ failed:
/*
* Create buffers for t
The generic function __set_page_dirty_buffers called by default by
set_page_dirty appears to be a correct superset of ramdisk_set_page_dirty.
So remove the specialized ramdisk version.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
drivers/block/rd.c | 27 ---
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> > +#ifdef CONFIG_COND_CALL_ENABLE_OPTIMIZATION
> > +#include /* optimized cond_call flavor */
> > +#else
> > +#include /* fallback on generic cond_call */
> > +#endif
>
> The preferred way to do this is to give every architecture an
> asm/co
Hello,
the build with the attached .config failed, make ends with:
...
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `vic_sys_interrupt':
: undefined reference
On 5/31/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
On Wednesday 30 May 2007 10:48:59 pm Andrew Morton wrote:
> You could require that the architecture implement some specific function
> for mapping the early-uart.
We could, but we already have bt_ioremap, dmi_ioremap, and early_ioremap.
Do we
Michal Piotrowski wrote:
You need to upgrade the kernel "yum upgrade kernel.i686"
If the problem still appears, fill bug report in RedHat bugzilla
https://bugzilla.redhat.com/bugzilla/index.cgi
I am seeing this problem in the FC5 2.6.20-1-2316 kernel, and I have not
seen a new kernel show up in
On Thu, May 31, 2007 at 06:16:52PM +0200, Tilman Schmidt wrote:
> Am 30.05.2007 21:38 schrieb Jan Engelhardt:
> > --- linux-2.6.22-rc3-git1.orig/drivers/isdn/Kconfig
> > +++ linux-2.6.22-rc3-git1/drivers/isdn/Kconfig
> > @@ -21,9 +21,7 @@ menuconfig ISDN
> >
> > if ISDN
> >
> > -menu "Old ISDN
Am 30.05.2007 21:38 schrieb Jan Engelhardt:
> --- linux-2.6.22-rc3-git1.orig/drivers/isdn/Kconfig
> +++ linux-2.6.22-rc3-git1/drivers/isdn/Kconfig
> @@ -21,9 +21,7 @@ menuconfig ISDN
>
> if ISDN
>
> -menu "Old ISDN4Linux"
> -
> -config ISDN_I4L
> +menuconfig ISDN_I4L
> tristate "Old ISDN
Hi,
On Thu, 2007-05-31 at 17:53 +0200, Jan Kratochvil wrote:
> On Thu, 31 May 2007, Pavel Machek wrote:
> >> Led subsystem allows us to set brightness, but there is
> >> nothing like brightness on this device. So brightness is
> >> actually interpreted as the command (only values between
> >> 0 an
Ken Chen wrote:
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
...
tested, like this?
Ken, your patch below works for me. Are you going to send this
on to Linus?
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 5526ead..0ed5470 100644
--- a/drivers/block/loop.c
+++ b/drivers
On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
> Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
> toshiba supplied daemon that polls, so I think we have to just bite the
> bullet.
... adding in reply in different thread...
On Thu, 2007-05-31 at 10:37 -0400, Dmit
Christoph,
On Thu, May 31, 2007 at 04:21:34PM +0100, Christoph Hellwig wrote:
> On Tue, May 29, 2007 at 06:48:17AM -0700, Stephane Eranian wrote:
> > sys_pfm_create_context():
> > - create a new perfmon2 context and returns a file descriptor in
> > the pfarg_ctx_t parameters. This is the
On Fri, May 25, 2007 at 09:58:12PM +0100, Rui Nuno Capela wrote:
>
> I wish I could give you more details, but the fact is I don't know
> where
> to look. The machine just freezes silently, again and again, with all
> kernels from -rt2 to -rt8 inclusive, with no traceable evidence, at
> least to m
Andrew, please patch ASAP as compile on SGI ia64 is broken. Please note this
patch does not address why modpost did not pick up this error.
ie) ./scripts/mod/modpost drivers/block/built-in.o yields no information about
the section mismatch. AFAIK, it should spit out a loud WARNING.
Patch agains
On Thu, 31 May 2007 05:56:33 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> >> I suspect that is a pretty rare case but it does indeed seem to exist
> >> as a problem.
> >
> > I think so too. But either we have some misunderstanding of the
> > codepaths involved, or the author of the comment
Hi,
On Thu, 31 May 2007, Pavel Machek wrote:
Led subsystem allows us to set brightness, but there is
nothing like brightness on this device. So brightness is
actually interpreted as the command (only values between
0 and 14 are accepted).
Ugh, no, I do not think we want to do that.
finally!
On Thu, 31 May 2007 13:20:48 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
(top-posting reversed)
> Pierre Ossman wrote:
> > Andrew Morton wrote:
> >> Whatever. I think you can work it out ;)
> >>
> >>
> >
> > Bare with me, I just woke up ;)
> >
> >> while (driver_probe_done() || (ROO
Robert Hancock <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I just realized that except for doing the code review and noticing
>> that the current cpu hotplug code is fundamentally incompatible
>> with x86 I haven't done anything about it. So here is my patch
>> to document what is w
Frank Sorenson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The patch to "remove combined mode quirk" (git bisect says
8cdfb29c0cd8018f92214c11c631d8926f4cb032) makes my laptop run slower
than a dead sloth. "hdparm -T" indicates that buffered disk reads on my
hard drive drop from 48-50
On Thu, May 31, 2007 at 08:05:19AM -0400, Jeff Garzik wrote:
> Paul Mundt wrote:
> >Please pull from:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
> >
> >Which contains:
>
> Out of curiosity, who maintains sh64?
>
I do.
> It has a couple irq handlers that have not be
On Thu, 2007-05-31 at 12:33 +0200, Jens Axboe wrote:
> Hi,
>
> This patch removes the ->sendfile() hook from the file_operations
> structure, and replaces the sys_sendfile() mechanism to be based on
> ->splice_read() instead. There should be no functional changes.
>
> Work to be done:
>
> - The
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to
> 2.6.21 but seems to contain stuff that is already in 2.6.21.3.
yes - it includes all of 2.6.21.3.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
201 - 300 of 462 matches
Mail list logo