On Wed, 25 Jul 2007, Nick Piggin wrote:
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
> It certainly doesn't run for me ever. Always kind of a "that's not the
> point" comment but I just keep wondering whenever I see anyone complain
> about updatedb why the
On Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Rene Herman wrote:
> It certainly doesn't run for me ever. Always kind of a "that's not the
> point" comment but I just keep wondering whenever I see anyone complain
> about
Dave Airlie wrote:
Is this with a binary-only module? We saw an issue with that in SLES9
where the module is returning a locked page from its nopage handler
when it isn't really supposed to. It might be fixed in latest drivers,
have you tried them?
Doesn't sound like it he mentions radeon
On Thu, 5 Jul 2007 18:52:27 -0700 (PDT) Joshua Wise <[EMAIL PROTECTED]> wrote:
> Background:
> This patch is a follow-on to "Info dump on Oops or panic()" [1].
>
> On some architectures, the kernel printed some information on the running
> kernel, but not on all architectures. The
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
It certainly doesn't run for me ever. Always kind of a "that's not the
point" comment but I just keep wondering whenever I see anyone complain
about updatedb why the _hell_ they are running it in the first place. If
On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Rene Herman wrote:
It certainly doesn't run for me ever. Always kind of a "that's not the
point" comment but I just keep wondering whenever I see anyone
complain about updatedb why the _hell_ they are running it in the
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
> It certainly doesn't run for me ever. Always kind of a "that's not the
> point" comment but I just keep wondering whenever I see anyone complain
> about updatedb why the _hell_ they are running it in the first place. If
> anyone who never
On 7/25/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 12:29:17PM +0800, rae l wrote:
> But is it valuable? Compared to a waste of sizeof(struct super_block)
> bytes memory.
It's less that struct super_block, actually.
> When some code want to refer fs_type->s_op, it almost
Eric St-Laurent wrote:
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as "I got these all wrong, so you can reclaim them" (which
this
On Tue, Jul 24, 2007 at 02:17:02PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch warnings:
> these functions are called only from __init functions.
>
> WARNING: vmlinux.o(.text+0x1861c): Section mismatch: reference to
> .init.text:free_bootmem
On Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
> Anyway, my point is that I worry that tuning for an unusual and
> infrequent workload (which updatedb certainly is), is the wrong way to
> go.
Well it runs every day or so for every
Keith Owens wrote:
> Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote:
>> Adding __builtin_trap after the
>> asm might be an ok fix. It will emit a spurious int 6, but that won't even
>> be
>> reached since the asm doesn't return, and it probably be less extra code than
>> the loop.
On Tue, Jul 24, 2007 at 09:56:59PM +0200, Stefan Richter wrote:
> Manuel Lauss wrote:
> > Actually, copying data to the disk while playing/seeking through a moviefile
> > which is also located on it is already enough. Forget the NFS thing...
> >
> > Afterwards the firewire_sbp2 module has to be
On Tue, 2007-07-24 at 11:25 -0700, Linus Torvalds wrote:
>
> On Tue, 24 Jul 2007, Andrew Morton wrote:
> >
> > I guess this was the bug:
>
> Looks very likely to me. Mike, Alexey, does this fix things for you?
I don't have very much runtime on it yet, but yes, it seems to have.
-Mike
SuperH allmodconfig broke:
fs/binfmt_flat.c:83: warning: initialization from incompatible pointer type
fs/binfmt_flat.c:94: error: conflicting types for 'flat_core_dump'
fs/binfmt_flat.c:78: error: previous declaration of 'flat_core_dump' was here
fs/binfmt_flat.c:94: error: conflicting types
On Tue, 13 Mar 2007 10:42:02 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> There are problems in the use of SPARSEMEM and pageblock flags that causes
> problems on ia64.
>
> The first part of the problem is that units are incorrect in
> SECTION_BLOCKFLAGS_BITS computation. This results in a
Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way
to go.
Well it runs every day or so for every desktop Linux user, and it has
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way to
go.
Well it runs every day or so for every desktop Linux user, and it has
similarities with
Linus Torvalds wrote:
On Tue, 24 Jul 2007, Benjamin Herrenschmidt wrote:
Besides, as Nick pointed out, it prevents some valid optimizations.
No it doesn't. Not the ones on the functions that just do an inline asm.
The only valid optimization it might break is for "constant_test_bit()",
In badness(), the automatic variable 'points' is unsigned long. Print it
as such.
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
---
mm/oom_kill.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
On Tue, 24 Jul 2007, Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
Looking at your past email, you have a 1GB desktop system and your
overnight updatedb run is causing stuff to get swapped out such that
swap prefetch makes it significantly better. This
Is this with a binary-only module? We saw an issue with that in SLES9
where the module is returning a locked page from its nopage handler
when it isn't really supposed to. It might be fixed in latest drivers,
have you tried them?
Doesn't sound like it he mentions radeon drm module which is
On Wed, Jul 25, 2007 at 12:29:17PM +0800, rae l wrote:
> But is it valuable? Compared to a waste of sizeof(struct super_block)
> bytes memory.
It's less that struct super_block, actually.
> When some code want to refer fs_type->s_op, it almost always want to
> refer some function pointer in s_op
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
> I don't like this kind of conditional information going from something
> like readahead into page reclaim. Unless it is for readahead _specific_
> data such as "I got these all wrong, so you can reclaim them" (which
> this isn't).
>
> But I
On 7/25/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 11:48:35AM +0800, rae l wrote:
> Why alloc_super use a static variable default_op?
> the static struct super_operations default_op is just all zeros, and
> just referenced as the initial value of a new allocated super_block,
On 7/24/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
On Tuesday 24 July 2007 02:33:05 pm Yinghai Lu wrote:
> I have a system that has the same problem, and it turns out that FW
> missed PNP0501 is DSDT for uart. and add that it into DSDT works well.
Is this FW that has been shipped? Can you
On Wed, Jul 25, 2007 at 11:48:35AM +0800, rae l wrote:
> Why alloc_super use a static variable default_op?
> the static struct super_operations default_op is just all zeros, and
> just referenced as the initial value of a new allocated super_block,
> what does it for?
So that we would not have to
Benjamin Herrenschmidt wrote:
On Tue, 2007-07-24 at 17:55 -0400, Trond Myklebust wrote:
If you want to use bitops as spinlocks you should rather be using
. That also does the right thing w.r.t.
pre-emption and sparse locking annotations.
Heh, I didn't know about those... A bit annoying that
Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Also a random day at the desktop, it is quite a broad scope and
pretty well impossible to analyse.
It is pretty broad, but that's also what swap prefetch is targetting.
As for hard to analyze, I'm not sure I agree. One can
On Sat, 2007-21-07 at 23:00 +0200, Peter Zijlstra wrote:
> Use the read-ahead code to provide hints to page reclaim.
>
> This patch has the potential to solve the streaming-IO trashes my
> desktop problem.
>
> It tries to aggressively reclaim pages that were loaded in a strong
> sequential
Why alloc_super use a static variable default_op?
the static struct super_operations default_op is just all zeros, and
just referenced as the initial value of a new allocated super_block,
what does it for?
the filesystem dependent code such as ext2_fill_super would fill this
field eventually,
Bret Towe wrote:
for a while in -git I've had an issue that on boot when gdm loads the
screen stays black
using ctrl-f1 doesn't return to a console and killing X doesn't help any
ssh'ing into the box does work top only shows 100% io-wait
dmesg shows nothing odd
the work around I have is at the
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
>> Actually I'd worked on what was called MPSS (Multiple Page Size Support)
>> before I ever started on pgcl. Some large portion of the pgcl proposal
>> as I presented it internally was to reduce the order of large page
>>
Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote:
>Adding __builtin_trap after the
>asm might be an ok fix. It will emit a spurious int 6, but that won't even be
>reached since the asm doesn't return, and it probably be less extra code than
>the loop.
int 6 is a two byte
On Tuesday 24 July 2007 02:33:05 pm Yinghai Lu wrote:
> I have a system that has the same problem, and it turns out that FW
> missed PNP0501 is DSDT for uart. and add that it into DSDT works well.
Is this FW that has been shipped? Can you give any more details,
like DMI info and a copy of the
On Tue, Jul 24, 2007 at 07:25:09PM -0400, Chris Mason wrote:
> On Tue, 24 Jul 2007 23:25:43 +0200
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> The tree is a critical part of the patch, but it is also the easiest to
> rip out and replace. Basically the code stores a range by inserting
> an
On Tue, 24 Jul 2007, Al Viro wrote:
> AFAICS, the patch below should do it for i386; instead of
> using a dummy loop to tell gcc that this sucker never returns,
> we do
> static void __always_inline __noreturn __BUG(const char *file, int line);
> containing the actual asm we want to insert
Hi Jean:
* Jean Delvare <[EMAIL PROTECTED]> [2007-07-22 12:09:48 +0200]:
> On Sun, 22 Jul 2007 00:30:56 +0200, Gabriel C wrote:
> > I noticed this warnings on current git:
> >
> > drivers/hwmon/pc87360.c:1082: warning: 'pc87360_remove' defined but not used
> > drivers/hwmon/sis5595.c:580:
Hi Jesper:
* Jesper Juhl <[EMAIL PROTECTED]> [2007-07-21 17:02:01 +0200]:
> Hi,
>
> This patch cleans up duplicate includes in
> drivers/hwmon/
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/hwmon/ams/ams-core.c b/drivers/hwmon/ams/ams-core.c
> index
On Tuesday 24 July 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> The above stanza still needs some tlc. I built a 2.6.22.1-rt6 (rt5
>> wouldn't build) using the same old config that a make oldconfig didn't
>> fuss about, but the reboot never completed, see the attached,
On Sun, 22 Jul 2007 18:17:17 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
>
> On Sunday 22 July 2007, Adrian Bunk wrote:
> > The Coverity checker spotted the following array overrun
> > in drivers/rtc/rtc-ds1307.c:
>
> Typo -- thanks, fix is attached.
>
> CUT HERE
> Fix a typo
On Tue, 24 Jul 2007 13:40:04 +0100
Ben Dooks <[EMAIL PROTECTED]> wrote:
>
> Fixup the changes from moving around the arch
> support for s3c24xx based systems.
>
> Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Acked-by: Alessandro Zummo <[EMAIL PROTECTED]>
--
Best regards,
Alessandro
On Sun, 22 Jul 2007 21:20:38 +0200 Gabriel C <[EMAIL PROTECTED]> wrote:
> I get this warning when CONFIG_SYSCTL is not set :
>
> ...
>
> arch/i386/kernel/nmi.c:52: warning: 'unknown_nmi_panic_callback' declared
> 'static' but never defined
>
> ...
>
> Signed-off-by: Gabriel Craciunescu
On Tuesday 24 July 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> The above stanza still needs some tlc. I built a 2.6.22.1-rt6 (rt5
>> wouldn't build) using the same old config that a make oldconfig didn't
>> fuss about, but the reboot never completed, see the attached,
From: "Matthew Hawkins" <[EMAIL PROTECTED]>
Date: Wed, 25 Jul 2007 11:26:57 +1000
> On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The other consideration here is, as Nick points out, are the problems which
> > people see this patch solving for them solveable in other, better ways?
> >
As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
on the PegasosPPC. This is because of a feature/bug in the OF device tree:
the "device_type" attribute is an empty string instead of "8042" as the
kernel expects. This patch (against 2.6.22.1) adds a secondary detection
On Tuesday 24 July 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> wrote:
>> The above stanza still needs some tlc. I built a 2.6.22.1-rt6 (rt5
>> wouldn't build) using the same old config that a make oldconfig didn't
>> fuss about, but the reboot never completed, see the attached,
On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
The other consideration here is, as Nick points out, are the problems which
people see this patch solving for them solveable in other, better ways?
IOW, is this patch fixing up preexisting deficiencies post-facto?
So let me get this straight
On Wed, 25 Jul 2007 11:09:21 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Also, I prefer the style where the ? and : operators have a space
> after them but not before them, rather than a space either side.
Could I point out that your likes and dislikes are immaterial? The whole
point here
On Wednesday 25 July 2007, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday 25 July 2007, Michal Piotrowski wrote:
> > Hi,
> >
> > On 24/07/07, Eric Sesterhenn / Snakebyte <[EMAIL PROTECTED]> wrote:
> > > hi,
> > >
> > > seems like the clock got screwed or something similar. During
On Tue, Jul 24, 2007 at 03:32:59PM -0500, jschopp wrote:
>>> Yep I think the consensus is we need a
>>> "--i-don't-agree-just-check-things-which-will-get-me-rejected-out-of-hand"
>>> option of some sort which will restrict output to the real errors.
>> No, the default should be to show only the
Andy Whitcroft writes:
> Ok, this is something we need to decide on. Currently we only ask for
> consistent spacing on all the mathematic operators. This is mostly as
> we do see a large number of non-spaced uses in defines and the like.
>
> I am happy to expand these tests so they are always
On 7/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
> On 7/24/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
>> Andi Kleen wrote:
>> >> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip)
>> when
>> >> using LinuxBIOS
On Wed, 25 Jul 2007, Jerome Glisse wrote:
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 24 Jul 2007, Jerome Glisse wrote:
> On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Mon, 23 Jul 2007, Igor Stoppa wrote:
> > > again, HAL / OHM / Mobilin
> >
> >
On Tuesday 24 July 2007, Russell King wrote:
> > >
> > > I think you got the year wrong:
> > >
> > > 5edf71ae (Russell King 2005-11-25 15:52:51 + 364)
> > > WARN_ON(irqs_disabled());
> > >
> > > which is due to this commit:
> > >
> > > [ARM] Do not call flush_tlb_kernel_range()
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Make alloc_pid() initialize pid_numbers and hash them
| into the hashtable, not the struct pid itself.
|
| Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
|
| ---
|
| pid.c | 47 +--
| 1 files changed,
On 7/23/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22 2007, Satyam Sharma wrote:
> Hi Walter,
>
> Thanks for reporting this.
>
> On 7/22/07, walter harms <[EMAIL PROTECTED]> wrote:
>> hello all,
>> on my asus notebook tm620 there is a crash with 2.6.22 and 2.6.21
>
> Did this happen
On Tue, 2007-07-24 at 22:04 +0200, Ingo Molnar wrote:
> Marcin, could you try the patch below too? [without having any other
> patch applied.] It basically turns the critical section into an irqs-off
> critical section and thus checks whether your problem is related to that
> particular area of
On 7/24/07, Simon Arlott <[EMAIL PROTECTED]> wrote:
On 24/07/07 17:34, Kay Sievers wrote:
> On 7/24/07, Simon Arlott <[EMAIL PROTECTED]> wrote:
>> On 24/07/07 13:54, Cornelia Huck wrote:
>> > On Tue, 24 Jul 2007 11:20:02 +0200,
>> > "Kay Sievers" <[EMAIL PROTECTED]> wrote:
>> >
>> >> It looks
On Tue, 24 Jul 2007 16:58:51 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > __GFP_COMP I'm not so sure about.
> > drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like
> > infiniband)
> > pass it into dma_alloc_coherent()
On Tue, 24 Jul 2007, Andrew Morton wrote:
> __GFP_COMP I'm not so sure about.
> drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like infiniband)
> pass it into dma_alloc_coherent() which some architectures implement via
> slab. umm,
> arch/arm/mm/consistent.c is one such.
Should
IA64
Subject : Regression in serial console on ia64 after 2.6.22
References : http://marc.info/?l=linux-ia64=118483645914066=2
Last known good : ?
Submitter : Horms <[EMAIL PROTECTED]>
Caused-By : Yinghai Lu <[EMAIL PROTECTED]>
commit
On Tue, 24 Jul 2007 17:19:17 -0500, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me
> that the following commit is to blame, and by reverting that commit, it
> works appropriately.
I have noted the same behavior on a Thinkpad 600X.
On
On Tue, 2007-07-24 at 16:02 -0700, [EMAIL PROTECTED] wrote:
>
> what requirements are needed? (I'm sure that there are others, but
> hopefully it's possible to avoid requirements like 'the clock speed
> for
> device A must be >X to allow device B to operate in mode Y')
I had an idea a while
Chris Snook wrote:
A fraction of *each* CPU, or a fraction of *total* CPU? Per-cpu
granularity doesn't make anything more fair.
Well, our current solution uses per-cpu weights, because our vendor
couldn't get the load balancer working accurately enough. Having
per-cpu weights and cpu
Hi Florian,
On 24/07/07, Florian Lohoff <[EMAIL PROTECTED]> wrote:
On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
> The problem is related to power management. The PHY has a number of PCI
configuration
> registers for power control, and the function of these changes based
On Tue, 24 Jul 2007 23:25:43 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-24 at 16:13 -0400, Trond Myklebust wrote:
> > On Tue, 2007-07-24 at 16:00 -0400, Chris Mason wrote:
> > > On Tue, 10 Jul 2007 17:03:26 -0400
> > > Chris Mason <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Tue, Jul 24, 2007 at 05:22:47PM -0400, Chris Snook wrote:
> Bill Huey (hui) wrote:
> Well, you need enough CPU time to meet your deadlines. You need
> pre-allocated memory, or to be able to guarantee that you can allocate
> memory fast enough to meet your deadlines. This principle extends
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 24 Jul 2007, Jerome Glisse wrote:
> On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> On Mon, 23 Jul 2007, Igor Stoppa wrote:
>> > again, HAL / OHM / Mobilin
>>
>> I was trying to define the lower level interfaces
On Tue, 24 Jul 2007 16:00:32 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > I think I'll duck this for now. Otherwise I have a suspicion that I'll
> > be the first person to run it and I'm too old for such excitement.
>
> I always
On 07-07-24 15:45 H. Peter Anvin wrote:
> Chuck Ebbert wrote:
> >
> >Okay, I tested with Fedora on x86_64 and it worked there too.
> >(Not that that proves much.)
> >
> >Did you capture any of the error messages, like the address
> >of the segfault?
> >
>
> FWIW, on x86-64, this should show up
Hi Lars,
On 7/24/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> >[...]
> >> Don't use signals between kernel
On Tue, Jul 24, 2007 at 04:08:11PM -0700, David Brownell wrote:
> On Tuesday 24 July 2007, Russell King wrote:
> > On Tue, Jul 24, 2007 at 02:29:05PM -0700, David Brownell wrote:
> > > On at least ARM (and I'm told MIPS too) dma_free_coherent() has a newish
> > > call context requirement: unlike
On Tuesday 24 July 2007, Russell King wrote:
> On Tue, Jul 24, 2007 at 02:29:05PM -0700, David Brownell wrote:
> > On at least ARM (and I'm told MIPS too) dma_free_coherent() has a newish
> > call context requirement: unlike its dma_alloc_coherent() sibling, it
> > may not be called with IRQs
On Tue, 24 Jul 2007, Alan Cox wrote:
>
> Just one version of Linux ago
> The PLL code broke - oh no!
> But set the right mode
> And fix up the code
> Makes the PLL timing sync go
Alan, I'm getting a bit worried about you.
Linus
-
To unsubscribe
On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote:
I think we need a set of constraints that trickle down the power
tree
and limit what a given driver can do locally.
what sort of contraints are you thinking of?
A parent power
Hi Mikie,
> Do you have any news regarding my case of slow transfers via
> Speedtouch USB modem on linux ?
I found my old speedtouch modem and tested here. I got 2.1 Mbaud
bulk downspeed, and 3 Mbaud isoc downspeed. This last is half the
speed my line supports, so something is wrong [*].
On Tue, 24 Jul 2007, Andrew Morton wrote:
> I think I'll duck this for now. Otherwise I have a suspicion that I'll
> be the first person to run it and I'm too old for such excitement.
I always had the suspicion that you have some magical script
which will immediately tell you that a patch is
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
> On 7/24/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
>> Andi Kleen wrote:
>> >> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip)
>> when
>> >> using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
Chuck Ebbert wrote:
Okay, I tested with Fedora on x86_64 and it worked there too.
(Not that that proves much.)
Did you capture any of the error messages, like the address
of the segfault?
FWIW, on x86-64, this should show up in dmesg.
-hpa
-
To unsubscribe from this list: send the
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >> Already with these patches I can compile a zImage kernel that is 450kb
> >> large (890kb decompressed)
> >
> > The important part is not how big the vmlinux is, but how much
> > memory is actually used
On 07/24/2007 06:00 PM, Ulrich Kunitz wrote:
> On 07-07-24 16:57 Chuck Ebbert wrote:
>
>>> $ strace ./cat
>>> execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
>>> directory)
>>> ...
>
> Chuck, my binaries run always into a segmentation violation. So
> ENOENT is not the
On Tue, 2007-07-24 at 13:04 +0100, Alan Cox wrote:
> Dear Rusty I think that we know
> Your code has good things to show
> But an unreliable guide
> To the poetic aside
> Would probably steal the show
That and your (slightly dated?) mm documentation were awesome. But can
we stop now?
Please?
On Tue, 2007-07-24 at 17:55 -0400, Trond Myklebust wrote:
>
> If you want to use bitops as spinlocks you should rather be using
> . That also does the right thing w.r.t.
> pre-emption and sparse locking annotations.
Heh, I didn't know about those... A bit annoying that I can't override
them in
On 7/24/07, Dmitry Monakhov <[EMAIL PROTECTED]> wrote:
Signed-off-by: Dmitry Monakhov <[EMAIL PROTECTED]>
---
drivers/md/raid5.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 0f30826..79dd2c7 100644
---
On Tue, 2007-07-24 at 09:05 -0400, Vlad Yasevich wrote:
>
> Please don't remove module_exit point for SCTP. Simply removing the
> __unsafe() call will
> be sufficient.
>
> The code has recently been cleaned up to allow safe unloading and I working
> on final
> cleanups. It currently works
Am 23.07.2007 11:47 schrieb Michal Piotrowski:
> Virtualization
>
> Subject : 2.6.22-git17 boot failure (XEN)
> References : http://lkml.org/lkml/2007/7/22/266
> Last known good : ?
> Submitter : Tilman Schmidt <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
>
Hello.
Linux 2.6.23-rc1 fails to power off my ThinkPad T42.
Git-bisect told me that the following commit is to blame,
and by reverting that commit, it works appropriately.
Regards,
--yoshfuji
bd804eba1c8597cbb7cd5a5f9fe886aae16a079a is first bad commit
commit
On Tue, 24 Jul 2007, Rafael J. Wysocki wrote:
> > Then device_suspend() can be simplified:
> >
> > int device_suspend(pm_message_t state)
> > {
> > int error = 0;
> >
> > might_sleep();
> > list_for_each_entry_reverse(dev, _locked, power.entry) {
> > error =
On Tue, 24 Jul 2007 12:36:59 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > > __GFP_MOVABLE The movability of a slab is determined by the
> > > options specified at kmem_cache_create time. If this is
> > >
On Tue, Jul 24, 2007 at 02:29:05PM -0700, David Brownell wrote:
> On at least ARM (and I'm told MIPS too) dma_free_coherent() has a newish
> call context requirement: unlike its dma_alloc_coherent() sibling, it
> may not be called with IRQs disabled. (This was new behavior on ARM as
> of late
> That cannot be a justification for breaking serial port probe that has
> been working for 10+ years.
Agree. With my "nearest thing we have to a serial maintainer" hat on
please revert this Andrew. Bjorn - lets discuss putting the right APIs in
place so you can busy out serial ports from other
On 07-07-24 16:57 Chuck Ebbert wrote:
> > $ strace ./cat
> > execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
> > directory)
> > ...
Chuck, my binaries run always into a segmentation violation. So
ENOENT is not the issue. (Notify it was on an x86-64.)
> > $ file cat
> >
> - use setserial to make the serial driver forget about ttyS2
> so an IR driver could claim it, or
>
> - use setserial to change the IRQ to 3 and just use the device
> in SIR mode, which is 16550-compatible so you can use the
> serial driver
>
> I didn't express that very
On 24/07/07, Greg KH <[EMAIL PROTECTED]> wrote:
On Mon, Jul 23, 2007 at 11:47:44AM +0200, Michal Piotrowski wrote:
> Unclassified
>
> Subject : kobject link failure
> References : http://lkml.org/lkml/2007/7/19/495
> Last known good : ?
This is caused by a patch that happened after
On Wed, 2007-07-25 at 07:37 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-07-24 at 11:13 -0700, Linus Torvalds wrote:
> >
> > IOW, if you do a spinlock with the bitops, the locking side should be
> > able
> > to use a "test_and_set_bit()" on its own, but the unlocking side
> > should be
>
Samuel Thibault wrote:
> Hi,
>
> Egmont got some UTF-8 fixes in mainline, Andrew Morton suggested it
> might be a good time to remember about bug 7746 Support for unicode dead
> keys: http://bugzilla.kernel.org/show_bug.cgi?id=7746 :
>
> « Quoting a mail from Vojtech Pavlik:
>
> "Several
Chris Friesen wrote:
Chris Snook wrote:
I don't think Chris's scenario has much bearing on your patch. What
he wants is to have a task that will always be running, but can't
monopolize either CPU. This is useful for certain realtime workloads,
but as I've said before, realtime requires
Hi,
Egmont got some UTF-8 fixes in mainline, Andrew Morton suggested it
might be a good time to remember about bug 7746 Support for unicode dead
keys: http://bugzilla.kernel.org/show_bug.cgi?id=7746 :
« Quoting a mail from Vojtech Pavlik:
"Several languages (polish, czech, slovak, ...) use dead
On Tue, 24 Jul 2007, Jeremy Fitzhardinge wrote:
> >
> > But gcc docs also talk about the other things volatile means, including
> > "not significantly moved".
>
> Actually, it doesn't. In fact it goes out of its way to say that "asm
> volatile" statements can be moved quite a bit, with
1 - 100 of 1032 matches
Mail list logo
