> 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
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
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_
>> 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
> > 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
> 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
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
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
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
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
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
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
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
>> # 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
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
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
> On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
> > In the mean time
> > does mounting the filesystem with data=writeback help?
>
> I have now nine hours uptime with data=writeback, and the file is
> still OK. Looks good.
>
> By this posting, I'm going to invoke murphy, so I'll
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
On Thu, 14 Dec 2006 12:31:16 +0100
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> You think it's easier for a manufacturer of industrial IO cards to
> debug a (large) kernel module?
You think its any easier to debug because the code now runs in ring 3 but
accessing I/O space.
> > uio also
Arjan van de Ven wrote:
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
On Thu, 14 Dec 2006 12:37:16 +0100
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> There are three breaks in that while loop, the first makes it return as
> soon as an interrupt occurs.
Doh ignore that I misread it. Perils of reading email before midday
-
To unsubscribe from this list: send the
> It has to be written once, but compiled for every kernel
> version and $arch out there (for out of tree drivers), or it
> has to wait for the next kernel release and distro sync (for
> in-tree drivers).
Still better than written for every _and_ compiled for every.
But wait, make it simpler:
>The patches can be found in the -mm releases or at:
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio.patch
>- UIO core
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch
>- UIO
Am Donnerstag, 14. Dezember 2006 12:51 schrieb Olivier Galibert:
> 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
> >
Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> On Thu, 14 Dec 2006 12:31:16 +0100
> Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> > You think it's easier for a manufacturer of industrial IO cards to
> > debug a (large) kernel module?
>
> You think its any easier to debug because the code
On Thu, 14 Dec 2006, tike64 wrote:
> 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(, 0);
> > > t = raw_timer() - t;
> > >
>
On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first.
You don't think I already get enough hatemail from binary-module users ? :)
Dave
--
http://www.codemonkey.org.uk
-
To
On Wed, 2006-12-13 at 15:53 -0800, Stephen Hemminger wrote:
> The connection between file and network device is through many
> layers and there is no direct binding. It could be 0 to N interfaces
> and even be data dependent.
you mean protocol dependent? yes,it goes trough the layer of the vfs
Am Donnerstag, 14. Dezember 2006 13:39 schrieb Alan:
> 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
> >
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary
On Dec 14 2006 12:42, Alan wrote:
>On Thu, 14 Dec 2006 12:31:16 +0100
>Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
>> You think it's easier for a manufacturer of industrial IO cards to
>> debug a (large) kernel module?
>
>You think its any easier to debug because the code now runs in ring 3 but
On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 12:42, Alan wrote:
> >On Thu, 14 Dec 2006 12:31:16 +0100
> >Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> >> You think it's easier for a manufacturer of industrial IO cards to
> >> debug a (large) kernel module?
> >
> >You
On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
> The rest looks good. Please resend and I'll add my Acked-by.
Thanks a lot for your comments and suggestions. Here's my 2nd try:
===
From: Karsten Weiss <[EMAIL PROTECTED]>
$ diffstat ~/iommu-patch_v2.patch
Documentation/kernel-parameters.txt |
Correct mis-spellings of "algorithm", "appear", "consistent" and
(shame, shame) "kernel".
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
Documentation/video4linux/bttv/Insmod-options |2 +-
arch/m32r/lib/usercopy.c |4 ++--
On Wed, Dec 13, 2006 at 10:47:32PM -0500, Daniel Drake wrote:
> In amd64-agp.c, would it be dangerous to remove the "aperture base > 4G"
> thing and instead simply only read the rightmost 7 bits to ensure the
> aperture base is always in range? (This is coming from someone with
> little
Containes .h file changes.
bill
--- include/linux/mutex.h d231debc2848a8344e1b04055ef22e489702e648
+++ include/linux/mutex.h 734c89362a3d77d460eb20eec3107e7b76fed938
@@ -15,6 +15,7 @@
#include
#include
#include
Jan Engelhardt wrote:
It has to be written once, but compiled for every kernel
version and $arch out there (for out of tree drivers), or it
has to wait for the next kernel release and distro sync (for
in-tree drivers).
Still better than written for every _and_ compiled for every.
But
Rough annotations to speed up the object attachment logic.
bill
--- arch/xtensa/platform-iss/network.c eee47b0ca011d1c327ce7aff0c9a7547695d3a1f
+++ arch/xtensa/platform-iss/network.c 76b16d29a46677a45d56b64983e0783959aa2160
@@
Build system changes.
bill
--- kernel/Kconfig.preempt 3148bd94270ea0a853d8e443616cd7a668dd0d3b
+++ kernel/Kconfig.preempt d63831dbfbb9e68386bfc862fd2dd1a8f1e9779f
@@ -176,3 +176,12 @@ config RCU_TRACE
Say Y here
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first. This is not something where we use my tree as a way to get it to
> other trees. This is something where the push had better come from the
> other direction.
I can probably speak for Ubuntu in saying we wont
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.35:
Adrian Bunk (3):
On Thu, Dec 14 2006, Joerg Schilling wrote:
> >CD recording : recorder no longer detected by "wodim" software set in
> >2.6.19. I suspect it's a bug in the software... but don't know where
> >to look for changes. 2.6.19-rc5 worked.
> >hardware: IDE MATSHITADVD-RAM UJ-820S
> >(2.6.19-git6 also
On 12/14/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Ok, the two-week merge period is over, and -rc1 is out there.
Still need this libata-sff.c patch:
http://marc.theaimsgroup.com/?l=linux-kernel=116343564202844=raw
to have my root device detected, ata_piix probe would otherwise
fail as
The end marker is missing from the driver's PCI ID table. This set of
changes adds the marker, switches to using PCI_DEVICE() and records the
table for the use in a module.
Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
Here's one more. ;-)
Please apply.
Maciej
>CD recording : recorder no longer detected by "wodim" software set in
>2.6.19. I suspect it's a bug in the software... but don't know where
>to look for changes. 2.6.19-rc5 worked.
>hardware: IDE MATSHITADVD-RAM UJ-820S
>(2.6.19-git6 also fails with external LiteON USB DVD burner)
I
Core infrastructure files with /proc interface
--- include/linux/lock_stat.h 554e4c1a2bc399f8a4fe4a1634b29aae6f4bb4de
+++ include/linux/lock_stat.h 554e4c1a2bc399f8a4fe4a1634b29aae6f4bb4de
@@ -0,0 +1,147 @@
+/*
+ * By Bill Huey
.c files that have been changed, rtmutex.c, rt.c
--- kernel/rt.c 5fc97ed10d5053f52488dddfefdb92e6aee2b148
+++ kernel/rt.c 3b86109e8e4163223f17c7d13a5bf53df0e04d70
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
Greg KH wrote:
It's just that I'm so damn tired of this whole thing. I'm tired of
people thinking they have a right to violate my copyright all the time.
Pretty much every license under the sun is getting violated,
and people are getting away with it. The GPL is not special
in this regard.
Hello,
I'm back with another annoying announcement and post of my "lock stat"
patches for Ingo's 2.6.19-rt14 patch. I want review, comments and
eventually inclusion into the -rt.
Changes in this release:
- forward ported to 2,6.19-rt14
- rt_mutex_slowtrylock() path now works with lock stat
On Wed, 2006-12-13 at 21:39 -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary drivers become
The file init/initramfs.c is always compiled and linked in the kernel
vmlinux even when BLK_DEV_RAM and BLK_DEV_INITRD are disabled and the
system isn't using any form of an initramfs or initrd. In this situation
the code is only used to unpack a (static) default initial rootfilesystem.
The
And the patch was reposted here:
http://marc.theaimsgroup.com/?l=linux-kernel=116594961106441=2
On Thu, 2006-12-14 at 14:59 +0100, Alessandro Suardi wrote:
> On 12/14/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > Ok, the two-week merge period is over, and -rc1 is out there.
>
> Still
On Wed, 2006-12-13 at 23:45 -0800, Roland Dreier wrote:
> > IOW, do ; while(0) / do { } while (0) is not a proper way to do a macro
> > that imitates a function returning void.
> >
> > Objections?
>
> None from me, although the ternary ? : is a pretty odd way to write
>
> if (blah)
>
Update all arch/*/kernel/vmlinux.lds.S to not include space for initramfs
when CONFIG_BLK_DEV_INITRAMFS is not selected. This saves another 4 kbytes
on most platfoms (some reserve PAGE_SIZE for initramfs).
Signed-off-by: Jean-Paul Saman <[EMAIL PROTECTED]>
--
Index:
Hi,
ext Frank Seidel wrote:
> Quoting Anderson Briglia <[EMAIL PROTECTED]>:
>> [...]
> Hi,
> thats really cool stuff you're providing with your patches. :)
> I have some feedback or questions some parts here.
> But as i just started trying to get into kernelhacking you probably
> better don't
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> ...
> it's ok for the timer to be a little over, but it must never be a
> little under.
> ...
> So we make sure the timer goes off in (n+1) ms, and not just (n).
Ok, this makes sense - thanks.
What confuses / confused me is that I have 4 combinations:
On Wed, 2006-12-13 at 17:41 -0800, Andrew Morton wrote:
> > Trond, please define precisely and completely and without reference to
> > the existing implementation: what behaviour does NFS want?
Part of the behaviour is dictated by our needs for
invalidate_inode_pages2(), part of the behaviour is
amikbd: missing declaration
sun3_NCR5380: more work_struct mess
sun3_NCR5380: cast is not an lvalue
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/keyboard/amikbd.c b/drivers/input/keyboard/amikbd.c
index 16583d7..c67e84e 100644
--- a/drivers/input/keyboard/amikbd.c
On Thu, Dec 14, 2006 at 10:36:13AM +, Alan wrote:
> > 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.
Hello,
my problem is, that the slackware maintainers decided to use kernel
2.6.17. Here is their comment, they posted to the changelog:
After much thought and consultation with developers, it has been decided
to move 2.6.17.x out of /testing and into /extra. It runs stable by all
reports,
Arjan van de Ven wrote:
>> Why not show both.
>> "intent" and "effective".
>
> that would change the file format .. which is used by apps today already
> (including glibc)
So, what about having another file, say /proc/self/emaps (effective
maps) that would display how things are really set.
On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
>
> > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> > going. If we don't stand up at some point, and ban binary drivers, we
> > will, I
Ben Collins wrote:
Here's the list of proprietary drivers that are in Ubuntu's restricted
modules package:
madwifi (closed hal implementation, being replaced in openhal)
fritz
ati
nvidia
ltmodem (does that even still work?)
ipw3945d (not a kernel
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 14 2006, Joerg Schilling wrote:
> > >CD recording : recorder no longer detected by "wodim" software set in
> > >2.6.19. I suspect it's a bug in the software... but don't know where
> > >to look for changes. 2.6.19-rc5 worked.
> > >hardware:
On 14/12/06, Manuel Reimer <[EMAIL PROTECTED]> wrote:
Hello,
my problem is, that the slackware maintainers decided to use kernel
2.6.17. Here is their comment, they posted to the changelog:
They had a 2.6.16 kernel in /extra before and as far as I know the
2.6.16 kernel series still gets
Florian Festi wrote:
I am looking for the meaning of the following key codes as #defined in
include/linux/input.h. I need to know what hardware produces the keycode
and what happens/should happen when the corresponding key is pressed.
Thanks for all you comments! They helped a lot.
The
Michael K. Edwards wrote:
I don't think it would. There is a strong argument that GPL drivers
in the mainline kernel are a good idea on technical and business
grounds.
Any volunteers to expand on that in the Kernelnewbies section
on this subject? So far the "business ground" is only half a
Jens Axboe wrote:
On Wed, Dec 13 2006, Larry Finger wrote:
There is a regression in v2.6.19-rc18 that makes one unable to write CD's.
In k3b, the drive status shows no devices. I used git bisect to find the
bad commit is the following:
Try a newer snapshot, it was fixed a few days ago.
Just a Thank you & EOThread message :-)
On Tue, Nov 28, 2006 at 09:24:15PM +0900, Tejun Heo wrote:
> Dunno about IDE layer. It has been done that way for long time and not
> sure whether adding such option will happen, but for libata, hpa
> handling is still not implemented ...
I'm now (since
On Thu, 14 Dec 2006, tike64 wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > ...
> > it's ok for the timer to be a little over, but it must never be a
> > little under.
> > ...
> > So we make sure the timer goes off in (n+1) ms, and not just (n).
Oops, that should have read (n+1) 10ms, or
> > I'd be happy to know how to enable it.
>
> CONFIG_HIGHMEM64G=y
This is not at all obvious from arch/i386/Kconfig. Maybe we should
fix this?
- Ted
Add an explanation that HIGHMEM64G is needed in order to get support
for the NX feature.
Remove an
>But I would ask that they honour the licence on the code I release, and
>perhaps more importantly on the code I import from other GPL sources.
It's not a question of "honoring the license"; it's a matter of what
is the reach of the license, as it relates to derivitive works. It's
a complicated
On Thu, 14 Dec 2006 14:59:23 +0100
"Alessandro Suardi" <[EMAIL PROTECTED]> wrote:
> On 12/14/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > Ok, the two-week merge period is over, and -rc1 is out there.
>
> Still need this libata-sff.c patch:
>
>
> Pretty much every license under the sun is getting violated,
> and people are getting away with it. The GPL is not special
> in this regard.
That may begin to change in time. There are a lot of people getting very
angry at the political level about the way large companies in particular
flout
On Thu, Dec 14, 2006 at 03:03:10AM -0500, James Morris wrote:
> 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,
Dave Jones wrote:
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for
> + 1 Gigabyte or more total physical RAM, answer "off" here.
>
I don't think your proposed wording (1 gigabyte or more) versus (more
than 1 gigabyte) doesn't really change the sense of this.
If we want to be even more explicit about this, then if the CPU level
selected by the user is
Linus Torvalds wrote:
Because I think it's stupid. So use somebody else than me to push your
political agendas, please.
ACK, I agree completely. I think its a silly, political, non-technical
decision being pushed here.
For the record, I also disagree with the sneaky backdoor way people
From: Theodore Tso <[EMAIL PROTECTED]>
Date: Thu, Dec 14, 2006 at 10:17:45AM -0500
>
> Remove an (incorrect) assertion that NOHIGHMEM is right for more
> users, since most systems are coming with at least 1G of memory these
> days, and even some laptops have up 4G of memory.
Given this (on a
Alan wrote:
Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example.
ACK++ We should definitely push Nouveau[1] as hard as we can.
Jeff
[1] http://nouveau.freedesktop.org/
On Thu, 2006-12-14 at 14:47 +, Pavel Machek wrote:
> Hi!
>
> > So far all first-hand experiences I heard of were positive (i.e. I did
> > not get an emaail from anyone saying: It had a negative effect for me),
> > so I propose to apply the patch from Con Kolivas. The wording in the
> >
On Thu, 2006-12-14 at 10:17 -0500, Theodore Tso wrote:
> > > I'd be happy to know how to enable it.
> >
> > CONFIG_HIGHMEM64G=y
>
> This is not at all obvious from arch/i386/Kconfig. Maybe we should
> fix this?
looks better; maybe add how to look for "pae" and "nx" in
the /proc/cpuinfo flags
Hi,
The kernel (sched.c) does not compile if CONFIG_HZ and CONFIG_SMP are set, and
CONFIG_NO_HZ isn't.
Is this patch correct ?
---
Index: linux-2.6.19-rt14-test/kernel/sched.c
===
--- linux-2.6.19-rt14-test.orig/kernel/sched.c
Hi,
this is the second and hopefully last release candidate for 2.4.34.
It fixes vulnerability CVE-2006-6106 affecting bluetooth (with
With malformed packets it might be possible to overwrite internal
CMTP and CAPI data structures).
Please build and test this version, especially on non-x86
In compiling the kernel without high res, I hit this error:
kernel/sched.c:4135: error: notick undeclared (first use in this function)
kernel/sched.c:4135: error: (Each undeclared identifier is reported only once
kernel/sched.c:4135: error: for each function it appears in.)
I'm assuming that
On Thu, 2006-12-14 at 10:37 -0500, Theodore Tso wrote:
> > + 1 Gigabyte or more total physical RAM, answer "off" here.
> >
>
> I don't think your proposed wording (1 gigabyte or more) versus (more
> than 1 gigabyte) doesn't really change the sense of this.
>
> If we want to be even more
Rik van Riel wrote:
Why would users buy a piece of hardware that needs a binary
only driver that's unsupportable, when they can buy a similar
piece of hardware that has a driver that's upstream and is
supported by every single Linux distribution out there?
In my experience it falls into a
Theodore Tso wrote:
+ 1 Gigabyte or more total physical RAM, answer "off" here.
I don't think your proposed wording (1 gigabyte or more) versus (more
than 1 gigabyte) doesn't really change the sense of this.
If we want to be even more explicit about this, then if the CPU level
On Thu, Dec 14, 2006 at 03:10:57PM +, James Courtier-Dutton wrote:
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/
Wow. That wins 'most ironic hostname' award for 2006.
Thankfully
On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> >
> > Thing is, if kernel.org kernels get patched to disallow binary modules,
> > whats to stop
On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:
>...
> The fact is, the reason I don't think we should force the issue is very
> simple: copyright law is simply _better_off_ when you honor the admittedly
> gray issue of "derived work". It's gray. It's not black-and-white. But
>
> The trick is to let a lawyer send cease and desist letters to people
> distributing the infringing software for 1 Euro at Ebay.
Doesn't that sound even more like the music industry ? Pick on Grandma,
and people who've no clue about the issue. It's not the way to solve such
problems. The world
On Thu, Dec 14, 2006 at 11:11:33AM -0500, Dave Jones wrote:
> On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> > If a kernel developer or a competitor sends a cease letter to
> > such a distribution, the situation changes from a complicated "derived
> > work" discussion to a
On Thu, 2006-12-14 at 15:10 +, James Courtier-Dutton wrote:
> Ben Collins wrote:
> >
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> >
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
> > ati
> >
On Wed, 13 Dec 2006, 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
>
On Thu, 14 Dec 2006, Peter Zijlstra wrote:
> 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
501 - 600 of 871 matches
Mail list logo
