Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
- Added the avr32 devel tree as git-avr32.patch (Haavard Skinnemoen)
- Don't enable locking API
Chen, Kenneth wrote on Thursday, December 14, 2006 5:59 PM
It seems utterly insane to have aio_complete() flush a workqueue. That
function has to be called from a number of different environments,
including non-sleep tolerant environments.
For instance it means that directIO on NFS will
Steven Rostedt [EMAIL PROTECTED] wrote:
So you got a big jitter using nanosleep??? If that's the case, could
you post the times you got. I'll also boot a kernel with the latest
-rt patch, without highres compiled, and see if I can reproduce the
same on x86.
You're very kind! Here you go:
On Thu, Dec 14, 2006 at 01:09:06PM -0800, Michael ODonald wrote:
Linus Torvalds wrote:
DMCA is bad because it puts technical limits over
the rights expressly granted by copyright law.
The best ways to get rich corporations on our side in fighting the
DMCA is to use the DMCA to hurt their
On Thursday 14 December 2006 02:16, Holger Macht wrote:
On Mon 11. Dec - 12:05:08, Kristen Carlson Accardi wrote:
Ok - how is this?
Looks good to me, thanks!
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Signed-off-by: Holger Macht [EMAIL PROTECTED]
Applied.
thanks,
-Len
Hi,
I am working on MPC8360E Security Engine. I have ported the Openswan
2.4.5(IPSec --KLIPS) with OCF to MPC8360E's Security Engine (Talitos).
Encryption and Decryption is working. But when I check the performance of
Talitos with netio benchmark Tool, IPSec S/W Algorithms is giving more
Add VMI SMP boot hook. We emulate a regular boot sequence and use the
same APIC IPI initiation, we just poke magic values to load into the CPU
state when the startup IPI is received, rather than having to jump through a
real mode trampoline.
This is all that was needed to get SMP to work.
VMI timer code. It works by taking over the local APIC clock when APIC is
configured, which requires a couple hooks into the APIC code. The backend
timer code could be commonized into the timer infrastructure, but there are
some pieces missing (stolen time, in particular), and the exact
These are the patches for the VMI backend to paravirt-ops. Base
kernel where I tested them was 2.6.19-git20.
Basically, there are only a couple of hooks needed that were left
out of the initial paravirt-ops merge, and then the backend code
is a very straightforward implementation of the
The VMI backend uses explicit page type notification to track shadow
page tables. The allocation of page table roots is especially tricky.
We need to clone the root for non-PAE mode while it is protected under
the pgd lock to correctly copy the shadow.
We don't need to allocate pgds in PAE mode,
Fairly straightforward implementation of VMI backend for paravirt-ops.
Subject: VMI backend for paravirt-ops
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r d8711b11c1eb arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Dec 12 13:51:06 2006 -0800
+++ b/arch/i386/Kconfig Tue Dec 12 13:51:13
The VMI ROM has a mode where hypercalls can be queued and batched. This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions. This is similar to the MMU batching hooks already
I found a clever way to make the extra IOPL switching invisible to
non-paravirt compiles - since kernel_rpl is statically defined to
be zero there, and only non-zero rpl kernel have a problem restoring IOPL,
as popf does not restore IOPL flags unless run at CPL-0.
Subject: IOPL handling for
Andrew Morton a écrit :
On Wed, 13 Dec 2006 16:12:46 -0800
Greg KH [EMAIL PROTECTED] wrote:
Original comment seemed to indicate that this conditional thing was
performance related. Is it really? If not, we should consider the below patch.
Yes, it's a performance gain and I don't see how this
Someone also mentioned that we could just put a nice poem into the
kernel module image in order to be able to enforce our copyright license
in any court of law.
Full bellies of fish
Penguins sleep under the moon
Dream of wings that fly
thanks,
Whoever says that has no
Eric W. Biederman wrote:
What is the problem you are trying to solve?
2 problems
1) irq's that irqbalance should not touch at all
2) irqs that can only go to a subset of processors.
1) is very real today
2) is partially real on some of the bigger numa stuff already.
-
To unsubscribe from this
On Wed, 13 Dec 2006, Martin J. Bligh wrote:
The point of banning binary drivers would be to leverage hardware
companies into either releasing open source drivers, or the specs for
someone else to write them.
IMHO, it's up to the users to decide if they want to keep buying hardware
which
with the patch it boots perfectly without any command-line args.
Are you getting the 'Firmware space is locked read-only' message then?
Thanks, Jan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, 2006-12-13 at 16:55 -0800, Greg KH wrote:
Oh, and for those who have asked me how we would enforce this after this
date if this decision is made, I'd like to go on record that I will be
glad to take whatever legal means necessary to stop people from
violating this.
I see no
On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
If a module arguably isn't a derived work, we simply shouldn't try to say
that its authors have to conform to our worldview.
I wouldn't argue that _anyone_ else should be exposed to my worldview; I
think the Geneva Convention has
Arjan van de Ven [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
What is the problem you are trying to solve?
2 problems
1) irq's that irqbalance should not touch at all
This is easy we just need a single bit. Not 128+ bytes on the huge
machines.
2) irqs that can only go to a subset
Eric W. Biederman wrote:
1) is very real today
2) is partially real on some of the bigger numa stuff already.
You have said you the NUMA cases is handled in another way already?
the numa case of I prefer that cpu is handled. Not the I cannot
work on those.
-
To unsubscribe from this list:
Eike == Rolf Eike Beer [EMAIL PROTECTED] writes:
Eike Am Mittwoch, 13. Dezember 2006 17:51 schrieb
Eike [EMAIL PROTECTED]:
I'm not sure about the driver being cpqfc, I know in 2.6.0 1 the
driver was definitely iphase.c/h/o I do know the chipset was used
by almost everyone, Compaq/HP/DEC and
I'll put a .config and a dmesg of the machine booting at
http://www.jdi-ict.nl/plain/ for those who want to look at it.
dmesg : http://www.jdi-ict.nl/plain/lnx01.dmesg
Kernel config : http://www.jdi-ict.nl/plain/lnx01.config
Hmm.. Switching CONFIG_HZ from 1000 to 250 seems to 'fix' the
i've posted on this before so here's a slightly-updated patch that
uses the kbuild menuconfig feature to make numerous entries under
the Device drivers menu selectable on the spot. if folks think this
is a good idea, what's the best way to get it in?
i could officially submit the patch as
Arjan van de Ven [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
1) is very real today
2) is partially real on some of the bigger numa stuff already.
You have said you the NUMA cases is handled in another way already?
the numa case of I prefer that cpu is handled. Not the I cannot work
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..2e03a3f
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,240 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int
Socket notifications.
This patch includes socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about various benchmarks and server itself
(evserver_kevent.c) can be found
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
This subsystem uses high-resolution timers.
id.raw[0] is used as number of seconds
id.raw[1] is used as number of
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentially eny kind of events.
poll/select() notifications.
This patch includes generic poll/select notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake, a lot of allocations and so on).
Signed-off-by: Evgeniy
Pipe notifications.
diff --git a/fs/pipe.c b/fs/pipe.c
index f3b6f71..aeaee9c 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -16,6 +16,7 @@
#include linux/uio.h
#include linux/highmem.h
#include linux/pagemap.h
+#include linux/kevent.h
#include asm/uaccess.h
#include asm/ioctls.h
@@ -312,6
Kevent posix timer notifications.
Simple extensions to POSIX timers which allows
to deliver notification of the timer expiration
through kevent queue.
Example application posix_timer.c can be found
in archive on project homepage.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git
On Thu, 14 Dec 2006, Jan Beulich wrote:
with the patch it boots perfectly without any command-line args.
Are you getting the 'Firmware space is locked read-only' message then?
yep...
so let me ask a naive question... don't we want the firmware locked
read-only because that protects the
the numa case of I prefer that cpu is handled. Not the I cannot work on
those.
How is the NUMA case of I prefer that cpu handled?
it's exported via /sys/bus/pci/devices/device/local_cpus
(and the irq is in the /irq directory next to local_cpus)
-
To unsubscribe from this list: send the
On Thu, 14 Dec 2006 09:15:39 +0100 (CET)
Igmar Palsenberg [EMAIL PROTECTED] wrote:
I'll put a .config and a dmesg of the machine booting at
http://www.jdi-ict.nl/plain/ for those who want to look at it.
dmesg : http://www.jdi-ict.nl/plain/lnx01.dmesg
Kernel config :
On Thu, Dec 14, 2006 at 12:10:15AM -0500, Bill Nottingham wrote:
Greg KH ([EMAIL PROTECTED]) said:
An updated version is below.
If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL
for removal at the same time, as this essentially renders that irrelevant.
That being
On Tue, 12 Dec 2006, Randy Dunlap wrote:
On Tue, 12 Dec 2006 07:48:51 +0100 (CET) Ben Castricum wrote:
This bug started to show up after the release of 2.6.19 (iirc plain 2.6.19
was still working fine).
The full dmesg is at
Hmm.. Switching CONFIG_HZ from 1000 to 250 seems to 'fix' the problem.
I haven't seen the issue in nearly a week now. This makes Andrew's theory
about missing interrupts very likely.
Andrew / others : Is there a way to find out if it *is* missing
interrupts ?
umm, nasty.
I'm really not convinced about the user-mode thing unless somebody can
show me a good reason for it. Not just some wouldn't it be nice kind of
thing. A real, honest-to-goodness reason that we actually _want_ to see
used.
Qemu? It would be nice if emulators could directly drive hardware:
On Thu, 14 Dec 2006 06:56:24 +
Al Viro [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 06:44:30AM +, Al Viro wrote:
On Wed, Dec 13, 2006 at 10:10:05PM -0500, Ben Collins wrote:
At least on PPC, the op ? op : dma construct causes a compile failure
because the dma_* is a
On Thu, 14 Dec 2006 09:55:38 +0100 (CET)
Igmar Palsenberg [EMAIL PROTECTED] wrote:
Hmm.. Switching CONFIG_HZ from 1000 to 250 seems to 'fix' the problem.
I haven't seen the issue in nearly a week now. This makes Andrew's theory
about missing interrupts very likely.
Andrew /
On Wed, 2006-12-13 at 23:56 +, Alan wrote:
On Wed, 13 Dec 2006 23:30:55 +0100
Thomas Gleixner [EMAIL PROTECTED] wrote:
- IRQ happens
- kernel handler runs and masks the chip irq, which removes the IRQ
request
IRQ is shared with the disk driver, box dead.
Err ?
IRQ happens
IRQ
On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
FWIW: As far as I understand the linux kernel code (I am no kernel
developer so please correct me if I am wrong) the PCI dma mapping code is
abstracted by struct dma_mapping_ops. I.e. there are currently four
possible
See below. The other machine is mostly identifical, except for i8042
missing (probably due to running an older kernel, or small differences in
the kernel config).
Does the other machine have the same problems?
No, but that machine has a lot less disk and networkactivity.
Are you
On Wed, Dec 13, 2006 at 01:29:25PM -0700, Erik Andersen wrote:
On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote:
We could not reproduce the data corruption anymore if we boot
the machines with the kernel parameter iommu=soft i.e. if we
use software bounce buffering instead of
On Thu, Dec 14, 2006 at 12:33:23AM +0100, Christoph Anton Mitterer wrote:
4)
And does someone know if the nforce/opteron iommu requires IBM Calgary
IOMMU support?
It doesn't, Calgary isn't found in machine with Opteron CPUs or NForce
chipsets (AFAIK). However, compiling Calgary in should make
On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote:
with DRI you have the case where something needs to do security
validation of the commands that are sent to the card. (to avoid a
non-privileged user to DMA all over your memory)
We also have the interesting case where your
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote:
- error in the Opteron (memory controller)
- error in the Nvidia chipsets
- error in the kernel
My guess without further information would be that some, but not all
BIOSes are doing some work to avoid this.
Does anyone
Fix do_page_fault and update_mmu_cache.
* Fix do_page_fault (vmalloc_fault:) to pass error_code correctly
to update_mmu_cache by using a thread-fault code for all m32r chips.
* Fix update_mmu_cache for OPSP chip
- #ifdef CONFIG_CHIP_OPSP portion is a workaround of OPSP;
Add a
This patch fixes the kernel entry point address of vmlinux.
The m32r kernel entry address is 0x08002000 (physical).
But, so far, the ENTRY point written in vmlinux.lds.S was not point
the correct kernel entry address.
(before fix)
$ objdump -x vmlinux
vmlinux: file format
Cosmetic updates and trivial fixes of m32r arch-dependent files.
- Remove RCS ID strings and trailing white lines
- Other misc. cosmetic updates
Signed-off-by: Hirokazu Takata [EMAIL PROTECTED]
---
arch/m32r/kernel/head.S |2 --
arch/m32r/lib/ashxdi3.S |
Dear Linux developers,
I recently discovered that the Linux kernel on 32 bits x86 processors
reports the stack as being non-executable while it is actually
executable (because located in the same memory segment).
# grep maps /proc/self/maps
bfce8000-bfcfe000 rw-p bfce8000 00:00 0
On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote:
I just realized that booting with iommu=soft makes my pcHDTV
HD5500 DVB cards not work. Time to go back to disabling the
memhole and losing 1 GB. :-(
That points to a bug in the driver (likely) or swiotlb (unlikely), as
On Thu, 2006-12-14 at 10:26 +0100, Franck Pommereau wrote:
Dear Linux developers,
I recently discovered that the Linux kernel on 32 bits x86 processors
reports the stack as being non-executable while it is actually
executable (because located in the same memory segment).
this is not per se
On Thu, Dec 14, 2006 at 02:52:35AM -0700, Erik Andersen wrote:
On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote:
I just realized that booting with iommu=soft makes my pcHDTV
HD5500 DVB cards not work. Time to go back to disabling the
memhole and losing 1 GB. :-(
That
Greetings,
Lockdep doesn't approve of cpufreq, and seemingly with cause... I had to
poke SysRq-O.
[ 1103.164377] Disabling non-boot CPUs ...
[ 1103.171094] stopped custom tracer.
[ 1103.174614]
[ 1103.174618] ===
[ 1103.182692] [ INFO:
Additional fixes for processors without ISA_DSP_LEVEL2.
sigcontext_t does not have dummy_acc1h, dummy_acc1l members any longer.
This patch is against v2.6.19.1 kernel.
From: Hirokazu Takata [EMAIL PROTECTED]
Subject: [PATCH 2.6.19] m32r: Make userspace headers platform-independent
Date: Wed, 06
* Mike Galbraith [EMAIL PROTECTED] wrote:
Greetings,
Lockdep doesn't approve of cpufreq, and seemingly with cause... I had
to poke SysRq-O.
hm ... this must be an upstream problem too, right? -rt shouldnt change
anything in this area (in theory).
Ingo
-
To unsubscribe from this
Greg KH wrote:
A large number of people have expressed interest recently in the
userspace i/o driver core which allows userspace drivers to be written
to handle some types of hardware.
Right now the UIO core is working and in the -mm releases. It's been
rewritten from the last time patches
* tike64 [EMAIL PROTECTED] wrote:
Steven Rostedt [EMAIL PROTECTED] wrote:
Also, have you tried this with a nanosleep instead of a select.
Select's timeout is just that, a timeout. It's not suppose to be
accurate, as long as it doesn't expire early. The reason I state
this, is that
On Thu, 2006-12-14 at 10:59 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Greetings,
Lockdep doesn't approve of cpufreq, and seemingly with cause... I had
to poke SysRq-O.
hm ... this must be an upstream problem too, right? -rt shouldnt change
anything in
dean gaudet [EMAIL PROTECTED] 14.12.06 09:40
On Thu, 14 Dec 2006, Jan Beulich wrote:
with the patch it boots perfectly without any command-line args.
Are you getting the 'Firmware space is locked read-only' message then?
yep...
so let me ask a naive question... don't we want the firmware
Am Donnerstag, 14. Dezember 2006 10:30 schrieb Muli Ben-Yehuda:
On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote:
with DRI you have the case where something needs to do security
validation of the commands that are sent to the card. (to avoid a
non-privileged user to DMA
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Version is 2.6.19-rc6-git. System was more or less idle, just normal desktop
stuff (copying single files by scp, writing mail). Don't know what exactly
was working when this happened, I saw it some minutes later.
BUG: warning at fs/inotify.c:181/set_dentry_child_flags()
[c017da03]
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
The userspace driver would register a couple of bytecode programs:
On Thu, 14 Dec 2006 01:35:17 +0100 (CET)
Jiri Slaby [EMAIL PROTECTED] wrote:
isicom, remove tty_{hang,wake}up bottomhalves
- tty_hangup() itself schedules work, so there is no need to schedule hangup
in the driver
- tty_wakeup() its safe to call it while in atomic (IS THIS CORRECT?), so
2008? I bet a lot of people would read the above to say that their
system will just drop dead of a New Year's hangover, and they'll freak.
I wouldn't want to be the one getting all the email at that point...
I wouldn't worry. Everyone will have patched it back out again by then,
or made their
Ingo Molnar [EMAIL PROTECTED] wrote:
tike64 [EMAIL PROTECTED] wrote:
Ok, understood; I tried this:
t = raw_timer();
ts.tv_nsec = 500;
ts.tv_sec = 0;
nanosleep(ts, 0);
t = raw_timer() - t;
It is better but I still see 8ms occasional delays when listing
Am Donnerstag, 14. Dezember 2006 09:49 schrieb Duncan Sands:
I'm really not convinced about the user-mode thing unless somebody can
show me a good reason for it. Not just some wouldn't it be nice kind of
thing. A real, honest-to-goodness reason that we actually _want_ to see
used.
But in order to get this core into the kernel tree, we need to have some
real drivers written that use it. So, for anyone that wants to see
this go into the tree, now is the time to step forward and post your
patches for hardware that this kind of driver interface is needed.
Might be kind of
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
An entire driver in bytecode? that means exposing the entire
On Wed, 13 Dec 2006 17:17:45 -0800 (PST)
Doug Thompson [EMAIL PROTECTED] wrote:
From: Mike Chan [EMAIL PROTECTED]
Diff against 2.6.19
This fix/change returns the offset into the page for
the ce/ue error, instead of just 0. The e752x dram controller reads
34:6 of the
linear address with
+void edac_mc_handle_fbd_ue(struct mem_ctl_info *mci,
+ unsigned int csrow,
+ unsigned int channela,
+ unsigned int channelb,
+ char *msg)
+{
+ int len = EDAC_MC_LABEL_LEN *
[why trim the cc?]
Hans-Jürgen Koch wrote:
Am Donnerstag, 14. Dezember 2006 10:44 schrieb Avi Kivity:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
The userspace driver would
On Wed, 13 Dec 2006 17:18:53 -0800 (PST)
Doug Thompson [EMAIL PROTECTED] wrote:
From: Frithiof Jensen [EMAIL PROTECTED]
This patch is meant for Kernel version 2.6.19
This is an attempt of providing an interface for memory
scrubbing control in EDAC.
Signed-off-by: Frithiof Jensen
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that why not do a real driver.
Arjan van de Ven wrote:
On Thu, 2006-12-14 at 12:46 +0200, Avi Kivity wrote:
Arjan van de Ven wrote:
I understand one still has to write a kernel driver to shut up the irq.
How about writing a small bytecode interpreter to make event than
unnecessary?
if you do that
As per Alan's suggestion I decompressed the kernel source tree with the
processes pegged to one CPU then the other, and as he predicted it took
vastly longer on one CPU than the other, but I don't know what that
implies, or how to fix it.
From the timing it sounds like one processor cache
On Wed, 13 Dec 2006 22:01:15 -0800
Hua Zhong [EMAIL PROTECTED] wrote:
I think allowing binary hardware drivers in userspace hurts
our ability to leverage companies to release hardware specs.
If filesystems can be in user space, why can't drivers be in user space? On
what *technical*
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about different code here, right ? The one, I'm looking
at returns on each interrupt event.
tglx
-
To unsubscribe from this list: send the
On Thu, 14 Dec 2006 08:21:20 +
David Woodhouse [EMAIL PROTECTED] wrote:
If they fail to do that under the 'honour system' then I'm not averse to
'enforcing' it by technical measures. (For some value of 'enforcement'
which is easy for them to patch out if their lawyers are _really_ sure
For the sharing case, some sort of softirq should be created. That is, when a
hard interrupt is generated and the irq handler is executed, set a flag that
at
some other point in time, the irq is delivered to userspace. Like you do with
signals in userspace:
NO.
The whole point is, YOU
IRQ is shared with the disk driver, box dead.
Err ?
IRQ happens
IRQ is disabled by the generic handling code
Handler is invoked and checks, whether the irq is from the device or
not.
- If not, it returns IRQ_NONE, so the next driver (e.g. disk) is
invoked.
- If yes, it masks
irqreturn_t uio_handler(...) {
disable interrupts for this dev;
set a flag that notifies userspace the next best time;
seomstruct-flag |= IRQ_ARRIVED;
return IRQ_HANDLED;
}
Rather than IRQ_HANDLED, it should have been: remove this irq handler
from the irq handlers
Am Donnerstag, 14. Dezember 2006 12:14 schrieb Alan:
On Wed, 13 Dec 2006 22:01:15 -0800
Hua Zhong [EMAIL PROTECTED] wrote:
I think allowing binary hardware drivers in userspace hurts
our ability to leverage companies to release hardware specs.
If filesystems can be in user space,
On Thu, 14 Dec 2006 12:22:16 +0100
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about different code here, right ? The one, I'm looking
at returns on
On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
BTW: It would be really great if this area of the kernel would get some
more and better documentation. The information at
linux-2.6/Documentation/x86_64/boot_options.txt is very
Am Donnerstag, 14. Dezember 2006 12:39 schrieb Alan:
On Thu, 14 Dec 2006 12:22:16 +0100
Thomas Gleixner [EMAIL PROTECTED] wrote:
On Thu, 2006-12-14 at 10:52 +, Alan wrote:
Might be kind of hairy given uio_read() doesn't even return from the
kernel.
We probably talk about
On Thu, 2006-12-14 at 10:59 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Greetings,
Lockdep doesn't approve of cpufreq, and seemingly with cause... I had
to poke SysRq-O.
hm ... this must be an upstream problem too, right? -rt shouldnt change
anything in
On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
That said, I'm going to suggest that you people talk to your COMPANY
LAWYERS on this, and I'm personally not going to merge that particular
code unless you can convince the people you work for to merge it first.
That's quoting material
On Thu, Dec 14, 2006 at 12:38:08PM +0100, Karsten Weiss wrote:
On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
BTW: It would be really great if this area of the kernel would get some
more and better documentation. The
# grep maps /proc/self/maps
bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack]
this shows that the *intent* is to have it non-executable.
Not all x86 processors can enforce this. All modern ones do.
Mine is quite recent:
# cat /proc/cpuinfo
processor : 0
vendor_id :
On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote:
A small German manufacturer produces high-end AD converter cards. He sells
100 pieces per year, only in Germany and only with Windows drivers. He would
now like to make his cards work with Linux. He has two driver programmers
On Thu, 2006-12-14 at 13:07 +0100, Franck Pommereau wrote:
# grep maps /proc/self/maps
bfce8000-bfcfe000 rw-p bfce8000 00:00 0 [stack]
this shows that the *intent* is to have it non-executable.
Not all x86 processors can enforce this. All modern ones do.
Mine is quite
Some fallout of: 2e892f43ccb602e8ffad73396a1000f2040c9e0b
CC mm/slab.o
/usr/src/linux-2.6-git/mm/slab.c:3557: error: conflicting types for
‘kmem_ptr_validate’
/usr/src/linux-2.6-git/include/linux/slab.h:58: error: previous declaration of
‘kmem_ptr_validate’ was here
Signed-off-by:
Duncan Sands wrote:
I'm really not convinced about the user-mode thing unless somebody can
show me a good reason for it. Not just some wouldn't it be nice kind of
thing. A real, honest-to-goodness reason that we actually _want_ to see
used.
Qemu? It would be nice if emulators could directly
On Thu, 14 Dec 2006 10:56:03 +0100
Hans-Jürgen Koch [EMAIL PROTECTED] wrote:
* They let somebody write the small kernel module they need to handle
interrupts in a _clean_ way. This module can easily be checked and could
even be included in a mainline kernel.
And might as well do the mmap
Ah, apologies, it's exam time and I probably didn't look hard enough
on the mailing list before posting. For the record though, I'd posted
the bug (no patch) to bugzilla on the 9th (although it looks as if the
email address it was assigned to is actually defunct - anyone know why
bugzilla is
1 - 100 of 871 matches
Mail list logo
