On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
It's also not yet clear that a scheduler can't be taught to do the
right thing with X without fiddling with nice levels.
Being fair doesn't prevent that. Implicit unfairness is wrong though,
because it will bite people.
What's
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
* Michael Ellerman [EMAIL PROTECTED] wrote:
Apparently it's not cool anymore to use SPIN/RW_LOCK_UNLOCKED. There's
some mention of this in Documentation/spinlocks.txt, but that only
talks about dynamic initialisation.
A comment in the code mentioning the preferred usage would be good
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA LEGACY, stat=0x400
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 kmem_getpages()/kmem_freepages() time.
We already touch -flags, -gfpflags, and -gfporder in
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
Max Kellermann wrote:
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA
Dave Hansen wrote:
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define
On Wed, Apr 18, 2007 at 12:55:25AM -0500, Matt Mackall wrote:
On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
It's also not yet clear that a scheduler can't be taught to do the
right thing with X without fiddling with nice levels.
Being fair doesn't prevent that. Implicit
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) \
list_entry((head)-next, type, member)
Here
Pekka Enberg wrote:
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
What's wrong with the spinlock? It exists
On Tue, 17 Apr 2007, John Anthony Kazos Jr. wrote:
--- linux-2.6.21-rc7.orig/Documentation/fb/framebuffer.txt2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/Documentation/fb/framebuffer.txt 2007-04-17
12:44:09.0 -0400
@@ -217,7 +217,7 @@ vsync length.
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
I don't know how that supports your argument for unfairness,
I never had such an argument. I like fairness.
My argument is that -you- don't have an argument for making fairness a
-requirement-.
processes are special only because
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
On Tue, 17 Apr 2007, Dave Jones wrote:
git-bisect just fingered it as responsible for my backlight doesn't turn on
suspend/resume regression on the Thinkpad X60. I think it's lying.
Actually I've seeing git bisect lying on me, too. I retried a few times
(fortunately it didn't require
On Tue, Apr 17, 2007 at 12:56:24PM -0400, Shaya Potter wrote:
Bharata B Rao wrote:
No. foo is not visible. While looking for a file in a union mounted
directory, the lookup starts from the topmost directory and proceeds
downwards if the file isn't present the top layers. If a whiteout is
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 the data. As the data flows
It seems that this might introduce serious denial of service
possibilities due to the fact that many of the file systems are not
robust to invalid on-block-device data.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Wed, Apr 18, 2007 at 01:55:34AM -0500, Matt Mackall wrote:
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
I don't know how that supports your argument for unfairness,
I never had such an argument. I like fairness.
My argument is that -you- don't have an argument for
Matt Mackall wrote:
On Tue, Apr 17, 2007 at 03:59:02PM -0700, William Lee Irwin III wrote:
On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
I'm working with the following suggestion:
On Tue, Apr 17, 2007 at 09:07:49AM -0400, James Bruce wrote:
Nonlinear is a must IMO. I
remember that the windows NT permission model is theoreticly superior to the
Unix permission model.
however there are far more insecure windows boxes out there then Unix boxes
(even if taken as a percentage of the installed base)
I don't think that anyone is claiming that AA is superior to
On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote:
Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
By the way, on this machine, I had a lot of SATA timeouts during
Max Kellermann wrote:
On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote:
Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
Unfortunately, NCQ is not supported on
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 device_unregister(). On return
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
immediate-detach driver model.
John Sigler wrote:
# : /var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 519083XT-PIC-XTtimer
2: 0XT-PIC-XTcascade
9: 0XT-PIC-XTacpi
10: 9786
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 socket with non-zero
callback is freed.
Here it is:
CPU1: CPU2
netlink_release():
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 socket with non-zero
On Tue, 2007-04-17 at 21:19 -0400, Trond Myklebust wrote:
I've split the issues introduced by the 2.6.21-rcX write code up into 4
subproblems.
The first patch is just a cleanup in order to ease review.
Patch number 2 ensures that we never release the PG_writeback flag until
_after_ we've
18.04.2007 06:25, Dmitry Torokhov wrote/a écrit:
On Saturday 14 April 2007 12:09, Éric Piel wrote:
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Was there 1/2 file?
I'd imagine that other serial drivers might get upset having their
-get_mcrtl() called prior to being opened. Perhaps we should be fixing
this in uart_read_proc()?
I looked at other serial drivers and I could not find any other
drivers which accesses port-info in their -get_mctrl(). This
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
1 - 100 of 738 matches
Mail list logo
