On Tue, 13 Mar 2007, Steven Rostedt wrote:
>
> Move kernel/acpi/processor.c to the common hold.
Please use
git diff -M
for things like this.
In fact, even if you weren't a git user, I'd ask you to *become* one just
because I think that it's a *lot* more productive if people actually
Matt Mackall wrote:
> Well you -could- do this:
>
> - reuse a long in struct page as a used map that divides the page up
> into 32 or 64 segments
> - every time you set a PTE, set the corresponding bit in the mask
> - when we zap, only visit the regions set in the mask
>
> Thus, you avoid
On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary
> constant and it should be clear that its value is chosen in net/scm.h
> and not actually derived
On Tue, Mar 13, 2007 at 02:07:22PM -0700, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 13 Mar 2007 15:21:25 -0500
>
> > Because the fan-out is large, the bulk of the work is bringing the last
> > layer of the tree into cache to find all the pages in the address
> >
On Tue, 2007-03-13 at 13:32 -0700, Jeremy Fitzhardinge wrote:
> Most of the existing clocksource infrastructure would only operate on
> CLOCK_TIMEBASE_REALTIME clocksources, so I'm not sure how much overlap
> there would be here. In the case of dealing with cpufreq, there's a
> certain appeal to
Hi1
> I've chased one of the 'Suspend to RAM' resume problems to a specific
> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
Has suspend/resume ever worked on that hardware?
> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
> = val', which appears to be
On Tue, 13 Mar 2007, Hugh Dickins wrote:
> On Tue, 13 Mar 2007, Alan Stern wrote:
> >
> > On the other hand, a quick survey of the kernel source shows that
> > DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job
> > for the faint-of-heart!
>
> Indeed, and faint-hearted Hugh
On Tue, 13 Mar 2007, Cornelia Huck wrote:
>
> Another call that deadlocked with Oliver's patch is ungroup for s390
> ccwgroup devices. It can be made to work again with a similar patch.
Could we please make this easier to use by having some common sysfs helper
routine for this kind of
* JanuGerman ([EMAIL PROTECTED]) wrote:
> My question is that whether root_plug.c security
> module is stacked with the SELinux security module or
> not. If root_plug.c is stacked, where i can find the
> code which handles the stacking of SELinux and
> root_plug.c within the kernel.
Look at
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 13 Mar 2007 15:21:25 -0500
> Because the fan-out is large, the bulk of the work is bringing the last
> layer of the tree into cache to find all the pages in the address
> space. And there's really no way around that.
That's right.
And I will
On 3/13/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
On Tue, 13 Mar 2007, Alan Stern wrote:
>
> On the other hand, a quick survey of the kernel source shows that
> DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job
> for the faint-of-heart!
Indeed, and faint-hearted Hugh
Pavel,
I've chased one of the 'Suspend to RAM' resume problems to a specific
line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
= val', which appears to be causing the problem. I've verified that the
pointer is not
On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > I think, it should be possible to spread this max expiration latency
> > > across the rotation, should it not?
> >
> > Can you try
Andi Kleen wrote:
> It depends -- under heavy network load you can spend a long time
> just processing interrupts.
Well, in that case you probably don't want to charge them to the process
which happens to be running at the time.
J
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, Mar 13, 2007 at 12:37:53PM -0400, Rik van Riel wrote:
> Andi Kleen wrote:
> >On Tue, Mar 13, 2007 at 09:07:09AM -0700, Chris Wright wrote:
> >>* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> >>>In other words, regardless of whether this particular pv_op lives or
> >>>dies, we're going
Tejun Heo a écrit :
> Can you apply the attached patch and report what the kernel says with
> ACPI turned on?
>
>
Hi,
I got this:
[ 13.523816] SCSI subsystem initialized
[ 13.528914] ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level,
low) -> IRQ 19
[ 14.529383] ahci :00:1f.2: AHCI
On Tue, 13 Mar 2007, Alan Stern wrote:
>
> On the other hand, a quick survey of the kernel source shows that
> DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job
> for the faint-of-heart!
Indeed, and faint-hearted Hugh wasn't intending to do so: but
stout-hearted Alan will
On Tue, Mar 13, 2007 at 10:31:27AM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
> >
> >> GCC (4.1 at least) unrolls it anyway, but I can't believe this code
> >>
> >
> > Are you sure? Normally it doesn't unroll
Hi Stephen,
On Mon, Mar 12, 2007 at 02:11:56PM -0700, Stephen Hemminger wrote:
> > Oh BTW, I have a newer version with a first approximation of the
> > cbrt() before the div64_64, which allows us to reduce from 3 div64
> > to only 2 div64. This results in a version which is twice as fast
> > as
Rusty Russell wrote:
> Hi all,
>
> The GDT stuff on x86 is a little more complex than it need be, but
> playing with boot code is always dangerous. These compile and boot on
> UP and SMP for me, but Andrew should let the cook in -mm for a while.
>
Hi Rusty,
This is my rough hacking
On Fri, 9 Mar 2007, Martin Drab wrote:
> On Fri, 9 Mar 2007, Martin Drab wrote:
> > On Thu, 8 Mar 2007, Martin Drab wrote:
> > > On Thu, 8 Mar 2007, Carsten Otte wrote:
> > > > On 3/8/07, Martin Drab <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > The thing is that I'd like to prevent kernel to
On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a
On Tue, Mar 13, 2007 at 01:17:00PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
> >
> >> Nick Piggin wrote:
> >>
> >>> However we still have to visit those to-be-unmapped parts of the page
> >>> table,
>
On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well. The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do
On Wed, Mar 14, 2007 at 07:21:41AM +1100, Kandan Venkataraman wrote:
> All comments have been taken care of.
>
> Description:
>
> A file_operations structure variable called loop_fops is initialised with
> the default block device file operations (def_blk_fops).
> The mmap operation is
john stultz wrote:
> My gut reaction would be to avoid using clocksources for now. While
> there is some thought going into how to expand clocksources for other
> uses (Daniel is working on this, for example), the design for
> clocksources has been very focused on its utility to timekeeping, so
On Wednesday 14 March 2007 06:54, Al Boldi wrote:
> Con Kolivas wrote:
> > On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> > > On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > > > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > > > I think, it should be possible to spread this
On Tue, 2007-03-13 at 19:09 +, Alan Cox wrote:
> > stuff is happening by comparing page->count and page->_mapcount, but it
> > certainly wouldn't be conclusive. But, does this kind of nonsense even
> > happen in practice?
>
> "Is it useful for me as a bad guy to make it happen ?"
A very
Pavel Machek wrote:
>
> That's okay, but if one of those savages got major for you, would you
> be willing to use it? :-).
Indeed I would.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
On Wednesday 14 March 2007 05:21, Mark Lord wrote:
> Con Kolivas wrote:
> > Can you try the new version of RSDL. Assuming it doesn't oops on you it
> > has some accounting bugfixes which may have been biting you.
>
> Retesting today with 2.6.21-rc3-git7 + 2.6.21-rc3-sched-rsdl-0.30.patch.
>
>
On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure. We can't expect users to finesse all
> >
On Tue, 2007-03-13 at 16:02 -0400, Chuck Ebbert wrote:
> > struct itimerval tim = {
> > .it_interval = {
> > .tv_sec = 140735669863712,
> > .tv_usec = 4199521
> > },
> Could this be fixed by:
>
>
All comments have been taken care of.
Description:
A file_operations structure variable called loop_fops is initialised with
the default block device file operations (def_blk_fops).
The mmap operation is overriden with a new function called loop_file_mmap.
A vm_operations structure variable
On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
> Nick Piggin wrote:
> > However we still have to visit those to-be-unmapped parts of the page
> > table,
> > to find the pages and free them. So we still at least need to bring it
> > into
> > cache for the read... at which
Matt Mackall wrote:
> On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> However we still have to visit those to-be-unmapped parts of the page
>>> table,
>>> to find the pages and free them. So we still at least need to bring it
>>> into
>>>
Christoph Hellwig wrote:
It's not obvious, but utter bullshit. Please go away if you think
starting post with quotes from CGL specs is even remotely close to
a good idea.
I don't know about CGL, but a unified async notification mechanism _is_
needed. In ~2002, I needed one, and what I
David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>
>
> I agree. Tasks that voluntarily relinquish their timeslices should get
On Tue, 2007-03-13 at 09:31 -0700, Jeremy Fitzhardinge wrote:
> The current Linux scheduler makes one big assumption: that 1ms of CPU
> time is the same as any other 1ms of CPU time, and that therefore a
> process makes the same amount of progress regardless of which particular
> ms of time it
On 3/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Subject: libata: PATA UDMA/100 configured as UDMA/33
> References : http://lkml.org/lkml/2007/2/20/294
>
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
>
On Tue, 13 Mar 2007, Hugh Dickins wrote:
> On Tue, 13 Mar 2007, Alan Stern wrote:
> >
> > The consensus is that we would be better off keeping Oliver's original
> > patch without your silly change, and instead fixing the particular method
> > call that deadlocked. Can you please try out the
Greg KH <[EMAIL PROTECTED]> writes:
> I do not think this should be reverted, as the odds that some one will
> rename their network device to be "irq" or something else that is in the
> pci device's directory is pretty slim. It also only shows up if
> CONFIG_SYSFS_DEPRECATED is disabled, not the
Hi!
> > Uhuh. User error, lets close the report.
> >
> > mmc changed the major to
> >
> > 236 mmc
> >
> > ... while it was something else in 2.6.20. Can we get stable device
> > allocation for mmc?
>
> What kind of savages do not use udev these days?! ;)
>
> I don't have the time and energy
On 3/13/07, Chris Friesen <[EMAIL PROTECTED]> wrote:
Lee Revell wrote:
> Sounds like Wengophone is broken. It should be using RT threads for
> time critical work, as JACK and Ardour2 are doing.
If the app has root privileges to set RT policy, then it could also set
deeply negative nice values
> > -#define SCM_MAX_FD (OPEN_MAX-1)
> > +#define SCM_MAX_FD (NR_OPEN-1)
>
> This is a bad idea. [...]
Ok. My only agenda is to get rid of OPEN_MAX.
I then propose the following instead.
Thanks,
Roland
---
[PATCH] avoid OPEN_MAX in SCM_MAX_FD
The OPEN_MAX constant is an arbitrary number
Johannes Bauer wrote:
> Dear Community,
>
> I think I've encountered a bug with the Linux kernel which results in a
> complete system lockup and which can be started without root priviliges.
> It's reproducible with 2.6.20.1 and 2.6.20.2 and only x64_64 seems
> affected.
>
> Here's the code
> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other
On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote:
> Subject: hrtimer_switch_to_hres():
> wrong tick_init_highres() return value handling
> References : http://lkml.org/lkml/2007/3/6/262
> Submitter : Linus Torvalds <[EMAIL PROTECTED]>
> Caused-By : Thomas Gleixner <[EMAIL
Con Kolivas wrote:
> On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> > On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > > I think, it should be possible to spread this max expiration latency
> > > > across the rotation, should
On Tue, 13 Mar 2007, Greg KH wrote:
>
> > - pci_save_state, pci_restore_state are broken and have been for a
> > while if used on anything besides plain pci (pci-x, pci-e and msi)
> > and are not used in pairs. (gregkh and Andrew have the patches to
> > correct this).
>
> I think these
On Tue, Mar 13, 2007 at 01:26:48PM -0600, Eric W. Biederman wrote:
> - We have a network ABI regression caused by the latest sysfs
> changes to net-sysfs.c In particular we now cannot rename network
> devices if our destination name happens to be the name of a sysfs file that
> the network
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> If I can manage to focus on this, it looks like the information I need to
>> start fixing this.
>
> I had a look at the second leak reported it seems to be caused by the
> same
Here is a quick summary of the regressions I am looking at.
- Currently we appear to have a pid leak in tty_io.c
http://lkml.org/lkml/2007/3/8/222
- There is a missing init_WORK in vt.c that cases oops
when we attempt to use SAK.
http://lkml.org/lkml/2007/3/11/148
- We have a network ABI
Hello,
I found this thread : http://lkml.org/lkml/fancy/2004/8/28/229
It was about a driver for a serial pci card.
Can anyone bring me the SYBAMIO.EXE file.
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Johannes Bauer <[EMAIL PROTECTED]> writes:
> Dear Community,
>
> I think I've encountered a bug with the Linux kernel which results in a
> complete system lockup and which can be started without root
> priviliges. It's reproducible with 2.6.20.1 and 2.6.20.2 and only x64_64
> seems affected.
I
On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote:
> I had a look at copy_one_pte().
> I cannot see any ioproc_update_page() call, not even for the COW pages.
> Is it intentional?
There is no such thing as ioproc_update_page in any mainline tree.
You must be looking at some vendor
I had a look at copy_one_pte().
I cannot see any ioproc_update_page() call, not even for the COW pages.
Is it intentional?
We can live with a COW page for a considerably long time.
How could the IO-PROC. know that a process-ID / user virt. addr. pair
refers to the same page?
The comment above
On Tue, Mar 13, 2007 at 08:07:35PM +0100, Pierre Ossman wrote:
>...
> What kind of savages do not use udev these days?! ;)
>...
Those whose Linux installation predates the devfs hype
and postdates the devfs hype
and predates the udev hype
and will postdate the udev hype
and predates the next hype
On Tuesday 13 March 2007, Pierre Ossman wrote:
> Pavel Machek wrote:
> >
> > Uhuh. User error, lets close the report.
> >
> > mmc changed the major to
> >
> > 236 mmc
> >
> > ... while it was something else in 2.6.20. Can we get stable device
> > allocation for mmc?
>
> What kind of savages
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Can you please select a different mailinglist for your trolling?
-
To unsubscribe from this
Pavel Machek wrote:
>
> Uhuh. User error, lets close the report.
>
> mmc changed the major to
>
> 236 mmc
>
> ... while it was something else in 2.6.20. Can we get stable device
> allocation for mmc?
What kind of savages do not use udev these days?! ;)
I don't have the time and energy to
please cut your cc lines next time, thanks.
On Tue, Mar 13, 2007 at 08:03:44PM +0100, Johann Borck wrote:
> if the next section seems obvious, please skip it
> -
> There is a need for a generic event handling mechanism in
if the next section seems obvious, please skip it
-
There is a need for a generic event handling mechanism in Linux - maybe
it is enough to cite the current CGL Performance Requirements Definition
Version 4.0 at
On Tue, 13 Mar 2007, Alan Stern wrote:
>
> The consensus is that we would be better off keeping Oliver's original
> patch without your silly change, and instead fixing the particular method
> call that deadlocked. Can you please try out the patch below with
> everything else as it was before?
Dear Community,
I think I've encountered a bug with the Linux kernel which results in a
complete system lockup and which can be started without root priviliges.
It's reproducible with 2.6.20.1 and 2.6.20.2 and only x64_64 seems affected.
Here's the code which triggers the bug (originally
On Tue, 13 Mar 2007, Roland McGrath wrote:
> > At that moment D, running on CPU 1, decides to unregister a breakpoint in
> > T. Clearing TIF_DEBUG now doesn't do any good -- it's too late; CPU 0 has
> > already tested it. CPU 1 goes in and alters the user breakpoint data,
> > maybe even
On Tue, Mar 13, 2007 at 12:23:06PM -0400, Mark Lord wrote:
> That's nice.
>
> But the P5B-VM board does not have any such jumper for USB,
> nor does it have any obvious combination of BIOS-setup options
> to accomplish it.
Well it could only be done by hardware. The P5B has those jumpers. I
On Tue 13-03-07 14:43:47, Ashif Harji wrote:
>
> >>I would like to submit a patch to fix the performance problem. The
> >>simplest solution is to remove the check. Even in the situation where an
> >>application does not read in PAGE_SIZE multiples as described above, if
> >>the page is accessed
Alexey Dobriyan wrote:
[...]
What happens is that module_get_kallsym() drops module_mutex,
returns "struct module *", module unloaded, "struct module *"
used.
The only use for the "struct module *" is to display the name of the
module.
This can be solved by adding a "char
I would like to submit a patch to fix the performance problem. The
simplest solution is to remove the check. Even in the situation where an
application does not read in PAGE_SIZE multiples as described above, if
the page is accessed frequently it should remain in the cache. However, I
am
On Tue, 13 Mar 2007 11:00:21 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> The consensus is that we would be better off keeping Oliver's original
> patch without your silly change, and instead fixing the particular method
> call that deadlocked.
Another call that deadlocked with
On Tuesday 13 March 2007, Gene Heskett wrote:
>Greetings;
>Someone suggested a fresh thread for this.
>
>I now have my scripts more or less under control, and I can report that
>kernel-2.6.20.1 with no other patches does not exhibit the undesirable
>behaviour where tar thinks its all new, even
We (the -stable team) are announcing the release of the 2.6.20.3 kernel.
It contains a number of bugfixes and all 2.6.20 users are recommended to
upgrade.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.20.2 and
diff --git a/Makefile b/Makefile
index d165e80..7d2f304 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .2
+EXTRAVERSION = .3
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/arch/sparc/kernel/of_device.c
Hi Takashi,
On 07/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
At Mon, 05 Mar 2007 19:07:50 +0100,
Michal Piotrowski wrote:
>
> Hi,
>
> I hit this bug on crashdump kernel
>
> [ 8450.127374] divide error: [#1]
> [ 8450.130876] PREEMPT
> [ 8450.133098] Modules linked in: snd_intel8x0
Con Kolivas wrote:
Can you try the new version of RSDL. Assuming it doesn't oops on you it has
some accounting bugfixes which may have been biting you.
Retesting today with 2.6.21-rc3-git7 + 2.6.21-rc3-sched-rsdl-0.30.patch.
Still not pleasant to use the GUI with a kernel build (-j1 or -j2)
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
[where xfs could be any module, I haven't tried]
BUG: unable to handle kernel paging request at virtual address e19f808c
printing eip:
> stuff is happening by comparing page->count and page->_mapcount, but it
> certainly wouldn't be conclusive. But, does this kind of nonsense even
> happen in practice?
"Is it useful for me as a bad guy to make it happen ?"
Alan
-
To unsubscribe from this list: send the line "unsubscribe
Hi!
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way
Hi!
> >Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> >>Subject: ThinkPad X60: bluetooth hardlocks
> >>References : http://lkml.org/lkml/2007/3/2/85
> >>Submitter : Pavel Machek <[EMAIL PROTECTED]>
> >>Handled-By : Marcel Holtmann <[EMAIL PROTECTED]>
> >>Status : unknown
> >
> >Does this
Hi!
> > > Subject: mmc card reader no longer works
> > > References : http://lkml.org/lkml/2007/2/27/91
> > > Submitter : Pavel Machek <[EMAIL PROTECTED]>
> > > Handled-By : Oliver Neukum <[EMAIL PROTECTED]>
> > > Status : unknown
> > >
> >
> > First I heard of this. The error report
David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that.
Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in
Randy.Dunlap [EMAIL PROTECTED] wrote:
| On Mon, 12 Mar 2007 [EMAIL PROTECTED] wrote:
|
| Please do a complete job on the 'for' line by eliminating the
| space before each semi-colon.
|
| --
| ~Randy
Ok. Here is the updated patch. The Patch 2/2 in this set should
still apply cleanly on top of
On Tue, 13 Mar 2007, Andrew Morton wrote:
>
> (The ARM thing is a pain, because the compiler cannot check that the
> definition and declaration match. However something like sparse could do
> so).
Well, I guess sparse could do it, but the fact is, this is just a gcc bug.
It would be much
On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
> what about identifying different resource categories and
> handling them according to the typical usage pattern?
>
> like the following:
>
> - cpu and scheduler related accounting/limits
> - memory related accounting/limits
> -
Lee Revell wrote:
Sounds like Wengophone is broken. It should be using RT threads for
time critical work, as JACK and Ardour2 are doing.
If the app has root privileges to set RT policy, then it could also set
deeply negative nice values as well.
Doesn't reallly help the regular user with
Florian Fainelli wrote:
> Hi Marc,
>
> Your patch does not seem to use the Linux LED API (include/linux/leds.h),
> which is sometimes pretty unknown, but dramatically ease your work.
> Maybe it
> is a good idea converting it to this API if you find it relevant.
Hi Florian,
Thanks for
Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
>
>> GCC (4.1 at least) unrolls it anyway, but I can't believe this code
>>
>
> Are you sure? Normally it doesn't unroll without -funroll-loops which
> the kernel does normally not set. Especially not with
Andrew Morton wrote:
> Correctly matching the section annotation on declarations and definitions
> is needed by at least ARM. We should ensure that we do this on all future
> patches and we should also apply this patch if only for this reason.
>
> (The ARM thing is a pain, because the compiler
Nick Piggin wrote:
> However we still have to visit those to-be-unmapped parts of the page
> table,
> to find the pages and free them. So we still at least need to bring it
> into
> cache for the read... at which point, the store probably isn't a big
> burden.
Why not try to find a place to stash
On Mon, 2007-03-12 at 22:04 -0800, Andrew Morton wrote:
> So these mmapped pages will contiue to be shared across all guests. The
> problem boils down to "which guest(s) get charged for each shared page".
>
> A simple and obvious and easy-to-implement answer is "the guest which paged
> it in".
* Masami Hiramatsu ([EMAIL PROTECTED]) wrote:
> Hi Mathieu,
>
> Mathieu Desnoyers wrote:
> > Hi Masami,
> >
> > I recently had to add support for inline code patching on i386 to my
> > marker infrastructure. Clearly, it looks like what is done in djprobes,
> > with the main difference that I
On Mon, 12 Mar 2007 20:06:43 BST, Xavier Bestel said:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your
> > encoding with one cpu? Is that what other dedicated desktop OSs would do?
>
> One thought
Ugh. I missed this one, when I fixed this. Sorry I thought the loop in
con_init() covered all of the consoles and we initialized all of them
at boot time :(
Bernhard Walle <[EMAIL PROTECTED]> writes:
> This patch initialises the SAK member of the vc_cons variable on all virtual
> terminals,
Rusty Russell wrote:
> + pack_descriptor((u32 *)[GDT_ENTRY_PERCPU].a,
> + (u32 *)[GDT_ENTRY_PERCPU].b,
> + __per_cpu_offset[cpu], 0xF,
> 0x80 | DESCTYPE_S | 0x2, 0); /* present read-write data
> segment */
>
Why testing
On Mon, Mar 12, 2007 at 10:07:33AM -0400, Jeff Garzik wrote:
> Pekka Enberg wrote:
> >Hi,
> >
> >On 3/12/07, Valerie Henson <[EMAIL PROTECTED]> wrote:
> >>--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
> >>+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
> >>@@ -17,11 +17,11 @@
>
On Tue, 2007-03-13 at 03:48 -0800, Andrew Morton wrote:
> If we use a physical zone-based containment scheme: fake-numa,
> variable-sized zones, etc then it all becomes moot. You set up a container
> which has 1.5GB of physial memory then toss processes into it. As that
> process set increases
...
[ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x/3577
[ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd]
[ 1756.728392] 2 locks held by nfsd4/3577:
[ 1756.728435] #0: (client_mutex){--..}, at: [] mutex_lock+0x8/0xa
[ 1756.728679] #1: (>i_mutex){--..},
Andi Kleen wrote:
On Tue, Mar 13, 2007 at 09:07:09AM -0700, Chris Wright wrote:
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
In other words, regardless of whether this particular pv_op lives or
dies, we're going to need to have to deal with stolen time properly. I
think this hook is
Hello,
This question is relevent to 2.6.20.
I noticed that if the RSS for the stack size is say, 8MB, running
a single-threaded process doesn't incur an increase of 8MB to
Committed_AS (/proc/meminfo).
However, on multi-threaded apps linked with pthread (on Debian
Etch with 2.6.20 vanilla
101 - 200 of 802 matches
Mail list logo
