n 1/11/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: Ohad Ben-Cohen <[EMAIL PROTECTED]>
> Date: Mon, 7 Jan 2008 18:22:48 +0200 (IST)
>
> > In the (rare) event of simultaneous mutual wake up requests,
> > do send the chip an explicit wake-up ack. This is required
> > for Texas Instruments's
> So I looked at the code - it seems you build a full extent of the blocks
> in the file, filling holes as you go along. I initally did that as well,
> but that is to slow to be usable in real life.
>
> You also don't support sparse files, falling back to normal fs
> read/write paths. Supporting
On Thu, 2008-01-10 at 09:43 +0200, Maxim Levitsky wrote:
> On Thursday, 10 January 2008 00:21:46 Yi Yang wrote:
> > Subject: ACPI: convert procfs to sysfs for /proc/acpi/wakeup
> > From: Yi Yang <[EMAIL PROTECTED]>
> >
> > /proc/acpi/wakeup is deprecated but it has to exist because
> > we haven't
>2. I noticed the _PAGE_PCD|_PAGE_PWT combination being used a lot, so
>I created _PAGE_NOCACHE to wrap them up. asm-x86/fb.h uses plain
>_PAGE_PCD; should it be _PAGE_NOCACHE too?
Setting PCD but not PWT (or the other way around) is yielding not fully
defined behavior (model specific) as per
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int
> *valid_agp)
> return 0;
> }
>
> +void __init early_gart_iommu_disable(void)
> +{
> + /*
On Fri, 11 Jan 2008 10:33:16 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> > > +struct device *class_find_device(struct class *class, void *data,
> > > +int (*match)(struct device *, void *))
> > > +{
> > > + struct device *dev;
> > > +
> > > + if
Greg,
I'm getting the following message from the kernel on an embedded ppc32
system:
PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0
The HW setup is a PCIe host controller and an e1000 NIC card. It
appears that pci_bus_assign_resources() is trying to call
On Wed, 09 Jan 2008 14:53:58 -0500
Bill Gribble <[EMAIL PROTECTED]> wrote:
>
> Any other sage advice? I feel like the device is really close to
> working, but I just can't get it there!
>
Since you're having problems with the very first part, I'm not sure I'd agree
with your assessment. ;)
> Hi Andi,
> I grepped and tried to do what you suggested.
> The first file that git grep reported was:
> arch/arm/common/rtctime.c:static const struct file_operations rtc_fops = {
>
> So I cooked up the following patch (probably mangled, just to give you
> a rough idea of what I did):
> diff
On Jan 11, 2008 12:14 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > --- a/arch/x86/kernel/aperture_64.c
> > +++ b/arch/x86/kernel/aperture_64.c
> > @@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int
> > *valid_agp)
> >
.. as all consumers of it don't require it to be modifiable.
Unfortunately, due to the two-level constifications, this required
touching quite many files, not all of which I am able to test - please
bare with eventual mistakes or oversights.
The patch doesn't change all instances where 'const'
In the EDAC code, I took the opportunity to replace the explicit cast
initializer with a safer, cast-less mechanism (as used elsewhere),
which makes this patch somewhat larger than it would have been
otherwise.
Again, the patch doesn't change all instances where 'const' could have
been added as a
.. as again all consumers of it don't require it to be modifiable.
As before, the patch doesn't change all instances where 'const' could
have been added as a result of the base structure changes, only where
either the change has a real effect (the module loader doesn't enforce
read-only section
On Fri, 11 Jan 2008 14:17:01 +0800
"Bryan Wu" <[EMAIL PROTECTED]> wrote:
> We were told this is an hardware design issue, so please help us to
> workaround it in software side with Mike's patch.
I'm afraid that's insufficient motivation for this change. All documentation
and real world tests
On 01/11/2008 09:29 AM, Kumar Gala wrote:
Greg,
I'm getting the following message from the kernel on an embedded ppc32
system:
PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0
The HW setup is a PCIe host controller and an e1000 NIC card. It
appears that
I recently upgraded from an amd 64bit system to an intel one and changed my
kernekl accordingly. Everything's great except this:
root 6 0.0 0.0 00 ?D< 17:11 0:00 [migration/1]
root 7 0.0 0.0 00 ?D< 17:11 0:00 [ksoftirqd/1]
root
On 01/11/2008 05:10 AM, Daniel Walker wrote:
A little feature addition to allow checkpatch.pl to check patches piped
into it, in addition to specific file arguments.
You can still add - as an argument to check stdin. In which way is this better?
regards,
--
Jiri Slaby
Faculty of Informatics,
On Jan 11, 2008 4:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Jan 2008 10:33:16 +0800,
> "Dave Young" <[EMAIL PROTECTED]> wrote:
>
>
> > > > +struct device *class_find_device(struct class *class, void *data,
> > > > +int (*match)(struct device *,
Since __cpuinitdata/__devinitdata don't allow const to be specified with
them (otherwise .init.data sections with and without the writeable attribute
will be generated by the compiler), and since __devinitdata except for
embedded systems evaluates to unconditionally and
__cpuinitdata at least in
The patch doesn't change all instances where 'const' could have been
added as a result of the base structure changes, only where the change
has a real effect (the module loader doesn't enforce read-only section
attributes at present, so only built-in files make a real difference).
Signed-off-by:
The patch probably doesn't change all instances where 'const' could
have been added as a result of the base structure changes, only where
the change has a real effect (the module loader doesn't enforce
read-only section attributes at present, so only built-in files make a
real difference).
Hi Jon,
On Wed, 19 Dec 2007 23:41:36 -0500, Jon Smirl wrote:
> Since copying i2c-mpc.c to maintain support for the ppc architecture seems to
> be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to
> support both the ppc and powerpc architecture. When ppc is deleted in six
>
The drivers picked just serve as examples (which I routinely build and
hence am able to easily verify), i.e. as before he patch doesn't change
all instances where 'const' could have been added as a result of the
base change, only where the change has a real effect (the module loader
doesn't
The patch probably doesn't change all instances where 'const' could
have been added as a result of the base structure changes, only where
the change has a real effect (the module loader doesn't enforce
read-only section attributes at present, so only built-in files make a
real difference).
Oleg Nesterov wrote:
> On 01/10, Petr Tesarik wrote:
>> I can actually see a bug which may be related:
>>
>> 1. a process creates a thread (or more threads)
>> 2. I attach/detach to that thread with strace several times
>> (each time pressing CTRL-C to quit strace)
>> 3. the whole
Hello.
Indan Zupancic wrote:
> > It seems to me that the alternatives you are proposing include
> > modification of userland applications. But my assumption is
> > that "Don't require modification of userland applications".
>
> If you want a secure system it isn't that unreasonable to expect
>
> > I think that it would be much much better to place wake-up attributes under
> > corresponding PCI and PNP devices.
> > Probably it is even better to link this code to PCI code, so PCI drivers
> > will be aware of ACPI.
> I like this idea, maxim. :)
> And that's what we actually did about half
On Fri, Jan 11 2008, Chris Smowton wrote:
> Just a couple of quick questions if anyone can shed light regarding
> functions exported for modules relating to splice():
>
> * Is there a particular reason why the useful helper __splice_from_pipe
> is exported, but not the locking equivalent
On Thu, Jan 10 2008, David Dillow wrote:
>
> On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote:
> > David Dillow <[EMAIL PROTECTED]> wrote:
> >
> > > At the moment, I'm not sure how to track this farther, or how to fix it
> > > properly. Any advice would be appreciated.
> >
> > Just
On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
On 01/11/2008 09:29 AM, Kumar Gala wrote:
Greg,
I'm getting the following message from the kernel on an embedded
ppc32 system:
PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for
:00:00.0
The HW setup is a PCIe host controller
Rather than fixing the output directory in the generated Makefile,
determine it from the placement of Makefile. This allows moving
the build tree around or accessing it through different mount paths.
(The lastword definition is a compatibility one for make prior to 3.81;
newer make will simply
On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> > We were told this is an hardware design issue, so please help us to
> > workaround it in software side with Mike's patch.
>
> So it's far more probable that you've misdiagnosed your error
On 01/11/2008 10:07 AM, Kumar Gala wrote:
On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote:
On 01/11/2008 09:29 AM, Kumar Gala wrote:
Greg,
I'm getting the following message from the kernel on an embedded
ppc32 system:
PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0
This completely untested patch is intended to be a suggestion only:
Code inspection for an entirely different purpose made me stumble
across this, and I think that modifying the string table of an ELF
object is a bad idea, since there's nothing disallowing a linker to
merge strings inside the
On Mon, Jan 07 2008, Rusty Russell wrote:
> I realize that sg chaining is a ploy to make the rest of the kernel
> devs feel the pain of the SCSI subsystem. But this was a little
> unsubtle.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r b3aec596b841 include/linux/scatterlist.h
.. allowing it to be write-protected just as other read-only data
under CONFIG_DEBUG_RODATA.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/kernel/vmlinux_32.lds.S |7 ---
On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote:
> On 01/11/2008 05:10 AM, Daniel Walker wrote:
> > A little feature addition to allow checkpatch.pl to check patches piped
> > into it, in addition to specific file arguments.
>
> You can still add - as an argument to check stdin. In which way
On 01/11/2008 10:17 AM, Daniel Walker wrote:
On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote:
On 01/11/2008 05:10 AM, Daniel Walker wrote:
A little feature addition to allow checkpatch.pl to check patches piped
into it, in addition to specific file arguments.
You can still add - as an
Don't rely on kmalloc(PAGE_SIZE) returning PAGE_SIZE aligned memory
(Xen requires GDT *and* LDT to be page-aligned). Using the page
allocator interface also removes the (albeit small) slab allocator
overhead. The same change being done for 64-bits for consistency.
Further, the Xen hypercall
On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
> On 01/11/2008 10:17 AM, Daniel Walker wrote:
> > On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote:
> >> On 01/11/2008 05:10 AM, Daniel Walker wrote:
> >>> A little feature addition to allow checkpatch.pl to check patches piped
> >>> into
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> Thanks for reporting this. Guillaume, did you write this patch? We
> need to get it into 2.6.24-rc7 asap. Let me know if I should take care
> of that, or if it's already queued up elsewhere.
they are from the scheduler git tree (except the first debug
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > Thanks for reporting this. Guillaume, did you write this patch? We
> > need to get it into 2.6.24-rc7 asap. Let me know if I should take care
> > of that, or if it's already queued up elsewhere.
>
> they
Hi.
Jens Axboe wrote:
> On Thu, Jan 10 2008, David Dillow wrote:
>> On Thu, 2008-01-10 at 23:44 +0100, Guillaume Chazarain wrote:
>>> David Dillow <[EMAIL PROTECTED]> wrote:
>>>
At the moment, I'm not sure how to track this farther, or how to fix it
properly. Any advice would be
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Thanks for reporting this. Guillaume, did you write this patch? We
> > need to get it into 2.6.24-rc7 asap. Let me know if I should take
> > care of that, or if it's already queued up elsewhere.
>
> they are from the scheduler git tree (except the
On Fri, 2008-01-11 at 10:23 +0100, Bernd Petrovitsch wrote:
> On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
> > On 01/11/2008 10:17 AM, Daniel Walker wrote:
> > > On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote:
> > >> On 01/11/2008 05:10 AM, Daniel Walker wrote:
> > >>> A little
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > With those patches, CONFIG_NO_HZ works just fine.
>
> could you please try the two patches below, do they fix the problem as
> well? They got a ton of testing in x86.git in the past ~2 months and
> we could perhaps still push them into v2.6.24.
On Jan 11, 2008 7:16 AM, James Bottomley
<[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> > First of all let me wish a happy new year.
> > I come back from the vacations and i compiled the initio driver with
> >
> > #define DEBUG_INTERRUPT 1
> >
On 01/11/2008 10:22 AM, Jan Beulich wrote:
Don't rely on kmalloc(PAGE_SIZE) returning PAGE_SIZE aligned memory
(Xen requires GDT *and* LDT to be page-aligned). Using the page
allocator interface also removes the (albeit small) slab allocator
overhead. The same change being done for 64-bits for
* David Dillow <[EMAIL PROTECTED]> wrote:
> Ingo, Thomas added as I think this is related to
> sched.c:__update_rq_clock()'s checking for forward time warps.
yep, we've got some fixes in this area. Do blktrace timestamps work fine
in v2.6.23, with NOHZ?
Ingo
--
To unsubscribe from
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Thanks for reporting this. Guillaume, did you write this patch? We
> > > need to get it into 2.6.24-rc7 asap. Let me know if I should take
> > > care of that, or if it's already queued up elsewhere.
>
Heip!
I did something like "dd if=/dev/sda1 bs=256M of=dump" and the whole system
hanged after a while.
Netconsole captured following soft lockup:
===cut
BUG: soft lockup - CPU#3 stuck for 11s! [metalog:4767]
CPU 3:
Modules linked in: fglrx(P) cinergyT2
Pid: 4767, comm: metalog Tainted: P
On Jan 11, 2008 6:05 PM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Jan 2008 04:47:44 -0500
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
>
> > Cliff should be able to enumerate the cards he has tested and the
> > issues he's run into. i'll see if i cant get more in depth
> >
David Dillow <[EMAIL PROTECTED]> wrote:
> Patched kernel, nohz=off:
> .clock_underflows : 213887
A little bit of warning about these patches, they are WIP, that's why I
did not send them earlier. It regress nohz=off.
A bit of context: these patches aim at making sure cpu_clock()
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Correction: it was not a high res time source, it was "the scheduler's
> per-cpu, non-exported, non-coherent, warps-and-jumps-like-hell high-res
> timesource that was intentionally called the _sched_ clock" ;-)
I think the warts of cpu_clock() are
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> David Dillow <[EMAIL PROTECTED]> wrote:
>
> > Patched kernel, nohz=off:
> > .clock_underflows : 213887
>
> A little bit of warning about these patches, they are WIP, that's why
> I did not send them earlier. It regress
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> > Correction: it was not a high res time source, it was "the
> > scheduler's per-cpu, non-exported, non-coherent,
> > warps-and-jumps-like-hell high-res timesource that was intentionally
> > called the _sched_ clock" ;-)
>
> I think the
Sorry about this one, mea culpa. This should go right after
the "x86 i387 user_regset" patch, or be rolled into it.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_signal.c |5 ++---
arch/x86/kernel/ptrace.c|1 -
include/asm-x86/fpu32.h | 10 --
Nikanth Karthikesan <[EMAIL PROTECTED]> writes:
>
> Also the globals random_read_wakeup_thresh and
> random_write_wakeup_thresh are not at all protected by any locks! Why
> locks are not needed for these?
Reading variables sizeof <= native word size (32bit or 64bit depending
on architecture) is
Daniel Walker wrote:
> On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
>> >> On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
>> >>> git show 9914cad54c79d0b89b1f066c0894f00e1344131c
>> >> | ./scripts/checkpatch.pl -
>> If somebody is hacking kernel, I think he should know the - trick
On Fri, Jan 11, 2008 at 12:04:14PM +0100, Roel Kluin wrote:
> Paul Mundt wrote:
> > Take a look at how CONFIG_PCMCIA_DEBUG is handled.
>
> In drivers/pcmcia/Makefile, when CONFIG_PCMCIA_DEBUG=y, it gives
> EXTRA_CFLAGS += -DDEBUG
> which causes the definition of DEBUG as a macro, with definition
On Fri, 2008-01-11 at 12:12 +0100, Andi Kleen wrote:
> Nikanth Karthikesan <[EMAIL PROTECTED]> writes:
> >
> > Also the globals random_read_wakeup_thresh and
> > random_write_wakeup_thresh are not at all protected by any locks! Why
> > locks are not needed for these?
>
> Reading variables sizeof
CaT wrote:
> Not sure what other info to provide
Is the bug present in 2.6.24-rc7?
--
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 majordomo info at
> It is perfectly possible to construct
> fully written cachelines, without reading the cacheline first. MOVDQ is
If you write a aligned full 64 (or 128) byte area and even then you can
have occassional reads which can be either painfully slow or even incorrect.
> but that's totally besides
> Write-Combining can be very useful for devices that are behind a slow or
> a high-latency transport, such as PCI, and which are mapped UnCached
That is what I wrote! If you meant the same we must have been
spectacularly miscommunicating.
-Andi
--
To unsubscribe from this list: send the line
A query on locks used to protect entropy_store
struct entropy_store {
/* mostly-read data: */
struct poolinfo *poolinfo;
__u32 *pool;
const char *name;
int limit;
struct entropy_store *pull;
/* read-write data: */
spinlock_t lock
On Fre, 2008-01-11 at 01:47 -0800, Daniel Walker wrote:
> On Fri, 2008-01-11 at 10:41 +0100, Jiri Slaby wrote:
> > On 01/11/2008 10:36 AM, Daniel Walker wrote:
> > > On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
> > >> If somebody is hacking kernel, I think he should know the - trick used
Paul Mundt wrote:
> On Fri, Jan 11, 2008 at 04:09:45AM +0100, Peter Stuge wrote:
>> On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
>>> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
>>> +#define DEBUG(x, args...) printk("%s: ", __func__, x, ##args)
>> Can this really
* David Dillow <[EMAIL PROTECTED]> wrote:
> > Just out of curiosity, could you try the appended cumulative patch
> > and report .clock_warps, .clock_overflows and .clock_underflows as
> > you did.
>
> With those patches, CONFIG_NO_HZ works just fine.
could you please try the two patches
On 01/11/2008 10:36 AM, Daniel Walker wrote:
On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
If somebody is hacking kernel, I think he should know the - trick used in many
programs, but do not consider this as a nack.
I'm hacking the kernel, and I didn't know the - trick .. So you have
On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
> On 01/11/2008 10:30 AM, Daniel Walker wrote:
> > On Fri, 2008-01-11 at 10:23 +0100, Bernd Petrovitsch wrote:
> >> On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
> >>> git show 9914cad54c79d0b89b1f066c0894f00e1344131c
> >> |
On 01/11/2008 10:30 AM, Daniel Walker wrote:
On Fri, 2008-01-11 at 10:23 +0100, Bernd Petrovitsch wrote:
On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
git show 9914cad54c79d0b89b1f066c0894f00e1344131c
| ./scripts/checkpatch.pl -
JftSoC:
git show
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> Just out of curiosity, could you try the appended cumulative patch
> >>> and report .clock_warps, .clock_overflows and .clock_underflows as
> >>> you did.
> >> With those patches, CONFIG_NO_HZ works just fine.
>
> Could these patches also
On Thu, Jan 10, 2008 at 11:06:16PM +0100, [EMAIL PROTECTED] wrote:
> Hi
>
> This patchset contains various UDF fs cleanups.
> It deprecates two patchsets I sent lately:
>
> http://lkml.org/lkml/2008/1/5/196 [PATCH 0/6] udf: improve code related to
> super_block v3
>
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> The regression is:
> 1)stoakley with 2 qual-core processors: 11%;
> 2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank David Miller for pointing me the netdev
On Fri, 11 Jan 2008 04:08:53 -0500
"Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > So it's far more probable that you've misdiagnosed your error than this
> > being the actual problem.
>
> the guys who design the silicon are
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > they are from the scheduler git tree (except the first debug patch),
> > but queued up for v2.6.25 at the moment.
>
> So this means that blktrace will be broken with CONFIG_NO_HZ for
> 2.6.24? That's clearly a regression.
64-bit CONFIG_NO_HZ is a
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > they are from the scheduler git tree (except the first debug patch),
> > > but queued up for v2.6.25 at the moment.
> >
> > So this means that blktrace will be broken with CONFIG_NO_HZ for
> > 2.6.24?
On Jan 11, 2008 4:35 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> > On Jan 11, 2008 3:40 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > > So it's far more probable that you've misdiagnosed your error than this
> > > being the actual problem.
> >
>
On Fri, 2008-01-11 at 10:41 +0100, Jiri Slaby wrote:
> On 01/11/2008 10:36 AM, Daniel Walker wrote:
> > On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
> >> If somebody is hacking kernel, I think he should know the - trick used in
> >> many
> >> programs, but do not consider this as a
On Thu, 10 Jan 2008, Parag Warudkar wrote:
> On Jan 9, 2008 6:56 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Can you apply the patch below + the debug patch which prints the timer
> > stats on softlockup and provide the output of this.
>
> Applied to today's git and running for 21
On Fri, 11 Jan 2008 04:47:44 -0500
"Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> Cliff should be able to enumerate the cards he has tested and the
> issues he's run into. i'll see if i cant get more in depth
> information from the hardware guys beyond the documentation on the sdh
> already
On Fre, 2008-01-11 at 01:30 -0800, Daniel Walker wrote:
> On Fri, 2008-01-11 at 10:23 +0100, Bernd Petrovitsch wrote:
> > On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
> > > On 01/11/2008 10:17 AM, Daniel Walker wrote:
> > > > On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote:
> > > >> On
>> --- linux-2.6.24-rc7/arch/x86/kernel/ldt_32.c2008-01-10
>> 16:53:54.0 +0100
>> +++ 2.6.24-rc7-x86-xen-ldt/arch/x86/kernel/ldt_32.c 2008-01-09
>> 13:59:50.0 +0100
>[...]
>> @@ -73,7 +72,7 @@ static int alloc_ldt(mm_context_t *pc, u
>> if
On Fri, Jan 11, 2008 at 10:45:30AM +0100, Roel Kluin wrote:
> Paul Mundt wrote:
> > On Fri, Jan 11, 2008 at 04:09:45AM +0100, Peter Stuge wrote:
> >> On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> >>> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> >>> +#define
(David, could you try the patch further below - does it fix bkltrace
timestamps too?)
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11 2008, Ingo Molnar wrote:
> >
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > > they are from the scheduler git tree (except the first debug
Bill Davidsen wrote:
> Andrea Righi wrote:
>> Allow to limit the bandwidth of I/O-intensive processes, like backup
>> tools running in background, large files copy, checksums on huge files,
>> etc.
>>
>> This kind of processes can noticeably impact the system responsiveness
>> for some time and
On Tue, Jan 01, 2008 at 03:48:09PM +0200, Adrian Bunk wrote:
Definately NAK for the MIPS segments. Some of the EXPERIMENTAL
dependencies should be removed but many options tagged with EXPERIMENTAL
are still dangerous.
Ralf
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Jan 08, 2008 at 06:44:00AM +0300, Dmitri Vorobiev wrote:
> I noticed that the commit f197465384bf7ef1af184c2ed1a4e268911a91e3
> (MIPS Tech: Get rid of volatile in core code) broke the software
> reset functionality for MIPS Malta boards in big-endian mode.
Thanks, applied.
Ralf
--
To
* Rik van Riel <[EMAIL PROTECTED]> [2008-01-08 15:59:39]:
> On large memory systems, the VM can spend way too much time scanning
> through pages that it cannot (or should not) evict from memory. Not
> only does it use up CPU time, but it also provokes lock contention
> and can leave large systems
On Thu, Jan 10, 2008 at 10:18:45PM +, Ralf Baechle wrote:
> On Tue, Jan 01, 2008 at 03:48:09PM +0200, Adrian Bunk wrote:
>
> Definately NAK for the MIPS segments. Some of the EXPERIMENTAL
> dependencies should be removed but many options tagged with EXPERIMENTAL
> are still dangerous.
>
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> Sorry about this one, mea culpa. This should go right after the "x86
> i387 user_regset" patch, or be rolled into it.
thanks, applied. Does this explain the crash/hang problems with 32-bit
apps on 64-bit kernels? What was the exact failure mode?
Paul Mundt wrote:
> On Fri, Jan 11, 2008 at 10:45:30AM +0100, Roel Kluin wrote:
>> Paul Mundt wrote:
>>> On Fri, Jan 11, 2008 at 04:09:45AM +0100, Peter Stuge wrote:
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
On Friday 11 January 2008, Trond Myklebust wrote:
>
> On Thu, 2008-01-10 at 21:24 -0500, Jeff Garzik wrote:
> > Trond Myklebust wrote:
> > > Hi,
> > >
> > > I'm getting the following Oops on boot with kernel 2.6.24-rc7-g88fb61e4.
> > >
> > > Starting udev: BUG: unable to handle kernel paging
Vince Fuller <[EMAIL PROTECTED]> writes:
> from Vince Fuller <[EMAIL PROTECTED]>
>
> This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
> (aka "class-E") address space as consistent with the Internet Draft
> draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait
On Fri, 11 Jan 2008 18:22:14 +0800
"Bryan Wu" <[EMAIL PROTECTED]> wrote:
>
> I guess it is for MMC/SD card insert detection. Is it related with the
> 4-bit MMC and 4-bit SD?
> Actually, there are some issues about the card insert detection on
> BF54x SDH. Following is some comments of our
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> I coded it, it's not all that bad, the output looks like:
>
> Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #17
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x6a/0x70
> [] backtrace_test_timer+0x23/0x25
On 01/11/2008 12:16 PM, Stefan Richter wrote:
Daniel Walker wrote:
On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote:
On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote:
git show 9914cad54c79d0b89b1f066c0894f00e1344131c
| ./scripts/checkpatch.pl -
If somebody is hacking kernel, I think
* Rik van Riel <[EMAIL PROTECTED]> [2008-01-08 15:59:39]:
> Changelog:
> - merge memcontroller split LRU code into the main split LRU patch,
> since it is not functionally different (it was split up only to help
> people who had seen the last version of the patch series review it)
Hi, Rik,
From: Ian Abbott <[EMAIL PROTECTED]>
If the fakephp driver is used to emulate removal of a PCI device by
writing text string "0" to the "power" sysfs attribute file, this causes
its parent directory and its contents (including the "power" file) to be
deleted before the write operation returns.
The random_ioctl is registered as an ioctl function but it does not
require BKL to be held when called. Changing it as an unlocked_ioctl
function.
Signed-off-by: Nikanth Karthikesan <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5fee056..2446e14 100644
1 - 100 of 796 matches
Mail list logo
