Quoting Paul E. McKenney ([EMAIL PROTECTED]):
> On Thu, Jul 14, 2005 at 08:44:50AM -0500, [EMAIL PROTECTED] wrote:
> > Quoting Paul E. McKenney ([EMAIL PROTECTED]):
> > > My guess is that the reference count is indeed costing you quite a
> > > bit. I glance quickly at the patch, and most of the
Adam Belay <[EMAIL PROTECTED]> :
[...]
Some nits + a suspect error branch. It seems nice otherwise.
> --- a/drivers/pci/bus/bus.c 1969-12-31 19:00:00.0 -0500
> +++ b/drivers/pci/bus/bus.c 2005-07-10 22:32:53.0 -0400
[...]
> +struct pci_bus * pci_alloc_bus(void)
> +{
> +
Linus Torvalds wrote:
There's absolutely nothing wrong with "jiffies", and anybody who thinks
that
msleep(20);
is fundamentally better than
timeout = jiffies + HZ/50;
just doesn't realize that the latter is a bit more complicated exactly
because the latter is a hell of a
>
> When you start merging DRM and fbdev you will be able to use relative
> paths that are closer together. For example #include
> "../char/drm/drmP.h" versus "#include "drm/drmP.h" for internal
> headers.
No. Using relative include paths is not good. I will most probarly
not work with make O=.
System:
Motherboard = Tyan K8WE
Processor = 2x Opteron 250
Memory = 8GB ECC Registered
On all of the recent release candidates except for
2.6.13-rc2-git2 the kernel panics while booting. These
versions include 2.6.13-rc2-git* (* != 2 ) and 2.6.13-rc3.
I also want to mention that I am using gcc
On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> There should be an _absolute_ interface
I'm not arguing there shouldn't be an absolute interface. I'm arguing
that *most* uses are relative, and as such a relative interface makes
sense for those cases.
> Btw, this is exactly why the
You can also look about some methods of "function redirection
hooks"... add some opcodes at the start of the "hooked function"
(something like to add a CALL or JMP pointing to the address of your
function). There are docs about this subject, but unfortunately I
couldn't find anything now
On Thu, Jul 14, 2005 at 08:44:50AM -0500, [EMAIL PROTECTED] wrote:
> Quoting Paul E. McKenney ([EMAIL PROTECTED]):
> > My guess is that the reference count is indeed costing you quite a
> > bit. I glance quickly at the patch, and most of the uses seem to
> > be of the form:
> >
> > increment
Hi all,
I have been coming across a problem with my serial port EXAR chip XR
17D152, when I try to use the 8250_pci driver. I am using
kernel-2.6.12.1 on RHEL4.0-U1 on pSeries box with 4-cpu. 8250_pci
during the boot time, after detecting the exar chip (I checked with the
pci_dev structure
On Wed, Jul 13, 2005 at 08:49:47PM +0200, Andi Kleen wrote:
> On Wed, Jul 13, 2005 at 11:44:26AM -0700, Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
>
> I think the patch is too risky for stable. I had even my doubts
> for mainline.
hmm.. Main
On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
>
> A note on the relaive timer API: There needs to be a way to say
> "x milliseconds from the time this timer should have triggered" instead
> of "x milliseconds from now", to avoid skew in timers that try to be
> strictly periodic.
I disagree.
Quoting Paul E. McKenney ([EMAIL PROTECTED]):
> On Thu, Jul 14, 2005 at 09:21:07AM -0500, [EMAIL PROTECTED] wrote:
> > On July 8 I sent out a patch which re-implemented the rcu-refcounting
> > of the LSM list in stacker for the sake of supporting safe security
> > module unloading. (patch
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 Kevin Radloff for identifying the issue and also root causing on
exact line of
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.
Why does my alps mouse pad have to stop working every time I test a new
"STABLE" kernel?
Why does swsup have to start
Hello,
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 the kernel the console is spammmed with:
pc_keyb: controller jammed (0xA7)
On Thu, 2005-07-14 at 09:21 -0700, [EMAIL PROTECTED] wrote:
> Hi Willy,
>
> I think at least I can remove the LOCK instruction when the lock is already
> held by someone else and enter the spinning wait directly, right?
If the lock is already held by someone else, the cpu is just going to
burn
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 patched can bring the kernel boot time to well under 10
Hi Willy,
I think at least I can remove the LOCK instruction when the lock is already
held by someone else and enter the spinning wait directly, right?
0: cmpb $0, slp
jle 2f# lock is not available, then spinning
directly without locking the bus
1: lock; decb
Hi kernel.
* kernel <[EMAIL PROTECTED]> dixit:
> First 446 bytes are boot code and all
> Next 64 bytes are for 4 partition records, 16 bytes each
> Last 2 bytes are signature
And that's right, but only for the MBR. If you set up an extended
partition in the MBR, the partition table for
Hello!
The attached patch passed about 36 hours of torture test on each of two
4-CPU x86 machines (about 100 passes through the torture-test script), so
am officially declaring it to be semi-sane. That said, on eight runs of
kernbench+LTP (also on 4-CPU x86 machines), only six passed, and the
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > > The whole point of using a semaphore in the pagebuf is because there
> > > > is no tracking of who "owns" the lock so
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> This reminds me of Documentation/stable_api_nonsense.txt . That no one
> should really be dependent on a particular kernel API doing a particular
> thing. The kernel is play dough for the kernel hacker (as it should be),
> including
> It was always effectual for IO where the mask is 0x.
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?
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 2005-07-14 at 06:18, Andi Kleen wrote:
> Daniel McNeil <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> The original reason for this limit was that lots of drivers
>
Take a look at FUSE, it should be able to do all you need
-
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 Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > The whole point of using a semaphore in the pagebuf is because there
> > > is no tracking of who "owns" the lock so we can actually release it
> > > in a different context. Semaphores were
On Thu, 2005-07-14 at 08:02 -0700, Christoph Lameter wrote:
> I doubt that increasing the timer frequency is the way to go to solve
> these issues. HZ should be as low as possible and we should strive for
> a tickless system.
Agreed. Most of those applications are driven by their own interrupt
On Thu, Jul 14, 2005 at 09:21:07AM -0500, [EMAIL PROTECTED] wrote:
> On July 8 I sent out a patch which re-implemented the rcu-refcounting
> of the LSM list in stacker for the sake of supporting safe security
> module unloading. (patch reattached here for convenience) Here are
> some performance
On Thu, 14 Jul 2005, Lee Revell wrote:
> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> > - there are real-time applications (robotic environments: fast rotating
> >tools, media and mobile/phone applications, etc.) that want 10
> >usecs precision. If such users increased HZ to
Roman Zippel writes:
> Hi,
>
> On Mon, 11 Jul 2005, Andrew Morton wrote:
>
> > > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > > logging and buffering capability, which does not currently exist in
> > > > the kernel.
> > >
> > > While the code is pretty
Andy Isaacson wrote:
> Yesterday I booted my laptop to 2.6.13-rc2-mm1, suspended to swsusp, and
> then resumed. It ran fine overnight, including a fair amount of IO
> (running firefox, rsyncing ~/Mail/archive from my mail server, hg pull,
> etc). This morning I did a swsusp:
>
> echo
On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> - there are real-time applications (robotic environments: fast rotating
>tools, media and mobile/phone applications, etc.) that want 10
>usecs precision. If such users increased HZ to 100,000 or even
>1000,000, the current timer
On Wednesday 13 July 2005 17:38, James Bottomley wrote:
> [PATCH] Remove i386_ksyms.c, almost
>
> made files like smp.c do their own EXPORT_SYMBOLS. This means that all
> subarchitectures that override these symbols now have to do the exports
> themselves. This patch adds the exports for
On Thu, Jul 14, 2005 at 05:45:15PM +0300, Yura Pakhuchiy wrote:
> Yes, but a lof of people use older versions of compilers and suffer
> from this bug.
> I personally was very unhappy when lost my data.
then host the patch somewhere and make sure to apply it.
-
To unsubscribe from this list: send
2005/7/14, Christoph Hellwig <[EMAIL PROTECTED]>:
> On Thu, Jul 14, 2005 at 04:50:01PM +0300, Yura Pakhuchiy wrote:
> > 2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> > > On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > > > I found patch by Greg Ungreger to fix this problem, but
Alex Williamson wrote:
>
> David, would you mind
> trying this on the XR16L255x part? (ie. don't use console=ttyS, use
> console=uart,...) Thanks,
I wasn't even aware you could do this...
These are the serial ports I have:
ttyS0 at MMIO 0xc800 (irq = 15) is a XScale IXP425 internal
On Thu, Jul 14, 2005 at 04:50:01PM +0300, Yura Pakhuchiy wrote:
> 2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> > On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > > I found patch by Greg Ungreger to fix this problem, but why it's still
> > > not in mainline? Or it's a gcc
If bailing out because there is nothing to receive in rp_do_receive(),
tty_ldisc_deref is not called. Failure to do so increases the ref count
and causes release_dev() to hang since it can't get the ref count to 0.
---
Signed-off-by: Michal Ostrowski <[EMAIL PROTECTED]>
drivers/char/rocket.c
RVK wrote:
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> >
> > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > 10KHz. Maybe the highest possible value is 8192 Hz, not sure.
>
> Can you post the triple-fault message? It really
On July 8 I sent out a patch which re-implemented the rcu-refcounting
of the LSM list in stacker for the sake of supporting safe security
module unloading. (patch reattached here for convenience) Here are
some performance results with and without that patch. Tests were run
on a 16-way ppc64
On Thu, 2005-07-14 at 11:24 +0200, Jan Engelhardt wrote:
> "My expectation is if we want to beat the competition, we'll want
> the ability to go *under* 100Hz."
> >>>
> >>> What does Windows do here?
> >>
> >> windows xp base rate is 100Hz... but multimedia apps can ask for almost
> >
K.R. Foley wrote:
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribute__'
K.R. Foley wrote:
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before
'__attribute__'
On 7/14/05, Russell King <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
> > The setup-bus code doesn't work correctly for configurations
> > with more than one display adapter in the same PCI domain.
> > This stuff actually is a leftover of an early
Helge Hafting wrote:
RVK wrote:
Proxies can be a good way of filtering but it can't avoid buffer
overflows.
Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
it on
Karsten Wiese wrote:
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
CC [M] sound/oss/emu10k1/midi.o
sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
sound/oss/emu10k1/midi.c:48: error: syntax
On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
> The setup-bus code doesn't work correctly for configurations
> with more than one display adapter in the same PCI domain.
> This stuff actually is a leftover of an early 2.4 PCI setup code
> and apparently it stopped working after
Jakub Jelinek wrote:
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
pure luck. NPTL threading uses it to store a pointer to per thread info
structure; other threading (linuxthreads) may have stored a pid there to
identify the internal thread. nptl is 2.6 only so you
I always thought;
First 446 bytes are boot code and all
Next 64 bytes are for 4 partition records, 16 bytes each
Last 2 bytes are signature
?
-fd
On Wed, 2005-07-13 at 06:24, Jan Engelhardt wrote:
> > Guys, thanks a lot for the explanations!
> >
> > Actually, it seems like one can backup
2005/7/14, Nathan Scott <[EMAIL PROTECTED]>:
> On Wed, Jul 13, 2005 at 06:22:28PM +0300, Yura Pakhuchiy wrote:
> > I found patch by Greg Ungreger to fix this problem, but why it's still
> > not in mainline? Or it's a gcc problem and should be fixed by gcc folks?
>
> Yes, IIRC the patch was
On Wed, Jul 13, 2005 at 11:04:56AM -0600, Alex Williamson wrote:
> On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote:
> >No, I think this is a problem with the broken A2 UARTs getting
> > confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP
> > or UART_CAP_EFR from the
Ingo Molnar wrote:
* Chuck Harding <[EMAIL PROTECTED]> wrote:
I missed getting -51-29 but just booted up -51-30 and all is well.
Thanks. Just out of curiosity, what was changed between -51-28, 29,
and 30?
-51-29 had new IO-APIC optimizations - and i reverted them in -51-30.
Ingo
On 7/14/05, Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
> The setup-bus code doesn't work correctly for configurations
> with more than one display adapter in the same PCI domain.
> This stuff actually is a leftover of an early 2.4 PCI setup code
> and apparently it stopped working after some
Hi,
On Mon, 11 Jul 2005, Andrew Morton wrote:
> > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > logging and buffering capability, which does not currently exist in
> > > the kernel.
> >
> > While the code is pretty nicely in shape it seems rather pointless to
> >
On 7/14/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > I'm thinking include/linux/drm/
> > > but include/linux would also be possible.
> > >
> > > Any suggestions or ideas?
> >
> > If you're in a mood to move things, how about moving drivers/char/drm
> > to drivers/video/drm.
>
> But that has
Daniel McNeil <[EMAIL PROTECTED]> writes:
> 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.
The original reason for this limit was that lots of drivers
(not only IDE) explode when you give them odd sizes. Sometimes
mb_cache_shrink() tries to free all sort of mbcache in the lru list.
All user of mb_cache_shrink() are ext2/ext3 xattr.
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
--- 2.6-rc/fs/mbcache.c.orig2005-07-14 20:40:34.0 +0900
+++ 2.6-rc/fs/mbcache.c 2005-07-14 20:43:42.0 +0900
> And you certainly shouldn't be using gettid () syscall in NPTL, as it
> is just an implementation detail that there is a 1:1 mapping between
> NPTL threads and kernel threads. It can change at any time.
Maybe I missed the point, but I thought the 1:1 mapping between NPTL
threads and kernel
RVK wrote:
Proxies can be a good way of filtering but it can't avoid buffer
overflows.
Yes they can - did you read and udnerstand my previous post at all?
A proxy _can_ avoid a buffer overflow by noticing the
anomalously large data item and simply refuse to pass
it on to the real server!
Hello,
I am not sure the "rm -rf linux/arch/i386/boot" is an acceptable delta
for the current code management system, but anyways it is only the second
step - after the attached patch has been discussed, modified and
hopefully accepted.
Unfortunately this second step will break compatibility
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
> Ingo Molnar wrote:
> > * Chuck Harding <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>CC [M] sound/oss/emu10k1/midi.o
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
> >>>sound/oss/emu10k1/midi.c:48: error: syntax
On Thu, Jul 14, 2005 at 02:25:43PM +0200, Arjan van de Ven wrote:
> pure luck. NPTL threading uses it to store a pointer to per thread info
> structure; other threading (linuxthreads) may have stored a pid there to
> identify the internal thread. nptl is 2.6 only so you might have
> switched
Patrick, Hebert,
This issues stills seems to be in the latest trees - is this patch or a
variation on it still bumping around?
Thanks!
Yair Itzhaki wrote:
Can anyone propose a patch that I can start checking?
I have come up with the following:
--- net/core/netfilter.c.orig 2005-04-18
> >
> So then what is the meaning of that typedef and why its still there ?
the typedef means that the *IMPLEMENTATION* uses an unsigned long to
store its cookie in.
>
> >Other implementations are allowed to use different types for this. In
> >fact, I'd be surprised if NPTL and LinuxThreads
Proxies can be a good way of filtering but it can't avoid buffer
overflows. It can only increase it. More code more bugs. If it is
running on a hardware firewall as a service then its more dangerous as
once it is compramised then IDS signatures also can be deleated :-). No
use of IDS the right
On Thu, Jul 14, 2005 at 12:25:40PM +0200, Krzysztof Halasa wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > And in short-term things, the timeval/jiffie conversion is likely to be a
> > _bigger_ issue than the crystal frequency conversion.
> >
> > So we should aim for a HZ value that
RVK wrote:
I don't think buffer overflow has anything to do with transparent
proxy. Transparent proxying is just doing some protocol filtering.
A transparent proxy is a protocol filter, which is why it is an
ideal way of detecting protocol-dependent buffer overflow attacks.
The detection
On Thu, Jul 14, 2005 at 09:42:18AM +0200, Arjan van de Ven wrote:
> > IOW, nothing ever sees any "variable frequency", and there's never any
> > question about what the timer tick is: the timer tick is 2kHz as far as
> > everybody is concerned. It's just that the ticks sometimes come in
> >
Hi Linus, please pull from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git/HEAD
This is a big NTFS update. It was meant for as soon as 2.6.12 was released
but it was delayed due to the need for a patch I submitted to Andrew for -mm
to make it to the mainline kernel (which
Stelian Pop schrieb:
> After resyncing cogito to the latest version (which incorporates the
> 'pack' changes, which were causing the failure), it does indeed work
> again, when using rsync.
>
hm, i haven't updated my git-tree (linux-2.6.git) for a while and i got
similiar error messages. i
The setup-bus code doesn't work correctly for configurations
with more than one display adapter in the same PCI domain.
This stuff actually is a leftover of an early 2.4 PCI setup code
and apparently it stopped working after some "bridge_ctl" changes.
So the best thing we can do is just to remove
>Before 2.6.12-rc2, the console was unblanked by just
>writing to the console.
>For keyboardless and mouseless systems (which is my
>case, embedded) this new behaviour is a bit annoying.
Interesting. I have observed the following (2.6.13-rc1 and a little
earlier):
mplayer bla.avi -vo cvidix
I attach a patch that modifies the mount program in the util-linux
package so that if /etc/mtab is a symbolic link (to a location outside
of /proc) then mount accesses mtab at the target of the symbolic link.
This feature is useful when the root filesystem is mounted read-only;
/etc/mtab can
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
pass back to the API, that pthread_t happens to be
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
it doesn't return a number it returns a pointer ;) or a floating point
number. You don't know :)
what it returns is a *cookie*. A cookie that you can only use to pass
back to various pthread functions.
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
> >pass back to the API, that pthread_t happens to be typedef'd to unsigned
> >long
Ian Campbell wrote:
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you
- Bug fixes:
1) On CX88 code, some cards needs to have audio reprogramed after
changing video channel;
2) Tuner autodetection code seems not to work on some cards. Now,
no_autodetect insmod option allows disabling autodetection code;
3) Minor fixes at tea5767 to reduce integer trunc;
4)
On Thu, Jul 14, 2005 at 12:12:02AM -0700, Sam Song wrote:
> It turned out the conflict of uart init definition
> like MPC10X_UART0_IRQ in ../syslib/mpc10x_common.c
> and SERIAL_PORT_DFNS in ../platform/sandpoint.h. By
> now, only MPC10X_UART0_IRQ stuff is needed.
> SERIAL_PORT_DFNS should be
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> bits/pthreadtypes.h:150:typedef unsigned long int pthread_t;
That's an implementation detail which you cannot determine any
information from.
What Arjan is saying is that pthread_t is a cookie -- this means that
you cannot interpret it in any way,
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 always
done this in the x86-64 kernels but not the i386 ones), so I
On Thu, 2005-07-14 at 15:36 +0530, RVK wrote:
> >
> >it doesn't return a number it returns a pointer ;) or a floating point
> >number. You don't know :)
> >
> >what it returns is a *cookie*. A cookie that you can only use to pass
> >back to various pthread functions.
> >
> >
> >
>
I don't think buffer overflow has anything to do with transparent proxy.
Transparent proxying is just doing some protocol filtering. Still the
proxy code may have some buffer overflows. The best way is first to try
avoiding any buffer overflows and take programming precautions. Other
way is to
Linus Torvalds <[EMAIL PROTECTED]> writes:
> And in short-term things, the timeval/jiffie conversion is likely to be a
> _bigger_ issue than the crystal frequency conversion.
>
> So we should aim for a HZ value that makes it easy to convert to and from
> the standard user-space interface
Hi,
--- Jan Engelhardt <[EMAIL PROTECTED]>
escribió:
> The console is unblanked when you hit a key (or
> probably move a mouse too),
> not when some application outputs something on
> stdout/stderr/etc.
Before 2.6.12-rc2, the console was unblanked by just
writing to the console.
For
Arjan van de Ven wrote:
On Thu, 2005-07-14 at 11:03 +0530, RVK wrote:
Robert Hancock wrote:
RVK wrote:
Can anyone suggest me how to get the threadId using 2.6.x kernels.
pthread_self() does not work and returns some -ve integer.
What do you mean, negative integer?
Vinay Venkataraghavan wrote:
I know how to implement buffer overflow attacks. But
how would an intrusion detection system detect a
buffer overflow attack.
Buffer overflow attacks vary, but have one thing in common. The
overflow string is much longer than what's usual for the app/protocol in
On Wed, 13 Jul 2005, Benjamin LaHaise wrote:
> That's one thing I truely dislike about the current timer code. If we
> could program the RTC interrupt to come into the system as an NMI (iirc
> oprofile already has code to do this), we could get much better TSC
> interpolation since we would
>> Patch 19/19 contains a .po file.
>
>Yes, the patch 19/19 contains the translation of configuration...
>I see Linus doesn't want the huge language files in kernel source.
>But what is Linus opinion about this little .po file?
What is little? Given that there's 'roughly' 119 languages (find
> >> /** The minor number of the fuse character device */
> >> -#define FUSE_MINOR 229
> >> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
> >
> >FUSE has an allocated fix minor. Dynamic minor is much harder to
> >handle with legacy /dev (not udev).
>
> How many users of 2.6.13 and up really do not
Chuck Ebbert wrote:
>Looks like Quilt is adding the space during push/pop operations. Only the
> lines it has touched in the series file have the trailing space.
Quilt versions prior to 0.39 would add a trailing space to the series
file entry when doing a quilt refresh with the default -p1
On Wed, 13 Jul 2005, Lee Revell wrote:
> Did anyone else find this strange:
>
> "The RTC is used in periodic mode to provide the system profiling
> interrupt on uni-processor systems and the clock interrupt on
> multi-processor systems."
>
> We just take NR_CPUS * HZ timer interrupts per
Hi,
>> /** The minor number of the fuse character device */
>> -#define FUSE_MINOR 229
>> +#define FUSE_MINOR MISC_DYNAMIC_MINOR
>
>FUSE has an allocated fix minor. Dynamic minor is much harder to
>handle with legacy /dev (not udev).
How many users of 2.6.13 and up really do not have/run udev?
On Wed, Jul 13, 2005 at 05:29:32PM -0400, Chuck Ebbert wrote:
> On Wed, 13 Jul 2005 at 00:23:42 -0700, Andrew Morton wrote:
>
> >>...and BTW why does every line in the series file have a trailing space?
> >
> > Not in my copy of
> >
On Thu 14 Jul 2005, Neil Brown wrote:
> > Aug 9 20:09:18 localhost kernel:
> > {:raid0:raid0_make_request+472}
>
> Looks like the problem is at:
> sector_div(x, (unsigned long)conf->hash_spacing);
> zone = conf->hash_table[x];
[...]
> Anyway, the following patch, if
>Looks like, since [1] was merged, a blanked console
>(due to inactivity for example) doesn't get unblanked
>anymore when new output is written to it.
The console is unblanked when you hit a key (or probably move a mouse too),
not when some application outputs something on stdout/stderr/etc.
"My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz."
>>>
>>> What does Windows do here?
>>
>> windows xp base rate is 100Hz... but multimedia apps can ask for almost
>
> 83Hz
Well, Windoes 98 (vmmon) shows very different ones:
This patch prevents the PCI<->PCI bridge driver from binding to PCI
express devices. This is needed to coexist with the PCI express root
port driver. Eventually we may want to rework and better integrate
linux PCI express link support, but for now this should work.
Signed-off-by: Adam Belay
The PCI bridge driver now checks if changing bridge_ctrl is necessary.
It also restores the original bridge_ctl settings when finished scanning
for devices. Finally, a pci_bus setup fix is included.
Signed-off-by: Adam Belay <[EMAIL PROTECTED]>
--- a/drivers/pci/bus/pci-bridge.c 2005-07-12
201 - 300 of 615 matches
Mail list logo
