Let me clarify with an example:
test.c:
**
open("abc.txt", O_RDONLY);
i ++;
Apparently, after the system call "open" in the kernel, the system
will return to the instruction "i++". My question is: can we find out
the instruction pointer in sys_open? If so, how?
Thanks!
xin
-
To unsubsc
On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Aug 01 2005, Jeff Garzik wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>Oh, and forget TCQ. It's a completely worthless technology inherited
> >>
> >>>from PATA,
> >>
> >>Agreed.
> >>
> >>There are a few controllers where we may -ev
* James Bruce <[EMAIL PROTECTED]> [050801 09:28]:
>
> Finally, as a conspiracy theorist, I wonder if Linus is just playing us
> to get more people working on the tick skipping and highres timer
> patches. Someone with the ability to herd cats obviously has to be
> sneaky. As an impressive dem
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
One thing that seems like a regression: doing
$ cat /proc/acpi/battery/BAT1/info
causes a two-second pause and then gives me the information, while in 2.6.12.3
that was near-instant.
$ dat
On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote:
> On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > > As a crude data point of idle system running a full kde desktop
> > > environment on
> > > powersave with minimal backlight and just
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
>
> This one is small enough that both shortlog and diffstat fit comfortably:
> no big architecture updates or anything like that. Some input, x86-64 and
> ppc updates, and various fairly small
Could you rework the patch to all of that? Seems that you have a clear
vision as to where to go.
On Mon, 1 Aug 2005, Paul Jackson wrote:
> Christoph wrote:
> > New version without the magic numbers ...
>
> Good.
>
> ===
>
> How about replacing:
>
> static const char *policy_types[] = { "de
Hi Marcelo,
is this appropriate for 2.4? It seems to apply cleanly to
your current git tree.
Signed-off-by: Horms <[EMAIL PROTECTED]>
From: john stultz <[EMAIL PROTECTED]>
Date: Fri, 1 Jul 2005 05:08:54 + (+1000)
Subject: [PATCH] ppc32: stop misusing ntps time_offset value
X-Git-Tag: v2.6.1
Hi Marcelo,
Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.
Signed-off-by: Horms <[EMAIL PROTECTED]>
From: Michael Krufky <[EMAIL PROTECTED]>
Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
Subject: [PATCH] v4l cx88 hue offset fix
X-Git-Tag: v2.6.12.3
X
Siddha, Suresh B wrote:
Jack Steiner brought this issue at my OLS talk.
Take a scenario where two tasks are pinned to two HT threads in a physical
package. Idle packages in the system will keep kicking migration_thread
on the busy package with out any success.
We will run into similar scenarios
On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > As a crude data point of idle system running a full kde desktop
> > environment on
> > powersave with minimal backlight and just chatting on IRC I find it's
> > just
> > under 10% battery life
On Sun, Jul 31, 2005 at 11:01:45PM -0400, Kurt Wall wrote:
> On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write:
> > This patch removes support for gcc < 3.2 .
> >
> > The advantages are:
> > - reducing the number of supported gcc versions from 8 to 4 [1]
> > allows th
On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> As a crude data point of idle system running a full kde desktop
> environment on
> powersave with minimal backlight and just chatting on IRC I find it's
> just
> under 10% battery life difference.
Have you tried the same test but without ar
On Tue, 2 Aug 2005 02:43 pm, Con Kolivas wrote:
> This has slightly more build fixes than the last one I posted and boots and
> runs fine on my laptop. So far at absolute idle it appears this pentiumM
> 1.7 is claiming to have _25%_ more battery life. I'll need to investigate
> further to see the r
On Sun, Jul 31, 2005 at 09:47:18AM +, Danny ter Haar wrote:
> A tyan AMD64 opteron machine functioning as a usenet gateway really
> pumps some traffic a day (http://newsgate.newsserver.nl)
> Incoming traffic comes through a optical gig-E card (acenic)
> and local traffic is fed to our spool box
Con Kolivas wrote:
> My desktop pentium4 did not like the patch erroring with "bad gzip magic
> number" on boot for reasons that aren't obvious to me. This could be related
> to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is
> working fine.
>
Just writing to report that
Christoph wrote:
> New version without the magic numbers ...
Good.
===
How about replacing:
static const char *policy_types[] = { "default", "prefer", "bind",
"interleave" };
with:
static const char *policy_types[] = {
[MPOL_DEFAULT]= "default",
[MPOL_PREFERRED] = "p
On Mon, 2005-08-01 at 09:09 +0200, Pavel Machek wrote:
> Hi!
>
> > > If you think it is a linux bug, can you produce small test case doing
> > > just the sigwait, and post it on l-k with big title "sigwait() breaks
> > > when straced, and on suspend"?
> > >
> > > That way it is going to get som
Ok, one more in the series towards final 2.6.13.
This one is small enough that both shortlog and diffstat fit comfortably:
no big architecture updates or anything like that. Some input, x86-64 and
ppc updates, and various fairly small fixes in random places.
Some reverts back to 2.6.12 behavio
On Tue, 2005-08-02 at 02:13 +0200, Thorsten Knabe wrote:
> Using OSS emulation with one of the
> VoIP phones
Are you referring to the in-kernel OSS emulation, or the alsa-lib
emulation ("aoss ./app")?
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
I discovered a minor change in 2.6.10-mm1, changing this value back
corrects the "ok" button issue.
diff -urN linux/drivers/usb/input/ati_remote.c
linux-2.6.11/drivers/usb/input/ati_remote.c
--- linux/drivers/usb/input/ati_remote.c2005-08-02
17:56:26.0 +1200
+++ linux-2.6.11/drive
Theodore Ts'o wrote:
> On Mon, Aug 01, 2005 at 12:18:18PM -0400, James Bruce wrote:
>>The tradeoff is a realistic 4.4% power savings vs a 300% increase in
>>the minimum sleep period. A user will see zero power savings if they
>>have a USB mouse (probably 99% of desktops). On top of that, we can
This is a code reordered version of the dynamic ticks patch from Tony Lindgen
and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but
thanks for the code. There is significant renewed interest by the lkml
audience for such a feature which is why I'm butchering your code (sorry
On Tue, 2 Aug 2005, Nick Piggin wrote:
>
> Any chance you can change the __follow_page test to account for
> writeable clean ptes? Something like
>
> if (write && !pte_dirty(pte) && !pte_write(pte))
> goto out;
>
> And then you would re-add the set_page_dirty logic further
On Mon, 2005-08-01 at 20:45 -0700, Linus Torvalds wrote:
>
> On Tue, 2 Aug 2005, Nick Piggin wrote:
> >
> > Surely this introduces integrity problems when `force` is not set?
>
> "force" changes how we test the vma->vm_flags, that was always the
> meaning from a security standpoint (and that ha
On Mon, 2005-08-01 at 23:55 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> > It means that IRQ 14 is running for a long time as an RT task
>
> Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's
> the IDE drive interrupt and it gets pre
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> It means that IRQ 14 is running for a long time as an RT task
Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's
the IDE drive interrupt and it gets pretty busy. Actually the check
doesn't really see if it is running f
On Tue, 2 Aug 2005, Nick Piggin wrote:
>
> Surely this introduces integrity problems when `force` is not set?
"force" changes how we test the vma->vm_flags, that was always the
meaning from a security standpoint (and that hasn't changed).
The old code had this "lookup_write = write && !force;
On Tue, 02 Aug 2005 13:05:50 +1000,
Keith Owens <[EMAIL PROTECTED]> wrote:
>The vcsnn value varies. I traced the dentry parent chain for the
>latest event. From bottom to top the d_name entries are
>
> dev, vcs16, vc, class, /.
>
>That makes no sense, why is dev a child of vcs16? Raw data at t
Grant Coady <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> Automating random config kernel build testing, for 2.6.13-rc4-mm1:
>
> Done processing 752 random builds, from which:
> ### 8 .configs produced errors
> ### 11 .configs produced undefs
> ### 52 .configs produced warnings
>
> Abbreviat
On Mon, 1 Aug 2005 12:03:21 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, 30 Jul 2005 02:29:55 -0700,
>> Andrew Morton <[EMAIL PROTECTED]> wrote:
>> >Keith Owens <[EMAIL PROTECTED]> wrote:
>> >>
>> >> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBU
Greetings,
Automating random config kernel build testing, for 2.6.13-rc4-mm1:
Done processing 752 random builds, from which:
### 8 .configs produced errors
### 11 .configs produced undefs
### 52 .configs produced warnings
Abbreviated errors (first 2 lines/error):
[EMAIL PROTECTED]:/opt/linu
On Mon, 1 Aug 2005, Sander wrote:
Dr. David Alan Gilbert wrote (ao):
* Sander ([EMAIL PROTECTED]) wrote:
Dr. David Alan Gilbert wrote (ao):
I was using rsync, but the problem with rsync is that I have
a back up server then filled with lots and lots of small files
- I want larger files for spo
On 2005.08.01 13:03:34 +, Roger Heflin wrote:
>
> On the newer Intels I have not found any useable ECC support
> is there any in the kernels?
For ia32, not in kernel now, see http://bluesmoke.sf.net
For ia64, kernel already have support.
>
> I can test a variety of hardware if someone nee
Linus Torvalds wrote:
Instead, I'd suggest changing the logic for "lookup_write". Make it
require that the page table entry is _dirty_ (not writable), and then
remove the line that says:
lookup_write = write && !force;
and you're now done. A successful mm fault for write _should_ a
Hi Tony, LKML
Since there appears to be renewed interest of late in dynamic ticks...
You didn't respond with my last patch for dynamic ticks so I assume that's
because you threw up when you saw what a mess it is. Anyway I'm sorry for
sending you that naive mess the first time around.
Here is
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things
Patrick McHardy wrote:
> Mattia Dongili wrote:
>
>>On Mon, Aug 01, 2005 at 04:27:53PM +0200, Patrick McHardy wrote:
>>
>>
--- include/linux/netfilter_ipv4/ip_conntrack.h.clean 2005-08-01
15:09:49.0 +0200
+++ include/linux/netfilter_ipv4/ip_conntrack.h 2005-08-01
>>>
On Mon, 2005-08-01 at 14:09 -0700, Daniel Walker wrote:
>
> You guys want me to always CC in the future?
Yes, please CC the LKML. I try to for all updates since I might have
done a mistake in my code that my shallow tests don't catch, and others
might. Also to let others know what I'm suggestin
On Mon, 2005-08-01 at 19:35 -0400, Dave Jones wrote:
> This means we will do the wrong thing on AMD machines which have
> 64 byte cachelines.
pcibios_init (in i386/pci/common.c, which is linked in by X86_64 PCI
code) seems to do this
if (c->x86 >= 6 && c->x86_vendor == X86_VENDOR_AMD)
On Mon, Aug 01, 2005 at 10:45:03AM +0200, Stelian Pop wrote:
> Le lundi 01 août 2005 à 02:59 +0200, Erik Waling a écrit :
> > Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method
> > to
> > initialize the SPIC device. The new way to initialize (and disable) the
> > device
>
Linus Torvalds wrote:
On Mon, 1 Aug 2005, Nick Piggin wrote:
Not sure if this should be fixed for 2.6.13. It can result in
pagecache corruption: so I guess that answers my own question.
Hell no.
This patch is clearly untested and must _not_ be applied:
Yes, I meant that the problem sh
New version without the magic numbers ...
---
String conversions for memory policy
This patch adds two new functions to mm/mempolicy.c that allow the conversion
of a memory policy to a textual representation and vice versa.
Syntax of textual representation:
default
preferred=
bind=
interleave=
On Mon, 1 Aug 2005, Andrew Haninger wrote:
Thorsten: Please remember to include the list(s) when emailing those
links/numbers. I'd like to be able to watch it, too, and add any
information that I can, rather than entering a duplicate bug.
Hello.
I have taken a closer look at the ALSA AD1816 s
On 02.08.2005 [02:03:59 +0200], Patrick McHardy wrote:
> Nishanth Aravamudan wrote:
> > On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote:
> >
> >>Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
> >>
> >>skb->stamp.tv_usec = xtime.tv_nsec * 1000;
> >>
> >>To
Dave Jones wrote:
During boot of todays -git, I noticed this..
PCI: Setting latency timer of device :00:1d.7 to 64
after boot, lspci shows..
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Dell: Unknown device
Nishanth Aravamudan wrote:
> On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote:
>
>>Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
>>
>>skb->stamp.tv_usec = xtime.tv_nsec * 1000;
>>
>>To convert nsec to usec, one should divide instead of multiplying:
>>
>>
On Mon, 1 Aug 2005, Paul Jackson wrote:
> Christoph wrote:
> > you need to create multiple
> > levels of directories in /proc//xx
>
> You do?
>
> Where's the new multiple directory levels in the two files:
>
> /proc//numa_policy # contains one word
> /proc//numa_nodelist
Christoph wrote:
> you need to create multiple
> levels of directories in /proc//xx
You do?
Where's the new multiple directory levels in the two files:
/proc//numa_policy # contains one word
/proc//numa_nodelist # contains one nodelist
There are some obvious negat
On Sat, 30 Jul 2005, Dominik Brodowski wrote:
> dpm_runtime_suspend and _resume() would be quite useful for some PCMCIA
> tasks. However, they are only exported in drivers/base/power/power.h. Any
> objection to moving it to include/linux/pm.h ? Any plans to break the
> functionality these functio
During boot of todays -git, I noticed this..
PCI: Setting latency timer of device :00:1d.7 to 64
after boot, lspci shows..
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Dell: Unknown device 0169
Flags: bus mast
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> Hmmm. this should have returned the behavior to normal. Ah. Need to use
> new_entry instead of entry. Try this (is there any way that I could get
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>
> +#ifdef CO
greg wrote:
Hi folks,
I'm looking for a timer resolution lower than 1 ms (and monotonic clock
rate) destined to be used with some network code running on x86
platforms. Would you please provide me with informations about how to
get/implement this.
AFAIK, there's a "high resultion timer" pat
On Mon, 1 Aug 2005, Paul Jackson wrote:
> In your related patch, you show how to merge this display of mempolicy
> into the new /proc//smap (rss size of each memory area) file.
> But this smap file (or, as you renamed it, emap file) is read-only,
> so far as I can tell. It enables display of info
On Tue, 2 Aug 2005, Richard Purdie wrote:
> > + update_mmu_cache(vma, address, entry);
> > + lazy_mmu_prot_update(entry);
> > +#endif
>
> This locks the system up after the "INIT: version 2.86 booting" message.
> SysRq still responds but that's about it.
Hmmm. this should have returned the b
Hi Andrew,
I noticed a strange return value in smsc_ircc_init in
drivers/net/irda/smsc_ircc2.c in rc4-mm1.
When reaching the line "if (ircc_fir > 0 && ircc_sir > 0)", ret is 0.
So I don't see the point of setting it to 0 in the "else" case.
>From what I see in 2.6.12 it should probably be set to
Ok - its definitely getting shorter and sweeter. Good.
There are quite a few small magic numbers - is there someway to code
these out? See also my comment below, mentioning kernel/power/main.c.
Changing one of the strings should not break the code until the
corresponding magic string length numb
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
>
> Maybe we better restore the pte flags changes the way they were if
> CONFIG_ATOMIC_TABLE_OPS i
Keith Owens wrote:
On Fri, 29 Jul 2005 13:55:23 -0700,
George Anzinger wrote:
This patch adds a notify to the die_nmi notify that the system
is about to be taken down. If the notify is handled with a
NOTIFY_STOP return, the system is given a new lease on life.
void d
The attached bluetooth oops can be reliably reproduced on my x86_64
laptop. It happens when hciattach is still running while a sequence of
"cardctl eject" and then "killproc /sbin/cardmgr" is executed.
Though this seems to point to preempt I could manage to cause similar
oopses on non-preemptible k
On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote:
> Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
>
> skb->stamp.tv_usec = xtime.tv_nsec * 1000;
>
> To convert nsec to usec, one should divide instead of multiplying:
>
> skb->stamp.tv_use
Let's be careful and not remove them twice. I know Andrew's already
sent a patch to linus to remove the duplication.
- kumar
On Aug 1, 2005, at 3:13 PM, Dave Jones wrote:
Somehow, these functions got included twice.
drivers/i2c/busses/i2c-mpc.c:386: error: redefinition of
'fsl_i2c_probe'
On Mon, 1 Aug 2005, Andrew Morton wrote:
> (I'm still not sure what happened to the idea of adding a call to "clear
> out this node+zone's pagecache now" rather than "set this noed+zone's
> policy")
Yes, We need the clear this zones page cache functionality. I am not sure what
the
Martin's recl
Delivery mode should be APIC_DM_FIXED when using physical mode.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/genapic_flat.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.13-rc4-mm1/arch/x86_6
On Mon, Aug 01, 2005 at 01:20:18PM -0700, Ashok Raj wrote:
> Auto selection of bigsmp patch removed this check from a shared common file
> in arch/i386/kernel/acpi/boot.c. We still need to call this to determine
> the right genapic code for x86_64.
>
Thanks venki,
missed the check for lapic an
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> Could you get me some more information about the hang? A stacktrace would
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed
* Lee Revell <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > ok - i've uploaded the -52-04 patch, does that fix it for you?
>
> Has anyone found their PS2 keyboard rather sluggish with this kernel?
> I'm not sure whether it's an -RT problem, I'll have to t
It is not required to choose the physflat mode when CPU hotplug is enabled
and CPUs <=8 case. Use of genapic_flat with the mask version is capable of
doing the same, instead of doing the send_IPI_mask_sequence() where its a
unicast.
This is another change that Andi introduced with the physflat
Newly introduced physflat_* shares way too much with cluster with only
a very differences. So we introduce some common functions in that can be
reused in both cases.
In addition the following are also fixed.
- Use of non-existent CONFIG_CPU_HOTPLUG option renamed to actual one in use.
- Removed co
On Wed, July 27, 2005 5:06 am, Richard Purdie said:
> On Wed, 2005-07-27 at 11:53 +0200, Pavel Machek wrote:
>> +/* read comadj */
>> +#ifdef CONFIG_MACH_POODLE
>> +comadj = 118;
>> +#else
>> +comadj = 128;
>> +#endif
>
> Can you go back to the Sharp source and confirm that these values
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that proba
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > > ok - i've uploaded the -52-04 patch, does that fix it for you?
> >
> > Has anyone found their PS2 keyboard rather sluggish with this kernel?
> > I'm not sure whether it's an -RT problem,
Anton Erasmus wrote:
On Wed, 27 Jul 2005 16:58:20 -, Chiefy <[EMAIL PROTECTED]>
wrote:
26 Jul 2005 20:04 UTC, Anton Erasmus typed:
How can I find out which SCSI ID is mapped to which device ?
Have a look at sg3_utils http://sg.torque.net/sg/index.html
Thanks,
These utilities seem t
On Mon, 1 Aug 2005, Richard Purdie wrote:
> That number rapidly increases and so it looks like something is failing
> and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two differe
Hi!
> >> + /* read comadj */
> >> +#ifdef CONFIG_MACH_POODLE
> >> + comadj = 118;
> >> +#else
> >> + comadj = 128;
> >> +#endif
> >
> > Can you go back to the Sharp source and confirm that these values should
> > be hardcoded in both the poodle and collie cases please? I know the
> > sharpsl_pa
Hello.
Could you send me critics and bugs?
Could somebody test it (but NOT now)?
Thanks.
drivers/char/isicom.c | 1610
-
include/linux/isicom.h |8
2 files changed, 817 insertions(+), 801 deletions(-)
Here it is (about 65 KiB):
http://www.fi.m
On Mon, 1 Aug 2005, Richard Purdie wrote:
> cmpxchg_fail_flag_update 1359210189
>
> That number rapidly increases and so it looks like something is failing
> and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault s
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote:
> Can you run kgdb on it to figure out what is going on?
Maybe, depending on how easily kgdb cross compiles and how quickly I can
learn to use it...
> There are some variables in /proc/vmstat that may help:
>
> spurious_page_faults 0
>
MM, NUMA : sys_set_mempolicy() doesnt check if mode < 0
A kernel BUG() is triggered by a call to set_mempolicy() with a negative first
argument.
This is because the mode is declared as an int, and the validity check doesnt
check < 0 values.
Alternatively, mode could be declared as unsigned int
On Mon, 1 Aug 2005, Linus Torvalds wrote:
>
> Of course, if VM_MAYWRITE is not set, you could just convert it silently
> to a MAP_PRIVATE at the VM level (that's literally what we used to do,
> back when we didn't support writable shared mappings at all, all those
> years ago), so at least now
On Monday, 1 of August 2005 14:15, Takashi Iwai wrote:
> Hi Rafael,
>
> At Sun, 31 Jul 2005 12:43:21 +0200,
> Rafael J. Wysocki wrote:
> >
> > Hi,
> >
> > This patch adds the handling of irq_request() failures during resume to
> > the snd_intel8x0 driver.
> >
> > Please consider for applying,
>
On Monday, 1 of August 2005 01:39, Kasper Sandberg wrote:
> hello, i run 2.6.13-rc4-git2, and i am experiencing problems with
> sk98lin, suddenly it just stops working, and i need to reboot to get
> network up again, does this fix it?
Unfortunately, it doesn't. It is only relevant if you suspend/
[now sending to lkml as sending to the pcmcia list without being
subscribed seems to go to /dev/null]
I do have problems with yenta_socket on my x86_64 laptop which appear
when using swsusp (suspend to disk mode).
1. When I do not access any pcmcia device from initrd during boot
I have to term
noticed by Chuck Ebbert: the .ldt entry of the TSS was set up
incorrectly. It never mattered since this was a leftover from
old times, so remove it.
From: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patc
On Mon, 1 Aug 2005, Hugh Dickins wrote:
> >
> > We have always just done a COW if it's read-only - even if it's shared.
> >
> > The point being that if a process mapped did a read-only mapping, and a
> > tracer wants to modify memory, the tracer is always allowed to do so, but
> > it's _not_
On Monday, 1 of August 2005 22:34, Hugh Dickins wrote:
> On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> > On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
> > >
> > > Linus has apparently dropped that patch for yenta, but in case it is
> > > reintroduced in the future you will probably
Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
skb->stamp.tv_usec = xtime.tv_nsec * 1000;
To convert nsec to usec, one should divide instead of multiplying:
skb->stamp.tv_usec = xtime.tv_nsec / 1000;
The same bug could be present in the lat
Auto selection of bigsmp patch removed this check from a shared common file
in arch/i386/kernel/acpi/boot.c. We still need to call this to determine
the right genapic code for x86_64.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
arch/x
Hi
i did run the systen half an hour without ppp . there was no badness in
the logs
in the time.
after after starting the internet without the firewall the messages about the
badness were after a few minutes in the log.
so the bug is not in the iptables code.
it might be in the pppd drive
On Mon, 1 Aug 2005, Richard Purdie wrote:
> > IP Not changing? Could it be in a loop doing faults for the same memory
> > location that you cannot observe with gdb? Or is there some hardware fault
> > that has stopped the processor?
>
> I'm not the worlds most experienced user of gdb but I can'
On Mon, Aug 01, 2005 at 12:18:18PM -0400, James Bruce wrote:
>
> The tradeoff is a realistic 4.4% power savings vs a 300% increase in the
> minimum sleep period. A user will see zero power savings if they have a
> USB mouse (probably 99% of desktops). On top of that, we can throw in
> Con's d
In the interest of CC'ing everyone here's another patch .
This checks for wake_up_process() calls inside was preempt off sections.
So if it was a spinlock , and you call wake_up_process() it will trigger
a warning.. These are problematic cause in RT the wake_up_process() (if
it's an RT task) will
Hi,
On Monday, 1 of August 2005 04:06, Andrew Morton wrote:
> Shaohua Li <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > > In general, I think that calling free_irq is the right behavior.
> > > Although irqs changing after suspend is rare, there are also some
> > > more serious issues. This has been d
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-08-01 at 23:03 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > - struct semaphore stop;
> > > + struct compat_semaphore stop;
> >
> > i think it's policy->lock that is the issue here?
> >
>
> I was
On Mon, 2005-08-01 at 23:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > - struct semaphore stop;
> > + struct compat_semaphore stop;
>
> i think it's policy->lock that is the issue here?
>
I was looking at Luca's original message where he showed the bug of
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> > of the trace is junk as glibc's arm memcpy implementation will have
> > destroyed the frame pointer. The current ins
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > here's the patch below. Could you try to revert it?
>
> Thanks Ingo.
>
> If Daniel was trying to detect soft lock ups of lower priority tasks
> (tasks that block all tasks lower than itself), I've added a counter
> to Daniels patch to keep from
On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> Ingo,
>
> What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> getting a bunch of them from the IDE interrupt. It's not locking up,
> but it does things that probably do take some time. Is this really
> necessary? Here's
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > here's the patch below. Could you try to revert it?
>
> You guys want me to always CC in the future?
well if it's somewhat larger than a trivial fix then it would definitely
be useful to always Cc: lkml. Trivial fixes can go to lkml too, just in
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that proba
1 - 100 of 303 matches
Mail list logo
