2007/3/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
hello ,
i am programming a trial firewall based on netfilter ,which needs the module to
access the data of user space ,so i use copy_from_user() but it can't work ,the
code(simple test code) is like this:
---user space program-
#include
#
On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 28 Mar 2007 13:55:54 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> My laptop (HP dv1240us) is always showing that my laptop is plugged
> into AC power, even when it is running off of the battery. When I
> plug into the AC after runn
On Thu, 29 Mar 2007 01:00:45 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On 3/28/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Mar 2007 13:55:54 -0700
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> > > My laptop (HP dv1240us) is always showing that my laptop is plugged
> > > i
Rereading to make sure I wasn't unclear anywhere...
On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
>
> I don't see what a < 95% load really means.
Egad. Here I'm pondering the numbers and light load as I'm typing, and
my fingers (seemingly independent when mind wanders off) typed < 9
Anyone? I am new here, excuse me if format is wrong. Please assist with
this problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Valentin
Zaharov
Sent: Wednesday, March 28, 2007 8:36 PM
To: linux-kernel@vger.kernel.org
Subject: cifs causes BUG: soft
This is a diff from Ken Chen, who sent it to me a week ago and received
the claimed prize $256. I think it's partially based on Jan's code,
while if fixes the bug Jan mentioned (as far as I know).
It does the following:
- allocate loop dynamically on the fly
- allocate one more (spare) loop eac
On Wed, 2007-03-28 at 00:39 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > It's an arch detail whether MSI irqs need to be masked using the PCI
> > MSI registers.
>
> Agreed. It isn't an arch detail that they need to be unmasked in
> the pci configuration sp
On Wed, 28 Mar 2007 20:35:55 +0200 "Valentin Zaharov" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We have continous problem with server freezes. We are using cifs mounts
> on apache powered web servers with content located on Win2k3 server.
> Servers freeze from time to time, producing following error
Hi,
following up on the firmware loading problems in 2.6.21-rc4-mm1, I've
been looking into uevent_suppress and using it in the firmware class.
As an added bonus, I also managed to suppress some unwanted uevents on
s390.
Works for me on i386 (the firmware stuff) and on s390 (the subchannel
stuff)
From: Cornelia Huck <[EMAIL PROTECTED]>
Suppress uevents for devices if uevent_suppress is set via
dev_uevent_filter(). This makes the driver core suppress all device
uevents, not just the add event in device_add().
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/base/core.c |5
From: Cornelia Huck <[EMAIL PROTECTED]>
We often have the situation that we register a subchannel and start
device recognition, only to find out that the device is not usable
after all, which triggers an unregister of the subchannel. This often
happens on hundreds of subchannels on a LPAR, leading
From: Cornelia Huck <[EMAIL PROTECTED]>
Use uevent_suppress instead of returning an error code in
firmware_uevent(). Get rid of the now unneeded FW_STATUS_READY
and FW_STATUS_READY_NOHOTPLUG.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/base/firmware_class.c | 10 ++
1
Thanks for your response!
I've tried different kernel versions.
Right now iam using generic 2.6.9-42 on one machine and 2.6.20.1 on
another one.
I also tried various distributions ( Suse, CentOS, RHEL4 ) - not sure it
is relevant.
Tried installing latest cifs modules, tried changing CIFSMaxBufSize
On Thu, 29 Mar 2007 11:13:04 +0200 "Valentin Zaharov" <[EMAIL PROTECTED]> wrote:
> I've tried different kernel versions.
> Right now iam using generic 2.6.9-42 on one machine and 2.6.20.1 on
> another one.
> I also tried various distributions ( Suse, CentOS, RHEL4 ) - not sure it
> is relevant.
>
Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
the split config tree is built, but failed to also adjust fixdep
accordingly - if changing a config option from or to m, files
referencing the respective CONFIG_..._MODULE (but not the
corresponding CONFIG_...) didn't get rebuilt.
Onc
> Oliver Joa wrote:
> >>eason or another, xfs has detected a corrupted on-disk inode format
> >>which it cannot recognize, and shuts down.
>
> Oh, one other thing that may not apply in your case, but may.
> Does your SATA disk support write caching? Does it support
> something called a barri
I get this error when try to apply the patch:
patch -p1 < cifs.patch
patching file include/linux/fs.h
patch: malformed patch at line 26: /*
Am I missing something or patch is bad?
Thanks in advance
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Thursday,
On Thursday 29 March 2007 09:17, Jan Beulich wrote:
> >>> Andi Kleen <[EMAIL PROTECTED]> 28.03.07 21:07 >>>
> >
> >> +#ifdef CONFIG_HOTPLUG_CPU
> >> + /* It must still be possible to apply SMP alternatives. */
> >> + if (num_possible_cpus() <= 1)
> >
> >It would be better to temporarily change th
Hi all,
I've been hacking on the Linux kernel all semester for my OS:
Internals class. We are given full autonomy in picking our final
programming project and I would love for mine to be /useful/ for the
Linux kernel and not just a theoretical exorcise. If anybody has any
bug fixes or features ma
Russ Meyerriecks wrote:
Hi all,
I've been hacking on the Linux kernel all semester for my OS:
Internals class. We are given full autonomy in picking our final
programming project and I would love for mine to be /useful/ for the
Linux kernel and not just a theoretical exorcise. If anybody has any
2007/3/29, Russ Meyerriecks <[EMAIL PROTECTED]>:
Hi all,
I've been hacking on the Linux kernel all semester for my OS:
Internals class. We are given full autonomy in picking our final
programming project and I would love for mine to be /useful/ for the
Linux kernel and not just a theoretical ex
On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote:
> (Did this fall through the cracks? I don't see it in -mm. It's
> standalone, and saves some silly code in lguest and presumably others).
Normally it should go to some some console maintainer?
Ok I can add it.
-Andi
-
To unsubscr
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c|3 +++
include/asm-blackfin/mach-bf561/bf561.h |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index b494f73..96ee2fa 1
> ---
> From: Yinghai Lu <[EMAIL PROTECTED]>
> Subject: x86_64 irq: Fix comments after changing IRQ0_VECTOR from 0x20 to 0x30
applied thanks
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
On Thursday 29 March 2007 09:58, Jan Beulich wrote:
> Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
> subsequent pfn-s are also invalid is wrong. Thus replace this by
> explicitly checking against the E820 map.
Applied thanks.
-Andi
-
To unsubscribe from this list: send the l
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 0f90ff9..a4219df 100644
--- a/arch/blackfin/mac
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index 96ee2fa..ce51882 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/k
Sorry for word wrap. this one is ok.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index 0f90ff9.
Hi!
> I have discussed with my colleagues why you say "ugly" against my
> procfs interface, then I noticed I may have misunderstood what you said.
> Is the reason for saying "ugly" two interfaces, i.e. preexisting ulimit
> (get/setrlimit) and my proc entry, exist to control core file size?
Yes.
On Sat, 24 Mar 2007, Adrian Bunk wrote:
> On Sat, Mar 24, 2007 at 02:49:42PM +0100, Armin Schindler wrote:
> > On Sat, 24 Mar 2007, Adrian Bunk wrote:
> > > Randy Dunlap reported in kernel Bugzilla #8241 the following compile
> > > error with CONFIG_ISDN_CAPI=m, CONFIG_ISDN_DIVAS=y:
> > >
> > > <
On Thu, 2007-03-29 at 12:36 +0200, Andi Kleen wrote:
> On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote:
> > (Did this fall through the cracks? I don't see it in -mm. It's
> > standalone, and saves some silly code in lguest and presumably others).
>
> Normally it should go to some s
On Thu, Mar 29 2007, Jan Kara wrote:
> > Oliver Joa wrote:
> > >>eason or another, xfs has detected a corrupted on-disk inode format
> > >>which it cannot recognize, and shuts down.
> >
> > Oh, one other thing that may not apply in your case, but may.
> > Does your SATA disk support write cac
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
>
> > I'm cautiously optimistic that we're at the thin edge of the bugfix
> > wedge now.
[...]
> and the numbers he posted:
>
> http://marc.info/?l=linux-kernel&m=117448900626028&w=2
>
> his test conclusion
Adrian Bunk wrote:
On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote:
Eric W. Biederman wrote:
Sid Boyce <[EMAIL PROTECTED]> writes:
This is what I've got so far on the first boot, I shall have to check the
manpage for git-bisect again to see if there is anything else
Eric W. Biederman wrote:
Sid I think I have found the problem. Could you try the following patch.
I believe I accidentally switched the sense of a test
diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,7 +790,7 @@ static
> ondemand is the biggest offender and the patch below reduces the number of
> interrupts by 50% or more (depending on HZ) on different test systems here.
Cool!
> Yes. There are quite a few other timers inside kernel that can be
> migrated. I will use timer_stats and track others and send in th
On Mar 29, 2007, at 07:41:12, Andi Kleen wrote:
ondemand is the biggest offender and the patch below reduces the
number of interrupts by 50% or more (depending on HZ) on different
test systems here.
Cool!
Yes. There are quite a few other timers inside kernel that can be
migrated. I will u
> Might also be useful to add an extra option to "top" to reduce the
> polling frequency if the system is otherwise idle. A fixed 30-sec
> timer and a deferrable 1-sec timer or somesuch?
Hmm, i think the current implementation is per CPU. top really would
like to have one that applies to all
This contains fixes for a bug that could cause too much latency with non-zero
niced processes, as well as fixes so that it SMP balancing actually works now
(the v32 forward port on top of smpnice was buggy).
X should be reniced to -10 for best results.
/proc/sys/kernel/base_timeslice can be redu
On x86-64, kernel memory freed after init can be entirely unmapped instead
of just getting 'poisoned' by overwriting with a debug pattern.
On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table
can also be write-protected.
(Not sure what the symbol 'stext' is good for; can it b
Hi Adrian,
Em Seg, 2007-03-26 às 06:08 +0200, Adrian Bunk escreveu:
> This patch fixes an off-by-one error spotted by the Coverity checker.
Thanks for pointing us about this. Instead of your patch, however, it is
better to replace all magic numbers at for on all gpiomask stuff. This
will avoid fu
On Thu, Mar 29, 2007 at 09:06:57PM +1000, Rusty Russell wrote:
> On Thu, 2007-03-29 at 12:36 +0200, Andi Kleen wrote:
> > On Thu, Mar 29, 2007 at 05:46:48PM +1000, Rusty Russell wrote:
> > > (Did this fall through the cracks? I don't see it in -mm. It's
> > > standalone, and saves some silly code
Hello,
> Now I want to explain the problem that leads me to explore the Linux
> disk cache management. This is actually from my project. In a file
> system I am working on, two files may have different inodes, but share
> the same data blocks. Of course additional block-level reference
> counti
Hello,
We need to come up with the best possible layout of arguments for the
fallocate() system call. Various architectures have different
requirements for how the arguments should look like. Since the mail
chain has become huge, here is the summary of various inputs received
so far.
Platform: s3
On Thu, 29 Mar 2007, Neil Brown wrote:
On Tuesday March 27, [EMAIL PROTECTED] wrote:
I ran a check on my SW RAID devices this morning. However, when I did so,
I had a few lftp sessions open pulling files. After I executed the check,
the lftp processes entered 'D' state and I could do 'nothi
On Thu, 29 Mar 2007, Henrique de Moraes Holschuh wrote:
On Thu, 29 Mar 2007, Justin Piszcz wrote:
Did you look at "cat /proc/mdstat" ?? What sort of speed was the check
running at?
Around 44MB/s.
I do use the following optimization, perhaps a bad idea if I want other
processes to 'stay aliv
On Thu, 29 Mar 2007, Justin Piszcz wrote:
> >Did you look at "cat /proc/mdstat" ?? What sort of speed was the check
> >running at?
> Around 44MB/s.
>
> I do use the following optimization, perhaps a bad idea if I want other
> processes to 'stay alive'?
>
> echo "Setting minimum resync speed to 2
On Thursday 29 March 2007 14:01, Jan Beulich wrote:
> On x86-64, kernel memory freed after init can be entirely unmapped instead
> of just getting 'poisoned' by overwriting with a debug pattern.
>
> On i386 and x86-64 (under CONFIG_DEBUG_RODATA), kernel text and bug table
> can also be write-prote
Hi,
artsd during kde start triggered this
=
[ INFO: inconsistent lock state ]
[ 2.6.21-rc5-rt4 #4
-
inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
artsd/3454 [HC1[1]:SC0[0]:HE0:SE1] takes:
((raw_spinlock_t *)(&lock->wait_lock)
On Thu, Mar 29, 2007 at 06:47:32PM +0800, Wu, Bryan wrote:
> diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
> b/arch/blackfin/mach-bf537/boards/stamp.c
> index 0f90ff9..a4219df 100644
> --- a/arch/blackfin/mach-bf537/boards/stamp.c
> +++ b/arch/blackfin/mach-bf537/boards/stamp.c
> @@ -68,7 +
On Wed, Mar 28, 2007 at 01:07:56PM -0700, Andrew Morton wrote:
> On Wed, 28 Mar 2007 22:56:32 +0400
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 28, 2007 at 10:38:14PM +0400, Alexey Dobriyan wrote:
> > > On Wed, Mar 28, 2007 at 08:04:46PM +0200, Andreas Mohr wrote:
> > > > [unrel
On 3/29/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
Rereading to make sure I wasn't unclear anywhere...
On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
>
> I don't see what a < 95% load really means.
Egad. Here I'm pondering the numbers and light load as I'm typing, and
my fingers (
Len Brown <[EMAIL PROTECTED]> writes:
> On an Intel processor, it seems that the safe and simple route
> is if the system exports C2 or deeper, don't use the LAPIC timer.
> (which is what 2.6.21-rc5 is doing as of this moment)
> We may be able to white-list some systems over time.
On AMD it is th
Maxim Levitsky wrote:
Hi,
I noticed that after suspend/resume cycle all my usb devices are
unplugged/replugged by uhci driver.
While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted
file-system, because disappeared device will cause f
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 27 Mar 2007, Len Brown wrote:
> >
> > I think the only fool-proof way to do this automatically is to
>
> Why not just take the known-good CPUID signature?
I didn't think we could reliably distingush mobile cpus with C2+
versus desktop CPUs w
Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> The main motivation was to have the arch in control of as much direct
> register writing as possible. Even though our HV does allow us to write
> to config space, it's not obviously safe for Linux to be flipping bits
> and also calling the HV to con
Hi all,
Backports of the staircase deadline cpu scheduler for 2.6.18.8 and
2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/.
Also, Debian Etch 4.0 kernels for both i686 and x86_64 are available.
Fedora Core 6 kernels might also be available later today/tomorrow.
Both patches looks
>>> Andi Kleen <[EMAIL PROTECTED]> 29.03.07 14:22 >>>
>On Thursday 29 March 2007 14:01, Jan Beulich wrote:
>> On x86-64, kernel memory freed after init can be entirely unmapped instead
>> of just getting 'poisoned' by overwriting with a debug pattern.
>>
>> On i386 and x86-64 (under CONFIG_DEBUG_R
On Thursday 29 March 2007 15:49, Jan Beulich wrote:
> >>> Andi Kleen <[EMAIL PROTECTED]> 29.03.07 14:22 >>>
> >On Thursday 29 March 2007 14:01, Jan Beulich wrote:
> >> On x86-64, kernel memory freed after init can be entirely unmapped instead
> >> of just getting 'poisoned' by overwriting with a de
Tomas M wrote:
255 loop devices are insufficient? What kind of scenario do you have
in mind?
Thank you very much for replying.
In 1981, Bill Gates said that 64KB of memory is enough for everybody.
And you know how much RAM do you have right now. :)
Actually, I believe the number was 640k, t
Many files include the filename at the beginning, serveral used a wrong one.
Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]>
---
This is a follow up to f30c2269544bffc7bf1b0d7c0abe5be1be83b8cb.
This patch was generated with the same program as the former patch.
arch/arm/mach-s3c2410/sleep.S
roland wrote:
partitions on loop or device-mapper devices ?
you can use kpartx tool for this.
bryn m. reeves told me, that it's probably poissible to create udev
rules that will automatically create partition maps when a new loop
device is setup, which is better than adding partitioning logig
Lee Revell wrote:
John wrote:
Would someone know how to disable SMM in this BIOS?
There's no generic way.
I understand. Would someone know how to disable SMM in the VIA Pro133T
chipset (VT82C596B south bridge). What I/O ports do I need to write to,
and what values should I write to these
Hello.
Maxim wrote:
---
This adds support of suspend/resume on i386 for HPET
The part after usually "---" gets cut off, the patch description and
signoff should actially *precede* it.
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/k
On Thursday 29 March 2007 15:20:27 Sergei Shtylyov wrote:
> Hello.
>
> Maxim wrote:
>
> > ---
> > This adds support of suspend/resume on i386 for HPET
>
>The part after usually "---" gets cut off, the patch description and
> signoff should actially *precede* it.
>
> > Signed-off-by: Maxim
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c | 68 +++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/i386
Sounds sane to me. My overall opinion on eepro100 removal is that we're
not there yet. Rare problem cases remain where e100 fails but eepro100
works, and it's older drivers so its low priority for everybody.
Needs to happen, though...
It seems that several Tyan Opteron base system that were u
Guennadi Liakhovetski wrote:
Jeff, might be worth getting the sk_buff leak fix in ppp from
http://www.spinics.net/lists/netdev/msg27706.html in 2.6.21 too?
Don't know how important it is for stable. It was present in 2.6.18 too.
Can you resend the patch to me, please?
Easier for the system t
Jan-Bernd Themann wrote:
This patch includes:
- removal of unused fields in structs
- ethtool statistics cleanup
- removes unsed functionality from send path
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
This patch applies on top of the netdev upstream branch for 2.6.22
drivers/n
On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote:
> I have a pxa255 based system with PCI added to it. The e100 would have
> memory corruption in its receive buffers detected by slab debugging
> unless I put in the patch to use the S-bit.
>
> Here is a link to the patch posting:
> ht
On 3/29/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting Maxim <[EMAIL PROTECTED]>:
> The patch below is a temporally fix, until
> clock-events and clocksources will get proper suspend/resume
> hooks:
Bingo!
I confirmed that it suspend/resume disk/ra
On Thu, 29 Mar 2007, Li Yu wrote:
> The last word is a question, what's the future of hiddev? It will merge
> into hidraw later? I think so, but can't sure.
Hi Li,
no, it won't, it doesn't provide compatible interface for purpose.
hiddev has currently the following drawbacks:
- USB-transport
Tino Keitel wrote:
On Mon, Mar 26, 2007 at 17:15:53 -0400, Alan Stern wrote:
[...]
The lack of messages from the iPod seems to indicate that the hub isn't
working right. You could try plugging the iPod into a different hub or
directly into the computer. Or maybe into a different port of that
On Thursday, 29 March 2007 09:44, Jiri Slaby wrote:
> Hi,
>
> I'm getting this while trying to swsups the machine in -rc5, -rc4 is fine:
>
> Disabling non-boot CPUs
> CPU 1 is now offline
> SMP alternatives: switching to UP code
> CPU1 is down
> swsusp: critical section:
> swsusp: Need to copy 13
Rafael J. Wysocki napsal(a):
> On Thursday, 29 March 2007 09:44, Jiri Slaby wrote:
>> Hi,
>>
>> I'm getting this while trying to swsups the machine in -rc5, -rc4 is fine:
>>
>> Disabling non-boot CPUs
>> CPU 1 is now offline
>> SMP alternatives: switching to UP code
>> CPU1 is down
>> swsusp: criti
Stephane Eranian wrote:
Hi,
On Sun, Mar 25, 2007 at 06:30:34PM +0200, Folkert van Heusden wrote:
I'd say "feature", glibc's malloc also returns an address on
malloc(0).
This is implementation defined-the standard allows for return of either
null or an address.
Entirely for entertainment: AIX
> > If we really care about using the LAPIC timer on systems with deeper
> > than C1 support, the only alternative seems to be to test
> > if it actually works or not at boot and run-time.
> > Otherwise, we wait for future hardware with guaranteed
> > not to break under any (BIOS) conditions ships,
This should be fixed in 2.6.21 as of 2/26. The fix was
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3677db10a635a39f63ea509f8f0056d95589ff90
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us do
On Thu, 29 Mar 2007 10:27:14 +0100 Jan Beulich wrote:
> Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
> the split config tree is built, but failed to also adjust fixdep
> accordingly - if changing a config option from or to m, files
> referencing the respective CONFIG_..._MODULE
Thanks a lot, I will try to update to latest kernel version and see if
it helps.
-Original Message-
From: Steven French [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 5:06 PM
To: Andrew Morton
Cc: Valentin Zaharov; linux-kernel@vger.kernel.org
Subject: Re: cifs causes BUG: soft
"Langsdorf, Mark" <[EMAIL PROTECTED]> writes:
> > > If we really care about using the LAPIC timer on systems with deeper
> > > than C1 support, the only alternative seems to be to test
> > > if it actually works or not at boot and run-time.
> > > Otherwise, we wait for future hardware with guarant
On Thu, 29 Mar 2007, Mark Lord wrote:
> Maxim Levitsky wrote:
> > Hi,
> > I noticed that after suspend/resume cycle all my usb devices are
> > unplugged/replugged by uhci driver.
> > While it is not that big problem to me, that can be a real problem if a
> > device is a flash card with mount
Alan Stern wrote:
On Thu, 29 Mar 2007, Mark Lord wrote:
Mmm.. this sounds really bad -- I wonder what happens if the rootfs is on USB ?
The system crashes as soon as it resumes. As you might expect.
With older kernels, things just "worked" this way. Has it now been broken ??
No; it has
>>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>
>> --- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0
>> +0100
>> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29
>> 11:11:10.0 +0200
>> @@ -29,8 +29,7 @@
>> * option which is mentioned in an
Hi list,
in file mm/slab.c and routine kmem_cache_init() I found there
is no checking for allocated memory on line:
/* 4) Replace the bootstrap head arrays */
{
struct array_cache *ptr;
ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
--
Sid Boyce wrote:
Eric W. Biederman wrote:
Sid I think I have found the problem. Could you try the following
patch. I believe I accidentally switched the sense of a test
diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,
Russ Meyerriecks wrote:
> If anybody has any bug fixes or features maybe they never got
> around to,
http://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED
has 1504 hits right now.
> and would be suitable for this situation,
This may be a problem.
--
Stefan Richter
-=-=-=
On Thu, 29 Mar 2007 17:06:24 +0100 Jan Beulich wrote:
> >>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>
> >> --- linux-2.6.21-rc5/scripts/basic/fixdep.c2007-02-04
> >> 19:44:54.0 +0100
> >> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c 2007-03-29
> >> 11:11:10.00
On 15-Mar-07, John Stoffel wrote:
> Would this explain why recent version of GDM don't find the keyboard
> properly when you boot with a kernel command line of:
>
>kernel ... console=tty0 console=ttyS1,96008N1
>
> until you stop and restart GDM? This was filed under Debian bug
> #406457 (see
From: John Feeney <[EMAIL PROTECTED]>
The 82875 EDAC driver enables an otherwise-hidden PCI device, but
doesn't register it as a PCI device properly. Therefore, the device
list in /proc/bus/pci/devices is different than the tree in
/sys/bus/pci. This usually manifests as the X server failing to
In checking a "make allmodconfig" I noticed that the apm device
(arch/i386/kernel/apm.c) is still using the old pm_send_all setup - I know
the fix is to add suspend/resume hooks but the apm code hasn't been touched
since 2002 and isn't using the new device API (it doesn't even register,
AFAICT,
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks t
On Mon, 2007-03-26 at 21:16 -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/
>
>
> - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU
> scheduler has been added.
make allyesconfig - didn't give me a clea
Hi, Roland, Andrew.
Something really sick is going on with combination of utrace, RCU and ia64.
Below are quickly reproducable oops happenning on 8-way SMP,
my lame-o attempts to decode it, and test program itself.
I checked 2.6.21-rc5 which was OK,
2.6.21-rc5 + linux-2.6.21-current-utrace.patch
Mitch Williams <[EMAIL PROTECTED]> writes:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight. This results in
> i
On Thu, Mar 29, 2007 at 08:58:00AM +0100, Jan Beulich wrote:
> Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
> subsequent pfn-s are also invalid is wrong. Thus replace this by
> explicitly checking against the E820 map.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
> Ac
Hi Jan,
Many thanks for your kind reply.
I know we can use device inode's radix tree to achieve the same goal.
The only downside could be: First, by default, Linux will not add the
data pages into that radix tree. Only when a file is opened in
O_DIRECT, the data pages will be put into dev's radi
Dave,
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8255
Okay. I tracked down the problem with git. Here is what is the submission that
causes the problem:
solaris linux-git # git bisect good
0916bd3ebb7cefdd0f432e8491abe24f4b5a101e is first bad commit
commit 0916bd3ebb
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
>int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
On Thu, 29 Mar 2007, Maxim wrote:
> On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> >
> > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not
> > to use the HPET, and set hpet_virt_address to NULL?)
>
> This is done here
>
> out_nohpet:
> iounmap(hpet_vi
1 - 100 of 263 matches
Mail list logo
