On Thursday 12 April 2007 12:12, Al Viro wrote:
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
This is needed for computing pathnames in the AppArmor LSM.
Which is an argument against said LSM in current form.
The fundamental model of AppArmor is to perform access checks
Has there been any measurable benefit yet due to tail padding?
We don't have data that tail padding actually helps. It all
depends on what data the linker lays out in the cachelines.
As of now we just want to create the infrastructure (so that
more and more people who need it, can use it).
It
I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
scheduled to go away most of a year ago. My question is what replaces it:
Does #define inline __always_inline become the new standard and uses of
__always_inline be removed, or should all instances of inline either be
Add a TestSetPageError() macro to the suite of page flag manipulators. This
can be used by AFS to prevent over-excision of rejected writes from the page
cache.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
include/linux/page-flags.h |1 +
1 files changed, 1 insertions(+), 0
Add a function - cancel_rejected_write() - to excise a rejected write from the
pagecache. This function is related to the truncation family of routines. It
permits the pages modified by a network filesystem client (such as AFS) to be
excised and discarded from the pagecache if the attempt to
Improve the handling of the case of a server rejecting an attempt to write back
a cached write. AFS operates a write-back cache, so the following sequence of
events can theoretically occur:
CLIENT 1CLIENT 2
=== ===
Implement shared-writable mmap for AFS.
The key with which to access the file is obtained from the VMA at the point
where the PTE is made writable by the page_mkwrite() VMA op and cached in the
affected page.
If there's an outstanding write on the page made with a different key, then
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using pci_alloc_consistent calls for these
allocations to more accurately acquire memory within the 31 bit
On 05/23/2007 07:04 PM, Randy Dunlap wrote:
That's a good source of confusion. To me, notime means something
like don't bother calculating time, instead of the proposed
behavior. Can't it be something like 'nologts' (no log timestamps)
or nots or notimestamps or nologtime instead?
nologtime
On Wed, May 23, 2007 at 12:09:56PM -0700, Yu, Fenghua wrote:
Has there been any measurable benefit yet due to tail padding?
We don't have data that tail padding actually helps. It all
depends on what data the linker lays out in the cachelines.
As of now we just want to create the
On Wed, 23 May 2007, Alan Cox wrote:
Add the needed constants and defines to activate the existing code.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-m68k/ioctls.h
* Rene Herman [EMAIL PROTECTED] wrote:
The trouble there is that unless you poll the bloody thing like mad
too much of the Q subchannels passes below you and you need a huge
number of retries to get anything out of it. I noticed when I started
adding audio bits that the driver took full
driver was snappy in that regard. When I replaced our sleeping loop with a
busy-wait same as the original the snappyness returned and moreover, reading
the TOC from the CD went from something close to a minute to approximately a
second. Thought that minute was just because I was dealing
Chris Malton wrote:
And where, may I ask, does one find the source of Google's modified
kernel? (At least, the unmodified bits!)
Google does not distribute their software, so they do not have to make
their modifications public.
WRT the Linux kernel, Google is essentially a closed source
On Wed, 23 May 2007 12:20:05 -0700 Ravikiran G Thirumalai [EMAIL PROTECTED]
wrote:
On Wed, May 23, 2007 at 12:09:56PM -0700, Yu, Fenghua wrote:
Has there been any measurable benefit yet due to tail padding?
We don't have data that tail padding actually helps. It all
depends on what
On Wed, May 23, 2007 at 03:02:19PM -0400, David Woodhouse wrote:
$ make headers_check
$ sed -i /auxvec.h/d include/asm/Kbuild
$ make headers_check
$ sed -i /auxvec.h/d include/asm-generic/Kbuild.asm
$ make headers_check
Why doesn't it recheck linux/auxvec.h and fail?
Because asm/auxvec.h
Hi Nitin,
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
[...]
diff --git a/Makefile b/Makefile
index 34210af..88053ba 100644
--- a/Makefile
+++ b/Makefile
@@ -826,11 +826,18 @@ include/config/kernel.release:
include/config/auto.conf FORCE
# Listed in dependency order
PHONY += prepare
On Wed, 23 May 2007 15:17:08 -0400
Salyzyn, Mark [EMAIL PROTECTED] wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using pci_alloc_consistent
From: Tim Gardner [EMAIL PROTECTED]
Subject: [PATCH] Work around Dell E520 BIOS reboot bug.
Force Dell E520 to use the BIOS to shutdown/reboot.
Signed-off-by: Tim Gardner [EMAIL PROTECTED]
---
I have at least one report that this patch fixes shutdown/reboot
problems on the Dell E520 platform.
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
I get a forbidden
On 05/23/2007 09:28 PM, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
The trouble there is that unless you poll the bloody thing like mad
too much of the Q subchannels passes below you and you need a huge
number of retries to get anything out of it. I noticed when I started
On Wed, 2007-05-23 at 21:34 +0200, Sam Ravnborg wrote:
On Wed, May 23, 2007 at 03:02:19PM -0400, David Woodhouse wrote:
$ make headers_check
$ sed -i /auxvec.h/d include/asm/Kbuild
$ make headers_check
$ sed -i /auxvec.h/d include/asm-generic/Kbuild.asm
$ make headers_check
Why
On 05/23/2007 09:34 PM, Alan Cox wrote:
driver was snappy in that regard. When I replaced our sleeping loop with a
busy-wait same as the original the snappyness returned and moreover, reading
the TOC from the CD went from something close to a minute to approximately a
second. Thought that
Rob Landley wrote:
I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
scheduled to go away most of a year ago. My question is what replaces it:
Does #define inline __always_inline become the new standard and uses of
__always_inline be removed, or should all instances of
On Wed, 23 May 2007 13:51:51 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 11:26 -0700, Kristen Carlson Accardi wrote:
On Wed, 23 May 2007 12:03:55 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:31 -0700, Kristen Carlson Accardi wrote:
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
Where is `struct termios2' defined? Right now it doesn't compile because
of that.
Sorry, shortage of qualified gnomes:
* Nicolas Mailhot [EMAIL PROTECTED] wrote:
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
Google does not distribute their software, so they do not have to make
their modifications public.
They do for the kernel - they produce an appliance.
WRT the Linux kernel, Google is essentially a closed source company.
They've quietly fed little bits back now and then but not made a big
Remove forgotten reference to 'cpu_khz' which have been removed for PowerPC in
2.6.21-rt7...
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
---
The irony here is that it was me who sent a patch to add that line. :-)
Index: linux-2.6/arch/powerpc/kernel/time.c
Le mercredi 23 mai 2007 à 21:57 +0200, Ingo Molnar a écrit :
* Nicolas Mailhot [EMAIL PROTECTED] wrote:
Ingo Molnar mingo at elte.hu writes:
Hi Ingo
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10
Alan Cox wrote:
Google does not distribute their software, so they do not have to make
their modifications public.
They do for the kernel - they produce an appliance.
Ah, I stand corrected.
WRT the Linux kernel, Google is essentially a closed source company.
They've quietly fed little
On Wed, May 23, 2007 at 03:40:25PM -0400, David Woodhouse wrote:
On Wed, 2007-05-23 at 21:34 +0200, Sam Ravnborg wrote:
On Wed, May 23, 2007 at 03:02:19PM -0400, David Woodhouse wrote:
$ make headers_check
$ sed -i /auxvec.h/d include/asm/Kbuild
$ make headers_check
$ sed -i
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using the original 40-pin IDE ribbon cable) and two
HighPoint HPT366 controllers, taking the 80-pin
On Wed, 23 May 2007 15:11:18 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact have reliable
enable bits.
-
To unsubscribe
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value anyway
before moving on to the 32 bit probe which is where I think the problem
is.
Well, the thing is, I'm pretty
Hello.
Linas Vepstas wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using the original 40-pin IDE ribbon cable) and two
You should have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- [ cut here ]
Badness at mm/slab.c:777
Call Trace:
[effd7d60] [c0008478] show_stack+0x50/0x184 (unreliable)
[effd7d80] [c00fc948] report_bug+0x84/0xc8
[effd7d90] [c0228af4] __kprobes_text_start+0x11c/0x4f0
[effd7da0]
Hello.
Alan Cox wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact have reliable
enable bits.
HPT36x either didn't have them yet or they were located in
Well, the thing is, I'm pretty sure there is at least one northbridge that
stops memory accesses from the CPU when you turn off the MEM bit on it.
Oops, you just killed the machine.
CS5520. But it doesn't have 64bit or PCI Express.
Alan
-
To unsubscribe from this list: send the line
Greg KH wrote:
[]
From: Kay Sievers [EMAIL PROTECTED]
Subject: Driver core: convert block from raw kobjects to core devices
This moves the block devices to /sys/class/block. It will create a
flat list of all block devices, with the disks and partitions in one
directory. For compatibility
Greg KH wrote:
[]
From: Kay Sievers [EMAIL PROTECTED]
Subject: Driver core: convert block from raw kobjects to core devices
This moves the block devices to /sys/class/block. It will create a
flat list of all block devices, with the disks and partitions in one
directory. For compatibility
On Wed, 23 May 2007, Alan Cox wrote:
+#define TCSETS2 _IOW('T',0x2B, struct termios2)
+#define TCSETSW2 _IOW('T',0x2C, struct termios2)
+#define TCSETSF2 _IOW('T',0x2D, struct termios2)
Where is `struct termios2' defined? Right now it doesn't compile because
of that.
Hi,
Hi,
On Tuesday 22 May 2007 18:23, Emmanuel Fusté wrote:
Hello,
Just to let you know that since I jumped from 2.6.16 to
2.6.20.7 and 2.6.21, I need the i8042.noloop option to get the
AUX port detected.
Without this option, the kernel silently omit the AUX port,
only the KBD
.
I did run, again, glitch1 on my laptop (T2500 CoreDuo, also Nvidia)
please check: http://www.debianpt.org/~elmig/pool/kernel/20070523/
Thanks, those data seem as expected.
--
bill davidsen [EMAIL PROTECTED]
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Wed, 23 May 2007, Alan Cox wrote:
Well, the thing is, I'm pretty sure there is at least one northbridge that
stops memory accesses from the CPU when you turn off the MEM bit on it.
Oops, you just killed the machine.
CS5520. But it doesn't have 64bit or PCI Express.
That patch
On Wed, 23 May 2007 21:15:20 +0200 Rene Herman wrote:
On 05/23/2007 07:04 PM, Randy Dunlap wrote:
That's a good source of confusion. To me, notime means something
like don't bother calculating time, instead of the proposed
behavior. Can't it be something like 'nologts' (no log
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value
anyway before moving on to the 32 bit probe which is where I
On Wednesday, 23 May 2007 19:48, Matt Mackall wrote:
On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 23 May 2007, Rafael J. Wysocki wrote:
While I agree with that, it would really be helpful if you tested the
latest -rc
kernel and saw if the bug
On Mon, 21 May 2007, Heiko Carstens wrote:
On Sun, May 20, 2007 at 09:29:49PM +0200, Thomas Gleixner wrote:
On Sun, 2007-05-20 at 21:18 +0200, Heiko Carstens wrote:
Hmm, that's a different problem than the 0x22 which shows up on
hyperthreading enabled P4 systems. Are you using plip ?
No,
On Wed, 23 May 2007, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing around
would make a difference, since we'd restore its original value
anyway before
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:20 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
Fixed it (finally). I don't think moving the 64 bit probing
around would make a
thanks for testing.
I did run, again, glitch1 on my laptop (T2500 CoreDuo, also Nvidia)
please check: http://www.debianpt.org/~elmig/pool/kernel/20070523/
Thanks, those data seem as expected.
These numbers are from a different machine (this has 2 cores).
The other machine it's Debian
Christoph Lameter napisał(a):
On Wed, 23 May 2007, Michal Piotrowski wrote:
Christoph, this looks like a bug in SLUB.
Please boot with slub_debug to find the bad code that overwrites a slab
object after it was freed.
[ 19.096577] Real Time Clock Driver v1.12ac
[ 21.650315] ***
On 05/23/2007 04:24 PM, Alan Cox wrote:
On Wed, 23 May 2007 15:11:18 -0500
[EMAIL PROTECTED] (Linas Vepstas) wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
HPT366 fixes were posted here earlier. It doesn't in fact
Jesse Barnes wrote:
Apparently Vista will move away from using type 1 config space accesses
though, so if we keep using it, we'll probably run into some lame board
Yep.
that assumes you're using mmconfig at some point in the near future.
But then again, we're often on that less tested
Uncompressing Linux .. Ok, booting the kernel.
BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
vendor)
PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0
This message is about device 01:00.0 as it says (your nvidia video
card based on later
So what we have now is space wastage on some architectures, space
savings on
some, but with no measurable performance benefit due to the
infrastructure
itself. Why not push the infrastructure when we really need it, as
against
pushing it now when we are not sure if it benefits?
It makes
On Wed, May 23, 2007 at 10:56:27PM +0200, Rafael J. Wysocki wrote:
On Wednesday, 23 May 2007 19:48, Matt Mackall wrote:
On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 23 May 2007, Rafael J. Wysocki wrote:
While I agree with that, it would really be
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Not for systems with PCIe... and the platforms I've been having
trouble with have PCIe slots, so I'd really like mmconfig to be
used at least on machines with PCIe bridges. For other machines,
it probably doesn't matter much. I
On Wed, May 23, 2007 at 12:42:47PM -0700, Arjan van de Ven wrote:
Rob Landley wrote:
I notice that feature-removal-schedule.txt has CONFIG_FORCED_INLINING
scheduled to go away most of a year ago. My question is what replaces it:
Does #define inline __always_inline become the new standard and
- every static function in a header file must be __always_inline
Why? Why does it matter whether a function is defined in a .h file or
a .c file? Can't the compiler decide better than we can whether
something should be inlined or not?
Your argument seems to imply that we should never use the
Why not `#define termios2 ktermios' (or vice versa) on platforms where
they are the same?
Because #define is a bit of a loose cannon when it comes to substitutions
and I didn't want nasty suprises. Also because ktermios may change in
future and I don't want to have to liase with 4 million port
Cliff Wickman wrote:
In order to do this, move_task_off_dead_cpu() must make a call to
cpuset_cpus_allowed(), which may block.
move_task_off_dead_cpu() has been within a critical region when called
from migrate_live_tasks(). So this patch also changes migrate_live_tasks()
to enable
From: Ingo Molnar [EMAIL PROTECTED]
Date: Wed, 23 May 2007 13:40:21 +0200
* Herbert Xu [EMAIL PROTECTED] wrote:
[NET_SCHED]: Fix qdisc_restart return value when dequeue is empty
My previous patch that changed the return value of qdisc_restart
incorrectly made the case where dequeue
Adrian Bunk wrote:
What about performance reasons?
We habe inline code in header files that heavily relies on being
nearly completely optimized away after being inlined.
fair
Especially with -Os it could even sound logical for a compiler to never
inline a non-forced inline'd three line
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space in
PCI-Express, rather than being locked into the 256-byte legacy PCI
config space.
Mostly for treacherous computing extensions where subsets of the config
space
Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space in
PCI-Express, rather than being locked into the 256-byte legacy PCI
config space.
Mostly for treacherous computing extensions where subsets of
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space
in PCI-Express, rather than being locked into the 256-byte legacy
PCI config space.
Mostly for treacherous
Jesse Barnes wrote:
On Wednesday, May 23, 2007 2:35 pm Alan Cox wrote:
One of the reasons why hardware vendors want to move away from
traditional accesses is to be able to use the larger config space
in PCI-Express, rather than being locked into the 256-byte legacy
PCI config space.
Mostly for
Andi Kleen wrote:
your patch did not work. See the correction below. The mask should contain
11 instead of 1.
Model 10 is now also included.
Ok thanks fixed.
For newsetup, did we agree to just go with model = 6 or (model = 6
model = 10)? Note that newsetup only does the MSR writes if
On Thu, May 24, 2007 at 12:26:29AM +0400, Sergei Shtylyov wrote:
Hello.
Linas Vepstas wrote:
I've got a rather old x86 box that I'm booting 2.6.21.1 on;
this kernel is not finding an ide controller on it.
The motherboard has 4 ide controllers total; two olde-fashioned
ones (PIIX4, using
On Wed, 23 May 2007, Jesse Barnes wrote:
You told it to not forward memory. Why complain when it does as told?
Well, because that's not actually very useful functionality, and likely
makes software that seems obviously correct wrt the PCI spec break.
I agree that a chip that doesn't do
On Wed, May 23, 2007 at 12:33:11PM +0200, Ingo Molnar wrote:
* Peter Zijlstra [EMAIL PROTECTED] wrote:
...
It also measures lock wait-time and hold-time in nanoseconds. The
minimum and maximum times are tracked, as well as a total (which
together with the number of event can give the
Jeff Garzik [EMAIL PROTECTED] :
Alan Cox wrote:
[...]
They've quietly fed little bits back now and then but not made a big song
and dance about it. Hopefully with Andrew there and the like more will
occur.
Strange that the NIC and SATA driver bits never seem to be among those
little
On Wed, 23 May 2007 23:05:24 +0200
Michal Piotrowski [EMAIL PROTECTED] wrote:
Christoph Lameter napisa__(a):
On Wed, 23 May 2007, Michal Piotrowski wrote:
Christoph, this looks like a bug in SLUB.
Please boot with slub_debug to find the bad code that overwrites a slab
object after
On Wednesday, May 23, 2007 2:54 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
You told it to not forward memory. Why complain when it does as
told?
Well, because that's not actually very useful functionality, and
likely makes software that seems obviously correct
Roland Dreier wrote:
Uncompressing Linux .. Ok, booting the kernel.
BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
vendor)
PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0
This message is about device 01:00.0 as it says (your nvidia video
We (the -stable team) are announcing the release of the 2.6.21.2 kernel.
This release has a large number of bugfixes in many areas.
I'll also be replying to this message with a copy of the patch between
2.6.21.1 and 2.6.21.2
The updated 2.6.21.y git tree can be found at:
This can end up running kthread_stop() against an already-exited task.
I don't think so since cifs_demultiplex_thread waits sufficiently long
before
exit but after setting srvTcp-tsk to zero (the wait is immediately after
waking up any processes that may be blocked on requests on this socket
On Wed, 23 May 2007, Jesse Barnes wrote:
How are those boards going to set up mmconfig? The whole standard is
broken, since there is no way to set it up.
Trust the firmware? What a piece of crap!
What do you mean? You set it up the normal way, by poking at config
space to see
--- Christoph Lameter [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007, Srihari Vijayaraghavan wrote:
I'm personally very happy that slub works stably without slub debug
options,
because that's what I'd run in a production env. Thanks to your patch,
slub is
quite stable without the slub
On Wed, 23 May 2007, Michal Piotrowski wrote:
[ 19.096577] Real Time Clock Driver v1.12ac
[ 21.650315] *** SLUB kmalloc-8: Redzone [EMAIL PROTECTED] slab 0xc528c530
[ 21.657365] offset=3360 flags=0x40c3 inuse=61 freelist=0xc90f6d58
[ 21.664349] Bytes b4 0xc90f6d10: 00 00 00
If i uncomment the saa716x_read or write, what i get is a solid freeze
on module load. If i leave it commented out, the module loads fine.
That sounds like a typical bug during driver development... you're
probably wedging the hardware by doing the wrong access.
I didn't see the source for
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Ehh. Even for PCIe, why not use the normal accesses for the first 256
bytes? Problem solved.
Ok, this patch also works. We still need to enable mmconfig space for
PCIe
On 24/05/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007 23:05:24 +0200
Michal Piotrowski [EMAIL PROTECTED] wrote:
Christoph Lameter napisa__(a):
On Wed, 23 May 2007, Michal Piotrowski wrote:
Christoph, this looks like a bug in SLUB.
Please boot with slub_debug to find
On Wed, 23 May 2007, Andrew Morton wrote:
argh, I never 100% understood the slab gobbledygook, and now we have slub
gobbledygook. I _hope_ what that's saying is that the 00 at 0xc90f6d28
wasn't supposed to be there.
Exactly. I tried to make the SLUB gobbledygook better. Any other ideas on
On Wednesday, May 23, 2007 3:16 pm Linus Torvalds wrote:
On Wed, 23 May 2007, Jesse Barnes wrote:
How are those boards going to set up mmconfig? The whole standard
is broken, since there is no way to set it up.
Trust the firmware? What a piece of crap!
What do you mean? You set
On Wednesday, May 23, 2007 3:24 pm Olivier Galibert wrote:
On Wed, May 23, 2007 at 02:20:23PM -0700, Jesse Barnes wrote:
On Wednesday, May 23, 2007 1:56 pm Linus Torvalds wrote:
Ehh. Even for PCIe, why not use the normal accesses for the first
256 bytes? Problem solved.
Ok, this patch
On Thu, 24 May 2007, Srihari Vijayaraghavan wrote:
I'm stunned. Honestly, I have no possible explanations for this behaviour. Do
you? I need more time to work out (until otherwise you might know a reason).
Hmmm... Bad. We have conflicting reports and no clear way to trigger the
bug. This may
On Wed, 23 May 2007 15:27:28 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Wed, 23 May 2007, Andrew Morton wrote:
argh, I never 100% understood the slab gobbledygook, and now we have slub
gobbledygook. I _hope_ what that's saying is that the 00 at 0xc90f6d28
wasn't supposed
Alan Cox [EMAIL PROTECTED] writes:
ddiff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h
linux-2.6.22-rc1-mm1/include/asm-arm/termbits.h
--- linux.vanilla-2.6.22-rc1-mm1/include/asm-arm/termbits.h 2007-04-30
Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature
will be enabled automatically by current acpi-cpufreq driver and cpufreq.
Refer to Intel Software Developer's Manual for more details about the feature.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index:
On Thu, 24 May 2007, Olivier Galibert wrote:
Isn't that a mac-intel instant killer? AFAIK they don't have type1,
period.
mac-intel are totally standard Intel chipsets. They have all of
conf1/conf2/mmconfig afaik.
I just happily booted my mac-mini with pci=nommconf, nothing bad
happened,
On 5/23/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Tue, 22 May 2007, Ray Lee wrote:
On 5/22/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
We don't agree there, as you are not talking about a stable kernel series.
Ah, so you're planning on submitting these patches
On Wednesday, May 23, 2007 3:48 pm Linus Torvalds wrote:
On Thu, 24 May 2007, Olivier Galibert wrote:
Isn't that a mac-intel instant killer? AFAIK they don't have
type1, period.
mac-intel are totally standard Intel chipsets. They have all of
conf1/conf2/mmconfig afaik.
I just happily
On Thu, May 24, 2007 at 01:29:02AM +0400, Oleg Nesterov wrote:
Cliff Wickman wrote:
In order to do this, move_task_off_dead_cpu() must make a call to
cpuset_cpus_allowed(), which may block.
move_task_off_dead_cpu() has been within a critical region when called
from
On Wed, May 23, 2007 at 10:15:10AM -0700, Christoph Lameter wrote:
On Wed, 23 May 2007, Russell King wrote:
That is wrong. ppc should have ZONE_NORMAL and no ZONE_DMA.
Otherwise you cannot switch off ZONE_DMA and you cannot switch off
bounce. ZONE_DMA is a zone for exceptional allocs.
Roland Dreier wrote:
If i uncomment the saa716x_read or write, what i get is a solid freeze
on module load. If i leave it commented out, the module loads fine.
That sounds like a typical bug during driver development... you're
probably wedging the hardware by doing the wrong access.
I
From: Linus Torvalds [EMAIL PROTECTED]
Date: Wed, 23 May 2007 15:16:23 -0700 (PDT)
That crap should be seen for the crap it is! Dammit, how hard can it
be to just admit that mmconfig isn't that great?
I knew mmconfig was broken conceptually the first time I started
seeing write posting bug
Jesse Barnes wrote:
On Tuesday, May 22, 2007 6:06 pm Robert Hancock wrote:
There was a big discussion about this back in 2002, in which Linus
wasn't overly enthused about disabling the decode during probing due
to risk of causing problems with some devices:
http://lkml.org/lkml/2002/12/19/145
801 - 900 of 1026 matches
Mail list logo
