On Fri, 2005-07-15 at 12:11 +0530, RVK wrote:
> Even in the presence of non-executable stack, Linux Torvalds explains
> that "It's really easy. You do something like this: 1) overflow the
> buffer on the stack, so that the return value is overwritten by a
> pointer to the system() library funct
Brian O'Mahoney wrote:
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a cop-out,
On Fri, 2005-07-15 at 11:39 +0530, RVK wrote:
> Understood on pid/tid and thread identifier diffrentiation. The question
> now is why pthread_t is typedef as unsigned long ?
It's just an arbitrary type that is big enough to contain the cookie.
Ian.
--
Ian Campbell
It is better to give than to
J.A. Magallon wrote:
On 07.14, RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
Ian Campbell wrote:
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way, it is just a "thing" which yo
On Fri, Jul 15, 2005 at 04:15:12AM +0200, Christian Kroll wrote:
> I have tested the patch against my DawiControl DC-150 RAID controller
> which is basically an add-on card with a SiI 3112 ASIC and a flash ROM.
> The activity LED of my case is directly connected to the add-on card.
>
> Unfortunate
Daniel McNeil wrote:
On Thu, 2005-07-14 at 16:16, Badari Pulavarty wrote:
How does your patch ensures that we meet the driver alignment
restrictions ? Like you said, you need atleast "even" byte alignment
for IDE etc..
And also, are there any restrictions on how much the "minimum" IO
size has
On Thu, Jul 14, 2005 at 07:00:11PM -0700, Christoph Lameter wrote:
> On Fri, 15 Jul 2005, David Gibson wrote:
>
> > Well, the COW patch implements a fault handler, obviously. What
> > specifically where you thinking about?
>
> About a fault handler of course and about surrounding scalability iss
On Thursday 14 July 2005 21:35, Andrew Haninger wrote:
> Hello.
>
> I'm using Linux Kernel 2.6.12.2 plus suspend 2.1.9.9 and acpi-20050408
> with the hibernate-1.10 script. My machine is a Shuttle SK43G which
> has a VIA KM400 chipset with an Athlon XP CPU.
>
> Suspension seems to work well. Howe
On Wed, Jul 13, 2005 at 07:04:38PM +0530, [EMAIL PROTECTED] wrote:
>
> I ma newbie to compactflash driver , I am using mpc862 PPC processor
> on my custom board having 64mb ram running linuxppc-2.4.18 kernel .
> i am using Sandisk Extreme CF 1GB which is 133x high speed, but
> found the performanc
Tejun Heo wrote:
Daniel McNeil wrote:
This patch relaxes the direct i/o alignment check so that user addresses
do not have to be a multiple of the device block size.
I've done some preliminary testing and it mostly works on an ext3
file system on a ide disk. I have seen trouble when the user
On Fri, 15 Jul 2005 00:27:48 +0200 Andi Kleen wrote:
> > > Some oprofile listings from a few of the test runs would be also nice.
> >
> > That is in the works. We will upload profile data. I'm having problem
> > with oprofile on some versions of kernel and that is being investigated
> > right n
Russell King <[EMAIL PROTECTED]> wrote:
> Well, in this case, the "whinging" resulted in
> finding a _real_ bug and locating why your ports
> weren't being found. So I guess it's
> good for something.
Indeed! The old kernel didn't have such an advantage.
> Can you mail me a diff of the changes
On Fri, 15 Jul 2005, Jesper Juhl wrote:
>
> It's buggy, that I know. setting kernel_hz (the new boot parameter) to
> 250 causes my system clock to run at something like 4-5 times normal
> speed
4 times normal. You don't actually make the timer interrupt happen at
250Hz, so the timer will be p
On Fri, 15 Jul 2005, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> > Audio did show slightly larger max latencies but nothing that would be of
> > significance.
> >
> > On video, maximum latencies are only slightly larger at HZ 250, all the
> > desired cpu was achi
On Fri, 15 Jul 2005, David Gibson wrote:
> I'm still not at all sure what you're getting at. Do you mean the
> demand-allocation patches which were floating around at some point - I
> gather they're important for doing sensible NUMA allocation of
> hugepages. They have a small overlap with the C
On Fri, Jul 15, 2005 at 05:45:58AM +0200, Jesper Juhl wrote:
> On 7/16/05, Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
>
> While I'm not qualified to comment on the implementation I do have a
> few small codingstyle comments :-)
>
>
> > diff --git a/fs/read_write.c b/fs/read_write.c
> > --
This patch fixes a microcode lockup in my CD-ROM adapters when a blank
CD is inserted. However, do not try to burn CDs yet! I'm pretty sure
that trying it will end in coasters.
- Fix a few cases where we were unable to resynchronize with replies
for previous commands. The main thing is to keep
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
> Audio did show slightly larger max latencies but nothing that would be of
> significance.
>
> On video, maximum latencies are only slightly larger at HZ 250, all the
> desired cpu was achieved, but the average latency and number of missed
EFI support in x86-64?
Is EFI only support IA64?
Is acpi in EFI?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Jul 2005 20:52:58 -0700
> yhlu <[EMAIL PROTECTED]> wrote:
>
> > Andi,
> >
> > How do yo think about make x86-64 kernel support openfirmware interface?
>
> I don't
On Fri, 15 Jul 2005 09:25, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > > I have to say, this whole thread has been pretty damn worthless in
> > > general in my not-so-humble opinion.
> >
> > This thread has really g
On Thu, 14 Jul 2005 20:52:58 -0700
yhlu <[EMAIL PROTECTED]> wrote:
> Andi,
>
> How do yo think about make x86-64 kernel support openfirmware interface?
I don't like it. We already have the old x86 BIOS interfaces and ACPI
and at some point EFI. No need for more.
-Andi
-
To unsubscribe from this
Interbech is a an application is designed to benchmark interactivity in Linux.
Version 0.21 update
http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
Changes:
Changed the design to run the benchmarked and background loads as separate
processes that spawn their own threads instead
Andi,
How do yo think about make x86-64 kernel support openfirmware interface?
Can we borrow some code from ppc64 arch?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 07:46:49PM -0700, yhlu wrote:
> > p.s. can you use powernow when acpi is disabled?
>
> Only on
On 7/16/05, Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
While I'm not qualified to comment on the implementation I do have a
few small codingstyle comments :-)
> diff --git a/fs/read_write.c b/fs/read_write.c
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -14,6 +14,7 @@
> #include
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's
Jan Blunck <[EMAIL PROTECTED]> wrote:
>
> This patch adds bogo dirent sizes for ramfs like already available for
> tmpfs.
>
> Although i_size of directories isn't covered by the POSIX standard it is
> a bad idea to always set it to zero. Therefore pretend a bogo dirent
> size for directory i_si
On Thu, Jul 14, 2005 at 04:05:17PM -0400, Horst von Brand wrote:
> Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
>
> [...]
>
> > Other than this, what are the general thoughts about this method as
> > opposed to just using a well defined byte order?
>
> I'd prefer a defined byte order. That
Hi all,
We (Anton Blanchard and others) have been trying to figure out the best
(or any) way to allow for IOMMU bypass when setting up DMA mappings on
particular devices. Our current idea is to hang a structure of pointers
to DMA mapping operations off the struct device and inherit it from the
de
On Thu, Jul 14, 2005 at 07:46:49PM -0700, yhlu wrote:
> p.s. can you use powernow when acpi is disabled?
Only on uniprocessor machines.
> p.s.s Is powerpc64 support ACPI? or ACPI is only can be used by x86?
powerpc64 uses openfirmware, not ACPI.
-Andi
-
To unsubscribe from this list: send the
On Thursday 14 July 2005 18:36, Mikael Pettersson wrote:
> On my x86-64 laptop (Targa Visionary 811: Athlon64 + VIA chipset,
> Arima OEM:d HW also sold by eMachines and others), ACPI is broken
> and hangs the x86-64 2.6.13-rc3 kernel.
>
> During boot, ACPI reduces the screen's brightness (it's alwa
This patch adds bogo dirent sizes for ramfs like already available for
tmpfs.
Although i_size of directories isn't covered by the POSIX standard it is
a bad idea to always set it to zero. Therefore pretend a bogo dirent
size for directory i_sizes.
Jan
Signed-off-by: Jan Blunck <[EMAIL PROTE
Greg,
If we can get this to Linus before 2.6.13 is released that would be a good
thing.
I2C-MPC: Restore code removed
A previous patch to remove support for the OCP device model was way
to generious and moved some of the platform device model code, oops.
Signed-off-by: Kumar Gala <[EMAIL PROTE
I didn't see any problem about NUMA with LinuxBIOS + 8way dual core system.
of couse the acpi support in Kernel is disabled.
p.s. can you use powernow when acpi is disabled?
p.s.s Is powerpc64 support ACPI? or ACPI is only can be used by x86?
YH
On 7/14/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
Hello.
I'm using Linux Kernel 2.6.12.2 plus suspend 2.1.9.9 and acpi-20050408
with the hibernate-1.10 script. My machine is a Shuttle SK43G which
has a VIA KM400 chipset with an Athlon XP CPU.
Suspension seems to work well. However, when I resume, the keyboard is
dead and there is a warning in dm
On Thu, 2005-07-14 at 16:49, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> > HZ=250 will fail in situations where HZ=1000 su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have tested the patch against my DawiControl DC-150 RAID controller
which is basically an add-on card with a SiI 3112 ASIC and a flash ROM.
The activity LED of my case is directly connected to the add-on card.
Unfortunately your patch doesn'
On Thu, Jul 14, 2005 at 04:54:56AM -0400, Adam Belay wrote:
> Hi all,
>
> I'm in the process of overhauling some aspects of the PCI subsystem.
> This patch series is a rewrite of the PCI probing and detection code.
> It creates a well defined PCI bus class API and allows a standard PCI
> driver to
> That, of course, you cannot do. But, you can regression test a lot of
> other things, and having a default test suite that is constantly being
> added to and always being run before releases (that test hardware
> agnostic stuff) could help cut down on the number of regressions in
> new releases.
On Thursday 14 July 2005 20:38, Andi Kleen wrote:
> It's basically impossible to regression test swsusp except to release it.
> Its success or failure depends on exactly the driver
> combination/platform/BIOS version etc. e.g. all drivers have to cooperate
> and the particular bugs in your BIOS ne
On Thu, Jul 14, 2005 at 10:09:11PM -0400, Parag Warudkar wrote:
> I have always wondered how Windows got it right circa 1995 - Version after
> version, several different hardwares and it always works reliably.
> I am using Linux since 1997 and not a single time have I succeeded in getting
> it t
> You can't test everything this way, nor should you, but you can test
> many things, and adding a bit of formal testing to the release
> procedure wouldn't be a bad thing IMO.
In the linux model that's left to the distributions. In fact doing it properly
takes months. You wouldn't want to wait mo
On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
> > > The problem is the process, not than the code.
> > > * The issues are too much ad-hock code flux without enough
> > > disciplined/formal
> > > regression testing and review.
> >
> > It's basically impossible to regression
On 7/15/05, Chris Friesen <[EMAIL PROTECTED]> wrote:
> Jesper Juhl wrote:
>
> > In my oppinion it would be nice if Linus/Andrew had some basic
> > regression tests they could run on kernels before releasing them.
>
> How do you regression test behaviour on broken hardware (and BIOSes)
> that you
Jesper Juhl wrote:
In my oppinion it would be nice if Linus/Andrew had some basic
regression tests they could run on kernels before releasing them.
How do you regression test behaviour on broken hardware (and BIOSes)
that you don't have?
Chris
-
To unsubscribe from this list: send the lin
Linus Torvalds wrote:
On Thu, 14 Jul 2005, Lee Revell wrote:
I don't think this will fly because we take a big performance hit by
calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However,
On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
>
> Trust me. When I say that the right thing to do is to just have a fixed
> (but high) HZ value, and just changing the timer rate, I'm -right-.
>
> I'm always right. This time I'm just even mor
On Fri, 15 Jul 2005, David Gibson wrote:
> Well, the COW patch implements a fault handler, obviously. What
> specifically where you thinking about?
About a fault handler of course and about surrounding scalability issues.
I worked on some hugepage related patches last fall. Have you had a look
On Thu, Jul 14, 2005 at 10:24:33AM -0700, Christoph Lameter wrote:
> On Thu, 7 Jul 2005, David Gibson wrote:
>
> > Now that the hugepage code has been consolidated across the
> > architectures, it becomes much easier to implement copy-on-write.
> > Hugepage COW is of limited utility of itself, how
On 15 Jul 2005 02:38:58 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Mark Gross <[EMAIL PROTECTED]> writes:
> >
> > The problem is the process, not than the code.
> > * The issues are too much ad-hock code flux without enough
> > disciplined/formal
> > regression testing and review.
>
> It's ba
On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > I don't think this will fly because we take a big performance hit by
> > calculating HZ at runtime.
>
> I think it might be an acceptable solution for a distribution that really
> needed it
On Thu, 14 Jul 2005 18:27:01 +0200, Thoralf Will <[EMAIL PROTECTED]> wrote:
> I didn't find any useful answer anywhere so far, hope it's ok to ask here.
> I'm currently trying to get a 2.4.31 up and running on an IBM
> BladeCenter HS20/8843. (base system is a stripped down RH9)
>
> When booting t
On Thu, 2005-07-14 at 23:37 +0100, Alan Cox wrote:
> In actual fact you also want to fix users of
>
> while(time_before(foo, jiffies)) { whack(mole); }
>
> to become
>
> init_timeout(&timeout);
> timeout.expires = jiffies + n
> add_timeout(&timeout);
> while(!timeo
David Lang wrote:
On Wed, 13 Jul 2005, Bill Davidsen wrote:
How serious is the 1/HZ = sane problem, and more to the point how
many programs get the HZ value with a system call as opposed to
including a header or building it in? I know some of my older
programs use header files, that was part
On Fri, 2005-07-15 at 03:55 +0300, Zvi Rackover wrote:
> hello all,
>
> i wish to write a module for i386 that can hook interrupts. the module
> loads its own interrupt descriptor table instead of the default
> system's table. after executing my own handler(s), the old appropriate
> handler will b
hello all,
i wish to write a module for i386 that can hook interrupts. the module
loads its own interrupt descriptor table instead of the default
system's table. after executing my own handler(s), the old appropriate
handler will be called.
i could not find any documentation or sample code explain
On Fri, 15 Jul 2005, Jesper Juhl wrote:
>
> Even if we only have to do it once at boot? The thought was to detect
> what type of machine we are booting on, figure out what a good HZ
> would be for that type of box, then set that HZ value and treat it as
> a constant from that point forward.
No,
Mark Gross <[EMAIL PROTECTED]> writes:
>
> The problem is the process, not than the code.
> * The issues are too much ad-hock code flux without enough disciplined/formal
> regression testing and review.
It's basically impossible to regression test swsusp except to release it.
Its success or f
Hello,
Could anybody provide any information as to why thread_info is kept
at the top of the stack. Also, does it mean that when thread_info is
kept it will be kept at the bottom of the heap itself also.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Daniel McNeil wrote:
This patch relaxes the direct i/o alignment check so that user addresses
do not have to be a multiple of the device block size.
I've done some preliminary testing and it mostly works on an ext3
file system on a ide disk. I have seen trouble when the user address
is on an od
[EMAIL PROTECTED] wrote:
Quoting Paul E. McKenney ([EMAIL PROTECTED]):
OK, but in the above case, "do something" cannot be sleeping, since
it is under rcu_read_lock().
Oh, but that's not quite what the code is doing, rather it is doing:
rcu_read_lock
while get next element fr
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> I don't think this will fly because we take a big performance hit by
> calculating HZ at runtime.
I think it might be an acceptable solution for a distribution that really
needed it, since it should be fairly simple. However, it's definitely not
the
On 7/15/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> > While reading this thread it occoured to me that perhaps what we
> > really want (besides sub HZ timers) might be for the kernel to
> > auto-tune HZ?
> >
> > Would it make sense to introduc
On Fri, 2005-07-15 at 02:04 +0200, Jesper Juhl wrote:
> While reading this thread it occoured to me that perhaps what we
> really want (besides sub HZ timers) might be for the kernel to
> auto-tune HZ?
>
> Would it make sense to introduce a new config option (say
> CONFIG_HZ_AUTO) that when select
Elias Kesh <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I would like to get some feedback on this patch for the kernel. It's sole
> purpose is to help in reducing boot time by not waiting to synchronize the
> clock edge with the hardware clock. This when combined with other boot
> reduction patch
On 7/13/05, Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
>
> > Len Brown, a year ago: "The bottom line number to laptop users is
> > battery lifetime. Just today somebody complained to me that Windows
> > gets twice the battery life th
On Thu, 2005-07-14 at 16:39, Andrew Morton wrote:
> Daniel McNeil <[EMAIL PROTECTED]> wrote:
> >
> > Do drivers have problems with odd addresses or with
> > non-512 addresses?
>
> I do recall hearing rumours that some bus-masters have fairly strict memory
> alignment requirements. A cacheline si
Mark Gross <[EMAIL PROTECTED]> wrote:
>
> I know this is a broken record, but the development process within the LKML
> isn't resulting in more stable and better code. Some process change could
> be
> a good thing.
We rely upon people (such as [EMAIL PROTECTED]) to send bug reports.
> Why
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
>
> On Thu, 14 Jul 2005, Lee Revell wrote:
> >
> > And I'm incredibly frustrated by this insistence on hard data when it's
> > completely obvious to anyone who knows the first thing about MIDI that
> > HZ=250 will fail in situations where H
On Thu, 2005-07-14 at 16:49 -0700, Linus Torvalds wrote:
> YOUR argument is "nobody else matters, only I do".
>
> MY argument is that this is a case of give and take.
I wouldn't say that. I do agree with you that HZ=1000 for everyone is
problematic, I just feel that a reasonable compromise is C
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> And I'm incredibly frustrated by this insistence on hard data when it's
> completely obvious to anyone who knows the first thing about MIDI that
> HZ=250 will fail in situations where HZ=1000 succeeds.
Ok, guys. How many people have this MIDI thing? Ho
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > This thread has really gone OT, but to revisit the original issue for a
> > bit, are you still unwilling to consider leaving the default HZ at 1000
> > for 2.6.13?
>
> Yes. I see absolutely no poi
chrdev_open issues a lock_kernel() before calling uart_open.
It would appear that servicing the blocking open request uart_open goes to
sleep with the kernel locked. Would this shut down subsequent access to
opening "/dev/tty"???
karl m
-
To unsubscribe from this list: send the line "unsubscr
On Thu, 2005-07-14 at 16:16, Badari Pulavarty wrote:
> How does your patch ensures that we meet the driver alignment
> restrictions ? Like you said, you need atleast "even" byte alignment
> for IDE etc..
>
> And also, are there any restrictions on how much the "minimum" IO
> size has to be ? I mea
On Thu, 2005-07-14 at 16:25 -0700, Linus Torvalds wrote:
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.
>
> I'
Daniel McNeil <[EMAIL PROTECTED]> wrote:
>
> Do drivers have problems with odd addresses or with
> non-512 addresses?
I do recall hearing rumours that some bus-masters have fairly strict memory
alignment requirements. A cacheline size, perhaps - that would be 32 bytes
given the age of the hardwa
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> But what you can do is to have HZ at some reasonably high value (ie in the
> kHz range), and then slow down the system clock to conserve energy, and
> increment jiffies by 16 or 32 when in "slow clock mode".
Btw, it doesn't have to even be a slow
On Thu, Jul 14, 2005 at 06:42:30PM -0400, Jon Smirl wrote:
> You need to take this code into account, from arch/i386/pci/fixup.c
Yes, I've seen that (nice code, btw :-). But my code snippet has
nothing to do with x86 or any particular architecture - it just
shows that some hypothetical platform th
On Thu, 14 Jul 2005, Lee Revell wrote:
>
> On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > I have to say, this whole thread has been pretty damn worthless in
> > general in my not-so-humble opinion.
> >
>
> This thread has really gone OT, but to revisit the original issue for a
> b
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> I suspect the problem for some of this is that people think of jiffies
> as incrementing by 1. If HZ is right then jiffies can be in nS, it just
> won't increment by 1.
No, jiffies _cannot_ be in nS, because of the fact that then it doesn't
fit in a wor
How does your patch ensures that we meet the driver alignment
restrictions ? Like you said, you need atleast "even" byte alignment
for IDE etc..
And also, are there any restrictions on how much the "minimum" IO
size has to be ? I mean, can I read "1" byte ? I guess you are
not relaxing it (yet)..
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> I have to say, this whole thread has been pretty damn worthless in
> general in my not-so-humble opinion.
>
This thread has really gone OT, but to revisit the original issue for a
bit, are you still unwilling to consider leaving the defau
On Thu, 14 Jul 2005, Alan Cox wrote:
>
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some religious reason is _stupid_.
>
> Getting rid of jiffies in its current form is a
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
> the following patch adds a post_setgid() security hook, and necessary dummy
> funcs.
why?
-
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.kerne
Hello Francois,
> > > I have a problem with a program named Gaussian (http://www.gaussian.com)
> > > (versions g98 or g03) and FC 4.0 (default kernel 2.6.11): I am used to
> > > take
> > > Gaussian binaries compiled on the RedHat 9.0 version, and used them on FC
> > > 2.0 or FC 3.0. If I try to d
On Thu, Jul 14, 2005 at 06:39:43PM -0400, Jon Smirl wrote:
> I had the wrong define, this is the one I was thinking of
> IORESOURCE_BUS_HAS_VGA
Oh, I definitely agree about that one. It's been unused for a couple of
years, at least. Let's kill it, please.
Ivan.
-
To unsubscribe from this list: s
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
> AFAIK John simply wants to change jiffies to count in nanoseconds
> since bootup and then call it "clock_monotonic".
Clocks and counter drift so calling it seconds would be
misleading. It would really only be good for approxima
On 07.14, RVK wrote:
> Ian Campbell wrote:
>
> >On Thu, 2005-07-14 at 16:32 +0530, RVK wrote:
> >
> >
> >>Ian Campbell wrote:
> >>
> >>
> >>>What Arjan is saying is that pthread_t is a cookie -- this means that
> >>>you cannot interpret it in any way, it is just a "thing" which you can
> >>
"Chen, Kenneth W" <[EMAIL PROTECTED]> writes:
> I'm pleased to announce that we have established a linux kernel
> performance project, hosted at sourceforge.net:
>
> http://kernel-perf.sourceforge.net
That's very cool. Thanks a lot.
Would it be possible to add 2.4.30 numbers and perhaps one or
First there are endless ways of stopping DAMAGE from buffer
over-runs, from code that accepts user data, eg extend buffer, dont
use dangerous strxxx functions so while you can move
stuff to proxies, and that has been done extensively e.g.
for sendmail it is a cop-out, far better fix the applic
Venkatesh Pallipadi <[EMAIL PROTECTED]> wrote:
>
>
>
> Attached patch fixes the recent C-state based on FADT regression reported by
> Kevin.
>
> Please apply.
>
> Thanks,
> Venki
>
>
> Fix the regression with c1_default_handler on some systems where C-states come
> from FADT.
>
> Thanks to K
Alexey Dobriyan wrote on Thursday, July 14, 2005 3:34 PM
> On Friday 15 July 2005 00:21, Chen, Kenneth W wrote:
> > I'm pleased to announce that we have established a linux kernel
> > performance project, hosted at sourceforge.net:
> >
> > http://kernel-perf.sourceforge.net
>
> Perhaps, some cool
> > Some oprofile listings from a few of the test runs would be also nice.
>
> That is in the works. We will upload profile data. I'm having problem
> with oprofile on some versions of kernel and that is being investigated
> right now.
If you run statically compiled kernels you could as well us
On Iau, 2005-07-14 at 21:13, Linus Torvalds wrote:
> There is no way to avoid having some kind of counter to specify time.
> NONE. The only choice is what you base your notion of time on, and how you
> represent it. Do you represent it as two separate counters and try to make
> it look like "frac
On 7/14/05, Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> It shouldn't be a problem. These days we have a lot of arch hooks
> in the PCI layer. I'd probably start with the following:
You need to take this code into account, from arch/i386/pci/fixup.c
/*
* Fixup to mark boot BIOS video selected by
On 7/14/05, Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 10:07:34AM -0400, Jon Smirl wrote:
> > I'm don't think it has ever been working in the 2.6 series. If you are
> > getting rid of it get rid of the #define PCI_BRIDGE_CTL_VGA in pci.h
> > too since this code was the onl
> just doesn't realize that the latter is a bit more complicated exactly
> because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> jiffies for some religious reason is _stupid_.
Getting rid of jiffies in its current form is a huge win for very
non-religious reasons. Jiffies i
On Thu, Jul 14, 2005 at 11:42:46PM +0200, Jan Engelhardt wrote:
> Hi,
>
>
> the following patch adds a post_setgid() security hook, and necessary dummy
> funcs.
... and why exactly would we want these?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
> -Original Message-
> From: Russell King
> Sent: Thursday, July 14, 2005 11:57 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 10:16:23AM -0700, karl malbrain wrote:
> > I'd love to do a ps listing for yo
On Thu, Jul 14, 2005 at 11:04:00AM -0500, John Rose wrote:
> Okay, point taken :) So for cases of base == maxbase, why would we ever
> want to return a nonzero value? What is the intended purpose of the
> second part of that conditional?
Well, just two examples (both for PCI IO limited to 16 bit
Hi,
On Thu, 14 Jul 2005, Nishanth Aravamudan wrote:
> We no longer use jiffies (the variable) as the basis for determining
> what "time" a timer should expire or when it should be added. Instead,
> we use a new function, do_monotonic_clock(), which is simply a wrapper
> for getnstimeofday().
And
1 - 100 of 323 matches
Mail list logo
