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 exi
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 th
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 o
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 reboot
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
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
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 SE
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
ke
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 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 retu
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 mod
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: 9786XT-PIC-
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_
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?
Ooop
> 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(). T
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
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
[ 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 xin
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 o
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 i
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
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. B
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
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
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 t
* 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
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
* 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 Q
* 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 p
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 wi
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::se
> > 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 referen
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.
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 i
> 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 allocat
* 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
> > 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 re
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::setUpdatesEnabl
* 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:
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 net
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
> somet
John Anthony Kazos Jr. wrote:
> Convert the subdirectory "crypto" to UTF-8. The files changed are
> and .
Aren't we using ASCII for C sources?
--
Stefan Richter
-=-=-=== -=-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
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.
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}
> include/net/irda/{irlmp_frame.h,irlan_eth
> 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, ma
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 ++
> arch/i386/ker
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
> > and .
>
> Aren't we using ASCII for C sources?
We haven't done that for many years - it makes it hard to spell
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,
* 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.93
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,
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 pr
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 a81b2b0a68303d8dfe616edc4c12c9030723ca1
>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 y
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 1cd1f5e02996
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
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
au
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 12:
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 +0
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
c
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 b1b13ea51dcaef72c5298a04d233b92206adf97
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 de126dc99bbafbb15d3fc7c96211e9648f4d
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 29d863d5eca58913c306bc8cd9a6b3a5dce
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 0134ea3532474f2c7bc2deabcf453b83f0
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 com
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:
pthread_mutex_lock()
xine_log()
function pointer call
right after it: pthread_mutex_
* 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 s
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 yie
* 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 expl
* 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 );
* 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_l
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]
Mo
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 commo
> 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 exclud
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 cl
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
(I'
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 o
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) control
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]
Mo
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 P
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 k
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 kmem_getpa
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 struct
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: [rw-r--r--] net_dev: eth0,eth1,...
| ...
|--- port2
1 - 100 of 372 matches
Mail list logo
