Vladimir V. Saveliev wrote:
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz
It applies to 2.6.12 +
http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29
Ah, this is just what I
On 7/13/05, Mikhail Kshevetskiy [EMAIL PROTECTED] wrote:
symptom
===
modprobe e100
ifconfig eth0 ip netmask netmask
result:
===
SIOCADDRT: Network is unreachable
There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are broken? This might indicate something
wierd
Ludovic Drolez wrote:
I recently had to boot a brand new system using a Marvel Yukon2 NIC
(sk98lin) driver which is not supported by the latest kernel (pci ids =
11ab:4361).
So I compiled the GPLed driver available from Syskonnect,
Russell King [EMAIL PROTECTED] wrote:
v. whining
1. To utter a plaintive, high-pitched,
protracted sound, as in pain,
fear, supplication, or complaint.
2. To complain or protest in a childish fashion.
3. To produce a sustained noise of relatively
high pitch: jet engines
On Wed, 13 Jul 2005 23:28:15 -0700, Jesse Brandeburg [EMAIL PROTECTED] wrote:
On 7/13/05, Mikhail Kshevetskiy [EMAIL PROTECTED] wrote:
symptom
===
modprobe e100
ifconfig eth0 ip netmask netmask
result:
===
SIOCADDRT: Network is unreachable
There were no such error in
On Thu, 2005-07-14 at 14:04 +1000, Dave Airlie wrote:
Hi,
I'd like to move the interface DRM header files (drm.h and *_drm.h)
somewhere more useful and also more user-space visible, (i.e. so
kernel-headers could start picking them up.)
I would suggest making ONE userspace visible header, and
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
bunches of 20.
btw we can hide all of this a lot nicer from just about the entire
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? It's not an integer, it's a
pthread_t,
/** The major number of the fuse character device */
-#define FUSE_MAJOR 10
+#define FUSE_MAJOR MISC_MAJOR
OK, this makes some sense.
/** The minor number of the fuse character device */
-#define FUSE_MINOR 229
+#define FUSE_MINOR MISC_DYNAMIC_MINOR
Why?
FUSE has an allocated fix
On Monday 11 July 2005 10:29, Marc Haber wrote:
After rebooting, the VLANs on the Intel-based interfaces worked fine, while
the tg3-based interfaces didn't answer to tagged ARP requests. The untagged
VLAN on the tg3-based interfaces was fine as well. When tcpdumping the
subinterfaces, I saw
On Wed, Jul 13, 2005 at 10:53:19AM -0700, karl malbrain wrote:
I've also noticed that the boot sequence probes for modems on the serial
ports. Is it possible that 8250.c is having a problem servicing an
interrupt from a character/state-change left over from this initialization?
I did ask for
* Linus Torvalds [EMAIL PROTECTED] wrote:
I suspect that it is impractical to reprogram the PIT on a very fine
granularity.
yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.
(in fact the cost is pretty much system-independent due to PIO.) On
modern, PIT-less
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 bind to PCI bridge devices. This results in the following:
* cleaner
This patch adds very simplistic suspend/resume support for the PCI
bridge driver. Soon this will be replaced with bridge specific code,
but for now we'll try using pci_save/restore_state().
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/pci-bridge.c 2005-07-14
This patch updates pci_scan_bus_parented() and also has some important
fixes to the PCI bus class.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/bus.c 2005-07-12 01:08:20.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-13 02:01:57.0 -0400
@@ -81,7 +81,7 @@
This patch adds pci_add_bus() for PCI bus registration. It also moves
pci_remove_bus() from remove.c to bus/bus.c for consistency.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/bus.c 2005-07-12 00:59:58.0 -0400
+++ b/drivers/pci/bus/bus.c 2005-07-12
This patch moves all device registration related functions to
bus/device.c.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/device.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/device.c 2005-07-12 01:32:41.0 -0400
@@ -0,0 +1,187 @@
+/*
+ * device.c - PCI
This patch adds a basic PCI-PCI bridge driver that utilizes the new
PCI bus class API.
Signed-off-by: Adam Belay [EMAIL PROTECTED]
--- a/drivers/pci/bus/pci-bridge.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/pci/bus/pci-bridge.c 2005-07-08 02:18:43.0 -0400
@@ -0,0
This patch divides the PCI probing code into three smaller files:
config.c - PCI configuration space parsing
probe.c - PCI bus detection routines
bus.c - the PCI bus class driver core
These files are placed in the new directory drivers/pci/bus. It will
be used for functions related to the PCI
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
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
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:
/dev/vmmon[4355]: host clock
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.
[1]
On Thu 14 Jul 2005, Neil Brown wrote:
Aug 9 20:09:18 localhost kernel:
8808eb98{: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
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? [Please
I just tried 2.6.12.2 with skas-V8.2. The server (otherwise reliable),
had a kernel crash (which I was unable to capture) within a couple of
hours of boot up.
Regards, Peter
Blaisorblade wrote:
On Tuesday 12 July 2005 00:26, Peter wrote:
Nothing in the logs prior to the first error
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 second, what's
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
/** 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?
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
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 be
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
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?
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 keyboardless and
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 formats.
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
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.
Hahaha..common. Please
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:
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 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
- 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)
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
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 int is
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.
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 typedef'd
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
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 it
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 updated
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
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
bunches of
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 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 makes it easy
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 would have
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
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
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 error before ')' token
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
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!
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
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
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
it
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 little point beyond
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
merge until an
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 bridge_ctl
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 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
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
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 some
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 incorrect for
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 error
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
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__'
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
83Hz
Well, Windoes 98
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
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 shouldn't
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
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 |
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
ttyS1 at
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 problem and
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 why it's
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 nicely in shape it
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 100,000
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, 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, 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 invented for
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 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
(not only
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
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
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 that
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
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
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
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)
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 hanging
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
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 reattached
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.
There should
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 ref count
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
1 - 100 of 615 matches
Mail list logo
