On Wed, 2007-12-12 at 08:29 +0100, Berkhan, Enrik (GE Infra, Oil & Gas)
wrote:
> Trond Myklebust wrote:
> > On Sun, 2007-12-09 at 19:52 +0100, Berkhan, Enrik (GE Infra, Oil & Gas)
> > wrote:
> >> - generic_file_mmap returns -ENOSYS for NOMMU systems; replicate this
> >> behaviour
> >
> > Why
fastcall is always defined to be empty, remove it from arch/x86
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
arch/x86/kernel/apic_32.c|2 +-
arch/x86/kernel/cpu/mcheck/k7.c |2 +-
arch/x86/kernel/cpu/mcheck/mce.h |2 +-
thanks, applied.
With your next batch of patches for 2.6.25, could you clean up:
> --- a/drivers/infiniband/hw/ehca/hcp_if.c
> +++ b/drivers/infiniband/hw/ehca/hcp_if.c
> @@ -89,6 +89,7 @@
> #define HCALL9_REGS_FORMAT HCALL7_REGS_FORMAT " r11=%lx r12=%lx"
>
> static
On Wed, 12 Dec 2007, Rene Herman wrote:
> Hi everyone.
>
> That was a succesful request, thanks to all who responded. This message also
> just now went out with all the respondents in CC but I believe that copy
> isn't making the list, so here's one without...
>
> In total you provided 60
On Wed, 12 Dec 2007, Remy Bohmer wrote:
> Also:
> Acked-by: Remy Bohmer <[EMAIL PROTECTED]>
>
> Thanks for the effort also, I still had it on my todo list, but that
> is needed anymore...
No problem. Could you also ACK the one I sent for mainline.
Thanks,
-- Steve
--
To unsubscribe from this
do_div() rounds down, so we add have the divisor to round up. This effected my
change to preempt_max_latency. Each time you read preempt_max_latency it gets
rounded lower.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
kernel/time/timekeeping.c |3 ++-
1 file changed, 2
On Dec 12, 2007 8:14 PM, Rene Herman <[EMAIL PROTECTED]> wrote:
> Time varies between 0.54 microseconds and 2.50 microseconds, with most
> around 1.3/1.4 microseconds. Numbers 58, 59 and 60 (the ones at > 2 us) I
> dont completely trust since similar machines are among the fastest as well.
Hi.
On Wed, Dec 12, 2007 at 07:39:25PM +0100, Bernd Petrovitsch wrote:
> On Mit, 2007-12-12 at 10:02 -0800, Daniel Phillips wrote:
> > On Wednesday 12 December 2007 09:46, J. Bruce Fields wrote:
> [...]
> > > People have proposed writing a daemon that just reads
> > > /proc/net/rpc/nfsd periodically
On Wed, Dec 12, 2007 at 12:43:34PM -0700, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
> >
> > It could enable the extended APIC IDs but not use them?
>
> In which case complaining is still correct (the BIOS was out of sync),
> enabling bit 17 is still correct and we are
thanks, 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 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last few
days. I did modify Rene's test program and ran it on my "problem"
machine, with the results below.
The interesting part of this is that port 80 seems to respond to "in"
Hello Steven,
>
> In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
> was implemented, and the simple irq handler had a masking set to it.
>
> Remy Bohmer discovered that some devices in the ARM architecture
> would trigger the mask, but never unmask it. His patch to do the
>
>> Hi Grant,
>
> Hi Michal,
>
> Sorry I didn't reply right away, got tied up with other stuff.
No worries.
>> I looked at your patches around uartlite. I have tryied to compile this
>> driver for Microblaze
>> platform. I use the latest kernel from kernel.org with old uartlite(in front
>>
On 12-12-07 21:18, linux-os (Dick Johnson) wrote:
But there are some things that get set up long before
udelay() is calibrated! The interrupt controllers,
the timer, etc. You can't just substitute or you
will end up with machines that won't boot!
We understand the problem. But it's not all
fastcall is always empty, remove it from net/
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
net/bluetooth/rfcomm/core.c |4 ++--
net/core/dev.c |2 +-
net/core/sock.c |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On Dec 12, 2007 2:44 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote:
> > On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote:
> > > On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > ...
> > > > The proper
On Wed, 12 Dec 2007, David P. Reed wrote:
> Who has attitude problems here? I have indeed learned a lot about assholes.
>
> linux-os (Dick Johnson) wrote:
>> Yep. We are all wrong. You come out of nowhere and claim to
>> be right. Goodbye.
>>
Hmmm, I gave you every opportunity to back off your
Port 0xED, just FYI:
cycles: out 1430, in 1370
cycles: out 1429, in 1370
(800 Mhz)
Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Sadly, I've been busy with other crises in my day job for the last
few days. I did modify Rene's test program and ran it on my
"problem" machine,
Hi Pete,
On Tue, 11 Dec 2007 15:48:03 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > if (scsi_status == 0) {
> > - uptodate = 1;
> > + error = 0;
> > } else {
> > - uptodate = 0;
> > + error = -EIO;
> > rq->errors = scsi_status;
> >
The IOAPIC hack that does a level=>edge to mask does not disable
interrupts. So we can receive interrupts when masked, and this means
that we can miss interrupts that arrive when the thread is handling
them.
This patch adds the "IRQ_PENDING" logic of the edge irqs to be
able to catch interrupts
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/apic.h |6 +++---
include/asm-x86/hw_irq_32.h| 14 +++---
include/asm-x86/mutex_32.h |7 +++
include/asm-x86/semaphore_32.h |8
4 files changed, 17 insertions(+), 18
-- Andrew Morton <[EMAIL PROTECTED]> wrote:
> hostap_plx.c first appeared in 2.6.14.
>
Just a thought: How far back will I be able to compile kernels correctly with
gcc 4.1.2?
Specifically:
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
Cheers,
Chris
fastcall is always defined to empty, remove it
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
drivers/net/ns83820.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index 972acc3..5eed99e 100644
---
Kill a process that tries to branch into a stub and execute a system
call. There are no security implications here - a system call in a
stub is treated the same as a system call anywhere else. But if a
process is trying to branch into a stub, either it is trying something
nasty or it has gone
sig_handler_common_skas needs significant modernization, starting with
its name and storage class.
There is no need to hide the true type of the sigcontext pointer, so
the void * dummy parameter can be replaced with a sigcontext *sc.
The array of uml_pt_regs structs used in the page fault case
A bit of defensive programming - during development, it ocassionally
happens that a call to init_new_context is missed, resulting in
context holding a host pid of zero. When that address space is torn
down, destroy_context does a kill(0), which instantly kills the whole
UML without any errors
This series is all cleanups. They should wait for 2.6.25.
Jeff
--
Work email - jdike at linux dot intel dot com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
This patch moves sig_handler_common_skas from
arch/um/os-Linux/skas/trap.c to its only caller in
arch/um/os-Linux/signal.c. trap.c is now empty, so it can be removed.
This is code movement only - the significant cleanup needed here is
done in the next patch.
Signed-off-by: Jeff Dike <[EMAIL
Get rid of some syscall counters which haven't been useful in ages.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/include/kern_util.h|1 -
arch/um/kernel/skas/syscall.c |3 ---
arch/um/kernel/syscall.c |3 ---
include/asm-um/processor-generic.h |
On Mon, 2007-12-10 at 18:02 -0800, Michael Rubin wrote:
> From: Michael Rubin <[EMAIL PROTECTED]>
>
> Fixing a bug where writing to large files while concurrently writing to
> smaller ones creates a situation where writeback cannot keep up with the
> traffic and memory baloons until the we hit
Style fixes to arch/um/os/helper.c and tidying up the breakpoint fix a
bit.
helper.c gets all the usual style fixes -
updated copyright
all printks get severities
Also -
errval changes to err in helper_child
fixed an obsolete comment
run_helper was
Hello,
This patch removes unused code from ext3_find_entry().
Compile and boot tested.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
fs/ext3/namei.c | 67174 -> 67077 (-97 bytes)
fs/ext3/namei.o | 157944 -> 157896 (-48 bytes)
fs/ext3/namei.c |4
1 file changed, 4
Alan Cox wrote:
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe
Trent Piepho wrote:
> On Wed, 12 Dec 2007, Adrian Bunk wrote:
>
>>> I don't see any issue on making both dependent on VIDEO_TUNER for
>>> 2.6.24, since they are currently used only by tuner core module
>>> (tuner.ko).
>>> ...
>>>
>> If "selected code isn't included" also counts as a bug
__videobuf_read_start() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
bd6ebe6d1cef48341d124d47ecaab4fff96a59a8
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index c8a5cb5..4e39a11 100644
--- a/drivers/media/video/videobuf-core.c
>From a5fd2d7c75168076dc6b4b94ea8cda529fc506b1 Mon Sep 17 00:00:00 2001
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 14:07:40 -0800
Subject: [RFC] [PATCH -mm] oom_kill: remove uid==0 checks
Root processes are considered more important when out of memory
and killing proceses.
Rene Herman wrote:
On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
Eh, oh, I guess you need to compile as a 32-bit
On Wed, 12 Dec 2007, Adrian Bunk wrote:
> >
> > I don't see any issue on making both dependent on VIDEO_TUNER for
> > 2.6.24, since they are currently used only by tuner core module
> > (tuner.ko).
> >...
>
> If "selected code isn't included" also counts as a bug at least dabusb
> is also affected
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Andrew, I assume these are more appropriate to go through your tree. Let
me know if you'd rather it go through someone else.
fs/aio.c| 17 -
fs/buffer.c |6 +++---
fs/fcntl.c |2 +-
fs/file_table.c
> Yes it does! I was just going to send the same patch myself :)
But, I am now seeing some errors that weren't there in 2.6.23
kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR*
last message repeated 15 times
kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c,
bits: HSYNC
linux-os (Dick Johnson) wrote:
But there are some things that get set up long before
udelay() is calibrated! The interrupt controllers,
the timer, etc. You can't just substitute or you
will end up with machines that won't boot!
The initial value could be set conservatively high.
--
To
Harvey Harrison wrote:
fastcall is always defined to be empty, remove it from arch/x86
Why is it always defined to be empty? Why isn't it used anymore?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Rene Herman wrote:
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't.
In any case, the udelay(2) approach seems to be a safe fix for this
machine.
By the way, _does_ anyone have a contact at
On Wed, 12 Dec 2007 21:58:25 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 12-12-07 21:26, Rene Herman wrote:
>
> > On 12-12-07 21:07, David P. Reed wrote:
>
> >> Someone might have an in to nVidia to clarify this, since I don't. In
> >> any case, the udelay(2) approach seems to be a safe
On 12-12-07 21:26, Rene Herman wrote:
On 12-12-07 21:07, David P. Reed wrote:
Someone might have an in to nVidia to clarify this, since I don't. In
any case, the udelay(2) approach seems to be a safe fix for this machine.
By the way, _does_ anyone have a contact at nVidia who could
On Tue, Dec 11, 2007 at 05:42:53PM -0500, Kiyoshi Ueda wrote:
> This patch converts um to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> As a result, the interface of internal function, ubd_end_request(),
> is changed.
Looks OK to me...
>From d4ca1a9749c5b40325ec2db9fcde2f2cbd0e0978 Mon Sep 17 00:00:00 2001
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 13:55:36 -0800
Subject: [RFC] [PATCH -mm] agp: remove uid comparison as security check
In the face of containers and user namespaces, a uid==0 check for
fastcall is always defined to be empty, remove it
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
mm/filemap.c| 10 +-
mm/highmem.c|4 ++--
mm/internal.h |2 +-
mm/memory.c |2 +-
mm/page-writeback.c |2 +-
mm/page_alloc.c | 16
On Wed, 2007-12-12 at 16:27 -0500, Phillip Susi wrote:
> Harvey Harrison wrote:
> > fastcall is always defined to be empty, remove it from arch/x86
>
> Why is it always defined to be empty? Why isn't it used anymore?
>
It was a leftover from before regparm(3) became the default on x86-32.
It
On 12/12/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
fastcall is always empty, remove it.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
kernel/exit.c|4 ++--
kernel/fork.c|2 +-
kernel/irq/chip.c| 10 +-
kernel/irq/handle.c |4 ++--
kernel/mutex-debug.c |2 +-
kernel/mutex.c | 22
On Tue, 2007-12-11 at 20:21 +, Mel Gorman wrote:
> This is a rebase of the two-zonelist patchset to 2.6.24-rc4-mm1 and some
> warnings cleared up. The warnings were not picked up before as they were
> introduced early in the set and cleared up by the end. This might have hurt
> bisecting so
>From c257cb67ce00c8769730cfa92379a53009d99b28 Mon Sep 17 00:00:00 2001
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 14:02:45 -0800
Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Reiser4 gives root some reserved blocks. Replace the uid==0 check,
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
lib/iomap.c | 32
lib/rwsem-spinlock.c | 16
lib/rwsem.c |8
lib/semaphore-sleepers.c |8
4 files changed, 32 insertions(+), 32
> No problem. Could you also ACK the one I sent for mainline.
I will test it first tomorrow morning.
Remy
--
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
Harvey Harrison wrote:
On Wed, 2007-12-12 at 16:27 -0500, Phillip Susi wrote:
Harvey Harrison wrote:
fastcall is always defined to be empty, remove it from arch/x86
Why is it always defined to be empty? Why isn't it used anymore?
It was a leftover from before regparm(3) became the default
Neil Horman <[EMAIL PROTECTED]> writes:
> I think this just leaves us with deciding on a mechanism for how to do
> single-application quirks. I take Andi's point that adding a flag set to the
> quirk data structure is a fine solution, but I'm really ok with static
> integers
> in individual
Linus, please pull the latest x86 git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
x86: an AMD/Barcelona bugfix, timers: two bugfixes, genirq:
missing inline function added. Tested on 32-bit and 64-bit x86.
Ingo
-->
Adrian Bunk
> One wonders if it does some SMM trick to capture port 0x80 writes and
> attempt to haul them off for debugging; it almost sounds like some kind
> of debugging code got let out into the field.
Not implausible. We've got a bug I've been dealing with where a vendor
left debug stuff enabled via
It is on:
$ uname -a
Linux home 2.6.23 #5 SMP PREEMPT Sun Oct 21 23:08:50 GST 2007 i686
unknown unknown GNU/Linux
And yes it happened on previous kernels also at least since .21
I've had 6 panics so far randomly, but generally when doing a "updatedb"
(from find(1)) which seems to trigger it
Subject: [PATCH] Remove fastcall from linux/include
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/linux/irq.h | 16
include/linux/kernel.h |2 +-
include/linux/mutex.h| 10 +-
include/linux/preempt.h |4 ++--
Hello,
The unused code found in ext3_find_entry() is also present (and still
unused)
in the ext4_find_entry() code. This patch removes it. Compile tested only.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
fs/ext4/namei.c | 68044 -> 67947 (-97 bytes)
fs/ext4/namei.o | 183840
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-generic/iomap.h | 32
include/asm-generic/mutex-dec.h |6 +++---
include/asm-generic/mutex-xchg.h |6 +++---
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git
Eric Dumazet wrote:
And what is the version of "ip" command you have on this machine ?
ip -V
iproute2-ss051107
You may try other versions of this command
http://devresources.linux-foundation.org/dev/iproute2/download/
They appear to be numbered by kernel version, and the above version
This has already been fixed. It's in our 8.2.3 patches, which were merged into
James's scsi-misc-2.6 tree at the beginning of November, and targeted for
2.6.25.
-- james s
Adrian Bunk wrote:
Commit 2e0fef85e098f6794956b8b80b79fbb4cbb7 added the folowing code
to
In article <[EMAIL PROTECTED]> (at Wed, 12 Dec 2007 15:57:08 -0600), "Chris
Friesen" <[EMAIL PROTECTED]> says:
> > You may try other versions of this command
> >
> > http://devresources.linux-foundation.org/dev/iproute2/download/
>
> They appear to be numbered by kernel version, and the above
Hi!
I know the git tree of linux kernel up to version 1.0:
git://git.kernel.org/pub/scm/linux/kernel/git/nico/archive.git
And i am aware of the history tree from 2.5.0 to 2.6.12 at
http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Has somebody done a _complete_ git tree from
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
"vague specific" ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without
On Wed, Dec 12, 2007 at 02:54:54PM -0500, James Bottomley wrote:
>
> On Wed, 2007-12-12 at 11:16 -0800, Andrew Morton wrote:
> > On Wed, 12 Dec 2007 14:43:42 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
> >
> > > Am 12.12.2007 schrieb Miquel van Smoorenburg:
> > > > On Wed, 2007-12-12 at 03:38
On Wed, Dec 12, 2007 at 02:15:35PM -0500, Dave Jones wrote:
> On Wed, Dec 12, 2007 at 09:45:07AM -0800, Greg Kroah-Hartman wrote:
>
> > Well, I respectively disagree. sysfs is NOT for exporting various
> > binary kernel structures to userspace directly. Again, the binary files
> > in sysfs
On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
> Greg KH wrote:
>>> This is a binary structure defined by protocol;
>> What protocol? Is this a "standard" documented somewhere?
>
> Yes, see Documentation/i386/* (although some of it is documented by
> reference to
Use proper encoding for LED values.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Note: earlier code worked because hardware only checks for zero.
--- a/drivers/input/misc/apanel.c 2007-12-12 13:07:03.0 -0700
+++ b/drivers/input/misc/apanel.c 2007-12-12
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> Yes, but we're talking about writing the configuration information
> to the kernel, not actually making any access checks with it. I
> think. What I think we're talking about (and please correct me David
> if I've stepped into the wrong theatre) is
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > This fd selects the
> > particular cache context that a particular instance of a running daemon is
> > using.
>
> Yes, but forgive me being slow, I don't see the problem.
I mean that it's not particularly sensible to have an auxiliary interface
> Mutter. These would be better as static inlines. A macro just invites
> variable-unused warnings on non-ia64 and outright compilation errors on
> ia64. Speaking from experience...
>
> static inline void arch_ptrace_stop(int exit_code, siginfo_t *info)
> {
> }
> #define arch_ptrace_stop
Greg KH wrote:
On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
Greg KH wrote:
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by
reference to
On 02/10/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > > These are generic statements, but i'm _really_ interested in the
> > > specifics. Real, specific code that i can look at. The typical Linux
> > > distro consists of in execess of 500
On Wed, 12 Dec 2007 14:21:46 -0800 Greg KH wrote:
> On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
> > Greg KH wrote:
> >>> This is a binary structure defined by protocol;
> >> What protocol? Is this a "standard" documented somewhere?
> >
> > Yes, see Documentation/i386/*
Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Dec 12, 2007 at 11:05:45AM -0800, H. Peter Anvin wrote:
>> Greg KH wrote:
This is a binary structure defined by protocol;
>>> What protocol? Is this a "standard" documented somewhere?
>>
>> Yes, see Documentation/i386/* (although some of it is
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> More likely, run it at build time in your .spec file to generate
> cachefiles.conf,
I don't think sticking it in cachefiles.conf is a good idea necessarily.
That has to be an administrator modifiable file. Is there a program I could
make cachefiles
On Tuesday 11 December 2007, Kiyoshi Ueda wrote:
> This patch converts ide-scsi to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by:
Hi Mauro,
On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
> What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
> fixed some bad locks.
>
> After this changeset, videobuf_read_stream() holds q->lock and calls
> videobuf_read_start(). To avoid waiting
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> It would seem to me that security_secctx_to_secid() ought to suffice if the
> application code was written correctly.
That's not quite sufficient as there still needs to be a verification step to
make sure the caller is allowed to do this.
> Be aware
Hi Linus,
This update contains: HPT37x PIO mode timings fixes (from Sergei Shtylyov),
Promise TX4 support bugfix, DMA modes reporting and validity checking fixes,
->io32_bit setting race fix, addition of device model/firmware/serial entries
to sysfs, some minor fixups and a few trivial patches
On Wednesday 12 December 2007, Luciano Rocha wrote:
> Anyway, how to compile with the sources of:
Thank you so much
I didn't think of using 2.4 headers... bad me!
Anyway, I can now hack this to compile with uclibc...
I don't know if it works yet, but at least it builds now (26KB)
I had to
On Dec 12, 2007 12:55 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-12-10 at 18:02 -0800, Michael Rubin wrote:
> > From: Michael Rubin <[EMAIL PROTECTED]>
> The part I miss here is the rationale on _how_ you solve the problem.
>
> The patch itself is simple enough, but I've been
Adrian Bunk <[EMAIL PROTECTED]> :
> This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:
[...]
> WARNING: vmlinux.o(.init.text.20+0x4cb25): Section mismatch: reference to
> .exit.text:sis190_mii_remove (between 'sis190_init_one' and 'read_eeprom')
Thanks. Applied at:
Harvey Harrison wrote:
> Some kprobe structure members had a superfluous e in their
> name.
>
> eflags -> flags
> esp -> sp
>
eflags and esp are the actual machine register names (at least in
32-bit), and therefore more distinctive than just "flags".
If this is in preparation for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Andrew, I've cc:d you here bc in doing this patch I noticed that your
> 64-bit capabilities patch switched this code from an explicit check
> of cap_t(p->cap_effective) to using __capable(). That means that
> now being
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > Have you example code for the security hook you mention? I'm not sure I
> > understand why security_secctx_to_secid() is not sufficient.
>
> security_secctx_to_secid() would just validate and map a context string to a
> secid.
Validate as in check
> Yes, it's now clear that all of this is so. Regrettably, it's used in
> dozens of drivers, most having nothing to do with an ISA/LPC bus.
>
> If it really is specific to the ISA architecture, then it should only be
> used in architecture specific code.
ISA/LPC is not architecture specific.
On Wed, 2007-12-12 at 15:00 -0800, Jeremy Fitzhardinge wrote:
> Harvey Harrison wrote:
> > Some kprobe structure members had a superfluous e in their
> > name.
> >
> > eflags -> flags
> > esp -> sp
> >
>
> eflags and esp are the actual machine register names (at least in
> 32-bit), and
Jeremy Fitzhardinge wrote:
Harvey Harrison wrote:
Some kprobe structure members had a superfluous e in their
name.
eflags -> flags
esp -> sp
eflags and esp are the actual machine register names (at least in
32-bit), and therefore more distinctive than just "flags".
If this is in
Randy Dunlap <[EMAIL PROTECTED]> writes:
> I don't know if this patch is trying to solve this (->) problem, but there
> is a desire for drivers to have a decent way to tell if the kernel that
> is executing is a kexec/crash kernel or not. If it is a kexec/crash
> kernel, then (some) drivers may
/proc/timer_stats currently reports the user of a timer by pid,
which is a reasonable approach. However if you are not in
the initial pid namespace the pid that is reported is nonsense.
Therefore until we can make timer_stats pid namespace safe just
disable it in the build if pid namespace
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>> Harvey Harrison wrote:
>>> Some kprobe structure members had a superfluous e in their
>>> name.
>>>
>>> eflags -> flags
>>> esp -> sp
>>>
>>
>> eflags and esp are the actual machine register names (at least in
>> 32-bit), and therefore more
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Harvey Harrison wrote:
Some kprobe structure members had a superfluous e in their
name.
eflags -> flags
esp -> sp
eflags and esp are the actual machine register names (at least in
32-bit), and therefore more
Glauber de Oliveira Costa wrote:
Since the last version of it received no comments on the interfaces, here
it goes a version, that I feel ready for inclusion.
The comments regarding style, specially the elimination of the #defines in
the desc_struct definition were merged. I also implemented
> I appear to have misread d_find_alias(). It would seem that the only way
> to ensure that a mountpoint won't be found is to remove it altogether
> from the inode->i_dentry list. AFAICS that should be largely harmless
> since the nfs sb->s_root is never visible to users, and is never part of
> a
Hi,
Can I implement mmap with an io port connected device on an x86 based CPU?
Background:
I've got a device driver which can be compiled for either x86 or ARM.
The driver provides an interface to an FPGA via either an IO port
(0x180) on the x86 or as a memory mapped SRAM-like device
901 - 1000 of 1182 matches
Mail list logo