Hi Nick,
On Tue, Apr 17, 2007 at 06:29:54AM +0200, Nick Piggin wrote:
(...)
> And my scheduler for example cuts down the amount of policy code and
> code size significantly. I haven't looked at Con's ones for a while,
> but I believe they are also much more straightforward than mainline...
>
>
On Tue, 17 Apr 2007 11:15:46 +0900 izumi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I encountered the following kernel panic. The cause of this problem was
> NULL pointer access in check_modem_status() in 8250.c. I confirmed
> this problem is fixed by the attached patch, but I don't know this
> is the
On Tuesday 17 April 2007, Willy Tarreau wrote:
>Hi Gene,
>
>On Tue, Apr 17, 2007 at 12:53:56AM -0400, Gene Heskett wrote:
>> On Monday 16 April 2007, Ingo Molnar wrote:
>> >this is the second release of the CFS (Completely Fair Scheduler)
>> >patchset, against v2.6.21-rc7:
>> >
>> >
On Tue, 2007-04-17 at 07:25 +0200, Willy Tarreau wrote:
> Have you tried previous version with the fair-fork patch ? It might be
> possible
> that your workload is sensible to the fork()'s child getting much CPU upon
> startup.
Dunno about that, but here's a possibly related datapoint. I
There's a couple of different ways I can see to fix the problem -
the first is to not reference the buffer in xlog_iodone() after
running the callbacks that may trigger it being freed. I'd prfer to
see if this fixes the problem before having to do more invasive
surgery. Can you try the patch
Am Donnerstag, 12. April 2007 08:27 schrieb Greg KH:
> On Mon, Apr 02, 2007 at 04:33:54PM +0200, Eric Dumazet wrote:
> > On Mon, 2 Apr 2007 14:47:59 +0200
> > Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > some atomic operations are only atomic, not ordered. Thus a CPU is
The flag SLAB_MUST_HWCACHE_ALIGN is
1. Never checked by SLAB at all.
2. A duplicate of SLAB_HWCACHE_ALIGN for SLUB
3. Fulfills the role of SLAB_HWCACHE_ALIGN for SLOB.
The only remaining use is in sparc64 and ppc64 and their use there
reflects some earlier role that the slab flag once may have
Hi Gene,
On Tue, Apr 17, 2007 at 12:53:56AM -0400, Gene Heskett wrote:
> On Monday 16 April 2007, Ingo Molnar wrote:
> >this is the second release of the CFS (Completely Fair Scheduler)
> >patchset, against v2.6.21-rc7:
> >
> > http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
> >
>
On Monday April 16, [EMAIL PROTECTED] wrote:
>
> cfq_dispatch_insert() was called with rq == 0. This one is getting really
> annoying... and md is involved again (RAID0 this time.)
Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or RAID5 that I
feel fairly safe concluding
Brian D. McGrew wrote:
Good evening gents!
I need some help in allocating memory and understanding how the system
allocates memory with physical versus virtual page tables. Please
consider the following snippet of code. Please, no wisecracks about bad
code; it was written in 30 seconds in
Hello, Maneesh.
Maneesh Soni wrote:
> I started looking at these patches and parallely also did some testing on a
> 8 CPU system. I am using the patches from Greg's tree at
> http://www.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git/
>
> I ran following loops parallelly
>
> # while
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 19:41:07 -0700
> That verbiage sounds fine -- so would you consider the previous patch
> I submitted (with module parameter) along with the wording above?
Yes, that sounds fine.
> I'm in transit for a redeye to NY so I won't be
On Mon, 2007-04-16 at 18:31 -0800, David Brownell wrote:
> Cleaning out some of my pending-reviews queue ... after you address
> these comments I think what I'd like to do is sign off on one clean
> patch, rather than initial-plus-cleanups.
>
>
Thanks a lot, David. We will try to cleanup the
On Monday 16 April 2007, Ingo Molnar wrote:
>this is the second release of the CFS (Completely Fair Scheduler)
>patchset, against v2.6.21-rc7:
>
> http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
>
>i'd like to thank everyone for the tremendous amount of feedback and
>testing the v1
Greetings everybody;
At some point in the last, say 6 months or so, some patches have been done to
the floppy.c area of the tree, and ever since, I have not been able to build
the driver in without wasting around a minute during the bootup with lags and
squawks about fd1 showing up in the boot
On Tue, Apr 17, 2007 at 02:25:39PM +1000, Peter Williams wrote:
> Nick Piggin wrote:
> >On Mon, Apr 16, 2007 at 04:10:59PM -0700, Michael K. Edwards wrote:
> >>On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
> >>>Note that I talk of run queues
> >>>not CPUs as I think a shift to multiple
From: Abhijit Bhopatkar <[EMAIL PROTECTED]>
First generation MacBooks were getting ignored by sigmatel drivers
and wrongly being identified as MACMINI. This patch makes them
identify as MACBOOK.
Signed-off-by: Abhijit Bhopatkar <[EMAIL PROTECTED]>
---
sound/pci/hda/patch_sigmatel.c |3 +++
On Tue, Apr 17, 2007 at 02:17:22PM +1000, Peter Williams wrote:
> Nick Piggin wrote:
> >On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
> >>On Tue, 2007-04-17 at 10:06 +1000, Peter Williams wrote:
> >>>Mike Galbraith wrote:
> Demystify what? The casual observer need only read
Nick Piggin wrote:
On Mon, Apr 16, 2007 at 04:10:59PM -0700, Michael K. Edwards wrote:
On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
Note that I talk of run queues
not CPUs as I think a shift to multiple CPUs per run queue may be a good
idea.
This observation of Peter's is the best
On Tue, 17 Apr 2007, Mike Galbraith wrote:
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely
FairScheduler [CFS]
On Tue, 2007-04-17 at 05:40 +0200, Nick Piggin wrote:
On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
Yup, and progress _is_ happening
Nick Piggin wrote:
On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
On Tue, 2007-04-17 at 10:06 +1000, Peter Williams wrote:
Mike Galbraith wrote:
Demystify what? The casual observer need only read either your attempt
at writing a scheduler, or my attempts at fixing the one
On Tue, Apr 17, 2007 at 06:01:29AM +0200, Mike Galbraith wrote:
> On Tue, 2007-04-17 at 05:40 +0200, Nick Piggin wrote:
> > On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
>
> > > Yup, and progress _is_ happening now, quite rapidly.
> >
> > Progress as in progress on Ingo's
Ingo Molnar wrote:
this is the second release of the CFS (Completely Fair Scheduler)
patchset, against v2.6.21-rc7:
http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
i'd like to thank everyone for the tremendous amount of feedback and
testing the v1 patch got - i could hardly keep
On Tue, 2007-04-17 at 05:40 +0200, Nick Piggin wrote:
> On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
> > Yup, and progress _is_ happening now, quite rapidly.
>
> Progress as in progress on Ingo's scheduler. I still don't know how we'd
> decide when to replace the mainline
On Mon, Apr 16, 2007 at 04:10:59PM -0700, Michael K. Edwards wrote:
> On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
> >Note that I talk of run queues
> >not CPUs as I think a shift to multiple CPUs per run queue may be a good
> >idea.
>
> This observation of Peter's is the best thing to
> > I have tested these patches with 2.6.20-mh1 + v4l-dvb-b5be3479f070 patchset.
> > I also tried 2.6.21-rc6 + v4l-dvb-b5be3479f070 patchset and this
> > combination
> > also works without OOPS.
> >
> Yes, that shows that the changesets prevent the oops, but it says
> nothing about vanilla
On Tue, Apr 17, 2007 at 04:29:01AM +0200, Mike Galbraith wrote:
> On Tue, 2007-04-17 at 10:06 +1000, Peter Williams wrote:
> > Mike Galbraith wrote:
> > >
> > > Demystify what? The casual observer need only read either your attempt
> > > at writing a scheduler, or my attempts at fixing the one
On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote:
> > > > > CONFIG_FB_BACKLIGHT=y
> > > > > CONFIG_ACPI_VIDEO=n
> > > >
> > > > That also gets me a dead display. Backlight doesn't turn back on.
> > >
> > > Anything under /sys/class/backlight?
> >
> > Entries from
On Mon, Apr 16, 2007 at 09:28:24AM -0500, Matt Mackall wrote:
> On Mon, Apr 16, 2007 at 05:03:49AM +0200, Nick Piggin wrote:
> > I'd prefer if we kept a single CPU scheduler in mainline, because I
> > think that simplifies analysis and focuses testing.
>
> I think you'll find something like
On Mon, 16 Apr 2007 19:43:03 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 18:21:12 -0700
> Mike Mattie <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 16 Apr 2007 16:36:13 +0200
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > [ Cc's added, full bug report was in
> > >
Zach Carter wrote:
Do you think there might be other bad hw, or another explanation?
Well, after updating the BIOS for the motherboard, I was able to rebuild the kernel 6 times in a row
with no page state errors. I noticed that the recent BIOS update includes "Enhanced compatibility
On Mon, 16 Apr 2007, Shaohua Li wrote:
On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
...
please check if the patch at
http://marc.info/?l=linux-acpi=117523651630038=2 fixed the issue
I have the same system as Mattia, and when I applied this patch and turned
CPU_IDLE back on, I got
Cleaning out some of my pending-reviews queue ... after you address
these comments I think what I'd like to do is sign off on one clean
patch, rather than initial-plus-cleanups.
On Monday 05 March 2007 2:41 am, Wu, Bryan wrote:
> --- linux-2.6.orig/drivers/spi/Kconfig2007-03-01
On Tue, 2007-04-17 at 00:44 +0400, Alexey Dobriyan wrote:
> On Mon, Apr 16, 2007 at 03:38:52PM -0400, Alan Stern wrote:
> > 3. Change the module code so that rmmod can return _before_ the
> > module is actually unloaded from memory (but after the module's
> > exit routine has
On Mon, 2007-04-16 at 22:50 -0400, Joshua Wise wrote:
> On Mon, 16 Apr 2007, Shaohua Li wrote:
> > On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
> >> ...
> > please check if the patch at
> > http://marc.info/?l=linux-acpi=117523651630038=2 fixed the issue
>
> I have the same system as
On Mon, 2007-04-16 at 15:53 -0400, Alan Stern wrote:
> The fundamental rule is that whenever you hand out a pointer to a routine
> living in a module, the receiver has to increment the module's refcount.
> But the driver core violates this rule all over the place.
Hi Alan,
Your rule is
On Tue, 2007-04-17 at 10:06 +1000, Peter Williams wrote:
> Mike Galbraith wrote:
> >
> > Demystify what? The casual observer need only read either your attempt
> > at writing a scheduler, or my attempts at fixing the one we have, to see
> > that it was high time for someone with the necessary
On Mon, 16 Apr 2007 18:21:12 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 16:36:13 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > [ Cc's added, full bug report was in
> > http://lkml.org/lkml/2007/4/16/18 ]
> >
> > On Mon, Apr 16, 2007 at 04:38:22AM -0700, Mike
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 16:47:05 -0700
>
> > Dave, according to your earlier emails, the qla2xxx driver worked
> > 'fine' in driver versions before commit
> > 7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that
Hi Jeff and crew,
I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:
[ 148.121490] hpt37x: DPLL did not stabilize.
Where before,
Good evening gents!
I need some help in allocating memory and understanding how the system
allocates memory with physical versus virtual page tables. Please
consider the following snippet of code. Please, no wisecracks about bad
code; it was written in 30 seconds in haste :-)
#include
Hi,
I encountered the following kernel panic. The cause of this problem was
NULL pointer access in check_modem_status() in 8250.c. I confirmed
this problem is fixed by the attached patch, but I don't know this
is the correct fix.
sadc[4378]: NaT consumption 2216203124768 [1]
Modules linked in:
sk_info_authunix is not being protected properly so the object that
it points to can be cache_put twice, leading to corruption.
We borrow svsk->sk_defer_lock to provide the protection. We should probably
rename that lock to have a more generic name - later.
Thanks to Gabriel for reporting
Now that sk_defer_lock protects two different things, make the
name more generic.
Also don't bother with disabling _bh as the lock is only
ever taken from process context.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svcsock.h |3 ++-
Following two patches fix a bug introduced in
7b2b1fee30df7e2165525cd03f7d1d01a3a56794
and hence is in 2.6.19 and later.
The first patch is a minimal fix which is suitable for all kernels
since 2.6.19-pre1. The second adds some consequent cleaning up
and is probably best left for 2.6.22-rc
On Monday 16 April 2007 23:57, Alan Cox wrote:
> I don't believe the existing behaviour _IS_ a mistake.
So what would be the arguments why this behavior makes sense, other than
legacy?
For /proc/mounts, one could argue that the admin might want to see everything,
but then that's not actually
Chris Friesen wrote:
William Lee Irwin III wrote:
The sorts of like explicit decisions I'd like to be made for these are:
(1) In a mixture of tasks with varying nice numbers, a given nice number
corresponds to some share of CPU bandwidth. Implementations
should not have the freedom to
On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote:
> On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> > >The error also happens in 2.6.19, same as in 2.6.18.
> > >I extracted this from syslog:
> > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >
On Mon, Apr 16, 2007 at 03:34:42PM -0700, Valerie Henson wrote:
> On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote:
> > On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote:
> >
> > > IMHO chunkfs could provide a much more promising approach.
> >
> > Agreed, that's one method
On Monday 16 April 2007 07:47, Davide Libenzi wrote:
> On Mon, 16 Apr 2007, Pavel Pisa wrote:
> > I cannot help myself to not report results with GAVL
> > tree algorithm there as an another race competitor.
> > I believe, that it is better solution for large priority
> > queues than RB-tree and
Jiri Kosina wrote:
> On Mon, 16 Apr 2007, Li Yu wrote:
>
>
>> HID bus prototype 20070416
>>
>
> Hi Li,
>
> thanks for taking care. Well, the patch is quite huge, do you think you
> could split it into separate independent parts (use quilt or somet
Chris Friesen wrote:
Peter Williams wrote:
To my mind scheduling and load balancing are orthogonal and keeping
them that way simplifies things.
Scuse me if I jump in here, but doesn't the load balancer need some way
to figure out a) when to run, and b) which tasks to pull and where to
push
Al Boldi wrote:
Peter Williams wrote:
Al Boldi wrote:
Reducing the prio-level granularity may also be helpful;
Because of some of the bit operations code makes it a bad idea to have
more than 160 priority levels, you're more or less limited to 60
priority levels for SCHED_OTHER tasks (as 100
On Mon, Apr 16, 2007 at 10:37:01AM +0200, Francis Moreau wrote:
>
> BTW, here are figures I got with 2 different versions of the driver
> when using tcrypt module. The second being the result with the
> optimized driver (no key reloading on each block):
>
> normal version:
> test 4 (128 bit key,
On Mon, 16 Apr 2007, John Johansen wrote:
> Label-based security (exemplified by SELinux, and its predecessors in
> MLS systems) attaches security policy to the data. As the data flows
> through the system, the label sticks to the data, and so security
> policy with respect to this data stays
On Mon, Apr 16, 2007 at 01:13:01PM +0800, Wang, Baojun wrote:
> PROBLEM: linux kernel 2.6.20.6 build failed for ppc board chestnut(ibm ppc
> 750GX/FX)
>
Confirmed. arch/ppc isn't getting much love these days.
> this brute force patch sould solve the problem:
This is missing a
Mike Galbraith wrote:
On Sun, 2007-04-15 at 13:27 +1000, Con Kolivas wrote:
On Saturday 14 April 2007 06:21, Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
[CFS]
i'm pleased to announce the first release of the "Modular Scheduler Core
and Completely
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 16:47:05 -0700
> Dave, according to your earlier emails, the qla2xxx driver worked
> 'fine' in driver versions before commit
> 7aef45ac92f49e76d990b51b7ecd714b9a608be1. If that were the case, then
> you would have seen the warning
Linus Torvalds wrote:
> Since we're still waiting for resolution for some regressions that people
> weren't able to work on last week, there's a new -rc kernel out there.
> Hopefully we'll get them all and I can do 2.6.21-final next weekend or
> so..
>
The patch to k8.c didn't make it in:
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 16:28:51 -0700
>
> > Sorry, but let's be realistic, this type of warning would have
> > *NEVER* been addressed if we kept the status quo
>
> Wrong. I watch the logs all the time and
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote:
> On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
>
> > I also like Andi's idea of using change_page_attr() to isolate the
> > problem. I'll try to send you a debug patch in the next few days to try
> > that out. Thanks.
>
>
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 16:28:51 -0700
> Sorry, but let's be realistic, this type of warning would have
> *NEVER* been addressed if we kept the status quo
Wrong. I watch the logs all the time and would have sent you a fix to
use the Sparc firmware info as
Zach Carter wrote:
>
> Dave Jones wrote:
>> On Sun, Apr 15, 2007 at 08:30:27PM -0700, Zach Carter wrote:
>> > list_del corruption. prev->next should be c21a4628, but was e21a4628
>>
>> 'c' became 'e' in that last address. A single bit flipped.
>> Given you've had this for some time, this smells
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 15:25:17 -0700
>
> > Fine, I'll agree that wacking-users (and
> > I'll wager the outliers) with a 2x4 was a bit extreme,
>
> And that, right there, is basically the end of the
On Monday April 16, [EMAIL PROTECTED] wrote:
>
> The challenge is making it be stable across inserts/deletes, never
> mind reboots. And it's not a "little bit of cacheing"; in order to be
> correct we would have to cache *forever*, since at least in theory an
> NFS client could hold on to a
Greetings all
Here is the current release of the Staircase cpu scheduler (the original
generation I design that spurned development elsewhere for RSDL), for
2.6.21-rc7
http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/sched-staircase-17.1.patch
To remind people
On Tue, 17 Apr 2007 00:39:10 +0200 Tilman Schmidt wrote:
> Am 15.04.2007 22:55 schrieb Robert P. J. Day:
> > as i recall, the isdn4linux was *un*obsoleted, wasn't it?
>
> Actually, it wasn't.
>
> We *did* reach a consensus that isdn4linux is not obsolete in the
> accepted sense of the word,
On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
Note that I talk of run queues
not CPUs as I think a shift to multiple CPUs per run queue may be a good
idea.
This observation of Peter's is the best thing to come out of this
whole foofaraw. Looking at what's happening in CPU-land, I
On Tue, 2007-04-17 at 00:21 +0200, Miguel Ojeda wrote:
> "Trivial patch, against -rc6. I don't know if anyone has fixed this by now."
>
I'll pick this up.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Andi Kleen wrote:
> Hmm, are you sure? Can you double check? With the latest tree?
>
> I could reproduce the problem and my change fixed the problem for me.
>
Hm. Me too. I just booted 2.6.21-rc7-ff-paravirt, and it seems fine.
J
-
To unsubscribe from this list: send the line
Brad Campbell wrote:
> Brad Campbell wrote:
>> G'day all,
>>
>> All I have is a digital photo of this oops. (It's 3.5mb). I have
>> serial console configured, but Murphy is watching me carefully and I
>> just can't seem to reproduce it while logging the console output.
>>
>
> And as usual, after
Am 15.04.2007 22:55 schrieb Robert P. J. Day:
> as i recall, the isdn4linux was *un*obsoleted, wasn't it?
Actually, it wasn't.
We *did* reach a consensus that isdn4linux is not obsolete in the
accepted sense of the word, because there is no replacement for it
so far.
OTOH I have since
On Mon, Apr 16, 2007 at 01:07:05PM +1000, David Chinner wrote:
> On Sun, Apr 15, 2007 at 08:50:25PM -0400, Rik van Riel wrote:
>
> > IMHO chunkfs could provide a much more promising approach.
>
> Agreed, that's one method of compartmentalising the problem.
Agreed, the chunkfs design is only
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 15:25:17 -0700
> Fine, I'll agree that wacking-users (and
> I'll wager the outliers) with a 2x4 was a bit extreme,
And that, right there, is basically the end of the conversation.
You don't do this to users, ever.
Put a big loud
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
> It seems that Asus exposes monitorining data using "ATK0110" (enumerated
> in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
> (they have different methods though). Another motherboard with the same
> device may
On Mon, 16 Apr 2007, David Miller wrote:
> From: Andrew Vasquez <[EMAIL PROTECTED]>
> Date: Mon, 16 Apr 2007 14:10:49 -0700
>
> > Ok, how about the following patch based on the one you posted which
> > adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
> > also adds the
Jan Engelhardt wrote:
> On Apr 15 2007 12:53, Henrique de Moraes Holschuh wrote:
>> On Sat, 14 Apr 2007, Pavel Machek wrote:
>>> How common are notebooks that cut power to disks during reboot?
>> Assuming it also does this when running Windows, I'd report it as a grave
>> bug to the vendor and
"Trivial patch, against -rc6. I don't know if anyone has fixed this by now."
Resend comment: Still present in -rc7.
---
drivers/video/Kconfig:
- Spelling: "Frambuffer hardware support"
drivers/video/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Miguel Ojeda
Ah, just found this original thread, now Cornelia's patches make more
sense...
On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan Stern wrote:
> Tejun, it just occurred to me that you would be interested in this email
> thread. Just to bring you up to speed, here's the original question:
>
> >
* Tony Lindgren <[EMAIL PROTECTED]> [070409 21:34]:
> From: Kai Svahn <[EMAIL PROTECTED]>
>
> This patch merges board specific files from N800 tree.
> Nokia has published the files at:
>
> http://repository.maemo.org/pool/maemo3.0/free/source/
> kernel-source-rx-34_2.6.18.orig.tar.gz
>
David Rientjes wrote:
Sure, but what I really like about the patch is that we're only flushing
something if !flush_end in the first place. So we can eliminate any TLB
flushing if that VMA didn't need it; that's a change from the current
behavior. And since the most obvious use-case for
Am Montag, den 16.04.2007, 12:25 -0400 schrieb Michael Krufky:
> CIJOML wrote:
> > Dne pondělí 16 duben 2007 17:34 Michael Krufky napsal(a):
> >
> >> Adrian Bunk wrote:
> >>
> >>> On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote:
> >>>
> Mauro,
>
> I've
17 Nis 2007 Sal tarihinde, Ingo Molnar şunları yazmıştı:
> - fixed child-runs first. A /proc/sys/kernel/sched_child_runs_first
>flag can be used to turn it on/off. (This might fix the Kaffeine bug
>reported by S.Çağlar Onur <)
Sorry for delayed response but i just find some free time,
From: Sebastian Kuzminsky <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 15:45:19 -0600
> I'm seeing some weird behavior in TCP. The issue is perfectly
> reproducible using netcat and other programs. This is what I do:
Please send your bug report again, but this time to the
[EMAIL PROTECTED]
On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote:
> > don't actually have to care --- if loading an invalid profile can bring
> > down
> > the system, then that's no worse than an arbitrary module that crashes the
> > machine. Not sure if there will ever be user loadable profiles; at
From: Andrew Vasquez <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 14:10:49 -0700
> Ok, how about the following patch based on the one you posted which
> adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and
> also adds the module-parameter override I mentioned above.
>
> Perhaps the
this is the second release of the CFS (Completely Fair Scheduler)
patchset, against v2.6.21-rc7:
http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
i'd like to thank everyone for the tremendous amount of feedback and
testing the v1 patch got - i could hardly keep up with just
Hugh Dickins wrote:
You're right to want to defer your pte_updates, David is right to want
to batch his TLB flushes. It bothers me that you have a surprising case,
and that unless you abandon your optimization, it imposes a new constraint
on how to proceed in common code (without #ifdef'ing
* Tony Lindgren <[EMAIL PROTECTED]> [070409 21:23]:
> From: Hiroshi DOYU <[EMAIL PROTECTED]>
>
> This patch adds a generic mailbox interface for for DSP and IVA
> (Image Video Accelerator). This patch itself doesn't contain
> any IVA driver.
Here's an updated version that merges in two later
> don't actually have to care --- if loading an invalid profile can bring down
> the system, then that's no worse than an arbitrary module that crashes the
> machine. Not sure if there will ever be user loadable profiles; at least at
> that point we had to care.
CAP_SYS_RAWIO is needed to do
> > That is a fairly significant and sudden change to the existing
> > kernel/user interface.
>
> Well, this is not meant for 2.6.21. I hope it is possible to change it in
> early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty
> doomed.
I don't believe the existing
On Mon, 16 Apr 2007, Dmitry Torokhov wrote:
> Hi Mauro,
>
> On 4/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > - Fix Kernel Bugzilla #8301: spinlock fix for flexcop-pci
>
> While move of spin_lock_init before request_irq is obviously correct I
> wonder what is the reason behind
Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> Subject: snd_intel8x0: divide error:
> References : http://lkml.org/lkml/2007/3/5/252
> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> Status : unknown
>
Oops is in
On Tue, Apr 17, 2007 at 12:28:31AM +0300, Mikko Tiihonen wrote:
> I actually was more worried that someone might complain that the pci
> scanning is copy & paste code from end of the same file. I did try to use
> the generic pci functions first but because they insist on enabling
> interrupts
On Thu, Apr 12, 2007 at 11:21:01AM +0100, Alan Cox wrote:
> > +
> > + /**
> > +* parent can ptrace child when
> > +* - parent is unconfined
> > +* - parent is in complain mode
> > +* - parent and child are confined by the same profile
> > +*/
>
> Your profiles are name
On Tue, Apr 17, 2007 at 01:08:29AM +0400, Anton Vorontsov wrote:
> On Mon, Apr 16, 2007 at 09:24:21PM +0100, Russell King wrote:
> > Utterly unsafe. What happens if some other module gets loaded which
> > does this, and then this module is unloaded followed by the other
> > module. Result: Oops.
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
> On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
>> +static void (*old_apm_get_power_status)(struct apm_power_info*);
>> +
>> +static int __init apm_battery_init(void)
>> +{
>> + printk(KERN_INFO "APM Battery
Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.
Use of Pathnames For Access Control
---
Some people in the security field believe that pathnames are an
inappropriate security mechanism. This depends on
On 4/16/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
On Mon, Apr 16, 2007 at 12:14:27PM -0700, Matt Reimer wrote:
> The shifts (<< 3 and >> 5) are just to get the bits reassembled in the
> right positions. The multiplication by 5 and subtracting 1/8 is
> because (AFAIK) we can't do floating
On Mon, 16 Apr 2007, Andi Kleen wrote:
Mikko Tiihonen <[EMAIL PROTECTED]> writes:
It looks probable that most NVidia chipsets have the HPET address at
0x44. It might be possible to enable the HPET even if BIOS did not
That seems like a dangerous assumption. If anything this needs to be
1 - 100 of 698 matches
Mail list logo