On Wednesday 23 February 2005 18:40, Dmitry Torokhov wrote:
On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote:
On Wednesday 23 February 2005 17:38, J.A. Magallon wrote:
On 02.23, Andrew Morton wrote:
Erm, this updated patch.
J
If we're sending a signal relating to a faulting instruction, then
always generate siginfo for that signal.
If the user has some unrelated process which has managed to consume
the user's entire allocation of siginfo, then signals will start being
delivered
Any chance to convince the alien who took control of Jeff's libata queue to
push:
r8169: synchronization and balancing when the device is closed
(1.1982.1.58 ?)
Test case on current 2.6.11-rc4:
- ifconfig ethX 10.0.0.1 up
- ifconfig ethX down
- ifconfig ethX 10.0.0.1 up
- Rx does not work any
Alan I ask the card which interrupt line it was given at
Alan boot-time:
Alan pci_read_config_byte(dev, PCI_INTERRUPT_LINE,
softp-interrupt_line);
Alan Then I request an IRQ:
Alan request_irq(softp-interrupt_line, sseintr, SA_INTERRUPT,
sse, softp);
Don't do
On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
Steven Cole [EMAIL PROTECTED] wrote:
Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
missing.
Looking at the IDE update in rc4-mm1:
+void ide_init_disk(struct gendisk *disk, ide_drive_t *drive)
+{
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few PPC/gcc
issues needed
Steven Cole [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Steven Cole [EMAIL PROTECTED] wrote:
I am having trouble getting recent -mm kernels to boot on my test box.
For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
VFS: Cannot open root device 301 or unknown-block(3,1)
On Wed, 23 Feb 2005, Mickey Stein wrote:
From: Mickey Stein
Versions: linux-2.6.11-rc4-bk11, gcc4 (GCC) 4.0.0 20050217 (latest fc
rawhide from 19Feb DL)
gcc 4.0.x cvs seems to dislike include/linux/i2c.h file and others due to a
current gcc 4.0.x change having to do with
array declarations.
On Wed, Feb 23, 2005 at 03:10:38PM -0700, Steven Cole wrote:
Andrew Morton wrote:
Steven Cole [EMAIL PROTECTED] wrote:
I am having trouble getting recent -mm kernels to boot on my test box.
For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following:
VFS: Cannot open root device 301 or
Chris Wright wrote:
/proc/N/status will tell you that a process has
a signal pending, but it won't tell you how many are pending).
Suggestion for good place to display that info?
I guess another line in /proc/N/status:
SigQue: 0 0 0 0 0 0 0 123 0 0 1238 0 0 0 0 0 ... 0 0 1
or
Horst von Brand [EMAIL PROTECTED] wrote:
Machine is sparc64, bk of today, gcc-3.4.2-6.fc3 (Aurora Corona). First 2.6
I try to build here, so it might be something known.
Build fails due to -Werror with:
include/asm/uaccess.h: In function `load_elf_binary':
Jeff Garzik [EMAIL PROTECTED] :
[...]
Agree it needs fixing, but I actually think the rx-offset stuff is more
urgent than this. For the future, it would be useful for both of us to
have separate r8169-fixes and r8169-cleanups queues.
Do you have a synonym/pointer for the rx-offset stuff ?
Hi Amon,
On Mon, Feb 21, 2005 at 11:19:16AM +0100, Amon Ott wrote:
- 5. Posix Capabilities Without Stacking Support
I don't get the point of these claims.
The LSM framework currently has full support for dynamic and
logic-changeable POSIX.1e capabilities, using the capable() hook and
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 23 Feb 2005, Lee Revell wrote:
Thanks, your patch fixes the copy_pte_range latency.
clear_page_range is also problematic.
Yes, I saw that from your other traces too. I know there are plans
to
On Wed, 2005-02-23 at 15:46 -0800, Roland Dreier wrote:
Alan pci_read_config_byte(dev, PCI_INTERRUPT_LINE,
softp-interrupt_line);
Alan request_irq(softp-interrupt_line, sseintr, SA_INTERRUPT,
sse, softp);
Don't do that. The kernel may need you to use a different interrupt
So, I think such a fork/execve/exit hooks is harmless now.
I don't recall seeing any microbenchmarking of the impact on fork/exit
of such hooks. You might find such a benchmark in lmbench, or at
http://bulk.fefe.de/scalability/.
--
I won't rest till it's the best ...
Lee Revell wrote:
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
If you are using i386 with 2-level page tables (no highmem), then
the behaviour should be more or less identical. Odd.
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about
I run installed and updated sarge. I downloaded 2.6.10 from kernel.org.
When I use apt-get under 2.4.27 everything is OK
When I use apt-get under 2.6.10, I get a segfault
I run the same combination (allthough a different configuration on a Pentium III (Coppermine) and
on a Intel(R) Pentium(R) M
Indeed, I think your patch does not go far enough. I can read POSIX to say
that the siginfo_t data must be available when `kill' was used, as well.
This patch makes it allocate the siginfo_t, even when that exceeds
{RLIMIT_SIGPENDING}, for any non-RT signal ( SIGRTMIN) not sent by
sigqueue
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be
I see this problem with the sata_sil.c driver and
SII3112 card. Others have reported seeing a similar
problem: http://lkml.org/lkml/2005/2/6/41
There seems to be a pending interrupt from the drive,
but the code has already set the NIEN bit, so the
ATA_IRQ_TRAP macro doesn't help (the
Retry... that patch got screwed up in the last
email...
-Brian
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail--- libata-core.c.orig 2005-02-23 17:41:03.831836464 -0800
+++
On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall [EMAIL PROTECTED] wrote:
On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
Steven Cole [EMAIL PROTECTED] wrote:
Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
missing.
Looking at the IDE update in
On Wed, 23 Feb 2005, linux-os wrote:
On Wed, 23 Feb 2005, Bodo Eggert wrote:
linux-os [EMAIL PROTECTED] wrote:
You don't seem to understand. A process that's stuck in 'D' state
shows a SEVERE error, usually with a hardware driver.
Or a network filesystem mount to a no longer existing
-Memory: 255872k available (1788k kernel code, 976k data, 144k init, 0k
highmem)
+Memory: 255872k available (1776k kernel code, 0k data, 144k init, 0k highmem)
That is weird... (0k data)
AGP special page: 0xc000
Calibrating delay loop... 830.66 BogoMIPS (lpj=4153344)
Mount-cache
Jeremy mentioned the aggravation of not being able to tell when your
processes are using up signal queue entries and hitting the
RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
showing how many queue items are in use, and allowed, for your uid.
I can certainly see the appeal
Jay wrote:
I think the microbenchmarking your link provides is irrelevant.
In the cases such as you describe where it's just some sort of empty
function call, then yes, I am willing to accept a wave of the hands and
a simple explanation of how it's not significant. I've done the same
myself ;).
On Thu, Feb 24, 2005 at 03:03:33AM +0100, Benoit Boissinot wrote:
On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall [EMAIL PROTECTED] wrote:
On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
Steven Cole [EMAIL PROTECTED] wrote:
Yes, that worked. 2.6.11-rc4-mm1 now boots
On Tuesday 22 February 2005 04:57 am, Martin MOKREJ wrote:
The 3GB labeled file corresponds to fast case, 4GB is ugly slow.
What can you gather from those files?
I did take a look and didn't analyze it further since Andi Mentioned it is a
known BIOS bug.
Sorry about the trouble - didn't imagine
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
it occurred to me that the normal setting of this limit is bizarrely low.
The initial hard limit setting (MAX_SIGPENDING) was taken from the old
max_queued_signals parameter, which was for the entire system in aggregate.
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
Lee Revell wrote:
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 150us. Currently its 422us from the
same clear_page_range code path.
Well it should be pretty trivial to add
* Roland McGrath ([EMAIL PROTECTED]) wrote:
Indeed, I think your patch does not go far enough. I can read POSIX to say
that the siginfo_t data must be available when `kill' was used, as well.
How? I only see reference to filling in SI_USER for rt signals?
Just curious...(I've only got SuSv3
* Roland McGrath ([EMAIL PROTECTED]) wrote:
Jeremy mentioned the aggravation of not being able to tell when your
processes are using up signal queue entries and hitting the
RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
showing how many queue items are in use, and
Does this patch do anything useful?
Jeff
= drivers/scsi/sata_sil.c 1.44 vs edited =
--- 1.44/drivers/scsi/sata_sil.c2005-02-17 19:43:51 -05:00
+++ edited/drivers/scsi/sata_sil.c 2005-02-23 21:27:18 -05:00
@@ -65,6 +65,7 @@
static u32 sil_scr_read (struct ata_port
Chad N. Tindel [EMAIL PROTECTED] wrote:
We have hit a defect where an exiting xterm process will hang. This is
running
on a 2-cpu IA-64 box. We have a multithreaded application, where one thread
is SCHED_FIFO and is running with priority 98, and the other thread is just
a normal
BTW, please CC your replies to linux-ide@vger.kernel.org as well.
-
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
Lee Revell wrote:
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
Lee Revell wrote:
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 150us. Currently its 422us from the
same clear_page_range code path.
Well it should be pretty trivial to
* Roland McGrath ([EMAIL PROTECTED]) wrote:
Indeed, I think your patch does not go far enough. I can read POSIX to say
that the siginfo_t data must be available when `kill' was used, as well.
How? I only see reference to filling in SI_USER for rt signals?
Just curious...(I've only got
Two questions: 1) This changes the interface for consumers of
/proc/[pid]/status data, do we care? Adding new line like this should be
safe enough.
As far as I can tell, noone fretted about the addition of Threads:,
ShdPnd:, etc., which were not always there.
2) Perhaps we should do
Does this patch do anything useful?
Jeff
Not really. It doesn't print the nobody cared
message, but still hangs at boot. I'd give you a
backtrace but my MAGIC_SYSRQ doesn't seem to be
working right now.
-Brian
Linux version 2.6.11-rc4 ([EMAIL PROTECTED])
(gcc version 3.3.2) #28
On Wed, 23 Feb 2005 14:31:20 -0500, Bill Davidsen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Hello
I have read a post in lkml.org that states that the problem experienced in
rc3 has gone (1). That is not the case for me.
My audio device is
:00:1f.5 Multimedia audio
On Thu, 2005-02-24 at 13:41 +1100, Nick Piggin wrote:
Lee Revell wrote:
Agreed, it would be much better to optimize this away than just add a
scheduling point. It seems like we could do this lazily.
Oh? What do you mean by lazy? IMO it is sort of implemented lazily now.
That is, we
* Roland McGrath ([EMAIL PROTECTED]) wrote:
Two questions: 1) This changes the interface for consumers of
/proc/[pid]/status data, do we care? Adding new line like this should be
safe enough.
As far as I can tell, noone fretted about the addition of Threads:,
ShdPnd:, etc., which were
Dmitry Torokhov wrote:
Yes, It usually happens either under high load, when mouse interrupts are
significantly delayed. Or sometimes it happen when applications poll
battey status and on some boxes it takes pretty long time. And because
it is usually the same chip that serves keyboard/mouse it
* Roland McGrath ([EMAIL PROTECTED]) wrote:
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
it occurred to me that the normal setting of this limit is bizarrely low.
The initial hard limit setting (MAX_SIGPENDING) was taken from the old
max_queued_signals parameter,
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all access is via imap, w/ approx
~1000 imapd
* Roland McGrath ([EMAIL PROTECTED]) wrote:
* Roland McGrath ([EMAIL PROTECTED]) wrote:
Indeed, I think your patch does not go far enough. I can read POSIX to
say
that the siginfo_t data must be available when `kill' was used, as well.
How? I only see reference to filling in
On Wednesday 23 February 2005 22:05, Anthony DiSante wrote:
Dmitry Torokhov wrote:
Yes, It usually happens either under high load, when mouse interrupts are
significantly delayed. Or sometimes it happen when applications poll
battey status and on some boxes it takes pretty long time. And
On Wed, 23 Feb 2005, Ron Peterson wrote:
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all
Jeff, please apply:
Here's a big stack of patches that make a significant step forward on
the long overdue orinoco driver merge. Still quite a long way to go,
but it's something. This patch stack is againt Linus' vanilla +
Viro's big iomap cleanup patch, as requested.
The first 9 patches make
Removes the orinoco driver's custom and dodgy connected variable
used to track whether or not we're associated with an AP. Replaces it
instead with netif_carrier_ok() settings.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
Use mdelay() or ssleep() instead of various silly more complicated
ways of delaying in the orinoco driver.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco_pci.c
===
---
Introduce a free_orinocodev() function into the orinoco driver, used
by the hardware type/initialization modules to free the device
structure in preference to directly calling free_netdev(). At the
moment free_orinocodev() just calls free_netdev(). Future merges will
make it clean up internal
Remove has_ibss_any flag and never set the CREATEIBSS RID when the
ESSID is empty. Too many firmware break if we do.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
===
---
Make the is_ethersnap() function take a void * rather than a pointer
to the internal header structure. This makes more logical sense and
reduces dependencies between different parts of the code.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
Previous patches have brought the in-kernel orinoco driver roughly to
parity with version 0.14alpha2 from out-of-tree. Update the version
number and changelog accordingly.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
Update the initialization code in the various PCI incarnations of the
orinoco driver. This applies similar initialization and shutdown
cleanups to the orinoco_pci, orinoco_plx and orinoco_tmd drivers. It
also adds COR reset support to the orinoco_plx and orinoco_tmd
drivers, improves PCI power
Update firmware detection code. This will now reliably detect
Intersil firmwares past verison 1.x, a serious flaw in the previous
code. It cleans up the code, and reduces the size of the private
structure by using single bits for the various firmware feature flags.
Signed-off-by: David Gibson
Delay netif_wake_queue() until the packet has actually been
transmitted, rather than just when the firmware has copied it into its
internal buffers. This seems to prevent problems on some Intersil
firmware versions (I suspect the problems were caused by the
firmware's buffers filling up).
john cooper wrote:
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few
Updates to the WEP configuration code. This adds support for shared
key authentication on Agere firmwares. It also adds support (in some
cases) for changing the WEP keys without disabling the MAC port (thus
triggering a reassociation by the firmware). This is needed by 802.1x
implementations,
On Wed, 2005-02-23 at 22:11 -0500, Ron Peterson wrote:
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages
Cleanup the various bits of initialization code for PCMCIA / PC-Card
orinoco devices. This includes one important bugfix where we could
fail to take the lock in some circumstances.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco_cs.c
FYI, pci_set_drvdata() needs to be one of the last functions called
during PCI -probe().
Jeff
-
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
David Gibson wrote:
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time it's really supposed to be a quickie, so people who
Ron Peterson [EMAIL PROTECTED] wrote:
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually
applied patches 1-14 to netdev-2.6. We'll let it sit there for a bit,
for testing and such. (netdev-2.6 gets auto-propagated to -mm)
Thanks for your patience and perserverance.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Apply some cleanups to the low-level orinoco handling code in
hermes.[ch]. This cleans up some error handling code, corrects an
error code to something more accurate, and also increases a timeout
value. This last can (when the hardware plays up) cause long delays
with spinlocks held, which is
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: working-2.6/drivers/net/wireless/orinoco.c
===
---
Reformats printk()s, comments, labels and other cosmetic strings in
the orinoco driver. Also moves, removes, and adds ratelimiting in
some places. Behavioural changes are trivial/cosmetic only. This
reduces the cosmetic/trivial differences between the current kernel
version, and the CVS version
On Wed, 23 Feb 2005, Lee Revell wrote:
On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
On Wed, 23 Feb 2005, Hugh Dickins wrote:
Please replace by new patch below, which I'm now running through lmbench.
That second patch seems fine, and I see no lmbench regression from it.
Dear all
I am new to this place, Please correct me if i am wrong.
Before console_init, printk is just filling up the printk buffer.
After console_init, will the message print out immediately?
best regard
Mike,Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Hi,
Can you please let me know, what all files does the OS look into to
load modules?
I see the following messages during boot rather installation:
==
Finished bus probing
modules to insert tg3 aic79xx
==
which files does the OS look into to load tg3 and aic79xx after
finishing bus
Mark Lord wrote:
Minor patch for new 2.6.xx sata_qstor driver attached,
as per Alexey's fine-toothed comb! :)
Signed-off-by: Mark Lord [EMAIL PROTECTED]
I had to apply this manually, since your mailer corrupts the patch by
encoding text/plain as base64. Please fix your mailer...
The ideal is
`xterm' is waiting for the other CPU to schedule a kernel thread (which is
bound to that CPU). Once that kernel thread has done a little bit of work,
`xterm' can terminate.
But kernel threads don't run with realtime policy, so your userspace app
has permanently starved that kernel thread.
But the other side of the coin is that a SCHED_FIFO userspace task
presumably has extreme latency requirements, so it doesn't *want* to be
preempted by some routine kernel operation. People would get irritated if
we were to do that.
Just to follow up a bit. People writing apps that run at
On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
- Original Message - From: Hugh Dickins [EMAIL PROTECTED]
though quite possibly you cannot afford
such experiments on this server, and will revert to 2.4 for now.
The problem is that my server is already in production
mode. I'm
On Thu, 24 Feb 2005, Nick Piggin wrote:
Hugh Dickins wrote:
I'm inlining pmd and pud levels, but not pte and pgd levels.
OK - that's probably sufficient for debugging. There is only so
much that can go wrong in the middle levels...
Yes, that was my thinking.
how does it look
On Thu, 2005-02-24 at 05:12 +, Hugh Dickins wrote:
On Thu, 24 Feb 2005, Nick Piggin wrote:
OK after sleeping on it, I'm warming to your way.
I don't think it makes something like David's modifications any
easier, but mine didn't go a long way to that end either. And
being a more
1. Rationale
Currently the Linux kernel implements a hierachical page table utilizing 4
layers. Architectures that have less layers may cause the kernel to not
generate code for certain layers. However, there are other means for mmu
to describe page tables to the system. For example
Hi,
here are some changes that freshen I8K driver (Dell Inspiron/Latitude
platform driver). The patches have been tested on Inspiron 8100.
i8k-lindent.patch
- pass the driver through Lindent to comply with CondingStyle requirements
(4 spaces vs. TAB indentation)
i8k-use-dmi.patch
- use
===
I8K: pass through Lindent to change 4 spaces identation to TABs
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
i8k.c | 954 +-
1 files changed, 477
===
I8K: Change to use stock dmi infrastructure instead of homegrown
parsing code. The driver now requres box's DMI data to match
list of supported models so driver can be safely compiled-in
by default without fear of
===
I8K: Change proc code to use seq_file.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
i8k.c | 64 ++--
1 files changed, 22 insertions(+), 42 deletions(-)
Index:
===
I8K: use module_{init|exit} instead of old style #ifdef MODULE
code, some formatting changes.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
i8k.c | 149
i8k.c | 117 ++
1 files changed, 117 insertions(+)
Index: dtor/drivers/char/i8k.c
===
--- dtor.orig/drivers/char/i8k.c
+++ dtor/drivers/char/i8k.c
@@ -22,6 +22,7 @@
This time it's really supposed to be a quickie, so people who can,
please check it out, and we'll make the real 2.6.11 asap.
Out of diskspace on kernel.org?
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
[...]
patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
Hi all,
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard PCI driver. It turns out to be a major
undertaking, as the PCI probing code is closely tied into a lot of other
PCI
Quoting Linus Torvalds ([EMAIL PROTECTED]):
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time
On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote:
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final
On Thu, 2005-02-24 at 04:56 +, Hugh Dickins wrote:
On Wed, 23 Feb 2005, Lee Revell wrote:
On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
On Wed, 23 Feb 2005, Hugh Dickins wrote:
Please replace by new patch below, which I'm now running through
lmbench.
That second
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
Please assume that whatever secret application the connector stuff was
originally written for will always be listening.
What happened to the idea of sending an on/off message down the netlink
socket?
...
Arrange for the
On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay [EMAIL PROTECTED] wrote:
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard PCI driver. It turns out to be a major
What about VGA
Chad N. Tindel [EMAIL PROTECTED] wrote:
`xterm' is waiting for the other CPU to schedule a kernel thread (which is
bound to that CPU). Once that kernel thread has done a little bit of work,
`xterm' can terminate.
But kernel threads don't run with realtime policy, so your userspace app
@@ -184,6 +186,7 @@
dev_list = link;
client_reg.dev_info = dev_info;
+ client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE;
That's not needed any longer for 2.6.
Dominik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Thu, 2005-02-24 at 01:45 -0500, Jon Smirl wrote:
On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay [EMAIL PROTECTED] wrote:
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard
Hi,
I hope that you can include the following set of CPU scheduler
patches in -mm soon, if you have no other significant performance
work going on.
There are some fairly significant changes, with a few basic aims:
* Improve SMT behaviour
* Improve CMP behaviour, CMP/NUMA scheduling (ie. Opteron)
1/13
Some fixes for unsynchronised TSCs. A task's timestamp may have been set
by another CPU. Although we try to adjust this correctly with the
timestamp_last_tick field, there is no guarantee this will be exactly right.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Index:
2/13
John Hawkes explained the problem best:
A large number of processes that are pinned to a single CPU results
in every other CPU's load_balance() seeing this overloaded CPU as
busiest, yet move_tasks() never finds a task to pull-migrate. This
condition occurs during module unload, but can
201 - 300 of 634 matches
Mail list logo
