* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > Ok. I will send a separate patch fixing ioremap_nocache on x86.
>
> Appended the patch. x86 folks, please consider for x86 mm git tree.
> Thanks.
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe
On Tue 2007-12-04 20:34:32, Andi Kleen wrote:
> On Tue, Dec 04, 2007 at 09:18:33PM +0200, Avi Kivity wrote:
> > Glauber de Oliveira Costa wrote:
> >> This patch moves the i386 control registers manipulation functions,
> >> wbinvd, and clts functions to system.h. They are essentially the same
> >>
On Sun 2007-12-09 23:50:39, Samuel Thibault wrote:
> Samuel Thibault, le Sun 09 Dec 2007 23:43:49 +0100, a écrit :
> > On big endian machines, /dev/vcsa stores text/attribute bytes in big
> > endian order, while it stores them in little endian order on little
> > endian machines. Is that
On Fri, 14 Dec 2007 23:20:30 PST, Matti Linnanvuori said:
> From: Matti Linnanvuori <[EMAIL PROTECTED]>
>
> /dev/urandom use no uninit bytes, leak no user data
>
> Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
>
> ---
>
> --- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> I believe this will suffer from the issue that was raised: this will
> use udelay() long before loop calibration (and no, we can't just "be
> conservative" since there is no "conservative" value we can use.)
>
> Worse, I suspect that at least the
On Sat, 2007-12-15 at 08:36 +0100, Ingo Molnar wrote:
> * Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> > x86: Use helper in kprobes{32|64}.c
>
> thanks, i've applied your kprobes pre-unification patches to x86.git.
>
> While we are at it, it might be nice to reduce the numbers of checkpatch
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> x86: Use helper in kprobes{32|64}.c
thanks, i've applied your kprobes pre-unification patches to x86.git.
While we are at it, it might be nice to reduce the numbers of checkpatch
warnings:
$ scripts/checkpatch.pl --file
Markus,
i've applied the first 4 patches to x86.git.
another detail: shouldnt this be structured so that the APIs are
introduced in kernel/ptrace.c, and that the architecture offers the
mechanism. (which would thus be ptrace-independent) This would also open
these APIs up to kernel-internal
From: Matti Linnanvuori <[EMAIL PROTECTED]>
/dev/urandom use no uninit bytes, leak no user data
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
+++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
@@
* Markus Metzger <[EMAIL PROTECTED]> wrote:
> Here's the new ptrace BTS API that supports two different overflow
> handling mechanisms (wrap-around and buffer-full-signal) to support
> two different use cases (debugging and profiling).
>
> It further combines buffer allocation and
On 14-12-07 23:05, Chuck Ebbert wrote:
On 12/12/2007 04:05 PM, H. Peter Anvin wrote:
Rene Herman wrote:
By the way, _does_ anyone have a contact at nVidia who could clarify?
Alan maybe? I'm quite curious what they did...
Summary:
Unless after booting with "acpi=off", outputs to port
[EMAIL PROTECTED] wrote:
On Dec 14, 2007 11:37 PM, <[EMAIL PROTECTED]> wrote:
I'll attach these logs since I can't read much into them.
I should do what I say...
It will take a while to finish looking over those logs, but are you using ipv6? If not, please
blacklist the ipv6 module to
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I'd say you hit a networking locking bug and then when trying to report
> that bug, lockdep crashed.
>
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
>
> diff -puN
John Reiser <[EMAIL PROTECTED]> wrote:
>
> If speed matters that much, then please recoup 33 cycles on x86
> by using shifts instead of three divides, such as (gcc 4.1.2):
>
>add_entropy_words(r, tmp, (bytes + 3) / 4);
>
> 0x8140689 :lea0x3(%esi),%eax
> 0x814068c :mov
On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Ray Lee wrote:
> >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
> >> fine. A quick scan of the log between 2.6.24-rc3 and current tip
> >> (-rc5)
On Fri, 14 Dec 2007 18:05:56 -0500
"John Stoffel" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Just fired up 2.6.24-rc5-mm1 on a Dual CPU PIII 550mhz system with 2gb
> of RAM. Got the following error. Let me know if you need more
> details or want me to run tests or make changes. Looks like
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
>
> I suppose we'll have to either introduce a new primitive or just
> go back to using BUG_ON.
Let's do the conservative thing and add a new primitive.
[PATCH] Added BARF_ON/BARF_ON_ONCE
The description of CONFIG_BUG clearly states
Greetings;
When I asked about a sata controller earlier this week, I gave a link to it.
Unforch (maybe) when it actually arrived, the cards box showed a silicon
image chip, and the card had a via. So much for getting what I ordered...
The required module then was sata_via, not sata_uli, and
OMAP has now a list at vger.
Signed-off-by: Dirk Behme <[EMAIL PROTECTED]>
Index: linux-osk/MAINTAINERS
===
--- linux-osk.orig/MAINTAINERS
+++ linux-osk/MAINTAINERS
@@ -3683,7 +3683,7 @@ S: Maintained
TI OMAP MMC INTERFACE
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
> Then I kindly submit that you should instead withdraw the code that
> allows you to use WARN_ON in a condition in the first place.
>
> Note that Dave Jones is currently poking at making WARN_ON
> out-of-line, so you're liable
On Sat, Dec 15, 2007 at 05:31:30PM +1100, Benjamin Herrenschmidt wrote:
>
> That's something I've actually never quite liked... the fact that we
> evaluate the expression anyway. I'm pretty happy with -not- evaluating
> the expression when CONFIG_BUG is on most of the time since whatever is
> in
On Fri, 2007-12-14 at 21:27 +0800, Herbert Xu wrote:
> Hi:
>
> [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off
>
> The description of CONFIG_BUG clearly states that both BUG and
> WARN_ON may be skipped. However, our actual implementation still
> checks the condition on WARN_ON
On Sat, Dec 15, 2007 at 12:12:00AM -0600, Matt Mackall wrote:
>
> I tend to agree with this position, except when it comes to handling
> filesystems, where panic is often (but not always) the right thing to
> do.
Given the choice between crashing the machine or potentially giving
an attacker
Tobias Diedrich <[EMAIL PROTECTED]> wrote:
>
> Meanwhile I added a slab statistic rrd script. Nothing obvious to
> see on ari or yumi yet, but on oni (which after all is the most
> affected by this) I can see 'size_2048' and 'TCPv6' growing
> steadily along with the route cache size (Presumably
On Fri, 2007-12-14 at 12:02 -0600, Matt Mackall wrote:
>
> I added CONFIG_BUG, and I think the current behavior is correct. As
> you've noticed, we have to evaluate condition, it may have
> side-effects. And if code does:
>
> /* this indicates a driver bug, report and fail gracefully */
arch/cris/arch-v10/vmlinux.lds.S
fix boot problem
* too old initcall style. replace INITCALLS macro
* __init_begin, __init_end move for free_initmem()
Note: with this patch kernel boot and mount root,
but after init done, kernel panic at do_signal() ...
ryu
Signed-off-by: Yuusei KUWANA
On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
> >
> > No. The code as written above should reduce to:
> >
> > if (val == NULL)
> > return -EFAULT;
> >
> > If I hadn't wanted to return -EFAULT in this
On Friday 14 December 2007 04:10, Arun Thomas wrote:
> Hi,
>
> My Dell Vostro desktop w/ an Intel E6850 dual-core 3GHz CPU has an 8+
> minute delay during boot. The machine seems to run fine after it
> boots. The problem occurs on the Ubuntu gutsy 2.6.22-14 kernel,
> 2.6.23.9, and 2.6.24-rc5. I
On Fri, Dec 14, 2007 at 11:52:18PM -0600, Matt Mackall wrote:
>
> No. The code as written above should reduce to:
>
> if (val == NULL)
> return -EFAULT;
>
> If I hadn't wanted to return -EFAULT in this case, I would have just written:
>
> WARN_ON(val == NULL);
Well
On Sat, 15 Dec 2007 09:22:00 +0530 Dhaval Giani <[EMAIL PROTECTED]> wrote:
> > Is it really the case that the bug only turns up when you run tests like
> >
> > while echo; do cat /sys/kernel/kexec_crash_loaded; done
> > and
> > while echo; do cat /sys/kernel/uevent_seqnum ; done;
> >
>
On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:13:21 -0500
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Sorry Andrew, I don't know who to forward this problem
On Fri, Dec 14, 2007 at 06:02:06PM -0800, Andrew Morton wrote:
> On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > > The simple way seems to be to malloc a large area, touch every page and
> > > > then look at
On Sat, Dec 15, 2007 at 12:16:59PM +0800, Herbert Xu wrote:
> On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
> >
> > I added CONFIG_BUG, and I think the current behavior is correct. As
> > you've noticed, we have to evaluate condition, it may have
> > side-effects. And if code does:
David P. Reed wrote:
Just a thought for a way to fix the "very early" timing needed to set up
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard "countdown timer" way to delay for n
On Sat, 15 Dec 2007, Adrian Bunk wrote:
> On Wed, Dec 12, 2007 at 05:01:51AM +, Hugh Dickins wrote:
> > On Tue, 11 Dec 2007, Chuck Ebbert wrote:
> > > On 11/28/2007 01:55 PM, Hugh Dickins wrote:
> > > > tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual
> > > > case in
> > >
Introduce queue_ accessors to set and clear queue_flags, which include debug
checks to ensure queue_lock is held. Non-checking versions are provided where
it is known that there can be no parallelism on queue_flags.
Index: linux-2.6/block/elevator.c
All queue_flag manipulations are performed under queue_lock (or eg. during
allocation-time where parallelism isn't a problem). So we can use non-atomic
bitops for these.
Index: linux-2.6/block/elevator.c
===
---
Hi,
This is just an idea I had, which might make request processing a little
bit cheaper depending on queue behaviour. For example if it is getting plugged
unplugged frequently (as I think is the case for some database workloads),
then we might save one or two atomic operations per request.
On Fri, 14 Dec 2007, Andrew Morton wrote:
> On Fri, 14 Dec 2007 15:39:26 -0500
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] wrote:
> > > From: Randy Dunlap <[EMAIL PROTECTED]>
> > >
> > > Make E1000E default to the same kconfig setting as E1000. So people's
> > > machiens
Jean,
I'd like to postpone the corresponding change to the point that
polling i2c patch is merged.
On Dec 15, 2007 12:16 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
>
> On Mon, 10 Dec 2007 17:37:05 +0800, eric miao wrote:
> > Support for PCA9539 as a GPIO chip is separated into two
On Dec 14, 2007 9:27 PM, Larry Finger <[EMAIL PROTECTED]> wrote:
>
> I suspect that mac80211 is doing something that your router does not like. Do
> you have any chance to
> capture the traffic between your computer and the router by using a second
> wireless computer running
> kismet or
On Fri, Dec 14, 2007 at 04:30:08PM -0800, John Reiser wrote:
> There is a path that goes from user data into the pool. This path
> is subject to manipulation by an attacker, for both reading and
> writing. Are you going to guarantee that in five years nobody
> will discover a way to take
>From 0bca662f68e7ffe84f333d7d26df25d846713db2 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c
for the following reasons:
1. there is currently no known users of this driver
2. the
On Fri, Dec 14, 2007 at 12:02:46PM -0600, Matt Mackall wrote:
>
> I added CONFIG_BUG, and I think the current behavior is correct. As
> you've noticed, we have to evaluate condition, it may have
> side-effects. And if code does:
>
> /* this indicates a driver bug, report and fail gracefully
>From b45be77acbf592b9c2085ed03ab5f16d780fa8c7 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA9539 on-chip
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTPUT
and
[updated] support for PCA9539 as a GPIO chip is separated into three patches:
0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander
0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
0003 - gpiolib: obsolete drivers/i2c/chips/pca9539.c
The 2nd one uses workqueue
On Sat, Dec 15, 2007 at 03:55:40AM +0100, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Rafael J. Wysocki wrote:
> > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> > > > On Saturday, 15 of December 2007, Chuck Ebbert
diff --git a/Makefile b/Makefile
index 3f2c4e3..ada10d5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .10
+EXTRAVERSION = .11
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/drivers/char/apm-emulation.c
We (the -stable team) are announcing the release of the 2.6.23.11 kernel.
It fixes two build errors in the 2.6.23.10 kernel. If you have no
problems with 2.6.23.10, then be happy and don't waste the electrons on
downloading another release.
I'll also be replying to this message with a copy of
I'd like to create another thread in LKML for the updated version, sorry.
On Dec 15, 2007 11:56 AM, eric miao <[EMAIL PROTECTED]> wrote:
> OK,
>
> Here's the updated version, which
> 1. modify the author info but still preserve Ben's credit in the source head
> 2. Alphabetic order in
OK,
Here's the updated version, which
1. modify the author info but still preserve Ben's credit in the source head
2. Alphabetic order in Kconfig/Makefile
3. typo fix and corrected Philips to NXP/TI
4. use dev_err instead of printk
5. move module_{init,exit} next to the routines
6. preserve
Hi Steve,
looks like this patch didn't make it into 2.6.23-rc5-rt1.
I refreshed Trem's final version - please review and include in the next
RT release.
Thanks
Sven
On Tue, 2007-11-20 at 23:09 +0100, trem wrote:
> Steven Rostedt wrote:
> > On Fri, 16 Nov 2007, Nelson, Shannon wrote:
> >>
> Is it really the case that the bug only turns up when you run tests like
>
> while echo; do cat /sys/kernel/kexec_crash_loaded; done
> and
> while echo; do cat /sys/kernel/uevent_seqnum ; done;
>
> or will any fork-intensive workload also do it? Say,
>
> while echo ; do
On Fri, Dec 14, 2007 at 06:55:46PM -0800, Randy Dunlap wrote:
> On Fri, 14 Dec 2007 11:49:53 -0800 Greg Kroah-Hartman wrote:
>
> > We (the -stable team) are announcing the release of the 2.6.23.10 kernel.
> > It a number of bugfixes and anyone using the 2.6.23 kernel series is
> > recommended to
Thanks for all your help :-)
Best wishes from Munich,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sat, Dec 15, 2007 at 02:52:56AM +0100, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> > > Freezer: Fix APM emulation breakage
> >
> > drivers/char/apm-emulation.c: In function 'apm_ioctl':
> >
Just a thought for a way to fix the "very early" timing needed to set up
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard "countdown timer" way to delay for n microseconds,
which as
On Fri, 14 Dec 2007 11:49:53 -0800 Greg Kroah-Hartman wrote:
> We (the -stable team) are announcing the release of the 2.6.23.10 kernel.
> It a number of bugfixes and anyone using the 2.6.23 kernel series is
> recommended to upgrade.
>
> I'll also be replying to this message with a copy of the
Tino Keitel wrote:
Hi folks,
I often build Debian packages inside a chroot. Today I discovered a
failure during an "aptitude update", which is a command to download new
package lists for the package management. In strace, the lines around
the failure look like this:
99% [Working]) = 14
Michael Kühn wrote:
Hi,
my first kernel patch, yay. :-)
On the file drivers/ata/ahci.c in line 1433 is declared a variable that
is never used in the function. I removed it.
Patch is in attachments (based on 2.6.23.10).
...
You'll need to do:
(1) repost it, but this time to [EMAIL
Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Ray Lee wrote:
>> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
>> fine. A quick scan of the log between 2.6.24-rc3 and current tip
>> (-rc5) doesn't show any obvious fixes, but then again, what do I know.
>> I'll check
On Saturday, 15 of December 2007, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> > > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> > >>>
[EMAIL PROTECTED] wrote:
Could this be the reason my BCM94311MCG rev 1 receives such terrible
performance with b43 but works well with bcm43xx? The device is
802.11b/g but my router is 802.11b. I filed a report on this issue
here: https://bugzilla.redhat.com/show_bug.cgi?id=413291
No. On my
David P. Reed wrote:
I believe (though no one seems to have confirming documentation from the
chipset or motherboard vendor) that port 80 is actually functional for
some unknown function on these machines. (They do respond to "in"
instructions faster than a bus cycle abort does - more
On Sat, 2007-12-15 at 09:11 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2007-12-14 at 06:52 -0500, Jon Masters wrote:
> > On Thu, 2007-12-13 at 14:00 +1100, Benjamin Herrenschmidt wrote:
> > > While reworking the powerpc PCI resource management, to make it more
> > > x86-like and use more of
Avi Kivity wrote:
kvm will forward a virtual machine's writes to port 0x80 to the real
port. The reason is that the write is much faster than exiting and
emulating it; the difference is measurable when compiling kernels.
Now if the cause is simply writing to port 0x80, then we must stop
On Sat, 15 Dec 2007 01:09:41 + Mel Gorman <[EMAIL PROTECTED]> wrote:
> On (13/12/07 14:29), Andrew Morton didst pronounce:
> > > The simple way seems to be to malloc a large area, touch every page and
> > > then look at the physical pages assigned ... they now mostly seem to be
> > >
On Dec 14, 2007 7:58 PM, Larry Finger <[EMAIL PROTECTED]> wrote:
> Rafael J. Wysocki wrote:
> >
> > Actually, can you explain why, from the technical point of view, the
> > version 4
> > firware is better than version 3, please?
>
> I will be very interested in Michael's answer to this question;
On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> >>> Freezer: Fix APM emulation breakage
> >>
Tejun Heo wrote:
Dec 14 01:06:33 fermat kernel: ata1: EH in ADMA mode, notifier 0x0
notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0
next
cpb idx 0x0
Dec 14 01:06:33 fermat kernel: ata1: CPB 0: ctl_flags 0x1f, resp_flags
0x2
Dec 14 01:06:33 fermat kernel: ata1: CPB 1:
On Friday, 14 of December 2007, Ray Lee wrote:
> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
> fine. A quick scan of the log between 2.6.24-rc3 and current tip
> (-rc5) doesn't show any obvious fixes, but then again, what do I know.
> I'll check current tip on the weekend
On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Chuck Ebbert wrote:
>> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
>>> Freezer: Fix APM emulation breakage
>> drivers/char/apm-emulation.c: In function 'apm_ioctl':
>> drivers/char/apm-emulation.c:370:
Hi Alan.
On Fri, 2007-12-14 at 22:24 +, Alan Cox wrote:
> Can you reproduce this without the Nvidia stuff ?
No,.. I'm running for about 2 years now with propreitary nvidia gpu
module,.. but I've never encountered that problem before.
Anyway,... I might have just missed it...
Ah and by the
On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> > Freezer: Fix APM emulation breakage
>
> drivers/char/apm-emulation.c: In function 'apm_ioctl':
> drivers/char/apm-emulation.c:370: error: implicit declaration of function
>
On Dec 14 2007 17:11, Gosney, JeremiX wrote:
>Subject: ARP Bug?
>
>We've noticed the 2.6-based Linux systems in our test lab are
>experiencing some "ARP flux"-like symptoms.
>
>The systems reply with eth0's hardware address to all ARP requests,
If you have the same subnet on multiple
We've noticed the 2.6-based Linux systems in our test lab are
experiencing some "ARP flux"-like symptoms.
The systems reply with eth0's hardware address to all ARP requests,
regardless of the IP being queried. Because of this, the system will
only send and receive packets on eth0; if eth0 is
On (13/12/07 14:29), Andrew Morton didst pronounce:
> > The simple way seems to be to malloc a large area, touch every page and
> > then look at the physical pages assigned ... they now mostly seem to be
> > descending in physical address.
> >
>
> OIC. -mm's /proc/pid/pagemap can be used to get
On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
> >
> > * Michael Buesch <[EMAIL PROTECTED]> wrote:
> >
> > > In my opinion this all is the work of the distributions and not the
> > > work of the kernel developers. Distributions
Consolidate printk and insert CPU id to cleanup SMP interleaved output.
In SMP, the machine check exception dispatches all logical processors
within a physical package to the machine-check exception handler, so the
printk within each handler outputs concurrently and makes the output
unreadable.
On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> Freezer: Fix APM emulation breakage
drivers/char/apm-emulation.c: In function 'apm_ioctl':
drivers/char/apm-emulation.c:370: error: implicit declaration of function
'wait_event_freezable'
make[2]: *** [drivers/char/apm-emulation.o] Error
Rafael J. Wysocki wrote:
Actually, can you explain why, from the technical point of view, the version 4
firware is better than version 3, please?
I will be very interested in Michael's answer to this question; however, my experience is that it
doesn't make much difference if your device is
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/kprobes_32.c | 18 +++---
arch/x86/kernel/kprobes_64.c | 14 --
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/kprobes_32.c b/arch/x86/kernel/kprobes_32.c
index
On Dec 14, 2007 6:17 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> does processor.max_cstate=1 make the failing configuration work?
> If yes, how about processor.max_cstate=2?
Until now 2 things were necessary to reproduce the problem -
1) CPU_IDLE=y and
2) Wakeups from Idle = 5-7 Per second (==
Andrew Morton wrote:
On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
The http://www.kerneloops.org website collects kernel oops and warning
reports from various mailing lists and bugzillas
Well that would have been fun to write. Does it watch
Arun Thomas wrote:
On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Thomas Gleixner wrote:
The problem is caused by an SMI during the calibration routine. We
really need to come up with a solid solution which does not rely on
the periodic timer coming in, when there is
On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > This user did get the following messages in dmesg:
> > >
> > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > >"or load failed.\n", path);
> >
> > So the
Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
Theodore Tso wrote:
> On Fri, Dec 14, 2007 at 12:45:23PM -0800, John Reiser wrote:
>
>>>It's getting folded into the random number pool, where it will be
>>>impossible to recover it unless you already know what was in the
>>>pool. And if you know what's in the pool, you've already broken into
This is a note to let you know that I've just added the patch titled
Subject: Add Documentation for FAIR_USER_SCHED sysfs files
to my gregkh-2.6 tree. Its filename is
add-documentation-for-fair_user_sched-sysfs-files.patch
This tree can be found at
On Wed, Dec 12, 2007 at 05:01:51AM +, Hugh Dickins wrote:
> On Tue, 11 Dec 2007, Chuck Ebbert wrote:
> > On 11/28/2007 01:55 PM, Hugh Dickins wrote:
> > > tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case
> > > in
> > > which shmem_getpage receives the page from its
On Fri, 14 Dec 2007 17:35:13 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 12/14/2007 05:17 AM, Andi Kleen wrote:
> >> so do whatever is necessary to enable dynticks.
> >
> > dynticks' main purpose is to save power, but C1e saves more power.
> > Disabling C1e for dynticks would be a fairly
On Fri, Dec 14, 2007 at 06:17:55PM -0500, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> On Fri, Dec 14, 2007 at 03:39:26PM -0500, Jeff Garzik wrote:
>>> [EMAIL PROTECTED] wrote:
From: Randy Dunlap <[EMAIL PROTECTED]>
>>> ...
>>> So I think the breakage that occurs is mitigated by two factors:
On Dec 14, 2007 2:01 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Thomas Gleixner wrote:
> >
> > The problem is caused by an SMI during the calibration routine. We
> > really need to come up with a solid solution which does not rely on
> > the periodic timer coming in, when there is something
Andrew Morton wrote:
On Fri, 14 Dec 2007 15:39:26 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
From: Randy Dunlap <[EMAIL PROTECTED]>
Make E1000E default to the same kconfig setting as E1000. So people's
machiens don't stop working when they use oldconfig.
bloat-o-meter assumes that a '.' anywhere in a symbol's name means
that it is static and prepends 'static.' to the first part of the
symbol name, discarding the portion of the name that follows the '.'.
However, the names of function entry points begin with '.' in the
ppc64 ABI. This causes all
On Fri, 14 Dec 2007 14:13:46 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Pavel Machek wrote:
> > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
> >> Ingo Molnar wrote:
> >>> wow, cool fix! (I remember that there were other systems as well that are
> >>> affected by port 0x80 muckery -
On Fri, 14 Dec 2007 17:13:21 -0500
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> Sorry Andrew, I don't know who to forward this problem to.
>
> I tried running: find /proc | xargs cat
> and got this:
>
> =
> [ INFO: inconsistent lock state ]
> 2.6.24-rc5-mm1 #26
>
On Fri, Dec 14, 2007 at 01:10:39PM -0800, Siddha, Suresh B wrote:
> On Thu, Dec 13, 2007 at 09:23:26PM -0700, Eric W. Biederman wrote:
> > [EMAIL PROTECTED] (Eric W. Biederman) writes:
> > Ok. My analysis here was wrong. Currently pgprot_noncached and
> > ioremap_nocache are out of sync. With
On Fri, Dec 14, 2007 at 12:45:23PM -0800, John Reiser wrote:
> > It's getting folded into the random number pool, where it will be
> > impossible to recover it unless you already know what was in the
> > pool. And if you know what's in the pool, you've already broken into
> > the kernel.
>
> The
1 - 100 of 928 matches
Mail list logo
