On Thu, 13 Dec 2007 15:03:07 +
> + if (mm != active_mm) {
> + /* Restore region IDs for mm */
> + if (mm && active_mm) {
> + activate_context(mm);
> + } else {
> + flush_tlb_all();
> +
[EMAIL PROTECTED] wrote:
>
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link
Theodore Tso wrote:
On Mon, Dec 17, 2007 at 08:30:05AM -0800, John Reiser wrote:
[You have yet to show that...]
There is a path that goes from user data into the pool.
Note particularly that the path includes data from other users.
Under the current implementation, anyone who accesses
Hi Ingo,
The following patch applies to sched-devel to replace the root-domain patch
that was reverted as noted here:
http://marc.info/?l=linux-mm-commits=119793598429477=2
I have confirmed that it builds and boots clean, and it passes checkpatch.
However, my test machine seems to be
On Mon, 17 Dec 2007 14:17:26 +0100
Lukas Hejtmanek <[EMAIL PROTECTED]> wrote:
> Hello,
>
> does /proc/sys/vm/swappiness still work as expected?
> # /proc/sys/vm# cat swappiness
> 0
>
> but scp-ing 2GB file causes many processes are swapped out due to increase of
> the file cache size. Why?
Hi,
This series integrate the processor.h header. There are a lot of things
that are deeply architectural differences between architectures, but
I've done my best to come to a settlement.
With this series, I am very close to have selectable paravirt for x86_64,
It applies ontop of today's x86
This patch wipes out the definitions of tsc_disable from processor_32.h
and move it to tsc.h, were it belongs
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor_32.h |7 ---
include/asm-x86/tsc.h |6 ++
2 files changed, 6
This patch moves the (duplicated) desc_empty implementation to desc.h,
where the descriptor things belong.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/desc.h |6 ++
include/asm-x86/processor_32.h |6 --
include/asm-x86/processor_64.h |
There's no need for the *_MASK flags (TF_MASK, IF_MASK, etc), found in
processor.h (both _32 and _64). They have a one-to-one mapping with the
EFLAGS value. This patch removes the definitions, and use the already
exisant X86_EFLAGS_ version when applicable.
Signed-off-by: Glauber de Oliveira
This patch unifies the paravirt pieces of processor.h
The functionality present in 32 bit, but not (yet) in 64-bit,
like load_sp0 is _not_ done here, and let to a different patch.
With this unification, we get paravirt for free in x86_64 processor.h
Signed-off-by: Glauber de Oliveira Costa
This patch moves the definition of set_iopl_mask to processor.h,
instead of letting it at processor_32.h.
For x86_64, nothing is done, as we don't really need such a function.
However, having it on both arches saves us from putting an ifdef in the
pv_cpu_ops struct.
Signed-off-by: Glauber de
This patch moves the pieces of processor_32.h and processor_64 that are
equal to processor.h. Only what's exactly the same is moved around, the rest
not being touched.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 116
current_text_addr() has a different implementation in x86_64 and
i386, but it is not fundamentally different. I stick to the i386
implementation, that seem to be a common base, and move it to processor.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h
Although slighly different, the tss_struct is very similar in x86_64 and
i386. The really different part, which matchs the hardware vision of it, is
now called x86_hw_tss, and each of the architectures provides yours.
It's then used as a field in the outter tss_struct.
Signed-off-by: Glauber de
There are currently two definitions of load_cr3, that essentially do the
same thing. This patch moves them all to processor.h.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/mmu_context_64.h |5 -
include/asm-x86/processor.h |7 +++
Paravirt guests need to inform the underlying hypervisor whenever the sp0
tss field changes. i386 already has such a function, and we use it for
x86_64 too. There's an unnecessary (for 64-bit) msr handling part in the
original
version, and it is placed around an ifdef. Making no more sense in
The thread_struct is not fundamentally different between architectures, and
this patch puts it in the common header. What's really unique for each of
them is enclosed in ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 44
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Since anyway we will have to keep a white- (or
This patch moves the mm_segment_t structure definition to processor.h
This makes mmsegment.h file useless, and it is deleted.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/mmsegment.h |8
include/asm-x86/processor.h |5 +
This patch moves i387 definitions from processor_32.h and processor_64.h
to processor.h. They are different. Very different. And there's appearently
nothing we can do about it, so they're enclosed inside ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
This patch moves the TASK_ALIGN constraints to common header.
The base of it is the same for x86_64 and i386. The only difference
is the presence of vSMP in x86_64. As it's not a worry in i386, we can
safely use the same code for both.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.
Signed-off-by: Glauber de
x86_cpuinfo is one more to the family of "not fundamentally different"
structs. It's unified in processor.h, with very specific fields enclosed
around ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |6 +-
include/asm-x86/processor.h
Mark Lord wrote:
Improve the existing boot/load time warnings from sata_mv
for Highpoint RocketRAID 23xx cards, based on new knowledge
about where the BIOS likes to overwrite sectors with metadata.
Harmless to us, but very useful for end users.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
This patch removes definitions and macros that are not used anymore
from processor_64.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor_64.h | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
Index:
This patch changes the bitwise operations in bitops.h to get
a void pointers as a parameter. Before this patch, a lot of warnings
can be seen. They're gone after it.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/bitops.h | 39
This patch moves the prefetch[w]? functions to processor.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 30 ++
include/asm-x86/processor_32.h | 25 -
include/asm-x86/processor_64.h |8
There's only one difference between the NOPs used in asm code for i386 and
x86_64:
i386 has a lot more variants. The code is moved to processor.h, and adjusted
accordingly.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 85
On Tue, 18 Dec 2007 10:38:13 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> > Is there a way to avoid it except turning off the swap?
> >
> Maybe...no.
>
Ah, sorry. If too much dirty page by ftp is trouble, tuning
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_writeback/centisecs
etc..
may
This patch moves definitions that are present in only one of the files
(between processor_32.h and processor_64.h), to processor.h. They're mostly
structures and function definitions.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |2 +-
Well, I guess it would be a smooth path if we rename the
drivers/i2c/chips/pca9539.c
since that's old style I2C driver, which means the driver name is not
so useful external
so the impact is actually minimum.
On Dec 18, 2007 4:29 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi David,
>
>
> On
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Quoting Tetsuo Handa ([EMAIL PROTECTED]):
> > Hello.
> >
> > Serge E. Hallyn wrote:
> > > CAP_MKNOD will be removed from its capability
> > I think it is not enough because the root can rename/unlink device files
> > (mv /dev/sda1 /dev/tmp; mv
Avoid adding the same type of cap multiple times, otherwise we will see dead
loop.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/pci.c
===
--- linux.orig/drivers/pci/pci.c2007-12-18
In 2.6.24, we turned on ACPI support in libata. This is needed in order
to support suspend/resume and BIOS passworded drives, but it inevitably
brought with it a host of new regressions -- which is what happens
anytime you blindly accept ATA commands the BIOS has decided to toss
your way. :)
A couple serious fixes (wireless, e100, sky2) and a bevy of minor ones.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS|6 ++
save_state->cap_nr should be correctly set, otherwise we can't find the
saved cap at resume.
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/pci.c
===
--- linux.orig/drivers/pci/pci.c2007-12-18
pci_save/store_state has multiple bugs, which will cause cap can't be
saved/restored correctly. Below 3 patches fix them.
fix the typo in pci_save_pcix_state
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/pci.c
On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
(Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
actually does that code?)
> > I try it again, and it reports it died at the same exact
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
> I hate to bring this again, but what if the admin in the container
> mounts an external file system (eg. nfs, usb, loop mount from a file,
> or via fuse), and that file system already has a device that we would
> like to ban inside that container ?
Hello.
Serge E. Hallyn wrote:
> But your requirements are to ensure that an application accessing a
> device at a well-known location get what it expect.
Yes. That's the purpose of this filesystem.
> So then the main quesiton is still the one I think Al had asked - what
> keeps a rogue
Chao cac ban,
Ban nhan duoc email nay la do ban hoac mot ai do da dang ky dia chi
email cua ban tai trang web: www.nhaban.net.tf, www.nhaban.vnn.bz,
www.nhadep.us de nhan cac thong tin nha dat moi nhat cua chung toi.
Nay chung toi han hanh thong bao voi cac ban cac can ho cao cap chung
toi dang
On Mon, 17 Dec 2007, Joe Perches wrote:
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> drivers/scsi/qla4xxx/ql4_def.h|2 +-
> drivers/scsi/qla4xxx/ql4_init.c |2 +-
Acked-by: David Somayajulu <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line
On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
> which also gets bonus points for being totally unreadable, and thus 100%
> in the spirit of uuid's.
Heh. UUID's don't have to be readable; just universally unique. Code
on the other hand should be readable. :-)
If you want
On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
>
> (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> doesn't list 'isofs' anyplace. Will Al or Andrew please vector to whoever
> actually does
On Dec 17, 2007 8:16 PM, Larry Finger <[EMAIL PROTECTED]> wrote:
>
> I hope that you have now convinced yourself that you should be using b43 and
> not messing around
> forcing b43legacy to use a device for which it was not intended.
>
I was convinced the moment I realized it worked exactly the
Another rework of the i2c for powerpc device tree patch. This version
implements standard alias naming only on the powerpc platform and only for the
device tree names. The old naming mechanism of i2c_client.name,driver_name is
left in place and not changed for non-powerpc platforms. This patch
Temporarily copy the mpc-i2c driver to continue support for the ppc
architecture until it is removed in mid-2008. This file should be deleted as
part of ppc's final removal.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl
Convert MPC i2c driver from being a platform_driver to an open firmware
version. Error returns were improved. Routine names were changed from fsl_ to
mpc_ to make them match the file name.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by:
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-mpc.c | 30 +-
1 files changed, 17
Follow on to: "Series to add device tree naming to i2c"
Teach module-init-tools about the i2c subsystem.
diff --git a/depmod.c b/depmod.c
index 0281c79..209eb0c 100644
--- a/depmod.c
+++ b/depmod.c
@@ -793,6 +793,7 @@ static struct depfile depfiles[] = {
{ "modules.inputmap",
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
Makefile |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index c1825aa..15ada3f 100644
--- a/Makefile
+++ b/Makefile
@@ -35,6 +35,9 @@ MAKEFLAGS += -rR
Ignore this patch, I forgot to remove it before mailing the series.
On 12/17/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
>
> Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
> ---
>
> Makefile |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote:
> On Sun, 16 Dec 2007 21:55:20 + Mel Gorman wrote:
>
> > > > Just using cp to read the file is enough to cause problems but I
> > > > included
> > > > a very basic program below that produces the BUG_ON checks. Is this a
> > > >
From: Divy Le Ray <[EMAIL PROTECTED]>
Add parity initialization for T3C adapters.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |1
drivers/net/cxgb3/cxgb3_main.c| 82
drivers/net/cxgb3/cxgb3_offload.c | 15 ++
From: Divy Le Ray <[EMAIL PROTECTED]>
set_pci_drvdata() stores a pointer to the adapter,
not the net device.
Add missing softirq blocking in t3_mgmt_tx.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 14 --
drivers/net/cxgb3/sge.c|
Hello,
[EMAIL PROTECTED] wrote:
> --- sata_nv.c.orig2007-12-17 21:08:12.0 +0530
> +++ sata_nv.c 2007-12-17 21:08:25.0 +0530
> @@ -2407,6 +2407,12 @@
> type = GENERIC;
> }
>
> + /* set 64bit dma masks, may fail */
> + if (type == ADMA) {
>
On Tue, 18 Dec 2007 10:37:32 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 09:07:56PM -0500, [EMAIL PROTECTED] wrote:
> > On Mon, 17 Dec 2007 14:56:44 PST, Andrew Morton said:
> >
> > (Adding Al Viro to the list, he's listed as "file systems" and MAINTAINERS
> > doesn't
Quoting Tetsuo Handa ([EMAIL PROTECTED]):
> Hello.
>
> Serge E. Hallyn wrote:
> > But your requirements are to ensure that an application accessing a
> > device at a well-known location get what it expect.
>
> Yes. That's the purpose of this filesystem.
>
>
> > So then the main quesiton is
Serge E. Hallyn wrote:
> Quoting Oren Laadan ([EMAIL PROTECTED]):
>> I hate to bring this again, but what if the admin in the container
>> mounts an external file system (eg. nfs, usb, loop mount from a file,
>> or via fuse), and that file system already has a device that we would
>> like to ban
Hi Steven,
I posted a suspend-to-ram fix to sched-devel earlier today:
http://lkml.org/lkml/2007/12/17/445
This fix should also be applied to -rt as I introduced the same regression
there. Here is a version of the fix for 23-rt13. I can submit a version for
24-rc5-rt1 at your request.
From: Chris Newport <[EMAIL PROTECTED]>
Date: Tue, 18 Dec 2007 02:58:29 + (GMT)
> On Tue, 18 Dec 2007, Stefan Richter wrote:
>
> > It's a 100% reproducible oops on Sparc (with FireWire controller) for
> > 2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that
> > the bug
Divy Le Ray wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Add parity initialization for T3C adapters.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
applied 1-2 to #upstream
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote:
> It runs on a freshly booted machine (no
> DSA involved, so we're not automatically hosed), so an attacker knows the
> initial pool state.
Not just a freshly booted system. The system has to be a freshly
booted, AND freshly
On Tue, 18 Dec 2007, Stefan Richter wrote:
It's a 100% reproducible oops on Sparc (with FireWire controller) for
2.6.23 and 2.6.24 kernels, but not 2.6.22. The reporter confirmed that
the bug also happens
How do you achieve a sparc system with firewire ?
AFAIK there is no SBUS firewire card.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Replacement for the last patch in the kprobes series I just sent.
arch/x86/kernel/kprobes.c | 45 +
1 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c
Theodore Tso wrote:
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote:
It runs on a freshly booted machine (no
DSA involved, so we're not automatically hosed), so an attacker knows the
initial pool state.
Not just a freshly booted system. The system has to be a
Chris Friesen <[EMAIL PROTECTED]> wrote:
>
> However, if I specifically try to print out one of the missing entries,
> it shows up:
>
> [EMAIL PROTECTED]:/root> /tmp/ip neigh show 192.168.24.81
> 192.168.24.81 dev bond2 lladdr 00:01:af:14:e9:8a REACHABLE
What about
ip -4 neigh show
Gregory Haskins wrote:
Hi Steven,
I posted a suspend-to-ram fix to sched-devel earlier today:
http://lkml.org/lkml/2007/12/17/445
This fix should also be applied to -rt as I introduced the same regression
there. Here is a version of the fix for 23-rt13. I can submit a version for
This patch modifies the ds1307, ds1374, and rs5c372 i2c drivers to support
device tree names using the new i2c mod alias support
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
Hello.
Serge E. Hallyn wrote:
> Nope, try
>
> touch /root/hda1
> ls -l /root/hda1
> mount --bind /dev/hda1 /root/hda1
> ls -l /root/hda1
[EMAIL PROTECTED] ~]# touch /root/hda1
[EMAIL PROTECTED] ~]# ls -l /root/hda1
-rw-r--r-- 1 root root 0 Dec 18 12:04 /root/hda1
[EMAIL PROTECTED] ~]#
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
> On a server, keyboard and mouse are rarely used. As you've described it,
> that leaves only the disk, and during the boot process, disk accesses and
> timing are somewhat predictable. Whether this is sufficient to break the
> RNG
Please apply the attached patch and try to use cdrom w/o specifying any
parameter and report kernel log.
Thanks.
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4753a18..acaa8b8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4537,6
Theodore Tso wrote:
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
On a server, keyboard and mouse are rarely used. As you've described it,
that leaves only the disk, and during the boot process, disk accesses and
timing are somewhat predictable. Whether this is sufficient
Adam isn't a maintainer anymore.
His old email address bounces.
Update to new email address.
On Mon, Dec 17, 2007 at 01:03:48PM -0800, Joe Perches wrote:
> > You seem to have an old email address in the
> > linux-kernel MAINTAINERS file.
> > Should it be deleted or changed?
On Mon, 2007-12-17 at
On Tue, Dec 18, 2007 at 02:39:00PM +1030, David Newall wrote:
>
> Thus, the entropy saved at shutdown can be known at boot-time. (You can
> examine the saved entropy on disk.)
>
If you can examine the saved entropy on disk, you can also introduce a
trojan horse kernel that logs all keystrokes
On Mon, 17 Dec 2007 20:12:06 -0800 Joe Perches <[EMAIL PROTECTED]> wrote:
> Adam isn't a maintainer anymore.
> His old email address bounces.
> Update to new email address.
>
> On Mon, Dec 17, 2007 at 01:03:48PM -0800, Joe Perches wrote:
> > > You seem to have an old email address in the
> > >
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Mon, Dec 17, 2007 at 08:57:50AM +1100, Paul Mackerras wrote:
>> Greg KH writes:
>>
>> > Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
>> > devices that are mmaped, that makes a bit more sense.
>> >
>> > But I'd like to see what
On Saturday 01 December 2007 07:02:43 Adam Jackson wrote:
> These types define the size of data read from /dev/apm_bios. They
> should not be hidden behind #ifdef __KERNEL__.
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
My mistake, sorry.
Rusty.
--
To unsubscribe from this list: send the line
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> This is directly analogous to how we treat identity information in IDE, or PCI
> configuration space -- some fields are pre-digested, but the entire raw
> information is also available.
Add to that a totally unchanged value can just be easier to get
Andi Kleen <[EMAIL PROTECTED]> writes:
>> I do know we need to use the low 4 pat mappings to avoid most of the PAT
>> errata issues.
>
> They don't really matter. These are all very old systems who have run
> fine for many years without PAT. It is no problem to let them
> continue to do so and
On Mon, 2007-12-17 at 20:28 -0800, Andrew Morton wrote:
> Please: just replace all instances with plain old "Adam Fritzler" and then
> ensure that the lookup key "Adam Fritzler" has an accurate (and
> non-duplicated anywhere else!) entry in MAINTAINERS or CREDITS or whatever.
Sure. See new patch
I hit a bug in 2.6.24-rc looks to be in 2.6.23 also so not sure how
long it's been there
with an xfs filesystem pbuilder has an issue using device files it
makes for chroot
the mknod command looks to work fine the file is created
however when attempting to use one of the created files you see
Venki Pallipadi <[EMAIL PROTECTED]> writes:
> Checking the manual for this. You are right, we had missed some steps here.
> Actually, manual says on MP, PAT MSR on all CPUs must be consistent (even when
> they are not really using it in their page tables.
> So, this will change the init and
On Friday 14 December 2007 18:51:06 Ananth N Mavinakayanahalli wrote:
> On Thu, Dec 13, 2007 at 11:09:16PM -0800, Andrew Morton wrote:
> > regular_kernel_text_address()? Dunno.
>
> Sounds better :-)
The better answer was to invert it and use "discarded_kernel_text_address()",
which is what you
Eric W. Biederman wrote:
_00FD_FC00_h - _00FD_FDFF_h On a hypertransport based
system should work. There is a 32MB window for it.
It doesn't. The termination on MMIO and IOIO transaction is different,
and poking this memory window with an MMIO transaction will lock the
> Has anyone *proven* that using uninitialized data this way is safe?
You can probably find dozens of things in the Linux kernel that have not
been proven to be safe. That means nothing.
> As
> a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I
> hear things like this.
On Tuesday 18 December 2007 09:52:26 Glauber de Oliveira Costa wrote:
> +static inline int desc_empty(const void *ptr)
> +{
> + const u32 *desc = ptr;
> + return !(desc[0] | desc[1]);
> +}
Erk. This really needs to be a union, not a void *. I guess we can clean it
later.
Rusty.
--
To
Intel IOMMU (a.k.a VT-d) is under rapid deployment on desktop
and mobile platforms. As platform provides multiple dma remap
engines for devices like those lives on south bridge (net, sound,
etc.), and we also have one engine specific to graphics device.
If this engine is functioning, the access
[PATCH] [intel_iommu] explicit export current graphics dmar status
To make it possbile to tell other modules about curent
graphics dmar engine status, that could decide if graphics
driver should remap physical address to dma address.
Also this one trys to make dmar_disabled really present
[PATCH] [AGP] Add generic support for graphics dma remapping
New driver hooks for support graphics memory dma remapping
are introduced in this patch. It makes generic code can
tell if current device needs dma remapping, then call driver
provided interfaces for mapping and unmapping. Change has
On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote:
> This patch changes the bitwise operations in bitops.h to get
> a void pointers as a parameter. Before this patch, a lot of warnings
> can be seen. They're gone after it.
No, this is a backwards step! These warnings are
[PATCH] [AGP] intel_agp: add support for graphics dma remapping on G33
When graphics dma remapping engine is active, we must fill
gart table with dma address from dmar engine, as now graphics
device access to graphics memory must go through dma remapping
table to get real physical address.
Add
> diff --git a/kernel/Makefile b/kernel/Makefile
> index dfa9695..749825a 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -80,3 +80,11 @@ quiet_cmd_ikconfiggz = IKCFG $@
> targets += config_data.h
> $(obj)/config_data.h: $(obj)/config_data.gz FORCE
> $(call
I'll have a TLS cleanup patch soon that makes the (only) use of desc_empty
pass a struct user_desc pointer.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Greetings!
System details:
Board: DTSP-ARM926Ej-S(new board)
Cross-toolchain: ELDK4.1
Linux kernel: 2.6.18
u-boot: 1.1.6
I have been able to successfully run u-boot and linux kernel with root file
system but when kernel is start the following error message
come.."kobject_add failed
Rusty Russell wrote:
On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote:
This patch changes the bitwise operations in bitops.h to get
a void pointers as a parameter. Before this patch, a lot of warnings
can be seen. They're gone after it.
No, this is a backwards step! These
what the heck, applied
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Dec 17, 2007 at 08:11:05AM +0100, Borislav Petkov wrote:
A slightly microoptimized version 1.1:
---
From: Borislav Petkov <[EMAIL PROTECTED]>
Check the patch level of the single hunks in a patch file, however only when
checkpatch.pl is called from within the kernel tree.
1101 - 1200 of 1228 matches
Mail list logo
