On 2008.02.25 15:08:35 -0500, Jeff Garzik wrote:
> Björn Steinbrink wrote:
>> Hm, do you have lockdep enabled? If not, does lockdep make this go away?
>> Because lockdep will set IRQF_DISABLED for all interrupt handlers, and
>> unless that flag is set, handle_IRQ_event wil
On 2008.02.07 00:58:42 +0100, Thomas Gleixner wrote:
> current mainline triggers:
>
> WARNING: at /home/tglx/work/kernel/x86/linux-2.6/arch/x86/mm/highmem_32.c:52
> kmap_atomic_prot+0xe5/0x19b()
> Modules linked in: ahci(+) sata_sil libata sd_mod scsi_mod raid1 ext3 jbd
> ehci_hcd ohci_hcd
On 2008.02.07 00:58:42 +0100, Thomas Gleixner wrote:
current mainline triggers:
WARNING: at /home/tglx/work/kernel/x86/linux-2.6/arch/x86/mm/highmem_32.c:52
kmap_atomic_prot+0xe5/0x19b()
Modules linked in: ahci(+) sata_sil libata sd_mod scsi_mod raid1 ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
On 2008.02.25 15:08:35 -0500, Jeff Garzik wrote:
Björn Steinbrink wrote:
Hm, do you have lockdep enabled? If not, does lockdep make this go away?
Because lockdep will set IRQF_DISABLED for all interrupt handlers, and
unless that flag is set, handle_IRQ_event will reenable interrupts while
On 2008.01.18 10:48:26 +0100, Jakob Oestergaard wrote:
> On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
> ...
> > Why do you make that mistake, when it is PROVABLY NOT TRUE!
> >
> > Try this trivial program:
> >
> > int main(int argc, char **argv)
> > {
> >
On 2008.01.18 10:48:26 +0100, Jakob Oestergaard wrote:
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
Why do you make that mistake, when it is PROVABLY NOT TRUE!
Try this trivial program:
int main(int argc, char **argv)
{
int i;
On 2008.01.09 23:41:42 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
> > On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
> >
> > > Do you have a simple recipe to just update from the the remote branch,
> > > assuming there are no local changes or
On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> > then you have a truly ancient x86.git repository ;-)
>
> I update only infrequently because frankly git's remote branch tracking
> is a mess. At least it doesn't really work for
On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
then you have a truly ancient x86.git repository ;-)
I update only infrequently because frankly git's remote branch tracking
is a mess. At least it doesn't really work for x86#mm
On 2008.01.09 23:41:42 +0100, Andi Kleen wrote:
On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
Do you have a simple recipe to just update from the the remote branch,
assuming there are no local changes or local
On 2008.01.04 23:26:33 +0100, Björn Steinbrink wrote:
> For cards that initially have the MAC address stored in reverse order,
> the forcedeth driver uses a flag to signal whether the address was
> already corrected, so that it is not reversed again on a subsequent
> probe.
>
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> I have this forcedeth MAC address reversal problem when suspending
> on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> problem on only one of them:
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
I have this forcedeth MAC address reversal problem when suspending
on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
problem on only one of them:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
On 2008.01.04 23:26:33 +0100, Björn Steinbrink wrote:
For cards that initially have the MAC address stored in reverse order,
the forcedeth driver uses a flag to signal whether the address was
already corrected, so that it is not reversed again on a subsequent
probe.
Unfortunately this flag
On 2008.01.05 07:10:02 +0100, Björn Steinbrink wrote:
> - nv_probe sees 00:11:22:00:00:01
> - doesn't match the vendor stuff
> - becomes 01:00:00:22:11:00
>
> Oops, that's not quite the expected thing.
Haha, I just noticed that that even is a multicast address, so you'd get
a ran
On 2008.01.04 23:43:52 +0100, Andreas Mohr wrote:
> On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
> > On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> > > And then it needs these card I/O functions wrapped into two
> > > functions which interface
to know what state the card is in.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
---
On 2008.01.04 15:08:42 +0100, Richard Jonsson wrote:
> Björn Steinbrink skrev:
>> Richard, could you give this a spin? And then we'd likely need someone
>> to test that with kexec...
&
On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
> Hi,
>
> On Fri, Jan 04, 2008 at 04:43:57AM +0100, Björn Steinbrink wrote:
> > On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> > > [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
> > >
> > >
On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
Hi,
On Fri, Jan 04, 2008 at 04:43:57AM +0100, Björn Steinbrink wrote:
On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
[ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr
On 2008.01.04 23:43:52 +0100, Andreas Mohr wrote:
On Fri, Jan 04, 2008 at 11:17:40AM +0100, Björn Steinbrink wrote:
On 2008.01.04 09:45:17 +0100, Andreas Mohr wrote:
And then it needs these card I/O functions wrapped into two
functions which interface with driver- and OS-related MAC
On 2008.01.05 07:10:02 +0100, Björn Steinbrink wrote:
- nv_probe sees 00:11:22:00:00:01
- doesn't match the vendor stuff
- becomes 01:00:00:22:11:00
Oops, that's not quite the expected thing.
Haha, I just noticed that that even is a multicast address, so you'd get
a random MAC address
On 2008.01.03 01:42:09 +0200, Adrian Bunk wrote:
> [ original bug report: http://lkml.org/lkml/2008/1/2/253 ]
>
> On Wed, Jan 02, 2008 at 10:48:43PM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> > > Bugreport regarding forcedeth
On 2007.12.29 11:18:18 -0800, Linus Torvalds wrote:
>
>
> On Sat, 29 Dec 2007, Arjan van de Ven wrote:
> >
> > It has been a quiet week due to the holidays, only 55 oops traces
> > have been collected.
>
> This would be more useful if it was more readable. As it is, you seem to
> have some
On 2007.12.29 11:18:18 -0800, Linus Torvalds wrote:
On Sat, 29 Dec 2007, Arjan van de Ven wrote:
It has been a quiet week due to the holidays, only 55 oops traces
have been collected.
This would be more useful if it was more readable. As it is, you seem to
have some formatting
the
accounting right again.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
Tested-by: Krzysztof Piotr Oledzki <[EMAIL PROTECTED]>
---
I'm not sure if it matters, but opposed to the final check in
__remove_from_page_cache, this one also cares about the task io
accounting, so m
the
accounting right again.
Signed-off-by: Björn Steinbrink [EMAIL PROTECTED]
Tested-by: Krzysztof Piotr Oledzki [EMAIL PROTECTED]
---
I'm not sure if it matters, but opposed to the final check in
__remove_from_page_cache, this one also cares about the task io
accounting, so maybe we want to use
inaccurate
accouting, so I'll just watch you and Jan battle that out until someone
comes up with a post-.24 patch to provide a clean fix for the issue.
Krzysztof, could you give this patch a test run?
If that "fixes" the problem for now, I'll try to come up with some
usable commit message
On 2007.12.19 09:44:50 -0800, Linus Torvalds wrote:
>
>
> On Sun, 16 Dec 2007, Krzysztof Oledzki wrote:
> >
> > I'll confirm this tomorrow but it seems that even switching to data=ordered
> > (AFAIK default o ext3) is indeed enough to cure this problem.
>
> Ok, do we actually have any ext3
On 2007.12.19 09:44:50 -0800, Linus Torvalds wrote:
On Sun, 16 Dec 2007, Krzysztof Oledzki wrote:
I'll confirm this tomorrow but it seems that even switching to data=ordered
(AFAIK default o ext3) is indeed enough to cure this problem.
Ok, do we actually have any ext3 expert
to it, you can
already have my
Signed-off-by: Björn Steinbrink [EMAIL PROTECTED]
On a side note, before 8368e328dfe1c534957051333a87b3210a12743b the task
io accounting for cancelled writes happened always happened if the page
was dirty, regardless of page-mapping. This was also already true
On 2007.12.08 17:16:24 -0500, Steven Rostedt wrote:
>
> Hi Linus,
>
> > On Fri, 7 Dec 2007, Linus Torvalds wrote:
> > >
> > > Can you do one run with oprofile, and see exactly where the cost is? It
> > > should hopefully be pretty darn obvious, considering your timing.
>
> The results are here:
On 2007.12.08 17:16:24 -0500, Steven Rostedt wrote:
Hi Linus,
On Fri, 7 Dec 2007, Linus Torvalds wrote:
Can you do one run with oprofile, and see exactly where the cost is? It
should hopefully be pretty darn obvious, considering your timing.
The results are here:
On 2007.12.07 13:53:11 +0300, Al Boldi wrote:
> Andreas Ericsson wrote:
> > So, to get to the bottom of this, which of the following workflows is it
> > you want git to support?
> >
> > ### WORKFLOW A ###
> > edit, edit, edit
> > edit, edit, edit
> > edit, edit, edit
> > Oops I made a mistake and
On 2007.12.07 13:53:11 +0300, Al Boldi wrote:
Andreas Ericsson wrote:
So, to get to the bottom of this, which of the following workflows is it
you want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back
On 2007.10.17 18:18:21 +0200, Björn Steinbrink wrote:
> On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
> >
> >
> > On Tue, 16 Oct 2007, Linus Torvalds wrote:
> > >
> > > I don't think you did anything wrong. You used both --full-history
> >
On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
>
>
> On Tue, 16 Oct 2007, Linus Torvalds wrote:
> >
> > I don't think you did anything wrong. You used both --full-history
> > (implicitly: git-whatchanged) and you made sure to see the diffs for both
> > sides of any merge (-m), and that
Hi Hans,
On 2007.10.17 12:41:11 +0200, Hans-Peter Jansen wrote:
> Dear Björn,
>
> Am Mittwoch, 17. Oktober 2007 02:53 schrieb Björn Steinbrink:
> > And then, if I may guess, James probably just noticed that there were
> > changes left and commited them (while they
On 2007.10.17 18:18:21 +0200, Björn Steinbrink wrote:
On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
On Tue, 16 Oct 2007, Linus Torvalds wrote:
I don't think you did anything wrong. You used both --full-history
(implicitly: git-whatchanged) and you made sure to see
Hi Hans,
On 2007.10.17 12:41:11 +0200, Hans-Peter Jansen wrote:
Dear Björn,
Am Mittwoch, 17. Oktober 2007 02:53 schrieb Björn Steinbrink:
And then, if I may guess, James probably just noticed that there were
changes left and commited them (while they were now down to just the
whitespace
On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
On Tue, 16 Oct 2007, Linus Torvalds wrote:
I don't think you did anything wrong. You used both --full-history
(implicitly: git-whatchanged) and you made sure to see the diffs for both
sides of any merge (-m), and that means that
On 2007.10.17 00:07:19 +0200, Hans-Peter Jansen wrote:
> Hi Jeff,
>
> while browsing through Linus' current check ins, I stumbled upon:
>
> [SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:
>
> --8<--
> 488a5c8a9a3b67ae117784cd0d73bef53a73d57d
> drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
On 2007.10.17 00:07:19 +0200, Hans-Peter Jansen wrote:
Hi Jeff,
while browsing through Linus' current check ins, I stumbled upon:
[SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:
--8--
488a5c8a9a3b67ae117784cd0d73bef53a73d57d
drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
1 files
On 2007.10.12 08:37:04 -0400, Robert P. J. Day wrote:
> On Fri, 12 Oct 2007, Björn Steinbrink wrote:
>
> > On 2007.10.12 08:04:20 -0400, Robert P. J. Day wrote:
> > >
> > > i can see what the theoretical purpose for it is here:
> > >
> > > http
On 2007.10.12 08:04:20 -0400, Robert P. J. Day wrote:
>
> i can see what the theoretical purpose for it is here:
>
> http://kerneltrap.org/node/6656
>
> but it's not clear how it can possibly be set from userland given
> that:
>
> $ grep -r TAINT_USER *
> include/linux/kernel.h:#define
On 2007.10.12 11:18:24 +0200, John Sigler wrote:
> Hello,
>
> I'm experiencing a full system lockup. I'm using an out-of-tree driver
> which I suspect is responsible. I'm trying to enable the NMI watchdog.
>
> # cat /proc/version
> Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue
On 2007.10.12 08:37:04 -0400, Robert P. J. Day wrote:
On Fri, 12 Oct 2007, Björn Steinbrink wrote:
On 2007.10.12 08:04:20 -0400, Robert P. J. Day wrote:
i can see what the theoretical purpose for it is here:
http://kerneltrap.org/node/6656
but it's not clear how it can
On 2007.10.12 11:18:24 +0200, John Sigler wrote:
Hello,
I'm experiencing a full system lockup. I'm using an out-of-tree driver
which I suspect is responsible. I'm trying to enable the NMI watchdog.
# cat /proc/version
Linux version 2.6.22.1-rt9 (gcc version 3.4.6) #1 PREEMPT RT Tue Oct 9
On 2007.10.12 08:04:20 -0400, Robert P. J. Day wrote:
i can see what the theoretical purpose for it is here:
http://kerneltrap.org/node/6656
but it's not clear how it can possibly be set from userland given
that:
$ grep -r TAINT_USER *
include/linux/kernel.h:#define TAINT_USER
On 2007.09.12 00:10:19 +0100, Adrian McMenamin wrote:
> On 12/09/2007, Björn Steinbrink <[EMAIL PROTECTED]> wrote:
> > On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
> > > On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
> > >
> > >> On 11/0
On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
> On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
>
>> On 11/09/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
>>> On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
>>>
OK, why does this line occasionally return true:
What exactly is
On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
On 11/09/2007, Rene Herman [EMAIL PROTECTED] wrote:
On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
OK, why does this line occasionally return true:
What exactly is occassionally? Does it
On 2007.09.12 00:10:19 +0100, Adrian McMenamin wrote:
On 12/09/2007, Björn Steinbrink [EMAIL PROTECTED] wrote:
On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
On 11/09/2007, Rene Herman [EMAIL PROTECTED] wrote:
On 09/12/2007 12:05 AM
On 2007.09.05 16:45:29 +0200, noah wrote:
> 2007/9/5, Björn Steinbrink <[EMAIL PROTECTED]>:
> > On 2007.09.05 16:04:13 +0200, noah wrote:
> > > 2007/9/5, Martin K. Petersen <[EMAIL PROTECTED]>:
> > > > >>>>> "Jan" == Jan En
On 2007.09.05 16:04:13 +0200, noah wrote:
> 2007/9/5, Martin K. Petersen <[EMAIL PROTECTED]>:
> > > "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
> >
> > Jan> 11:40 sun:../scsi_host/host0 # echo 1 >scan
> > Jan> -bash: echo: write error: Invalid argument
> >
> > Jan> What is the proper
On 2007.09.05 16:04:13 +0200, noah wrote:
2007/9/5, Martin K. Petersen [EMAIL PROTECTED]:
Jan == Jan Engelhardt [EMAIL PROTECTED] writes:
Jan 11:40 sun:../scsi_host/host0 # echo 1 scan
Jan -bash: echo: write error: Invalid argument
Jan What is the proper way to trigger a rescan, if
On 2007.09.05 16:45:29 +0200, noah wrote:
2007/9/5, Björn Steinbrink [EMAIL PROTECTED]:
On 2007.09.05 16:04:13 +0200, noah wrote:
2007/9/5, Martin K. Petersen [EMAIL PROTECTED]:
Jan == Jan Engelhardt [EMAIL PROTECTED] writes:
Jan 11:40 sun:../scsi_host/host0 # echo 1 scan
On 2007.09.02 02:36:18 +0200, Oleg Verych wrote:
> * Tue, 31 Jul 2007 23:40:11 +0200
> >
> []
> > eventhough people often write only when they have something to complain
> > about, I for once would like to congratulate Matti and David, our mail
> > admins, for the wonderful job they've done with
On 2007.09.02 02:36:18 +0200, Oleg Verych wrote:
* Tue, 31 Jul 2007 23:40:11 +0200
[]
eventhough people often write only when they have something to complain
about, I for once would like to congratulate Matti and David, our mail
admins, for the wonderful job they've done with the spams
On 2007.08.31 17:24:46 -0700, Daniel Walker wrote:
> On Fri, 2007-08-31 at 20:06 +0200, Björn Steinbrink wrote:
>
>
> > > something to do with the nmi hertz adjustment that happens after
> > > check_nmi_watchdog() ..
> >
> > Hm hm, does the same th
On 2007.08.31 09:35:23 -0700, Daniel Walker wrote:
> On Fri, 2007-08-31 at 09:21 -0700, Stephane Eranian wrote:
> > In this patch, the setup_*() routine now extract the MSR from the wd_ops
> > to copy them into the nmi_watchdog_ctlblk. This is not done for P4 because
> > of the special and ugly
On 2007.08.31 09:35:23 -0700, Daniel Walker wrote:
On Fri, 2007-08-31 at 09:21 -0700, Stephane Eranian wrote:
In this patch, the setup_*() routine now extract the MSR from the wd_ops
to copy them into the nmi_watchdog_ctlblk. This is not done for P4 because
of the special and ugly case of
On 2007.08.31 17:24:46 -0700, Daniel Walker wrote:
On Fri, 2007-08-31 at 20:06 +0200, Björn Steinbrink wrote:
something to do with the nmi hertz adjustment that happens after
check_nmi_watchdog() ..
Hm hm, does the same thing (watchdog stuck after check) happen with
older kernels
On 2007.08.29 10:49:12 -0700, Christoph Lameter wrote:
> On Wed, 29 Aug 2007, Peter Lund wrote:
>
> >
> > - if (tmp >= RADIX_TREE_INDEX_BITS)
> > - index = ~0UL;
> > - return index;
> > + if (shift < 0)
> > + return ~0UL;
> > + if (shift >= 8 * sizeof(unsigned long))
On 2007.08.29 10:49:12 -0700, Christoph Lameter wrote:
On Wed, 29 Aug 2007, Peter Lund wrote:
- if (tmp = RADIX_TREE_INDEX_BITS)
- index = ~0UL;
- return index;
+ if (shift 0)
+ return ~0UL;
+ if (shift = 8 * sizeof(unsigned long))
8*
On 2007.08.07 17:06:49 -0700, Daniel Walker wrote:
>
> This patch below hangs my system on boot if I set nmi_watchdog=2 . It
> shows the NMI as stuck then the system hangs .. nmi_watchdog=1 works
> fine, and the system boots without any watchdog options ..
>
> The machine is an Intel allagash
On 2007.08.07 17:06:49 -0700, Daniel Walker wrote:
This patch below hangs my system on boot if I set nmi_watchdog=2 . It
shows the NMI as stuck then the system hangs .. nmi_watchdog=1 works
fine, and the system boots without any watchdog options ..
The machine is an Intel allagash
On 2007.07.30 12:25:54 -0300, Glauber de Oliveira Costa wrote:
> Since the value in ret will go through a return statement,
^^^
You mean "err" I guess?
> it does not need to be put in eax register directly. Instead,
> we let the compiler do his job and choose what to do with
On 2007.07.30 12:25:54 -0300, Glauber de Oliveira Costa wrote:
Since the value in ret will go through a return statement,
^^^
You mean err I guess?
it does not need to be put in eax register directly. Instead,
we let the compiler do his job and choose what to do with it,
On 2007.07.28 01:29:19 +0200, Andi Kleen wrote:
> > Any faults in that reasoning?
>
> GNU sort uses a merge sort with temporary files on disk. Not sure
> how much it keeps in memory during that, but it's probably less
> than 150MB. At some point the dirty limit should kick in and write back the
On 2007.07.27 20:16:32 +0200, Rene Herman wrote:
> On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
>
>> Updatedb or another process that uses the FS heavily runs on a users
>> 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
>> pressure that causes other applications to be
On 2007.07.27 20:16:32 +0200, Rene Herman wrote:
On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
Updatedb or another process that uses the FS heavily runs on a users
256MB P3-800 (when it is idle) and the VFS caches grow, causing memory
pressure that causes other applications to be swapped to
On 2007.07.28 01:29:19 +0200, Andi Kleen wrote:
Any faults in that reasoning?
GNU sort uses a merge sort with temporary files on disk. Not sure
how much it keeps in memory during that, but it's probably less
than 150MB. At some point the dirty limit should kick in and write back the
data
On 2007.07.26 11:58:29 +0200, Björn Steinbrink wrote:
> Note that the total RSS usage of updatedb+sort was just about 50MB,
> nevertheless swap grew to more than 300MB. It's also interesting that
> swapping is so aggressive, that the amount of free memory is constantly
> growing. I
On 2007.07.26 08:56:59 +0200, Rene Herman wrote:
> On 07/26/2007 08:39 AM, Bongani Hlope wrote:
>
>> On Thursday 26 July 2007 05:59:53 Rene Herman wrote:
>
>>> So what's happening? If you sit down with a copy op "top" in one terminal
>>> and updatedb in another, what does it show?
>
>> Just tested
On 2007.07.26 11:58:29 +0200, Björn Steinbrink wrote:
Note that the total RSS usage of updatedb+sort was just about 50MB,
nevertheless swap grew to more than 300MB. It's also interesting that
swapping is so aggressive, that the amount of free memory is constantly
growing. I'm a missing
On 2007.07.26 08:56:59 +0200, Rene Herman wrote:
On 07/26/2007 08:39 AM, Bongani Hlope wrote:
On Thursday 26 July 2007 05:59:53 Rene Herman wrote:
So what's happening? If you sit down with a copy op top in one terminal
and updatedb in another, what does it show?
Just tested that, there's a
On 2007.07.19 11:55:05 +0200, Andi Kleen wrote:
>
> From: [** iso-8859-1 charset **] Bj�rnSteinbrink <[EMAIL PROTECTED]>
>
> The performance counter allocator relies on the nmi watchdog being
> probed, so we have to do that even if the watchdog is not enabled.
Are you going to revert your fixes
On 2007.07.19 11:55:06 +0200, Andi Kleen wrote:
>
> From: [** iso-8859-1 charset **] Bj�rnSteinbrink <[EMAIL PROTECTED]>
>
> The Intel PerfMon NMI watchdog was using the generic reservation
> function which always reserves the first performance counter. But the
> watchdog actually uses the
On 2007.07.19 11:55:06 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The Intel PerfMon NMI watchdog was using the generic reservation
function which always reserves the first performance counter. But the
watchdog actually uses the second
On 2007.07.19 11:55:05 +0200, Andi Kleen wrote:
From: [** iso-8859-1 charset **] Bj�rnSteinbrink [EMAIL PROTECTED]
The performance counter allocator relies on the nmi watchdog being
probed, so we have to do that even if the watchdog is not enabled.
Are you going to revert your fixes to the
On 2007.07.03 14:42:25 -0700, Linus Torvalds wrote:
>
>
> On Tue, 3 Jul 2007, Bj?rn Steinbrink wrote:
> > Andi said that one of the regression fixes wasn't critical for .22 and
> > that he wants to do a stopgap for the other regression (my patch
> > sucked), reverting the code to the .21
On 2007.07.03 18:45:24 +0200, Michal Piotrowski wrote:
> Subject: OProfile issues
> References : http://lkml.org/lkml/2007/6/12/207
> Submitter : Stephane Eranian <[EMAIL PROTECTED]>
> Handled-By : Björn Steinbrink <[EMAIL PROTECTED]>
> Patch : http://
On 2007.07.03 18:45:24 +0200, Michal Piotrowski wrote:
Subject: OProfile issues
References : http://lkml.org/lkml/2007/6/12/207
Submitter : Stephane Eranian [EMAIL PROTECTED]
Handled-By : Björn Steinbrink [EMAIL PROTECTED]
Patch : http://lkml.org/lkml/2007/6/12/392
On 2007.07.03 14:42:25 -0700, Linus Torvalds wrote:
On Tue, 3 Jul 2007, Bj?rn Steinbrink wrote:
Andi said that one of the regression fixes wasn't critical for .22 and
that he wants to do a stopgap for the other regression (my patch
sucked), reverting the code to the .21 version. So you
On 2007.06.30 14:06:14 +0200, Tim Boneko wrote:
> Hello!
> I am not subscribed to this list so please CC answers to my mail
> address. THX!
>
> I recently replaced the mainboard of one of my servers with a Tyan
> Tomcat K8E. The onboard gigabit NIC is a Broadcom BCM5721. After
> compiling and
On 2007.06.30 14:06:14 +0200, Tim Boneko wrote:
Hello!
I am not subscribed to this list so please CC answers to my mail
address. THX!
I recently replaced the mainboard of one of my servers with a Tyan
Tomcat K8E. The onboard gigabit NIC is a Broadcom BCM5721. After
compiling and loading
On 2007.06.29 01:42:22 -0700, Josh Triplett wrote:
> Jan Engelhardt wrote:
> > On Jun 29 2007 00:53, Josh Triplett wrote:
> >> And if you really want highlighting, you can always use grep --color. :)
> >
> > Been there, done that, have GREP_COLOR env variable defined!
>
> Same here. Now I just
On 2007.06.29 01:42:22 -0700, Josh Triplett wrote:
Jan Engelhardt wrote:
On Jun 29 2007 00:53, Josh Triplett wrote:
And if you really want highlighting, you can always use grep --color. :)
Been there, done that, have GREP_COLOR env variable defined!
Same here. Now I just need to
On 2007.06.25 23:51:51 -0700, Amitabha Roy wrote:
> Hi
>
> >From looking at the default_do_nmi code in traps.c it seems that (at
> least for the non BSP case, with reason=0) the die notifier chain gets
> called with val=DIE_NMI_IPI.
>
> However in the profile_exceptions_notify_handler we check
On 2007.06.25 23:51:51 -0700, Amitabha Roy wrote:
Hi
From looking at the default_do_nmi code in traps.c it seems that (at
least for the non BSP case, with reason=0) the die notifier chain gets
called with val=DIE_NMI_IPI.
However in the profile_exceptions_notify_handler we check for
On 2007.06.25 21:36:17 +0200, Andi Kleen wrote:
> On Monday 25 June 2007 21:09, Andrew Morton wrote:
> > On Wed, 20 Jun 2007 20:34:48 +0200
> >
> > Bj__rn Steinbrink <[EMAIL PROTECTED]> wrote:
> > > The performance counter allocator relies on the nmi watchdog being
> > > probed, so we have to do
On 2007.06.25 13:01:58 -0700, Stephane Eranian wrote:
> Hi,
> On Mon, Jun 25, 2007 at 09:36:17PM +0200, Andi Kleen wrote:
> > On Monday 25 June 2007 21:09, Andrew Morton wrote:
> > > On Wed, 20 Jun 2007 20:34:48 +0200
> > >
> > > Bj__rn Steinbrink <[EMAIL PROTECTED]> wrote:
> > > > The performance
On 2007.06.25 08:40:35 -0400, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> >* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> >
> >>hm, restoring nmi.c to the v2.6.21 state does not fix the
> >>nmi_watchdog=2 hang. I'll do a bisection run.
> >>
> >
> >and after spending an hour on 15
On 2007.06.25 08:49:05 -0400, Jeremy Fitzhardinge wrote:
> Björn Steinbrink wrote:
> >On 2007.06.25 10:26:52 +0200, Ingo Molnar wrote:
> >
> >>* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>the winner is ...
> >>
On 2007.06.25 10:26:52 +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > the winner is ...
> >
> > f8822f42019eceed19cc6c0f985a489e17796ed8 is first bad commit
> > commit f8822f42019eceed19cc6c0f985a489e17796ed8
> > Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>
On 2007.06.25 10:26:52 +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
the winner is ...
f8822f42019eceed19cc6c0f985a489e17796ed8 is first bad commit
commit f8822f42019eceed19cc6c0f985a489e17796ed8
Author: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Wed May
On 2007.06.25 08:49:05 -0400, Jeremy Fitzhardinge wrote:
Björn Steinbrink wrote:
On 2007.06.25 10:26:52 +0200, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
the winner is ...
f8822f42019eceed19cc6c0f985a489e17796ed8 is first bad commit
commit
On 2007.06.25 08:40:35 -0400, Jeremy Fitzhardinge wrote:
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm, restoring nmi.c to the v2.6.21 state does not fix the
nmi_watchdog=2 hang. I'll do a bisection run.
and after spending an hour on 15 bisection steps:
On 2007.06.25 13:01:58 -0700, Stephane Eranian wrote:
Hi,
On Mon, Jun 25, 2007 at 09:36:17PM +0200, Andi Kleen wrote:
On Monday 25 June 2007 21:09, Andrew Morton wrote:
On Wed, 20 Jun 2007 20:34:48 +0200
Bj__rn Steinbrink [EMAIL PROTECTED] wrote:
The performance counter allocator
On 2007.06.25 21:36:17 +0200, Andi Kleen wrote:
On Monday 25 June 2007 21:09, Andrew Morton wrote:
On Wed, 20 Jun 2007 20:34:48 +0200
Bj__rn Steinbrink [EMAIL PROTECTED] wrote:
The performance counter allocator relies on the nmi watchdog being
probed, so we have to do that even if the
1 - 100 of 276 matches
Mail list logo
