Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try xine-ui or gxine? Because I suspect rather xine-lib
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of
On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
PROTECTED]) wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race
On Wed, Apr 18, 2007 at 12:32:40PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
PROTECTED]) wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Oh, one more thing, with proper code audit, we can just make
device_unregister() do the waiting instead of adding separate
device_unregister_wait(). I think that will be a good step toward
On Fri, 2007-03-30 at 16:05 -0700, Dan Williams wrote:
Allows architectures to advertise that they support MSI rather than listing
each architecture as a PCI_MSI dependency.
rev2:
* update i386 and x86_64 as well
Signed-off-by: Dan Williams [EMAIL PROTECTED]
Acked-by: Eric W. Biederman
Madhusudhan c wrote:
Hi Pierre/philip,
Hi Madhusudhan,
Feel free to add me as cc in the future if you want me to notice your mail ;)
This is regarding the MMCv4 support that came in as part of the MMC
core of 2.6.20 linux kernel version.
The high speed MMC cards can support 4-bit/8-bit
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Out of curiosity, why not to fix a netlink_dump_start() to remove
callback in error path, since in 'no-error' path it removes it in
netlink_dump().
It already does
On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
2.6.21-rc7-cfs-v2
534.80user 30.92system 2:23.64elapsed 393%CPU
534.75user 31.01system 2:23.70elapsed 393%CPU
534.66user 31.07system 2:23.76elapsed 393%CPU
534.56user 30.91system
Hi,
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister [EMAIL PROTECTED] wrote:
[1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
Could you try
* Ingo Molnar [EMAIL PROTECTED] wrote:
update: i've reproduced one kind of a hang but i'm not sure it's the
same hang Ismail is seeing. It was quite hard to trigger it under CFS,
i had to do wild forward/backward button seeks on a real DVD and i
mixed it with CPU-intense workloads on the
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:32:40PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
PROTECTED]) wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from /usr/lib/libxine.so.1
#3 0xb7a030ab in
* Ingo Molnar [EMAIL PROTECTED] wrote:
these were only the threads that showed up in htop. Here's a full
analysis about what all threads are doing:
Process 9303: stuck in xine_play()/pthread_mutex_lock()
Process 9319: stuck in pthread_cond_timedwait()
Process 9320: stuck in
On Wed, Apr 18, 2007 at 10:50:42AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
It already does (netlink_destroy_callback), but that doesn't help
with this race though since without this patch we don't enter the
error path.
I thought that with releasing a socket, which will have a
On Wed, 2007-04-18 at 11:01 +0200, Ingo Molnar wrote:
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled ()
I've tried to make this unprivileged mount thing as simple as
possible, and no simpler. If we can make it even simpler, all the
better.
We are certainly much more complex then the code in plan9 (just
read through it) so I think we have room for improvement.
Just for reference what I
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
backtrace:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from
On Wed, Apr 18, 2007 at 01:03:56PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Yes, you are right, that it will not be freed in netlink_release(),
but it will be freed in netlink_dump() after it is processed (in no-error
path only though).
But error path will leak it. On
Evgeniy Polyakov wrote:
On Wed, Apr 18, 2007 at 10:50:42AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
I thought that with releasing a socket, which will have a callback
attached only results in a leak of the callback? In that case we can
just free it in dump() just like it is done in
The basic reason for all this is to eventually allow the low-level
serial drivers to function without a uart_info structure being
allocated. This will allow the serial console, debuggers like kgdb,
and the IPMI serial driver to use one interface to the uart code and
Its cheaper to allocate a
* Christoph Pfister [EMAIL PROTECTED] wrote:
are the updated backtraces in the followup mail i just sent more
useful? (I still have that stuck session running so i can whatever
debugging you'd like to see done.)
QWidget::setUpdatesEnabled() is (wrongly) present in every thread
except
Allowing this and other flags to NOT be propagated just makes it
possible to have a set of shared mounts with asymmetric properties,
which may actually be desirable.
The shared mount feature was designed to ensure that the mount remained
identical at all the locations.
OK, so remount
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
are the updated backtraces in the followup mail i just sent more
useful? (I still have that stuck session running so i can whatever
debugging you'd like to see done.)
QWidget::setUpdatesEnabled() is
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it is, 9303 with better symbol names:
#0
On Wed, Apr 18, 2007 at 11:16:50AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
That is what I referred to as error path. Btw, with positive return
value we end up in subsequent call to input which will free callback
under lock as expected.
No, nothing is going to call
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing problem when
something
John Anthony Kazos Jr. wrote:
Convert the subdirectory crypto to UTF-8. The files changed are
crypto/fcrypt.c and crypto/api.c.
Aren't we using ASCII for C sources?
--
Stefan Richter
-=-=-=== -=-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
2.6.21-rc7-cfs-v2
534.80user 30.92system 2:23.64elapsed 393%CPU
534.75user 31.01system 2:23.70elapsed 393%CPU
534.66user
On 4/17/2007 7:53 PM, John Anthony Kazos Jr. wrote:
From: John Anthony Kazos Jr. [EMAIL PROTECTED]
Convert the include subdirectory to UTF-8. The following files are
changed.
include/net/irda/{iriap.h,irttp.h,iriap_event.h,parameters.h}
Yet another hard drive which doesn't seem to get NCQ right.
I have a Samsung 400LJ that appears to work fine with NCQ on an Intel
965 chipset motherboard (Asus P5B) and Linux kernel 2.6.20.7.
Dmesg Output :
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7,
Hi,
The patch looks good to me.
On Mon, Apr 16, 2007 at 11:27:58PM +0200, Rafael J. Wysocki wrote:
---
Documentation/cpu-hotplug.txt |9 +++--
arch/i386/kernel/cpu/intel_cacheinfo.c|2 ++
arch/i386/kernel/cpu/mcheck/therm_throt.c |2 ++
On Wed, 18 Apr 2007 11:33:29 +0200
Stefan Richter [EMAIL PROTECTED] wrote:
John Anthony Kazos Jr. wrote:
Convert the subdirectory crypto to UTF-8. The files changed are
crypto/fcrypt.c and crypto/api.c.
Aren't we using ASCII for C sources?
We haven't done that for many years - it makes
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it
* Nick Piggin [EMAIL PROTECTED] wrote:
535.43user 30.62system 2:23.72elapsed 393%CPU
Thanks for testing this! Could you please try this also with:
echo 1 /proc/sys/kernel/sched_granularity
507.68user 31.87system 2:18.05elapsed 390%CPU
507.99user 31.93system
Trond Myklebust [EMAIL PROTECTED] writes:
I was mainly interested in feedback from Peter, Florin and Ogawa-san to
find out if this series fixes their problems. You were unfortunate
enough to have been on earlier Ccs, so I didn't dare trim you off. :-)
Sorry. I'm trying to reproduce that, but
Cornelia Huck wrote:
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing
cyclades, create cy_init_Ze
Move Ze init code into new cy_init_Ze, because we will need it in another
place and it will make the code totally unreadable.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 1cd1f5e029963fc449c4f84495770611e5c35297
tree a81b2b0a68303d8dfe616edc4c12c9030723ca12
That by itself would suggest a single-bit error, which would point
you to running memtest86 overnight to check your RAM. Worth a try.
ok,
I've finished today the long testing on my ram with memtest86+ 1.65
(distributed in debian): no errors.
so I think the problem is somewere else...
tnx for
cyclades, use pci_iomap/unmap
fork remove code for pci -- move it to separate, new, function and don't
care about pci in the former.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 2d99f97963f6a60727c1cc8d21d3bdbf4ba48d7f
tree aba7f710a1668c17d56d45ff805ec03adc950c42
parent
cyclades, init Ze immediately
There will be no other choice after introducing pci probing anyway.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 15bad81f3abe0638e7ccf34fd14cf6c372146742
tree 3dfe3a58322b197e80d09757e4049f1221240a6d
parent 2d99f97963f6a60727c1cc8d21d3bdbf4ba48d7f
author
2007/4/18, Christoph Pfister [EMAIL PROTECTED]:
2007/4/18, Ingo Molnar [EMAIL PROTECTED]:
* Christoph Pfister [EMAIL PROTECTED] wrote:
which thread would be the most interesting to you - 9324?
The thread which should wake the main thread - but hmm ... 9303 seems
to be rather
cyclades, create cy_pci_probe
Move probing code to separate function for easy pci probing conversion.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 07df3f0fcb1cad6a274d5b7b32d65df54c3f4fb4
tree cb3c77a959c7ca9d63faaec82c154a752e87ff42
parent 15bad81f3abe0638e7ccf34fd14cf6c372146742
cyclades, move card entries init into function
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit de8850dd6c04762688b19609b13cb16a1e6399a9
tree 288721fb454613ce1d3bdd6ec10ca6e01c3059c7
parent 07df3f0fcb1cad6a274d5b7b32d65df54c3f4fb4
author Jiri Slaby [EMAIL PROTECTED] Mon, 02 Apr 2007
cyclades, init card struct immediately
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 39e37f9c0e50657a546e20c2e37f58e0f260cdf6
tree f67e112b80d616e9d2fc57f35b6e39a45bea81a7
parent de8850dd6c04762688b19609b13cb16a1e6399a9
author Jiri Slaby [EMAIL PROTECTED] Mon, 02 Apr 2007 12:47:57 +0200
cyclades, remove some global vars
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit b1b13ea51dcaef72c5298a04d233b92206adf978
tree a55032090e0b1c40e541685b49f8f608edf60611
parent 39e37f9c0e50657a546e20c2e37f58e0f260cdf6
author Jiri Slaby [EMAIL PROTECTED] Mon, 02 Apr 2007 12:50:04 +0200
cyclades, cy_init error handling
- do not panic if tty_register_driver fails
- handle fail paths properly
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 8c76c370ee1c1efa31f64807162c15922fae1e3a
tree 19fe12eba568aece1d0b406a4d735f393f2cd3dd
parent b1b13ea51dcaef72c5298a04d233b92206adf978
cyclades, tty_register_device separately for each device
Do not register all tty devices at the init time, delay it for the time
until some device is found.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit ad4f792b92f8e6350a62b61442bb6812969bfd73
tree
cyclades, clear interrupts before releasing
Without this patch, the driver sometimes causes IRQXX: Nobody cares. Fix
it by turning off irqs when releasing.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 0156510dee9d326af2ec52cf8b1a388ce9a839e9
tree
cyclades, allow DEBUG_SHIRQ
Test if base addr is non-null in ISR to prove the card has been correctly
initialized. This is needed for DEBUG_SHIRQ for example.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 71c2e9b72594f69e4e226006206ffa74b55c1642
tree
On Wed, April 18, 2007 6:56, Dmitry Torokhov said:
On Tuesday 17 April 2007 13:19, John Anthony Kazos Jr. wrote:
 /*
- * Samma på svenska..
+ * Samma pÃÂ¥ svenska..
 */
Translating this comment into english so more people could understand it
would be better option.
The comment says
Hello,
I have the same problems with CPU-Hotplug. Whenever I turn off the
second core and turn it back on, /proc/cpuinfo shows that the second
core is on, but at a different speed.
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 72
* Christoph Pfister [EMAIL PROTECTED] wrote:
It's nearly impossible for me to find out which mutex is deadlocking.
i've disassembled the xine_play function, and here are the function
calls in it:
unresolved widget call?
pthread_mutex_lock()
xine_log()
unresolved widget call?
function
* Andy Whitcroft [EMAIL PROTECTED] wrote:
as usual, any sort of feedback, bugreports, fixes and suggestions
are more than welcome,
Pushed this through the test.kernel.org and nothing new blew up.
Notably the kernbench figures are within expectations even on the
bigger numa systems,
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c does
this:
pthread_mutex_unlock( stream-demux_lock );
lprintf (sched_yield\n);
sched_yield();
pthread_mutex_lock( stream-demux_lock );
why is this done? CFS has definitely changed the yield
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
plus it does this too:
pthread_mutex_unlock( stream-demux_lock );
xine_usec_sleep(10);
pthread_mutex_lock( stream-demux_lock );
this would explain the
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
plus it does this too:
pthread_mutex_unlock( stream-demux_lock );
xine_usec_sleep(10);
pthread_mutex_lock( stream-demux_lock );
this would
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. I've reviewed all uses of demux_lock. ./src/xine-engine/demux.c
does this:
pthread_mutex_unlock( stream-demux_lock );
lprintf (sched_yield\n);
sched_yield();
pthread_mutex_lock( stream-demux_lock );
why is
I wrote:
Aren't we using ASCII for C sources?
Not anymore, according to http://lkml.org/lkml/2007/4/18/94 .
--
Stefan Richter
-=-=-=== -=-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Alan Cox wrote:
The real test of whether Sun were serious about ZFS being anywhere but
Solaris is what they do to license it - they've patented everything they
can, and made the code available only under licenses incompatible with
other OS products. Their intent is quite clear, and quite sad.
Gene Heskett wrote:
Chuckle, see how you are? You keep quoting the 'PC', and 20 years ago the PC
term included a lot of machinery that didn't always run M$ code. TRS-80
Color Computers and such, or Apple II, Commode-door etc.
Bloody heck. You know very well I was using the term in the
Please do see:
http://www.opensolaris.org/os/about/faq/licensing_faq/#patents
Which appears to agree with everything I said not what you are claiming.
The patent license is strictly tied to their implementation and its
derivatives under the CDDL, so specifically acts to exclude Linux.
Alan
-
Alan Cox wrote:
Please do see:
http://www.opensolaris.org/os/about/faq/licensing_faq/#patents
Which appears to agree with everything I said not what you are claiming.
The patent license is strictly tied to their implementation and its
derivatives under the CDDL, so specifically acts to
On Tue, 2007-04-17 at 23:07 -0500, Florin Iucha wrote:
When 'big-copy' hangs, if I switch to a different console and run
'lsof', '[u]mount', or use shell completion on a network mount then that
process goes into D state. I cannot umount the network shares nor
stop autofs. I cannot do a clean
Andi Kleen wrote:
There are usually chipset specific bits that can be set to disable
SMMs. See the datasheet if you can get them. Unfortunately most
chipset vendors don't give out data sheets easily.
I managed to find the south bridge data sheet.
http://linux.kernel.free.fr/VT82C686B.pdf
Pavel Emelianov writes:
There are many places in the kernel where the construction like
foo = list_entry(head-next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
Tejun Heo [EMAIL PROTECTED] wrote:
This really isn't a regression. It's been always like that with libata.
libata doesn't make devices go into standby mode and shutdown(8) does
it for libata. The problem here is that libata does issue
SYNCHRONIZE_CACHE on shutdown. So, the sequence of
Hi Perre/Philip,
Feel free to add me as cc in the future if you want me to notice your mail ;)
Sure. In fact I looked around to find your email id and did not find
it. In future I will include you in cc.
We haven't determined it as necessary, and as Philip commented, most (if not
all)
Alright, was anybody able to apply these? The major portion of the changes
still remains and I want to make sure what I'm doing is working before I
spend a lot of time on it.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
From: Keiichi KII [EMAIL PROTECTED]
This patch contains the following cleanups.
- add __init for initialization functions(option_setup() and
init_netconsole()).
Acked-by: Matt Mackall [EMAIL PROTECTED]
Signed-off-by: Keiichi KII [EMAIL PROTECTED]
Signed-off-by: Takayoshi Kochi [EMAIL
Bodo Eggert wrote:
SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part
is acked and waiting to be merged, so the fix will be available in
2.6.22. However, it's disabled by default to remain compatible with the
From: Keiichi KII [EMAIL PROTECTED]
This patch contains the following changes for supporting multiple logging
agents.
1. extend netconsole to multiple netpolls
To send kernel messages to multiple logging agents, extend netcosnole
to be able to use multiple netpolls. Each netpoll sends
On Wed, 18 Apr 2007 09:17:19 +0300 (EEST)
Pekka J Enberg [EMAIL PROTECTED] wrote:
On Tue, 17 Apr 2007, Eric Dumazet wrote:
This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
or else you defeat NUMA optimizations if touching a field in kmem_cache
at
On 2007/04/18 09:56, Tejun Heo [EMAIL PROTECTED] wrote:
It's more likely your chipset just has busted MSI support. Please
post the result of 'lspci -tv' and 'lspci -nn'.
See attachments. I found the nomsi workaround in a forum, and
didn't bother to investigate the real cause yet.
Max
From: Keiichi KII [EMAIL PROTECTED]
This patch contains the following changes.
create a sysfs entry for netconsole in /sys/class/misc.
This entry has elements related to netconsole as follows.
You can change configuration of netconsole(writable attributes such as IP
address, port number and so
The mm structures of interactive tasks are marked and
the pages belonging to them are never shifted to inactive
list in lru algorithm. Thus keeping interactive tasks in
memory as long as possible.
The interactivity is already determined by schedular so
we reuse that knowledge to mark the mm
From: Keiichi KII [EMAIL PROTECTED]
We use symbolic link for net_device.
The link in sysfs represents the corresponding network etherdevice.
-+- /sys/class/misc/
|-+- netconsole/
|-+- port1/
| |--- id [r--r--r--] id
| |--- net:net_dev [rw-r--r--] net_dev: eth0,eth1,...
| ...
|---
From: Keiichi KII [EMAIL PROTECTED]
This patch contains switch function of netpoll.
If enabled attribute of certain port is '1', this port is used
and the configurations of this port are uable to change.
If enabled attribute of certain port is '0', this port isn't used
and the configurations of
On Wed, Apr 18, 2007 at 11:53:34AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
So looking at elapsed time, a granularity of 100ms is just behind the
mainline score. However it is using slightly less user time and
slightly more idle time, which indicates that
Hi!
Add a blink driver for debugging
Simple driver that blinks the keyboard LEDs when loaded. Useful
for checking that the kernel is still alive or for crashdumping.
For checking if kernel is alive/crashdumping... can user just do
setleds +caps; sleep 1; setleds -caps; ... ? You can even
On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
Again, for comparison 2.6.21-rc7 mainline:
508.87user 32.47system 2:17.82elapsed 392%CPU
509.05user 32.25system 2:17.84elapsed 392%CPU
508.75user 32.26system 2:17.83elapsed
From: Keiichi KII [EMAIL PROTECTED]
We add ioctls for adding/removing target.
If we use NETCONSOLE_ADD_TARGET ioctl,
we can dynamically add netconsole target.
If we use NETCONSOLE_REMOVE_TARGET ioctl,
we can dynamically remoe netconsole target.
We attach a sample program for ioctl.
From: Keiichi KII [EMAIL PROTECTED]
The netconsole is a very useful module for collecting kernel message under
certain circumstances(e.g. disk logging fails, serial port is unavailable).
But current netconsole is not flexible. For example, if you want to change ip
address for logging agent, in
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking others. :-(
Rob Meijer wrote:
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to
On Wednesday 18 April 2007 22:14, Nick Piggin wrote:
On Wed, Apr 18, 2007 at 07:33:56PM +1000, Con Kolivas wrote:
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
Again, for comparison 2.6.21-rc7 mainline:
508.87user 32.47system 2:17.82elapsed 392%CPU
509.05user 32.25system
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
David Miller writes:
Here is Patrick McHardy's patch:
So this
On Tue, Apr 17, 2007 at 10:37:38PM -0700, Andrew Morton wrote:
Florin, can we please see /proc/meminfo as well?
http://iucha.net/nfs/21-rc7-nfs2/meminfo
Also the result of `echo m /proc/sysrq-trigger'
http://iucha.net/nfs/21-rc7-nfs2/big-copy
This has 'echo m /proc/sysrq-trigger',
On Tue, Apr 17 2007, Neil Brown wrote:
On Monday April 16, [EMAIL PROTECTED] wrote:
cfq_dispatch_insert() was called with rq == 0. This one is getting really
annoying... and md is involved again (RAID0 this time.)
Yeah... weird.
RAID0 is so light-weight and so different from RAID1 or
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if its
cache is clean. Sadly some disks actually spin up when it receives spin
down command while spun down to immediately spin down again, so we would
be fixing problem for some number of disks while breaking
Hello.
Mike Mattie wrote:
I have added Sergei Shtylyov to the address list after seeing his recent posts
on hpt366 issues, and the
git changelog for the hpt366.c driver. I am very confident that I have
pinpointed the defect in the driver.
Indeed you have. Thank you.
[ Cc's added, full
Tejun Heo wrote:
Alan Cox wrote:
Not that simple. Most disks don't spin up on SYNCHRONIZE_CACHE if
its cache is clean. Sadly some disks actually spin up when it
receives spin down command while spun down to immediately spin down
again, so we would be fixing problem for some number of disks
On Wednesday 18 April 2007 22:13, Nick Piggin wrote:
On Wed, Apr 18, 2007 at 11:53:34AM +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
So looking at elapsed time, a granularity of 100ms is just behind the
mainline score. However it is using slightly less user time and
Chris Friesen wrote:
Peter Williams wrote:
Chris Friesen wrote:
Suppose I have a really high priority task running. Another very
high priority task wakes up and would normally preempt the first one.
However, there happens to be another cpu available. It seems like it
would be a win if we
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
very uneasy
On Apr 17, 2007 18:25 +0530, Amit K. Arora wrote:
On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote:
Wouldn't
int fallocate(loff_t offset, loff_t len, int fd, int mode)
work on both s390 and ppc/arm? glibc will certainly wrap it and
reorder the arguments as needed, so there
Alan Cox wrote:
Thought about that and querying power state before doing shutdown
sequence but things get somewhat ugly because shutdown sequence is
driven from sd-shutdown(). We'll have to snoop both sync and shutdown
commands and check whether the system is shutting down. Also, I felt
Zachary Amsden wrote:
Are you sure that it still wins even with these patches? I can't see
ptep_get_and_clear getting much faster than a pure non-emulated, and
the stress case which wins 25-30% is fork/exit being able to drop the
pte updates in zap_pte_range from trapping and / or going into
401 - 500 of 738 matches
Mail list logo
