On Thu, Sep 27 2007, NeilBrown wrote:
> Hi Jens,
> here are a few more patches from my set that makes various changes to bio
> submission and handling.
>
> These change the ->bi_end_io prototype so that
>1/ no 'size' is passed
>2/ there is no return value.
>
> The 'size' is not
Hi all!
(Please Cc)
kernel 2.6.23-rc6
Debian/sid
kernel ooops:
BUG: unable to handle kernel paging request at virtual address 104b
printing eip:
c0195bd3
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: vboxdrv binfmt_misc fuse coretemp hwmon gspca videodev
* Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> [2007-09-27 11:49]:
> > Martin, could you check the iperf patch below instead of the yield
> > patch - does it solve the iperf performance problem equally well,
> > and does CPU utilization drop for you too?
>
>
* Ingo Molnar <[EMAIL PROTECTED]> [2007-09-27 11:49]:
> Martin, could you check the iperf patch below instead of the yield
> patch - does it solve the iperf performance problem equally well,
> and does CPU utilization drop for you too?
Yes, it works and CPU goes down too.
--
Martin Michlmayr
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
Hi Andrew,
The drivers/net/ibm_newemac/mal seems to be broken with 2.6.23-rc8-mm2 also, it
was
reported on 2.6.23-rc8-mm1 (http://lkml.org/lkml/2007/9/25/173).
--
Thanks & Regards,
Hi Dmitry,
>-Original Message-
>From: Dmitry Torokhov [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 26. September 2007 15:38
>To: [EMAIL PROTECTED]; Michael Hennerich
>Cc: [EMAIL PROTECTED]; Linux Kernel; uclinux-dist-
>[EMAIL PROTECTED]
>Subject: Re: [PATCH 1/2] [INPUT] Blackfin BF54x Input
[various useful comments snipped]
Thanks Geoff -- I will incorporate all of the points you mentioned.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
Davide,
A further question: what is the expected behavior in the
following scenario:
1. Create a timerfd and arm it.
2. Wait until M timer expirations have occurred
3. Modify the settings of the timer
4. Wait for N further timer expirations have occurred
5. read() from the timerfd
Does the
On 9/27/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> I cross compile arm and mips kernels from the same kernel tree.
You can use O= feature and skip this issue completely.
make ARCH=mips O=../build/mips ...
make ARCH=arm O=../build/arm ...
> When
> I build a kernel the first time
1. kernel BUG at net/core/skbuff.c:1341!
2. I got a kernel panic, the hardware is a good IBM 206m server
with 2 Gb ECC memory, Memtest86+ run several times without
problem. The message on the console is quite explicit, so is this
really a kernel bug?
The box is a web server with moderate
Hello,
On Thu, 27 Sep 2007 19:04:11 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Let me guess... this is a T61 or X61 ?
Bad luck ;)
This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU,
a bunch of disk (2 IDE, 3 SATA, 1 CDRW and 1 DVDRW-DL), and a damned
Olitec PCI
Hi,
When calling the RELDISP VT ioctl, we are reading vt_newvt while the console
workqueue could be messing with it (through change_console()).
We fix this race by taking the console semaphore before reading vt_newvt.
Andrew, would you please consider this patch for -mm inclusion ?
There is nice 2 byte hole after struct task_struct::ioprio field
into which we can put two 1-byte fields: ->fpu_counter and ->oomkilladj.
[cc'ing Arjan just in case ->fpu_counter placement wasn't completely random :^)]
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
* Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> > I think the real fix would be for iperf to use blocking network IO
> > though, or maybe to use a POSIX mutex or POSIX semaphores.
>
> So it's definitely not a bug in the kernel, only in iperf?
>
> (CCing Stephen Hemminger who wrote the iperf
* Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > the (small) patch below fixes the iperf locking bug and removes the
> > yield() use. There are numerous immediate benefits of this patch:
> ...
> >
> > sched_yield() is almost always the symptom of broken locking or other
> > bug. In that sense
Sorry, my mistake, the link should be
http://lkml.org/lkml/2007/7/25/268
memtest was running for one week with no results, i also tried the ram
from another box.
I replaced all SATA kables half a year ago with no result :/
A friend told me he had problems with a VIA Board when using the
hardware
On Thu, 27 Sep 2007, Mariusz Kozlowski wrote:
> It looks like hidraw_connect() is leaking memory in case of failure.
> Also it should return -ENOMEM when kzalloc fails.
Mariusz,
good catch, will apply to me tree.
Thanks,
--
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list: send the
On 26-09-2007 15:31, Ingo Molnar wrote:
> * David Schwartz <[EMAIL PROTECTED]> wrote:
>
I think the real fix would be for iperf to use blocking network IO
though, or maybe to use a POSIX mutex or POSIX semaphores.
>>> So it's definitely not a bug in the kernel, only in iperf?
>>
I cross compile arm and mips kernels from the same kernel tree. When
I build a kernel the first time with a fresh kernel tree, the
include/asm symlink is set properly. However, when I compile for a
different $ARCH, the include/asm is not changed and the build fails.
Would it be possible for the
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
- The scheduler devel tree has been restored
- The driver tree is presently busted, so I reverted it to the 2..23-rc8-mm1
version.
- It's now a nearly-32MB diff.
Boilerplate:
- See the `hot-fixes'
Hello,
HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI
devices in the expected order.
(John, can you please confirm and ACK this?)
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]>
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index ebc6f3c..8737c53
Let me guess... this is a T61 or X61 ?
There's a problem with these that we don't fully understand yet, we're
getting those stale interrupts all over the range.
I wonder if it could be a bug with the ICH8 chipset...
If yours is one of these, it's being dealt with (or attempted to deal
with) at
Le Wed, 26 Sep 2007 13:01:44 -0700,
Andrew Morton <[EMAIL PROTECTED]> a écrit :
> Also, I don't think we're seeing enough review and test from people on
> these patch series - I don't have time to do it all. (Well, apparently I
> do, but I don't think it's a good situation).
I don't object to
* Antoine Martin <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> These are pure cpu scheduling tests, not doing any I/O this time. All
> these tests are still "pathological" in the sense that they are only
> meant to show differences between schedulers
Michael Kerrisk <[EMAIL PROTECTED]> wrote, on 26 Sep 2007:
>
> .TH TIMERFD_CREATE 2 2007-09-26 Linux "Linux Programmer's Manual"
> .SH NAME
> timerfd_create, timerfd_settime, timer_gettime \-
s/timer_/timerfd_/
> timers that notify via file descriptors
> .SH SYNOPSIS
> .\" FIXME . This header
Andrew Morton wrote:
> On Wed, 26 Sep 2007 19:08:18 +0200
> Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
>
>> Align with the opening parenthesis.
>>
>> Changelog since V1 (http://lkml.org/lkml/2007/9/21/527):
>> - renamed fill_threadgroup() and add_tsk() to respectively
>>
[EMAIL PROTECTED] wrote:
> Serge E. Hallyn [EMAIL PROTECTED] wrote:
> | Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> | > Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> | > > The option is called NAMESPACES. It can be selectable only
> | > > if EMBEDDED is chosen (this was Eric's requisition).
Hi Henry.
Snipped a very detaild an good example...
Thanks for your comprehensive feedback on this topic.
>
> Idea for future:
> An 'APPEND_LDFLAGS' would be nice to append flags behind the last .o
> object. Than can be close the group with --end-group.
>
> Exactly linker call would be with
H. Peter Anvin wrote:
> Balbir Singh wrote:
>> Andreas Schwab wrote:
>>> Maxim Uvarov <[EMAIL PROTECTED]> writes:
>>>
diff --git a/Documentation/accounting/getdelays.c
b/Documentation/accounting/getdelays.c
index cbee3a2..73924df 100644
---
Hello Sam,
Henry Nestler wrote:
Sam Ravnborg wrote:
What macro should set for linker parameters of foo.o ? I'm not shure.
Have you read:
Documentation/kbuild/makfilefiles.txt?
[...]
If your example requires the LDFALGS_$@ I wil introduce it - for now
it has not been required (except for
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> humm... I think, it'd be safer to have something like the following
> change in place.
>
> The thing is that __pick_next_entity() must never be called when
> first_fair(cfs_rq) == NULL. It wouldn't be a problem, should
> 'run_node' be the very
Now snd_register_device_for_dev() can oops when device_create() returns
ERR_PTR(err).
Scenario:
preg->dev = device_create(...); /* fails */
if (preg->dev) /* contains ERR_PTR(err) */
dev_set_drvdata(preg->dev, private_data);
and dev_set_drvdata() looks like this:
static inline void
>>> Stephen Hemminger <[EMAIL PROTECTED]> 26.09.07 19:12 >>>
>On Wed, 26 Sep 2007 17:08:19 +0100
>"Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
>> >>> Stephen Hemminger <[EMAIL PROTECTED]> 26.09.07 17:37 >>>
>> >On Wed, 26 Sep 2007 08:53:27 +0100
>> >"Jan Beulich" <[EMAIL PROTECTED]> wrote:
>> >
>>
It looks like hidraw_connect() is leaking memory in case of failure.
Also it should return -ENOMEM when kzalloc fails.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/hid/hidraw.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
---
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot,
As bi_end_io is only called once when the reqeust is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Signed-off-by: Neil
Greg KH wrote:
On Wed, Sep 26, 2007 at 11:40:58PM +0200, Brice Goglin wrote:
Greg KH wrote:
Here's a summary of the current state of the Linux PCI subsystem, as of
2.6.23-rc8.
If the information in here is incorrect, or anyone knows of any
outstanding issues not listed here, please let me
The only caller of bio_endio that does not pass the full bi_size
is end_that_request_first. Also, no ->bi_end_io method is really
interested in bi_size being decremented.
So move the decrement and related code into ll_rw_blk and merge it
with order_bio_endio to form req_bio_endio which does
Currently bi_end_io can be called multiple times as sub-requests
complete. However no ->bi_end_io function wants to know about that.
So only call when the bio is complete.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/bio.c |4 +++-
1 file changed, 3
Hi Jens,
here are a few more patches from my set that makes various changes to bio
submission and handling.
These change the ->bi_end_io prototype so that
1/ no 'size' is passed
2/ there is no return value.
The 'size' is not really of interest to any bi_end_io handler in existance.
The entire function of flush_dry_bio_endio is to undo the effects
of bio_endio (when called on a barrier request). So remove the
function and the call to bio_endio.
This allows us to remove "bi_size" from "struct request_queue".
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat
On Thursday 20 September 2007, you wrote:
> So instead of:
> printk(KERN_NOTICE "Fruit=%d\n", banana);
> It would now be:
> printk(KERN_NOTICE, "Fruit=%d\n", banana);
>
> Change the header from:
> #define KERN_NOTICE "<5>"
> to:
> #define KERN_NOTICE 5
>
> Then you can change the printk
> Then what is return value if my module tries to 'get' a module which does not
> exist (and is a module, not in-built)? . Is it '1' ?
> Or am I imagining a hypothetical scenario which would not exist?
That is not supposed to happen. After a module got unloaded there shouldn't
be any objects
On Wed, 26 Sep 2007 15:27:10 +0200,
Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote:
> > Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong
> > somewhere...
>
> I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and
> CONFIG_DEBUG_KOBJECT, following Cornelia
* Andr? Goddard Rosa <[EMAIL PROTECTED]> wrote:
> Hi, Ingo , Mike and Peter!
>
> Just passing around to say that 2.6.23-rc8-sched-dev is the best
> scheduler ever to me. It's great for 3D games.
cool! :-)
> http://www.openarena.ws/?files is really great with this
> scheduler. I
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote:
> Adrian Bunk wrote:
>> You claimed:
>>
>> <-- snip -->
>>
>> Look, when chroot was being designed, I think they intended that even root
>> should be unable to get out. They went so far as to say that dot-dot
>> wouldn't let you
Hi.
On Thursday 27 September 2007 16:33:54 Huang, Ying wrote:
> On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote:
> > But, in my ignorance, I'm not sure even fixing the ext3 bug will
> > guarantee you consistent metadata so that you can handle a
> > swap/hibernate file. You can do a
Adrian Bunk wrote:
You claimed:
<-- snip -->
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
<-- snip -->
You were clearly saying that whom you call
On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote:
> But, in my ignorance, I'm not sure even fixing the ext3 bug will
> guarantee you consistent metadata so that you can handle a
> swap/hibernate file. You can do a sync(), but how do you make that
> not race against running processes
RJW> This message lists some known regressions from 2.6.22 for which there are
RJW> no fixes in the mainline that I know of. If any of them have been fixed
RJW> already, please let me know.
RJW>
RJW> If you know of any other unresolved regressions from 2.6.22, please let me
know
RJW> either and
Thanks for you reply, please see inline.
Heiko Carstens de.ibm.com> writes:
>
[snip]
> > static inline int try_module_get(struct module *module){
> > int ret = 1; <--- error case when !module
> > if (module) {
> > unsigned int cpu = get_cpu();
> > if
Torsten Kaiser wrote:
On 9/27/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
On Thu, 27 Sep 2007 05:19:06 -, Shreyansh Jain said:
> -
> static inline int try_module_get(struct module *module){
> int ret = 1; <--- error case when !module
> if (module) {
> unsigned int cpu = get_cpu();
> if (likely(module_is_live(module)))
>
On 9/27/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Tejun Heo wrote:
> > Torsten Kaiser wrote:
> >> Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
> >> following change looked the most suspicions to me:
> >>
> I was going through try_module_get function in include/linux/module.h file
> (2.6.22 stock kernel) - which is like:
>
> -
> static inline int try_module_get(struct module *module){
> int ret = 1; <--- error case when !module
> if (module) {
> unsigned int cpu = get_cpu();
>
Hi Tejun,
On Thu, 27 Sep 2007 09:55:22 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Paul Rolland wrote:
> > Hi David,
> >
> > On Mon, 24 Sep 2007 23:56:59 +0930
> > David Newall <[EMAIL PROTECTED]> wrote:
> >
> >> Paul Rolland "(???) wrote:
> >>> Hell, IRQ 23 is shared between libata and
Hi, Peter,
On Wed, 2007-09-19 at 09:04 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > Known Issues:
> >
> > 1. Where is safe to place the linked list of setup_data?
> > Because the length of the linked list of setup_data is variable, it
> > can not be copied into BSS segment of
Hi, Peter,
On Wed, 2007-09-19 at 09:04 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
Known Issues:
1. Where is safe to place the linked list of setup_data?
Because the length of the linked list of setup_data is variable, it
can not be copied into BSS segment of kernel as that of
Hi Tejun,
On Thu, 27 Sep 2007 09:55:22 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Paul Rolland wrote:
Hi David,
On Mon, 24 Sep 2007 23:56:59 +0930
David Newall [EMAIL PROTECTED] wrote:
Paul Rolland (???) wrote:
Hell, IRQ 23 is shared between libata and my modem !!!
I was going through try_module_get function in include/linux/module.h file
(2.6.22 stock kernel) - which is like:
-
static inline int try_module_get(struct module *module){
int ret = 1; --- error case when !module
if (module) {
unsigned int cpu = get_cpu();
On 9/27/07, Tejun Heo [EMAIL PROTECTED] wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
On Thu, 27 Sep 2007 05:19:06 -, Shreyansh Jain said:
-
static inline int try_module_get(struct module *module){
int ret = 1; --- error case when !module
if (module) {
unsigned int cpu = get_cpu();
if (likely(module_is_live(module)))
Torsten Kaiser wrote:
On 9/27/07, Tejun Heo [EMAIL PROTECTED] wrote:
Tejun Heo wrote:
Torsten Kaiser wrote:
Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the
following change looked the most suspicions to me:
Thanks for you reply, please see inline.
Heiko Carstens heiko.carstens at de.ibm.com writes:
[snip]
static inline int try_module_get(struct module *module){
int ret = 1; --- error case when !module
if (module) {
unsigned int cpu = get_cpu();
if
RJW This message lists some known regressions from 2.6.22 for which there are
RJW no fixes in the mainline that I know of. If any of them have been fixed
RJW already, please let me know.
RJW
RJW If you know of any other unresolved regressions from 2.6.22, please let me
know
RJW either and I'll
On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote:
But, in my ignorance, I'm not sure even fixing the ext3 bug will
guarantee you consistent metadata so that you can handle a
swap/hibernate file. You can do a sync(), but how do you make that
not race against running processes without
Adrian Bunk wrote:
You claimed:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
-- snip --
You were clearly saying that whom you call they
Hi.
On Thursday 27 September 2007 16:33:54 Huang, Ying wrote:
On Wed, 2007-09-26 at 16:30 -0400, Joseph Fannin wrote:
But, in my ignorance, I'm not sure even fixing the ext3 bug will
guarantee you consistent metadata so that you can handle a
swap/hibernate file. You can do a sync(),
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote:
Adrian Bunk wrote:
You claimed:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
* Andr? Goddard Rosa [EMAIL PROTECTED] wrote:
Hi, Ingo , Mike and Peter!
Just passing around to say that 2.6.23-rc8-sched-dev is the best
scheduler ever to me. It's great for 3D games.
cool! :-)
http://www.openarena.ws/?files is really great with this
scheduler. I played a
On Wed, 26 Sep 2007 15:27:10 +0200,
Pierre-Yves Paulus [EMAIL PROTECTED] wrote:
Please use CONFIG_SLUB and turn on SLUB debugging. Something is very wrong
somewhere...
I did so, on 2.6.23-rc8. I also did include CONFIG_DEBUG_DRIVER and
CONFIG_DEBUG_KOBJECT, following Cornelia Huck's
Then what is return value if my module tries to 'get' a module which does not
exist (and is a module, not in-built)? . Is it '1' ?
Or am I imagining a hypothetical scenario which would not exist?
That is not supposed to happen. After a module got unloaded there shouldn't
be any objects around
On Thursday 20 September 2007, you wrote:
So instead of:
printk(KERN_NOTICE Fruit=%d\n, banana);
It would now be:
printk(KERN_NOTICE, Fruit=%d\n, banana);
Change the header from:
#define KERN_NOTICE 5
to:
#define KERN_NOTICE 5
Then you can change the printk guts to do
Hi Jens,
here are a few more patches from my set that makes various changes to bio
submission and handling.
These change the -bi_end_io prototype so that
1/ no 'size' is passed
2/ there is no return value.
The 'size' is not really of interest to any bi_end_io handler in existance.
It
The entire function of flush_dry_bio_endio is to undo the effects
of bio_endio (when called on a barrier request). So remove the
function and the call to bio_endio.
This allows us to remove bi_size from struct request_queue.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
Currently bi_end_io can be called multiple times as sub-requests
complete. However no -bi_end_io function wants to know about that.
So only call when the bio is complete.
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./fs/bio.c |4 +++-
1 file changed, 3 insertions(+), 1
The only caller of bio_endio that does not pass the full bi_size
is end_that_request_first. Also, no -bi_end_io method is really
interested in bi_size being decremented.
So move the decrement and related code into ll_rw_blk and merge it
with order_bio_endio to form req_bio_endio which does
As bi_end_io is only called once when the reqeust is complete,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Signed-off-by: Neil
Greg KH wrote:
On Wed, Sep 26, 2007 at 11:40:58PM +0200, Brice Goglin wrote:
Greg KH wrote:
Here's a summary of the current state of the Linux PCI subsystem, as of
2.6.23-rc8.
If the information in here is incorrect, or anyone knows of any
outstanding issues not listed here, please let me
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall [EMAIL PROTECTED] wrote:
For sure, a root user can get out of a chroot a million different
ways. Young Alan said as much at the beginning of this
conversation, and I have always agreed. I don't hope to secure Linux
within chroot, simply to
It looks like hidraw_connect() is leaking memory in case of failure.
Also it should return -ENOMEM when kzalloc fails.
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/hid/hidraw.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
---
Stephen Hemminger [EMAIL PROTECTED] 26.09.07 19:12
On Wed, 26 Sep 2007 17:08:19 +0100
Jan Beulich [EMAIL PROTECTED] wrote:
Stephen Hemminger [EMAIL PROTECTED] 26.09.07 17:37
On Wed, 26 Sep 2007 08:53:27 +0100
Jan Beulich [EMAIL PROTECTED] wrote:
Otherwise 'modprobe -r' on a module
Now snd_register_device_for_dev() can oops when device_create() returns
ERR_PTR(err).
Scenario:
preg-dev = device_create(...); /* fails */
if (preg-dev) /* contains ERR_PTR(err) */
dev_set_drvdata(preg-dev, private_data);
and dev_set_drvdata() looks like this:
static inline void
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
humm... I think, it'd be safer to have something like the following
change in place.
The thing is that __pick_next_entity() must never be called when
first_fair(cfs_rq) == NULL. It wouldn't be a problem, should
'run_node' be the very first
Hello Sam,
Henry Nestler wrote:
Sam Ravnborg wrote:
What macro should set for linker parameters of foo.o ? I'm not shure.
Have you read:
Documentation/kbuild/makfilefiles.txt?
[...]
If your example requires the LDFALGS_$@ I wil introduce it - for now
it has not been required (except for
H. Peter Anvin wrote:
Balbir Singh wrote:
Andreas Schwab wrote:
Maxim Uvarov [EMAIL PROTECTED] writes:
diff --git a/Documentation/accounting/getdelays.c
b/Documentation/accounting/getdelays.c
index cbee3a2..73924df 100644
--- a/Documentation/accounting/getdelays.c
+++
Hi Henry.
Snipped a very detaild an good example...
Thanks for your comprehensive feedback on this topic.
Idea for future:
An 'APPEND_LDFLAGS' would be nice to append flags behind the last .o
object. Than can be close the group with --end-group.
Exactly linker call would be with grouping
[EMAIL PROTECTED] wrote:
Serge E. Hallyn [EMAIL PROTECTED] wrote:
| Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
| Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
| The option is called NAMESPACES. It can be selectable only
| if EMBEDDED is chosen (this was Eric's requisition). When
|
Andrew Morton wrote:
On Wed, 26 Sep 2007 19:08:18 +0200
Guillaume Chazarain [EMAIL PROTECTED] wrote:
Align with the opening parenthesis.
Changelog since V1 (http://lkml.org/lkml/2007/9/21/527):
- renamed fill_threadgroup() and add_tsk() to respectively
fill_threadgroup_stats() and
Michael Kerrisk [EMAIL PROTECTED] wrote, on 26 Sep 2007:
.TH TIMERFD_CREATE 2 2007-09-26 Linux Linux Programmer's Manual
.SH NAME
timerfd_create, timerfd_settime, timer_gettime \-
s/timer_/timerfd_/
timers that notify via file descriptors
.SH SYNOPSIS
.\ FIXME . This header file may well
* Antoine Martin [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
These are pure cpu scheduling tests, not doing any I/O this time. All
these tests are still pathological in the sense that they are only
meant to show differences between schedulers rather than try
Le Wed, 26 Sep 2007 13:01:44 -0700,
Andrew Morton [EMAIL PROTECTED] a écrit :
Also, I don't think we're seeing enough review and test from people on
these patch series - I don't have time to do it all. (Well, apparently I
do, but I don't think it's a good situation).
I don't object to your
Let me guess... this is a T61 or X61 ?
There's a problem with these that we don't fully understand yet, we're
getting those stale interrupts all over the range.
I wonder if it could be a bug with the ICH8 chipset...
If yours is one of these, it's being dealt with (or attempted to deal
with) at
Hello,
HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI
devices in the expected order.
(John, can you please confirm and ACK this?)
Signed-off-by: Michal Schmidt [EMAIL PROTECTED]
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index ebc6f3c..8737c53
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
- The scheduler devel tree has been restored
- The driver tree is presently busted, so I reverted it to the 2..23-rc8-mm1
version.
- It's now a nearly-32MB diff.
Boilerplate:
- See the `hot-fixes'
I cross compile arm and mips kernels from the same kernel tree. When
I build a kernel the first time with a fresh kernel tree, the
include/asm symlink is set properly. However, when I compile for a
different $ARCH, the include/asm is not changed and the build fails.
Would it be possible for the
On 26-09-2007 15:31, Ingo Molnar wrote:
* David Schwartz [EMAIL PROTECTED] wrote:
I think the real fix would be for iperf to use blocking network IO
though, or maybe to use a POSIX mutex or POSIX semaphores.
So it's definitely not a bug in the kernel, only in iperf?
Martin:
Actually, in
On Thu, 27 Sep 2007, Mariusz Kozlowski wrote:
It looks like hidraw_connect() is leaking memory in case of failure.
Also it should return -ENOMEM when kzalloc fails.
Mariusz,
good catch, will apply to me tree.
Thanks,
--
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list: send the line
Sorry, my mistake, the link should be
http://lkml.org/lkml/2007/7/25/268
memtest was running for one week with no results, i also tried the ram
from another box.
I replaced all SATA kables half a year ago with no result :/
A friend told me he had problems with a VIA Board when using the
hardware
* Jarek Poplawski [EMAIL PROTECTED] wrote:
the (small) patch below fixes the iperf locking bug and removes the
yield() use. There are numerous immediate benefits of this patch:
...
sched_yield() is almost always the symptom of broken locking or other
bug. In that sense CFS does the
301 - 400 of 714 matches
Mail list logo
