On Fri, 2008-02-22 at 11:22 +0800, eric miao wrote:
>
> I have a rough peek into the git tree on opensource.wolfsonmicro.com,
> find another PMIC framework, and here instead is a regulator framework,
> looks like a simplified or dedicated one. What is their relationship?
>
This is probably the
On Friday, 22 of February 2008, Ingo Molnar wrote:
>
> * Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
> > The s2ram command has a built-in whitelist used to set up video
> > rePOSTing. If you want to test, reboot and do
> >
> > echo mem >/sys/power/state
> >
> > without i915 being loaded. If
Hi.
make randconfig (v2.6.25-rc2 + unrelated patches) found this:
CC [M] sound/drivers/opl3/opl3_synth.o
sound/drivers/opl3/opl3_synth.c: In function ‘snd_opl3_find_patch’:
sound/drivers/opl3/opl3_synth.c:308: error: ‘OPL3_PATCH_HASH_SIZE’ undeclared
(first use in this function)
On Sat, Feb 23, 2008 at 12:55:03AM +1030, David Newall wrote:
> Bart Van Assche wrote:
> > There is a reason to limit line length: scientific research has shown
> > that readability of regular texts is optimal for a line length between
> > 55 and 65 characters.
>
> Putting aside the point that
On Fri, 22 Feb 2008 07:43:08 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 22 Feb 2008, Sam Ravnborg wrote:
> >
> > This is a regression. Can you please revert this commit.
>
> Not really. The thing is, CONFIG_CC_STACKPROTECTOR has never done
> anything at all, now it
On Friday, 22 of February 2008, Soeren Sonnenburg wrote:
> On Fri, 2008-02-22 at 00:06 +0100, Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Soeren Sonnenburg wrote:
> > > On Thu, 2008-02-21 at 01:31 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday, 20 of February 2008, Soeren
match_strcpy() is a somewhat creepy function: the caller needs to make
sure that the destination buffer is big enough, and when he screws up
or forgets, match_strcpy() happily overruns the buffer.
There's exactly one customer: v9fs_parse_options(). I believe it
currently can't overflow its
Andi Kleen wrote:
> On Fri, Feb 22, 2008 at 05:44:47PM +0530, Balbir Singh wrote:
>> My concern with all the points you mentioned is that this solution might
>> need to
>> change again,
>
> No why would it need to change again?
>
>> depending on the factors you've mentioned. vmalloc() is good
Hi Ivo,
On 18/02/2008, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> Hi,
>
[...]
> Above traces should be enough, but to determine where rt2x00 broke
> down approximatly I need to have a few test result on specific moments.
> Could you test the kernel with the following versions:
>
> rt2x00
On Fri, 22 Feb 2008, Sam Ravnborg wrote:
>
> This is a regression. Can you please revert this commit.
Not really. The thing is, CONFIG_CC_STACKPROTECTOR has never done anything
at all, now it does, and it shows that it never worked.
So the commit that made it do something shouldn't be
On Fri, Feb 22, 2008 at 06:45:32PM +0900, Kohei KaiGai wrote:
> I believe it is correct assumption that long type and pointers have
> same width in the linux kernel. Please tell me, if it is wrong.
That is correct, it is one of the assumptions that is safe to make. But
you should fix the
Currently, c_idle is declared in the stack, and thus, have no static address.
Peter Zijlstra points out this simple solution, in which c_idle.work
is initializated separatedly. Note that the INIT_WORK macro has a static
declaration of a key inside.
Signed-off-by: Glauber Costa <[EMAIL
On Sat, 2008-02-23 at 00:55 +1030, David Newall wrote:
> Bart Van Assche wrote:
> > There is a reason to limit line length: scientific research has shown
> > that readability of regular texts is optimal for a line length between
> > 55 and 65 characters.
>
> Putting aside the point that we're
> At some point checkpatch.pl would need to be updated to know about this
> exception too, that would be the next step.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Ian Campbell schrieb:
> On Fri, 2008-02-22 at 12:00 +0100, Arnd Hannemann wrote:
>> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
>> accordingly.
>
> Really? Xen guests should work on non-PAE if you have a non-PAE
> hypervisor (which most distros don't ship but which
- add locking to open/close/hangup and ioctl (tiocm)
- add pci hot-un-plug support (hangup on board remove, wait for openers)
- cleanup block_till_ready
- move close code common to close/hangup into separate function to be
able to call it from open when hangup occurs while block_till_ready
- let
It allows to simplify the code, especially MoxaPortSetBaud.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 65 +++
1 files changed, 19 insertions(+), 46 deletions(-)
diff
Cleanup of
- whitespace
- macros
- useless casts
- return (sth); -> return sth;
- types
- superfluous parenthesis and braces
- init tmp directly in moxa_get_serial_info
- commented defunct code
- commented prototypes
- MOXA/moxa printk case
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by:
- moxa_flush_chars -- no code; ldics handle this well
- moxa_put_char -- only wrapper to moxa_write (same code), tty does this
the same way if tty->driver->put_char is NULL
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c |
Drop a message to dmesg about card being ready.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index
- del timer after we are sure it won't be fired again
- make timer scheduling atomic
- don't reschedule timer when all cards have gone
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 26 +++---
1 files
- merge 2 timers into one -- one can handle the emptywait as good as the other
- merge 2 separated poll functions into one, this allows handle the actions
directly and simplifies the code
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
- schedule timer even after some card is installed, not after insmod
- cleanup timer functions
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 62 +-
1 files changed, 21
- allow stats only for sys_admin
- move TCSBRK* processing to .break_ctl tty op
- let TIOCGSOFTCAR and TIOCSSOFTCAR be processed by ldisc
- remove MOXA_GET_MAJOR, MOXA_GET_CUMAJOR
- fix jiffies subtraction by time_after
- move moxa ioctl numbers into the header; still not exported to userspace,
- cleanup types
- use tty_prepare_flip_string and io memcpys
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 124 --
drivers/char/moxa.h |2 +-
2 files changed, 51
The only relevant sign of port being ready is its board->ready since now.
Remove all other flags for this purpose which are set almost on the same
place. Move ports inside the board to be sure that nobody will grab
reference to the port without being sure that it exists.
Signed-off-by: Jiri Slaby
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index ae5433c..c440ec5 100644
--- a/drivers/char/moxa.c
We don't need to hold a reference to port index. In most cases we need
port structure anyway and index is available in port->tty->index.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 354
Substitute ioctl load firmware interface by kernel firmware api.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 1219 +--
drivers/char/moxa.h | 296 +
2 files
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 188 +++
1 files changed, 69 insertions(+), 119 deletions(-)
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index
according to ioctl_list, both have int * as a param, not ulong *.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/moxa.c
- request region before remapping pci io space
- use ioremap, iounmap istead of iomap interface, because we use
readX/writeX for accessing this space because of isa support
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c |
Make the code more readable, remap the base address directly. Describe
module parameters.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Tested-by: Oyvind Aabling <[EMAIL PROTECTED]>
---
drivers/char/moxa.c | 64 ++
1 files changed, 33
Static ISA field is empty and probably will never be filled in, remove it.
The driver still supports ISA cards passed through module parameter.
This actually fixes one bug inside the initialization of module-param passed
cards initialization.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
On 02/22, Pavel Emelyanov wrote:
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1291,10 +1291,33 @@ void sigqueue_free(struct sigqueue *q)
> __sigqueue_free(q);
> }
>
> +static int do_send_sigqueue(int sig, struct sigqueue *q, struct task_struct
> *t,
> + struct
David Brownell wrote:
>> David, do you think writing 0 bytes is a valid use of this API?
>
> Just a zero byte transfer ... no, though it depends what you mean
> by "valid". (I'm not sure I'd expect all controller drivers to
> reject such requests.) That has no effect on bits-on-the-wire,
> and
1) 2.4.36.1 hangs (probably during ext2_readdir())
2) 2.4.36.1 hangs during compilation of lighttpd-1.4.18.
It is probably during ext2_readdir() but I cannot confirm that..
Currently it only happens during compilation of lighttpd-1.4.18, always
in the same place.
Kernel 2.4.36 w/
Atsushi Nemoto wrote:
> If the driver could not handle zero length transfer, then the driver
> should reject it (just like unsupported transfer mode). Then the
> behavior will be 'assert chip select and wait some time' or 'rejected
> by the driver'.
This would be OK. It would not be hard to
Bart Van Assche wrote:
> There is a reason to limit line length: scientific research has shown
> that readability of regular texts is optimal for a line length between
> 55 and 65 characters.
Putting aside the point that we're talking code, not regular text, I've
heard that said before and I
The DMA implementation seems to be only there for a single PCI driver and the
driver does not use these interfaces. So remove it.
I don't have cris cross compilers so uncompiled/untested.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index:
No callers in tree, so get rid of them.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/include/linux/dma-mapping.h
===
--- linux.orig/include/linux/dma-mapping.h
+++ linux/include/linux/dma-mapping.h
@@ -128,22 +128,5
There are two users of dma_declare_coherent_memory in tree. Make them
dependent on the architectures who actually implement that instead of
falling at runtime. All cases I checked fail fataly (no recovery)
so these drivers will never work on these architectures.
I'm also a little puzzled why
Add option to enable -Wframe-larger-than= on gcc 4.4
gcc mainline (upcoming 4.4) added a new -Wframe-larger-than=...
option to warn at build time about too large stack frames. Add a config
option to enable this warning, since this very useful for the kernel.
I chose (somewhat arbitarily) 2048
Hi all,
On Tue, Jan 29, 2008 at 8:16 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 02:17:37AM -0600, Rob Landley wrote:
>
> > The 2.6.23 kernel built for mips with the attached .config works fine for
> me
> > under qemu (both big endian and little endian), but a 2.6.24
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
>
> Hello.
>
> The bcm43xx driver won't work any more, if the b44 Ethernet
> driver is enabled. This happens because the b44 driver
> needlessly enables the b43_pci_bridge code, which claims
> the same pci ids as the bcm43xx driver. The
On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <[EMAIL PROTECTED]> wrote:
> > > David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> Hi Sam
>
> On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > Option 1) is the worst of the three as that can cost
> > of many hours bug-hunting.
> > Option 3) may seem optimal but I do not like to
> > In any case, I would love to have __CHECK_ENDIAN__ enabled by default at
> > least on the wireless code (just caught another bug with it...)
>
> So build with make C=2 -D__CHECK_ENDIAN__ net/ieee80211/, etc. - it's not
> that such a script would be tricky...
It's not that I don't know how
Adds support for the PPS sources connected with the interrupt pin of a
parallel port.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
drivers/char/lp.c | 61 +++
drivers/pps/clients/Kconfig | 10 +++
include/linux/parport.h |
> Instead of a new recommendation (from now on we recommend something
> contrary to what we required up until yesterday --- let's go unwrap
> strings everywhere in the kernel now), how about simply saying that
> printk format strings are not subject to the 80 column rule?
I personally slightly
Each PPS source can be registered/deregistered into the system by
using special modules called "clients". They simply define the PPS
sources' attributes and implement the time signal registartion
mechanism.
This patch adds a special directory for such clients and adds a dummy
client that can be
This patch adds into the PPS's documentation directory a possible
implementation of the PPS API (RFC 2783) by using the LinuxPPS's char
devices.
This file is not just an example but it can be used into real
systems. :)
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
This patch adds the kernel side of the PPS support currently named
"LinuxPPS".
PPS means "pulse per second" and a PPS source is just a device which
provides a high precision signal each second so that an application
can use it to adjust system clock time.
Common use is the combination of the
Adds support for the PPS sources connected with the CD (Carrier
Detect) pin of a serial port.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
drivers/pps/clients/Kconfig | 10 ++
drivers/serial/8250.c|2 +
drivers/serial/serial_core.c | 71
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
Documentation/pps/Makefile |2 +-
Documentation/pps/ppsctl.c | 62
2 files changed, 63 insertions(+), 1 deletions(-)
create mode 100644 Documentation/pps/ppsctl.c
diff --git
Here some utilities and examples about the PPS API and the LinuxPPS
support.
* ppstest.c implements an useful testing program, while
* ppsfind tries to help the user into finding a specific PPS source by
using its name or path.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
This patch set adds the PPS support into Linux.
PPS means "pulse per second" and its API is specified by RFC 2783
(Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0).
The code has been tested with the NTPD program
(http://www.eecis.udel.edu/~mills/ntp/html/index.html) and several
On Fri, 2008-02-22 at 08:38 -0500, Mark Hounschell wrote:
> >> List of commits
> >>cpuisol: Make cpu isolation configrable and export isolated map
> >
> > cpu_isolated_map was a bad hack when it was introduced, I feel we should
> > deprecate it and fully integrate the functionality into
On Thursday 21 February 2008, David Howells wrote:
> David Howells <[EMAIL PROTECTED]> wrote:
> > > Have you got before/after benchmark results?
> >
> > See attached.
>
> Attached here are results using BTRFS (patched so that it'll work at all)
> rather than Ext3 on the client on the partition
Andi Kleen wrote:
> --- linux.orig/Documentation/CodingStyle
> +++ linux/Documentation/CodingStyle
> @@ -83,20 +83,32 @@ preferred limit.
> Statements longer than 80 columns will be broken into sensible chunks.
> Descendants are always substantially shorter than the parent and are placed
>
Gregory,
I guess we should have just read Documentation/memory-barriers.text
Here's the snippet:
Any atomic operation that modifies some state in memory and returns
information
about the state (old or new) implies an SMP-conditional general memory
barrier
(smp_mb()) on each side of the actual
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> * Gregory Haskins <[EMAIL PROTECTED]> wrote:
>
> > My assumption is that the xchg() (inside update_current()) acts as an
> > effective wmb(). If xchg() does not have this property, then this
> > code is broken and patch 6/14 should also add a:
>
>
On Fri, 2008-02-22 at 08:35 -0500, Steven Rostedt wrote:
> > My assumption is that the xchg() (inside update_current()) acts as an
> > effective wmb(). If xchg() does not have this property, then this code
> > is broken and patch 6/14 should also add a:
> >
> >
> > + smp_wmb();
>
Peter Zijlstra wrote:
> On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
>
>> As you suggested I'm sending CPU isolation patches for review/inclusion into
>> sched-devel tree. They are against 2.6.25-rc2.
>> You can also pull them from my GIT tree at
>>
On Fri, 2008-02-22 at 12:00 +0100, Arnd Hannemann wrote:
> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
> accordingly.
Really? Xen guests should work on non-PAE if you have a non-PAE
hypervisor (which most distros don't ship but which does exist).
Ian.
--
Ian
* Gregory Haskins <[EMAIL PROTECTED]> wrote:
> My assumption is that the xchg() (inside update_current()) acts as an
> effective wmb(). If xchg() does not have this property, then this
> code is broken and patch 6/14 should also add a:
xchg() is a strong implicit memory barrier, it implies
On Fri, 22 Feb 2008, Gregory Haskins wrote:
> Gregory Haskins wrote:
> > @@ -732,14 +741,15 @@ rt_spin_lock_slowlock(struct rt_mutex *lock)
> >
> > debug_rt_mutex_print_deadlock();
> >
> > - schedule_rt_mutex(lock);
> > + update_current(TASK_UNINTERRUPTIBLE,
Gregory Haskins wrote:
@@ -732,14 +741,15 @@ rt_spin_lock_slowlock(struct rt_mutex *lock)
debug_rt_mutex_print_deadlock();
- schedule_rt_mutex(lock);
+ update_current(TASK_UNINTERRUPTIBLE, _state);
I have a question for everyone out there about this particular part of
* James Morris <[EMAIL PROTECTED]> wrote:
> > Please send me your full .config and the gcc version you used for
> > building the failing kernel.
>
> config attached.
thanks, i'll try that.
> gcc version 4.1.2 20071124 (Red Hat 4.1.2-36)
ok, i have a slightly older one:
gcc version 4.1.2
RFC: Update coding standard to avoid split up printk format strings
Common occurrence: You see some error message in the kernel log you don't
understand, Standard way to handle this is to grep the kernel source code
for that error message and then look at the code and figure out what
is wrong
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > This needs to be CCed to netdev.
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
> I'll have to install a git repo to check, or maybe you can send me the diff
> to
> reverse vs. 2.6.25-rc2?
diff --git
[EMAIL PROTECTED] said:
> This needs to be CCed to netdev.
> Any chance that
> git revert 69cc64d8d92
> makes this report go away?
I'll have to install a git repo to check, or maybe you can send me the diff to
reverse vs. 2.6.25-rc2?
--
To unsubscribe from this list: send the line
Sam Ravnborg ravnborg.org> writes:
>
> In at least 99% of the cases this is OK and the check has found
> several bugs where things would not have worked due to different
> alignmnet between kernel and userland. Just think about the
> issues in a mixed 32/64 bit world.
>
I don't see how this
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > +static int smack_task_kernel_act_as(struct task_struct *p,
> > + struct task_security *sec, u32 secid)
> > +{
> > + return -ENOTSUPP;
> > +}
> ...
> > +static int smack_task_create_files_as(struct task_struct *p,
> >
* Matthew Garrett <[EMAIL PROTECTED]> wrote:
> The s2ram command has a built-in whitelist used to set up video
> rePOSTing. If you want to test, reboot and do
>
> echo mem >/sys/power/state
>
> without i915 being loaded. If you get a console back on resume then
> the platform is
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> * James Morris <[EMAIL PROTECTED]> wrote:
>
> > > works fine for you? That has all the current stackprotector fixes. I
> > > plan to send a separate pull request with just the stackprotector
> > > fixes to Linus, they are looking good in testing so
On Fri, Feb 22, 2008 at 05:44:47PM +0530, Balbir Singh wrote:
>
> My concern with all the points you mentioned is that this solution might need
> to
> change again,
No why would it need to change again?
> depending on the factors you've mentioned. vmalloc() is good and
> straightforward, but
Both function do the same thing after proper locking, but
with different sigpening structs, so move the common code
into a helper.
After this we have 4 places that look very similar:
send_sigqueue: calls do_send_sigqueue and signal_wakeup
send_group_sigqueue: calls do_send_sigqueue and
On Thu, Feb 21, 2008 at 09:59:24PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Thomas Gleixner wrote:
> > > That or we need to do the NOP/un-NOP part in the update_vsyscall code
> > > dependent on if the current clocksource supports vread, instead of on
> > > the /proc entry access.
> >
The signr variable may be declared without initialization -
it is set ro the return value from __dequeue_signal() right
at the function beginning.
Besides, after recalc_sigpending() two checks for signr to
be not 0 may be merged into one. Both if-s become easier
to read.
Thanks to Oleg for
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The way the client works is like this:
>
> Thanks for the excellent ascii art, that cleared up the confusion right
> away.
You know what they say about pictures... :-)
> > What are you trying to do exactly? Are you actually playing with it, or
>
On Thu, Feb 21, 2008 at 08:45:53PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Andi Kleen wrote:
>
> > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> > > Hi,
> > >
> > > I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> > > out the actual
* Joerg Roedel <[EMAIL PROTECTED]> wrote:
> > ok. Then i guess we should just leave the warning and the backtrace
> > in place until they get a fix done?
>
> No. I don't agree. The MTRRs are set up by the BIOS because it knows
> the hardware best (I know this is only true in theory). The OS
Both sig_ignored() and do_sigactoin() check for signr to be explicitly
or implicitly ignored. Introduce a helper for them.
This patch is aimed to help handling signals by pid namespace's
init, and was derived from one of Oleg's patches
From: Jeff Dike <[EMAIL PROTECTED]>
Subject: Re: [PATCH 09/16] um: use get_personality()
Date: Wed, 20 Feb 2008 11:27:34 -0500
Message-ID: <[EMAIL PROTECTED]>
> On Wed, Feb 20, 2008 at 07:19:13PM +0800, WANG Cong wrote:
> > Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>
> Looks good - you should
On Thu, Feb 21, 2008 at 01:58:19AM +0800, Herbert Xu wrote:
> On Wed, Feb 20, 2008 at 06:47:58PM +0100, Milan Broz wrote:
> >
> > I just tested one affected configuration and problem was in missing
> > "chainiv.ko" module on ramdisk.
>
> Ah OK. We probably should merge chainiv into the blkcipher
On Fri, Feb 22, 2008 at 2:46 AM, David Newall <[EMAIL PROTECTED]> wrote:
> Krzysztof Halasa wrote:
> > Perhaps we should increase line length limit, 132 should be fine.
> > Especially useful with long printk() lines and long arithmetic
> > expressions.
>
> Yes; or even longer. 80 characters
Yinghai Lu <[EMAIL PROTECTED]> writes:
> quad core 8 socket system will have apic id lifting.the apic id range could
> be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to
> three clusters
> and that is large than 2. So it is treated as clustered_box.
>
> and will get
>
>
Hi!
> > Does this fit what you had in mind?
>
> Yes it does.
>
> Now I'll ask if you think embedding this information in one of the C
> files for a module would be even nicer?
I kind of like to be able to grep over just Kconfig files, to find out
what is going on...
--
(english)
Hi!
> It's "snapshot-and-restore", and my opinion is that:
>
> - it should *never* call "suspend()"/"resume()" at all (that should be
>reserved purely for suspend-to-RAM and has real power management
>issues!)
Hmm, entering S4 seems like good place to call suspend() for... unless
you
Andi Kleen wrote:
> Balbir Singh wrote:
>> Andi Kleen wrote:
1. We could create something similar to mem_map, we would need to handle 4
>>> 4? At least x86 mainline only has two ways now. flatmem and vmemmap.
>>>
different ways of creating mem_map.
>>> Well it would be only a single way
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> (*) I keed, I keed. Of *course* I'll have to fix things like this in the
> future too. But hopefully not quite as often.
The pragmatic solution would be to just fix the scripts to accept From
everywhere @)
-Andi
--
To unsubscribe from this list:
* James Morris <[EMAIL PROTECTED]> wrote:
> > works fine for you? That has all the current stackprotector fixes. I
> > plan to send a separate pull request with just the stackprotector
> > fixes to Linus, they are looking good in testing so far.
>
> Nope, same problem.
>
> (I followed your
On Thu, Feb 21, 2008 at 9:24 PM, Gordon Farquharson
<[EMAIL PROTECTED]> wrote:
> Hi Sam
>
>
> On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > Option 1) is the worst of the three as that can cost
> > of many hours bug-hunting.
> > Option 3) may seem optimal
Steps to reproduce:
vi -t NETFILTER
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -1396,7 +1396,7 @@ define xtags
$(all-kconfigs) | xargs $1 -a \
Hi,
sorry that I step in so late, procmail sorted this thread in the wrong
box.
Normally I reserved the complete last week for working on mISDN to get it
ready to submit it to -mm, but reality did hit me and I had to do some
other importent stuff :-(
On Thu, Feb 21, 2008 at 11:33:04AM +0100,
Max Krasnyanskiy <[EMAIL PROTECTED]> writes:
>
> static struct module *load_module(void __user *umod,
> unsigned long len,
> const char __user *uargs)
> {
> ...
>
> /* Now sew it into the lists so we can get lockdep and
On Fri, 22 Feb 2008, David Woodhouse wrote:
> On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
> >
> > + del_timer(>info_timer);
> > +
> > hcon->l2cap_data = NULL;
> > kfree(conn);
>
> Shouldn't that be del_timer_sync() ?
Hmm, probably yes.
tglx
--
To
On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
> As you suggested I'm sending CPU isolation patches for review/inclusion into
> sched-devel tree. They are against 2.6.25-rc2.
> You can also pull them from my GIT tree at
>
On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
>
> + del_timer(>info_timer);
> +
> hcon->l2cap_data = NULL;
> kfree(conn);
Shouldn't that be del_timer_sync() ?
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
401 - 500 of 1123 matches
Mail list logo
