On Sun, 29 Jul 2007, Domen Puncer wrote:
> On 29/07/07 00:02 +0200, Jesper Juhl wrote:
> > Hi,
> >
> > Here's a small patch, prompted by a find by the Coverity checker,
> > that removes a potential NULL pointer dereference from
> > drivers/net/sb1000.c::sb1000_dev_ioctl().
> > The checker
Hi all,
My new laptop came with some of the above. Has anyone tried looking at
this to see what is involved in using it?
http://www.intel.com/support/chipsets/itm/
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp0jeeNpjY79.pgp
On Thursday 26 July 2007 11:57, [EMAIL PROTECTED] wrote:
> On Fri, July 27, 2007 12:29 am, Alan Cox wrote:
> >> > A small number of boxes do share IRQ12 and it was switched to shared
> >> for
> >> > them.
> >> If that is the case interrupt handlers should be able to determine
> >> whether
> >> a
> It's like CONFIG_HZ - more or less often debated, and now we have everyone
> happy by giving them the choice.
That's an interesting analogy -- since really the right answer there
seems not to be modal at all, but rather to do CONFIG_NO_HZ.
- R.
-
To unsubscribe from this list: send the line
On 29/07/07 00:02 +0200, Jesper Juhl wrote:
> Hi,
>
> Here's a small patch, prompted by a find by the Coverity checker,
> that removes a potential NULL pointer dereference from
> drivers/net/sb1000.c::sb1000_dev_ioctl().
> The checker spotted that we do a NULL test of 'dev', yet we
>
This patch adds the /sys/module//notes/ magic directory, which has
a file for each allocated SHT_NOTE section that appears in .ko.
This is the counterpart for each module of /sys/kernel/notes for vmlinux.
Reading this delivers the contents of the module's SHT_NOTE sections.
This lets userland
On Sun, 29 Jul 2007 10:49:18 +0800 Eugene Teo <[EMAIL PROTECTED]> wrote:
>
> arch/i386/kernel/apm.c: In function 'apm_init':
> arch/i386/kernel/apm.c:2240: warning: format '%lx' expects type 'long
> unsigned int', but argument 3 has type 'u32'
>
> apm_info.bios.offset is of type 'u32'.
>
>
On Friday 27 July 2007 16:12, Andrew Morton wrote:
> On Fri, 27 Jul 2007 21:43:59 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > > Sure, but why is the locking interruptible rather than plain old
> > > mutex_lock()?
> >
> > Hm, well. We hold this mutex for several seconds, as writing
Hi Parag,
On Friday 27 July 2007 10:43, Parag Warudkar wrote:
> Ignore my previous whitespace damaged patch. This one should be good.
>
> tsdev.c warns about scheduled removal each time tsdev_open is called -
> So even for a default boot I get to see the warning 3 times -
>
> [ 340.537078]
Al Boldi wrote:
Chris Snook wrote:
At best, reads can be read-ahead and cached, which is why
sequential swap-in sucks less. On-demand reads are as expensive as I/O
can get.
Which means that it should be at least as fast as swap-out, even faster
because write to disk is usually slower than
Andrew Morton wrote:
On Fri, 27 Jul 2007 13:37:08 -0700
Nick Pasich <[EMAIL PROTECTED]> wrote:
Greg/Peter/Al,
added linux-usb-devel.
I've been using the edgeport 4 port USB to Serial Converter
to monitor APC Smart UPS's via apcupsd for quite awhile on
various Linux boxes.
I just upgraded
Danny ter Haar wrote:
[ added linux-acpi and Len to CC ]
> Quoting Gabriel C ([EMAIL PROTECTED]):
>> Maybe try to :
>> disable BSG ( maybe some leftover bug )
>> boot acpi=off ( that got merged kind late )
>
> My first git disected kernel wouldn't boot, but with
> acpi=off it would indeed boot!
The current stub definitions of bsg_register_queue() and
bsg_unregister_queue() as macros leads to
drivers/scsi/scsi_sysfs.c: In function 'scsi_sysfs_add_sdev':
drivers/scsi/scsi_sysfs.c:718: warning: unused variable 'rq'
because the first parameter of bsg_register_queue() is completely
Hi Indan,
On Friday 27 July 2007 19:28, Indan Zupancic wrote:
> Hi,
>
> Not real feedback, just some nitpicks.
>
> On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
> > +static int input_defuzz_abs_event(int value, int old_val, int fuzz)
> > +{
> > + if (fuzz) {
> > + if (value >
thanks, I applied this by hand since it was so trivial.
-
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 at http://www.tux.org/lkml/
On Sat, 28 Jul 2007 21:33:59 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> > What I think is killing us here is the blockdev pagecache: the pagecache
> > which backs those directory entries and inodes. These pages get read
> > multiple times because they hold multiple
Hi Indan,
On Friday 27 July 2007 18:25, Indan Zupancic wrote:
> Sorry for the babbling, just wanted to say that I've tested these
> patches and that they seem to fix real problems.
>
Thank you for testing the patches.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe
the patch looks fine except your mailer seems to have mangled
it... can you resend so I can apply it?
thanks...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Quoting Gabriel C ([EMAIL PROTECTED]):
> Maybe try to :
> disable BSG ( maybe some leftover bug )
> boot acpi=off ( that got merged kind late )
My first git disected kernel wouldn't boot, but with
acpi=off it would indeed boot!
As did the 2.6.23-rc1-git5 kernel...
I will bisect further to find
Tong Li wrote:
Without the global locking, the global synchronization here is simply
ping-ponging a cache line once of while. This doesn't look expensive to
me, but if it does after benchmarking, adjusting sysctl_base_round_slice
can reduce the ping-pong frequency. There might also be a smart
This patch fixes these warnings:
fs/partitions/check.c: In function ‘add_partition’:
fs/partitions/check.c:391: warning: ignoring return value of ‘kobject_add’,
declared with attribute warn_unused_result
fs/partitions/check.c:394: warning: ignoring return value of
Danny ter Haar wrote:
> Quoting Bartlomiej Zolnierkiewicz ([EMAIL PROTECTED]):
>> Please retry with the latest -git kernel and if the problem is still
>> there install git, get kernel tree and run git-bisect.
>
> I ran over "make menuconfig" and did a few changes.
>
>
arch/i386/kernel/apm.c: In function 'apm_init':
arch/i386/kernel/apm.c:2240: warning: format '%lx' expects type 'long
unsigned int', but argument 3 has type 'u32'
apm_info.bios.offset is of type 'u32'.
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
---
arch/i386/kernel/apm.c |2 +-
1
Hello,
I had something like this in video.S for years, so it is probably time
to try to push it upstream... Besides other problems it confirmed that
when I connect HDTV to my nVidia, BIOS decides that 640x480 is largest
possible resolution, as it is largest standard resolution smaller than
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Bill Huey (hui) wrote:
You have to consider the target for this kind of code. There are
applications
where you need something that falls within a constant error bound.
According
to the numbers, the current CFS rebalancing logic doesn't
On Sat, Jul 28, 2007 at 03:52:02PM -0700, Jeremy Fitzhardinge wrote:
> Neil Horman wrote:
> > Jeremy asked that I make a patch next week to address split_argv's
> > requirement
> > that the argc parameter be non-NULL. I'll be fixing that next week, and
> > what I
> > can do is further enhance
Con Kolivas <[EMAIL PROTECTED]> writes:
> Interesting... Trying to avoid reading email but with a flooded inbox
> it's quite hard to do.
Con, good to hear from you. Good luck with your future endeavors.
Charles
--
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable,
*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
The previous DEBUG_SHIRQ patch missed one case. The console doesn't
set its host descriptors non-blocking.
Sorry, things looked okay when I tested on my UML environment (Puppy
Linux). Some xterms
Al Boldi wrote:
Good idea, but unless we understand the problems involved, we are bound to
repeat it. So my first question would be: Why is swap-in so slow?
As I have posted in other threads, swap-in of consecutive pages suffers a 2x
slowdown wrt swap-out, whereas swap-in of random pages
> Boot failure on x86_64 (64X2), says it can't find init, specifically
> /init. 2.6.23-rc1-git1 boots and runs successfully. I haven't tried
> -git2. I shall reboot on 2.6.23-rc1-git3 tomorrow and record the full
> message.
> Strings from vmlinux in both the above:-
>
> Kernel alive
>
Andrew Morton wrote:
What I think is killing us here is the blockdev pagecache: the pagecache
which backs those directory entries and inodes. These pages get read
multiple times because they hold multiple directory entries and multiple
inodes. These multiple touches will put those pages onto
Quoting Bartlomiej Zolnierkiewicz ([EMAIL PROTECTED]):
> Please retry with the latest -git kernel and if the problem is still
> there install git, get kernel tree and run git-bisect.
I ran over "make menuconfig" and did a few changes.
http://www.dth.net/kernel/config-2.6.23-rc1-git5
It boots,
On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote:
> I don't think anything was suppressed here.
I disagree. See below.
> You seem to say that more modular code would have helped make for a nicer
> way to do schedulers, but if so, where were those patches to do that?
> Con's
On Fri, 2007-07-27 at 12:45 +0200, Andi Kleen wrote:
> Rusty Russell <[EMAIL PROTECTED]> writes:
>
> > Jason Yeh sent his crashing .config: bzImages made with
> > CONFIG_RELOCATABLE=y put the relocs where the BSS is expected, and we
> > crash with unusual results such as:
>
> The normal kernel
On 29/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote:
> Tony,
>
> Second time attempt at this and a much better job I think.
>
Sorry, given I've jsut said this *does* work at 24bpp and 32bpp I'd
better clean up the Documentation patch,,,
diff --git a/Documentation/fb/pvr2fb.txt
On Sun, 2007-07-29 at 01:41 +0200, Volker Armin Hemmann wrote:
> Hi,
>
> I never tried Con's patchset, for two reasons:
> I tried his 2.4 patches ones, and I never saw any improvements. So when
> people
> were reporting huge improvements with his SD scheduler, I compared that with
> the
Tony,
Second time attempt at this and a much better job I think.
This patch consolidates your earlier patch, some cleanup of the
documentation and, crucially, some better handling of the pvr2
registers based on more up to date information.
Testing shows that it seems to work pretty well at
Quoting Bartlomiej Zolnierkiewicz ([EMAIL PROTECTED]):
> Should be harmless for now but we would like to fix it the long-term,
> please send "hdparm --Istdout /dev/hda" output.
I allready made that available in the same subdir:
http://www.dth.net/kernel/
Output repeated here:
voyage:~#
On Friday 27 July 2007, Michal Piotrowski wrote:
> IDE
>
> Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
> References : http://lkml.org/lkml/2007/7/27/298
> Last known good : ?
> Submitter : dth <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
Interesting... Trying to avoid reading email but with a flooded inbox it's
quite hard to do.
A lot of useful discussion seems to have generated in response to people's
_interpretation_ of my interview rather than what I actually said. For
example, everyone seems to think I quit because CFS was
On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > This patch makes sure we don't dereference a NULL pointer in
> > drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
> > struct net_device *net =
Hi,
On Friday 27 July 2007, dth wrote:
> I have a via mini-itx epia 5000 motherboard as a firewall.
> It has an ide device: PQI 128MB flash DOM [1] which just plugs
> directly into the ide connector on the motherboard.
> 2.6.22-git17 works, although it gives some warning
> hda:
On Friday 27 July 2007, David Lamparter wrote:
> [PATCH] ide: sis5513.c: Add FSC Amilo A1630 PCI subvendor/dev to laptops
>
> Recognise the FSC Amilo A1630's incarnation of a SiS5513 chip as laptop to
> get UDMA100 support.
>
> Signed-off-by: David Lamparter <[EMAIL PROTECTED]>
applied, thanks
Hi,
I never tried Con's patchset, for two reasons:
I tried his 2.4 patches ones, and I never saw any improvements. So when people
were reporting huge improvements with his SD scheduler, I compared that with
the reports of huge improvements with his 2.4 kernel patches.
...
The second: too many
Hi,
On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This patch makes sure we don't dereference a NULL pointer in
> drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
> struct net_device *net = pegasus->net; assignment.
> The existing code checks if 'pegasus' is NULL
Neil Horman wrote:
> Jeremy asked that I make a patch next week to address split_argv's requirement
> that the argc parameter be non-NULL. I'll be fixing that next week, and what
> I
> can do is further enhance it such that it ignores spaces in quoted strings,
> which should address the case
Sam Ravnborg wrote:
> kasprintf pulls in kmalloc which proved to be fatal for at least
> bootimage target on alpha.
> Move it to a separate file so only users of kasprintf are exposed
> to the dependency on kmalloc.
>
OK by me (that's what my original patch did), but it might be worth
Hi,
The Coverity checker points out (CID: 1500) that we can in some
cases end up doing a double free of 'model' in asus_hotk_get_info().
I'm not 100% sure it is right, but better safe than sorry,
especially since this is so simple to turn into a non-issue - simply
set 'model' to NULL after the
From: Mel Gorman <[EMAIL PROTECTED]>
Lumpy reclaim works by selecting a lead page from the LRU list and then
selecting pages for reclaim from the order-aligned area of pages. In the
situation were all pages in that region are inactive and not referenced by
any process over time, it works well.
We are transitioning pages from active to inactive in
clear_active_flags, those need counting as PGDEACTIVATE vm events.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Mel Gorman <[EMAIL PROTECTED]>
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d419e10..99ec7fa 100644
---
As pointed out by Mel when reclaim is applied at higher orders a
significant amount of IO may be started. As this takes finite time
to drain reclaim will consider more areas than ultimatly needed
to satisfy the request. This leads to more reclaim than strictly
required and reduced success rates.
> The onstack array seems fine to me, even if you do end up deciding on
> an array of one. Is there any evidence that it's a problem getting a
> page for the freeing (other than in circumstances that are already
> badly slowed down)? It's obvious that we need a fallback route,
> but optimizing
Linus Torvalds wrote:
I personally feel that modal behaviour is bad, so it would introduce what
is in my opinion bad code, and likely result in problems not being found
and fixed as well (because people would pick the thing that "works for
them", and ignore the problems in the other module).
On 7/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> could you try CONFIG_HZ_1000 instead of the 250 you are using currently?
> Also, please enable CONFIG_SCHED_DEBUG to improve the output of
> cfs-debug-info.sh.
>
> Ingo
>
Hi, Igno.
Sorry for so long response, I hadn't opportunity to
On Sat, 28 Jul 2007, Jan Engelhardt wrote:
>
> I generally run with CONFIG_HZ=100, CONFIG_NO_HZ=n, CONFIG_PREEMPT_NONE.
Ok, that's HZ=100 is likely the worst case, as it effectively multiples
all the scheduler latencies by 10 (rather than by 4, which is what the
default 250Hz does).
That
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
struct net_device *net = pegasus->net; assignment.
The existing code checks if 'pegasus' is NULL and bails out if
it is, so we better not touch that pointer until
On Sat, 28 Jul 2007, Bill Huey wrote:
>
> My argument is that schedule development is open ended. Although having
> a central scheduler to hack is a a good thing, it shouldn't lock out or
> supress development from other groups that might be trying to solve the
> problem in unique ways.
I
On Jul 28 2007 14:33, Linus Torvalds wrote:
>
>Btw, people who actually have 3D games installed (I have exactly one:
>ppracer, and I can't really say that I care about how it feels), if you
>don't have CONFIG_HZ=1000, this really is worth testing.
>
>I think Ingo probably ran with CONFIG_NO_HZ
On Saturday 28 July 2007 17:06:50 [EMAIL PROTECTED] wrote:
> On Sat, 28 Jul 2007, Daniel Hazelton wrote:
> > On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote:
> >> On Sat, 28 Jul 2007, Rene Herman wrote:
> >>> On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote:
> On Fri, 27 Jul 2007,
On Sat, 28 Jul 2007, Linus Torvalds wrote:
>
> Yes, it's what "/proc/sys/kernel/sched_granularity_ns" is supposed to
> tweak, but maybe there's some misfeature there, or maybe the default is
> just bad for games, or whatever.
>
> Ingo: that sysctl_sched_granularity initialization doesn't
On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote:
> So your argument is that SD shouldn't have been merged either, because it
> would have resulted in one scheduler over the other?
My argument is that schedule development is open ended. Although having
a central scheduler to hack is
On Sat, 28 Jul 2007, Diego Calleja wrote:
> El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
> escribió:
> >
> > So "modal" things are good for fixing behaviour in the short run. But they
> > are a total disaster in the long run, and even in the short run they
On Sat, 28 Jul 2007, Daniel Hazelton wrote:
On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote:
On Sat, 28 Jul 2007, Rene Herman wrote:
On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote:
On Fri, 27 Jul 2007, Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
nobody
On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote:
> As a long-term maintainer, trust me, I know what matters. And a person who
> can actually be bothered to follow up on problem reports is a *hell* of a
> lot more important than one who just argues with reporters.
>
>
El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) <[EMAIL PROTECTED]>
escribió:
> of how crappy X is. This is an open argument on how to solve, but it
> should not have resulted in really one scheduler over the other. Both
So your argument is that SD shouldn't have been merged either, because
On Sat, 28 Jul 2007, Alan Cox wrote:
It is. Prefetched pages can be dropped on the floor without additional I/O.
Which is essentially free for most cases. In addition your disk access
may well have been in idle time (and should be for this sort of stuff)
and if it was in the same chunk as
On Sat, 28 Jul 2007, Rene Herman wrote:
On 07/28/2007 10:55 AM, [EMAIL PROTECTED] wrote:
it looks to me like unless the code was really bad (and after 23 months in
-mm it doesn't sound like it is)
Not to sound pretentious or anything but I assume that Andrew has a fairly
good overview of
On Jul 28 2007 22:51, Diego Calleja wrote:
>El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
>escribió:
>
>> So "modal" things are good for fixing behaviour in the short run. But they
>> are a total disaster in the long run, and even in the short run they tend
>> to
On Tue, Jul 17, 2007 at 03:52:07PM -0400, Dmitry Torokhov wrote:
> Hi Christoph,
>
> On 7/17/07, Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >
> >Yep, attached (cold reboot, not pressing any keys, 2.6.21).
> >
>
> Ok, I see. You don't use PS/2 mouse and so BIOS told us that mouse is
> absent
> kasprintf pulls in kmalloc which proved to be fatal for at least
> bootimage target on alpha.
> Move it to a separate file so only users of kasprintf are exposed
> to the dependency on kmalloc.
Withe the addition of missing $(LIB_Y) it really seems to compile now.
Can not boot test before some
El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
escribió:
> So "modal" things are good for fixing behaviour in the short run. But they
> are a total disaster in the long run, and even in the short run they tend
> to have problems (simply because there will be cases
> Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I
> wonder if this is due to the RAM failing at the point where the framebuffer
> is mapped?
you are probably right... I removed one of the RAMs, no crash
anymore. This is not ... nice. The manual says, that the board
On Sat, 28 Jul 2007, jos poortvliet wrote:
>
> Your point here seems to be: this is how it went, and it was right. Ok, got
> that.
But I wanted to bring out more than what you make sound like "that's what
happened, deal with it". I tried to explain _why_ the choices that were
made were in
On Fri, Jul 27, 2007 at 10:47:21PM -0400, Rik van Riel wrote:
> Tim Chen wrote:
> > Ingo,
> >
> > Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
> > Benchmark was run on a 2 socket Core2 machine.
> >
> > The change in scheduler treatment of sched_yield
> > could play a part
On Sat, Jul 28, 2007 at 10:04:50PM +0200, Sam Ravnborg wrote:
>
> The fix is to split kasprintf out to a separate file to
> avoid pulling in more stuff than necessary.
I just sent a patch doing this and I assume you take care of the alpha changes.
Thanks,
Sam
-
To unsubscribe from this
kasprintf pulls in kmalloc which proved to be fatal for at least
bootimage target on alpha.
Move it to a separate file so only users of kasprintf are exposed
to the dependency on kmalloc.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Meelis Roos
On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote:
> Your point here seems to be: this is how it went, and it was right. Ok, got
> that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
> how many did leave without this splash. How many didn't even get involved
> I have absolutely no idea what triggers this crash.
Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I
wonder if this is due to the RAM failing at the point where the framebuffer
is mapped?
Try running memtest86 on it.
--
Cheers,
Alistair.
137/1 Warrender Park
On Sat, Jul 28, 2007 at 08:05:08PM +0300, Meelis Roos wrote:
> Retested this compile error with todays 2.6.23-rc1+git, still the same.
>
> > > LD arch/alpha/boot/bootloader
> > > arch/alpha/boot/bootloader.lds:25: undefined symbol `srm_printk'
> > > referenced in expression
> >
> > I was
On Fri, 27 Jul 2007, Cliff Wickman wrote:
> I've run into a problem with the ATA SCSI disk driver when running in a
> kdump dump-capture kernel.
>
> I'm running on 2-processor x86_64 box. It has 2 scsi disks, /dev/sda and
> /dev/sdb
>
> My kernel is 2.6.22, and built to be a dump capturing
On Fri, 27 Jul 2007, Chris Snook wrote:
Bill Huey (hui) wrote:
You have to consider the target for this kind of code. There are
applications
where you need something that falls within a constant error bound.
According
to the numbers, the current CFS rebalancing logic doesn't achieve that to
Hi Jeff,
I noticed this warnings when CONFIG_PM=n
...
drivers/ata/libata-core.c:5993: warning: 'ata_host_disable_link_pm' defined but
not used
drivers/ata/libata-core.c:6004: warning: 'ata_host_enable_link_pm' defined but
not used
...
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
On Sat, 28 Jul 2007, Jan Engelhardt wrote:
>
> Time to investigate...
Well, one thing that would be worth doing is to simply create a trace of
time-slices for both schedulers.
It could easily be some hacky thing that just saves the process name and
TSC at each scheduling event in some
good day,
when setting up a more or less old board, 2.6.22.1 crashes during an
"emerge --sync" (gentoo installation).
first, the screen will start funny - like a crashed C64 (from the "good"
old days). I made a photo, you can look at it here:
Op Saturday 28 July 2007, schreef Linus Torvalds:
>
> Compare this to SD for a while. Ponder.
>
> Linus
Your point here seems to be: this is how it went, and it was right. Ok, got
that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
how many did
On Fri, 27 Jul 2007, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread 1.0 billion
cycles during the next second,
On Jul 28 2007 10:50, Linus Torvalds wrote:
>On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>>
>> First off, i've personally run tests on many more machines than my own,
>> i've had lots of people try on their machines, and i've seen totally
>> unrelated posts to lkml, plus i've seen the experiences
> > Volanomark runs better
> > and is only 40% (instead of 80%) down from old scheduler
> > without CFS.
> 40 or 80 % is still a huge regression.
> Dmitry Adamushko
Can anyone explain precisely what Volanomark is doing? If it's something
dumb like "looping on sched_yield until the 'right'
Andrew Morton wrote:
> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> I got this compile error with a randconfig (
>> http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ).
>>
>> ...
>>
>> net/core/netpoll.c: In function 'netpoll_poll':
>>
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote:
>
> OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require
> quite a bit of (compilation) testing on different architectures.
Sure. I'm not too worried, the fallout should be of the trivial kind.
Also, mind basing it on the
On Sat, 28 Jul 2007, jos poortvliet wrote:
>
>
Actually, the tag you were looking for was ""
> http://osnews.com/permalink.php?news_id=18350_id=259044
>
> Now I wonder. Apparently, one person complaining about SD was reason to keep
> it out
On Saturday, 28 July 2007 00:25, Adrian Bunk wrote:
> On Thu, Jul 26, 2007 at 01:55:18PM -0700, Linus Torvalds wrote:
> >
> >
> > On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> > >
> > > My point is we have ACPI dependent on PM, so if you want ACPI, you end
> > > up with all of the STR stuff
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote:
>
> On Sat, 28 Jul 2007, Linus Torvalds wrote:
> >
> > And it's the *top*level* code that selects HOTPLUG_CPU. Through
> > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND.
>
> In other words, the problem seems to be that
Yoichi Yuasa wrote:
Hi,
I got the following error on MIPS Cobalt.
MIPS Cobalt has the 0x1000 offset between resource and bus region.
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:09.1
pata_via :00:09.1: failed to request/iomap BARs for port 0 (errno=-16)
On Sat, 2007-07-28 at 10:50 -0700, Linus Torvalds wrote:
>
> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
> >
> > First off, i've personally run tests on many more machines than my own,
> > i've had lots of people try on their machines, and i've seen totally
> > unrelated posts to lkml, plus i've
On Sat, 28 Jul 2007, Jan Engelhardt wrote:
>
> You cannot please everybody in the scheduler question, that is clear,
> then why not offer dedicated scheduling alternatives (plugsched comes to mind)
> and let them choose what pleases them most, and handles their workload best?
This is one
Op Saturday 28 July 2007, schreef Linus Torvalds:
> On Sat, 28 Jul 2007, Michael Chang wrote:
> > I do recall there is one issue on which Con wouldn't budge -- anything
> > that involved boosting certain kinds of processes in the kernel.
>
> I did that myself, so that's a non-issue.
>
> No. The
On 28/07/07, Ondrej Zajicek <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 28, 2007 at 03:51:38PM +0100, Adrian McMenamin wrote:
> > Tony,
> >
> > This patch - on top of your others - fixes the colour output for 16bpp
> > RGB565 output in the Dreamcast - it was a simple out by one error in
> > the bit
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg
Unfortunately,
On Sat, 28 Jul 2007, Kasper Sandberg wrote:
>
> First off, i've personally run tests on many more machines than my own,
> i've had lots of people try on their machines, and i've seen totally
> unrelated posts to lkml, plus i've seen the experiences people are
> writing about on IRC. Frankly, im
1 - 100 of 398 matches
Mail list logo
