On Jan 11, 2008 1:17 AM, Bryan Wu [EMAIL PROTECTED] wrote:
On Jan 10, 2008 7:57 PM, Pierre Ossman [EMAIL PROTECTED] wrote:
On Thu, 10 Jan 2008 17:22:55 +0800
Bryan Wu [EMAIL PROTECTED] wrote:
At page 4-3 of ADSP-BF54x Blackfin(R) Processor Peripheral Hardware
Reference, there is a
This name is just passed to platform_device_alloc which has its parameter
declared const.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
drivers/base/platform.c |2 +-
include/linux/platform_device.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Rik
+static inline int is_file_lru(enum lru_list l)
+{
+ BUILD_BUG_ON(LRU_INACTIVE_FILE != 2 || LRU_ACTIVE_FILE != 3);
+ return (l/2 == 1);
+}
below patch is a bit cleanup proposal.
i think LRU_FILE is more clarify than /2.
What do you think it?
Index:
Roland McGrath [EMAIL PROTECTED] writes:
It's not too pretty, but I found this made the PANIC: early exception
messages become much more reliably useful: 1. print the vector number,
2. print the %cs value, 3. handle error-code-pushing vs non-pushing vectors.
For what do you need cs? It should
From: Vince Fuller [EMAIL PROTECTED]
Date: Mon, 7 Jan 2008 17:10:57 -0800
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.
Am Freitag, 11. Januar 2008 schrieb Joerg Platte:
konqueror 987jplatte mem REG8,6 2590525
1336104 /var/tmp/kdecache-jplatte/ksycoca
konqueror 987jplatte 12r REG8,6 2590525
1336104 /var/tmp/kdecache-jplatte/ksycoca
konqueror 987jplatte 13u
At Thu, 10 Jan 2008 23:02:53 +0100,
Harald Dunkel wrote:
Takashi Iwai wrote:
Hm... Just to be sure, try the patch below. It's a clean up patch
that I'd like to apply later.
Sorry, no sound.
OK, but I'd like to know whether this makes no regression to rc6.
Could you check?
Also,
Probably true that it's not worth the space. I couldn't figure a way to do
it that doesn't use at least 8 bytes per vector. Of course, the vectors
= 32 are never interesting, so 256 bytes of dispatch table could cover it.
Anyway, I think it's fine just to have the patch on hand to enable for a
Please pull from the for-linus branch:
git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus
This will update the following files:
fs/xfs/linux-2.6/xfs_file.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
through these commits:
commit
* Andi Kleen [EMAIL PROTECTED] wrote:
but that's not too smart: why dont they use WB plus cflush
instead?
Because they need to access it WC for performance.
I think you have it fundamentally backwards: the best for
performance is WB + cflush. What would WC offer for
I bisected my startup problem down to:
197e4989b0404996dfe3ab091c1398e4c2813d44 is first bad commit
commit 197e4989b0404996dfe3ab091c1398e4c2813d44
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:06 2008 +0100
x86: mark native_read_tsc()
* Roland McGrath [EMAIL PROTECTED] wrote:
It's not too pretty, but I found this made the PANIC: early
exception messages become much more reliably useful: 1. print the
vector number, 2. print the %cs value, 3. handle error-code-pushing vs
non-pushing vectors.
thanks, applied.
since
* Roland McGrath [EMAIL PROTECTED] wrote:
I bisected my startup problem down to:
i fixed this in my tree yesterday but was held up by another problem
from uploading it. The patch below should apply to the tree you have.
Ingo
--
Subject: x86: fix sched_clock()
From: Ingo
please check the one that can be applied to x86.git -mm
YH
[PATCH] x86-64: disable the GART early v2
For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
installed.
when try to use kexec second kernel, and the first doesn't include
gart_shutdown.
the second kernel
On Fri, Jan 11 2008, Mikulas Patocka wrote:
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
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> @@ -170,14 +170,13 @@ void cpu_idle(void)
> current_thread_info()->status |= TS_POLLING;
> /* endless idle loop with no priority at all */
> while (1) {
> + tick_nohz_stop_sched_tick();
> while
[ CCing Magnus Damm and Ian Campbell ]
On Wed, Jan 09, 2008 at 08:14:23PM -0500, Vivek Goyal wrote:
> On Wed, Jan 09, 2008 at 10:57:47AM +0800, Huang, Ying wrote:
> > This patch add an architecture specific struct arch_kimage into struct
> > kimage. Three pointers to page table pages used by
Andrew Morton wrote:
> Doing this in a piecemeal through-a-pinhole fashion won't work very well
> and is a bit risky.
Yes, agree, that's also my feeling.
--
Pierre Peiffer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Wed, Jan 09 2008, Alasdair G Kergon wrote:
> Here's the latest version of dm-loop, for comparison.
>
> To try it out,
> ln -s dmsetup dmlosetup
> and supply similar basic parameters to losetup.
> (using dmsetup version 1.02.11 or higher)
Why oh why does dm always insist to reinvent
On Wed, Jan 09, 2008 at 10:45:13PM +, Alasdair G Kergon wrote:
> On Wed, Jan 09, 2008 at 11:46:03PM +0100, Andi Kleen wrote:
> > struct inode *inode = file->f_dentry->d_inode;
>
> And oops if that's not defined?
For file_operations which we talk about here it always is defined.
Block_device
On Thu, Jan 10 2008, Nick Piggin wrote:
> On Wednesday 09 January 2008 19:52, Jens Axboe wrote:
>
> > So how does it work? Instead of punting IO to a thread and passing it
> > through the page cache, we instead attempt to send the IO directly to the
> > filesystem block that it maps to.
>
> You
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, you could/should probably fold this into Masami's kprobe
unification patch.
commit 17735e04f7f18bea4dcbe4daa31c34acac55b332
Author: Masami Hiramatsu <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:30:50 2008 +0100
kprobes code for x86
On Thu, Jan 10, 2008 at 12:42:25PM +1100, Nick Piggin wrote:
> > So how does it work? Instead of punting IO to a thread and passing it
> > through the page cache, we instead attempt to send the IO directly to the
> > filesystem block that it maps to.
>
> You told Christoph that just using
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote:
> > Joerg,
> >
> > Can you try the attached patches? Thank you.
> > I cannot reliably reproduce the bug yet.
>
> Please ignore the first patch and only apply the two debugging
>
On Wed, Jan 09, 2008 at 10:42:08PM -0800, Arjan van de Ven wrote:
>
> Subject: Add a simple backtrace test module
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> During the work on the x86 32 and 64 bit backtrace code I found it useful
> to have a simple test module to test a process and irq
On Wed, Jan 09, 2008 at 11:51:48PM -0800, Andrew Morton wrote:
> > +++ b/fs/ufs/super.c
> > @@ -131,6 +131,8 @@ static void ufs_print_super_stuff(struct super_block
> > *sb,
> > printk(KERN_INFO" cs_nffree(Num of free frags): %llu\n",
> >(unsigned long long)
> >
On Thu, Jan 10 2008, Jens Axboe wrote:
> On Wed, Jan 09 2008, Alasdair G Kergon wrote:
> > Here's the latest version of dm-loop, for comparison.
> >
> > To try it out,
> > ln -s dmsetup dmlosetup
> > and supply similar basic parameters to losetup.
> > (using dmsetup version 1.02.11 or higher)
On Wed, Jan 09 2008, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > So how does it work? Instead of punting IO to a thread and passing it
> > through the page cache, we instead attempt to send the IO directly to the
>
> Great -- something like this was needed for a long time.
On Thu, Jan 10, 2008 at 09:37:53AM +0100, Joerg Platte wrote:
> Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote:
> > > Joerg,
> > >
> > > Can you try the attached patches? Thank you.
> > > I cannot reliably reproduce the bug
On Thu, Jan 10, 2008 at 08:40:41AM +, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 11:51:48PM -0800, Andrew Morton wrote:
> > > +++ b/fs/ufs/super.c
> > > @@ -131,6 +131,8 @@ static void ufs_print_super_stuff(struct super_block
> > > *sb,
> > > printk(KERN_INFO" cs_nffree(Num
On Thu, Jan 10 2008, Christoph Hellwig wrote:
> > > loop maintains a prio tree of known
> > > extents in the file (populated lazily on demand, as needed).
> >
> > Just a quick question (I haven't looked closely at the code): how come
> > you are using a prio tree for extents? I don't think they
On Thu, Jan 10, 2008 at 03:03:03AM +0300, Anton Salikhmetov wrote:
...
> > I guess a third possible time (if we want to minimize the number of
> > updates) would be when natural syncing of the file data to disk, by
> > other things in the VM, would be about to clear the I_DIRTY_PAGES
> > flag on
Hi everybody - Happy New Year to you all!
OK, updated to git rc7 yesterday - I now see this in syslog:
"Driver 'sd' needs updating - please use bus_type methods"
The warning never appeared in RC6, and all google reveals are other
peoples logs that are posted about other issues.
Do I need
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
On Thu, 10 Jan 2008 00:45:27 +0800
"Bryan Wu" <[EMAIL PROTECTED]> wrote:
>
> Actually, Blackfin BF54x on-chip SDIO host controller is supposed to
> support 1-bit and 4-bit MMC or SD. But in the real platform, when MMC
> works at 4-bit mode there will be a FIFO underrun error
>
On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
> > IMHO this shouldn't be done in the loop driver anyway. Filesystems have
> > their own effricient extent lookup trees (well, at least xfs and btrfs
> > do), and we should leverage that instead of reinventing it.
>
> Completely agree,
Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]>
Cc: Marc Singer <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL PROTECTED]>
---
Documentation/arm/Sharp-LH/IOBarrier |2 +-
drivers/mtd/devices/doc2000.c |2 +-
include/asm-arm/arch-realview/irqs.h |2 +-
Andi Kleen wrote:
> Here's a proposal for some useful code transformations the kernel janitors
> could do as opposed to running checkpatch.pl.
>
> Most ioctl handlers still running implicitely under the big kernel
> lock (BKL). But long term Linux is trying to get away from that. There is a
> new
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
> From: Alex Dubov <[EMAIL PROTECTED]>
>
> Sony MemoryStick cards are used in many products manufactured by Sony. They
> are available both as storage and as IO expansion cards. Currently, only
> MemoryStick Pro storage cards are
On Thu, Jan 10 2008, Christoph Hellwig wrote:
> On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
> > > IMHO this shouldn't be done in the loop driver anyway. Filesystems have
> > > their own effricient extent lookup trees (well, at least xfs and btrfs
> > > do), and we should leverage
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:42:08PM -0800, Arjan van de Ven wrote:
> >
> > Subject: Add a simple backtrace test module
> > From: Arjan van de Ven <[EMAIL PROTECTED]>
> >
> > During the work on the x86 32 and 64 bit backtrace code I found it
> >
> I have been unable to reproduce your problem here, and I notice you have
> the proprietary, highly invasive and closed-source Nvidia driver
> installed in your kernel.
>
> Can you try using the "nv" or "vesa" (unaccelerated) Xorg drivers and
> reproduce the problem that way?
>
> If you *do*
> * Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > FASTCALL is defined empty in -mm, but UML is not compiled with
> > -mregparm=3 and so this breaks things (I noticed problems with
> > rwsem_down_write_failed).
> >
> > Tried recompiling UML with -mregparm=3, but that resulted in a strange
>
On Thu, Jan 10, 2008 at 10:04:29AM +0100, Ingo Molnar wrote:
> yeah, agreed, we'll clean this all up, and move the other testcode there
> too, ok? There's rcutorture, lock-selftests, rt-tester,
> kprobes-smoke-test and now backtracetest.
>
> Arjan might as well want to use the opportunity and
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> During the work on the x86 32 and 64 bit backtrace code I found it
> useful to have a simple test module to test a process and irq context
> backtrace. Since the existing backtrace code was buggy, I figure it
> might be useful to have such a
> Can you explain the rationale behind that running on the BKL? What type of
It used to always run with the BKL because everything used to
and originally nobody wanted to review all ioctl handlers in tree to see if
they can run with more fine grained locking. A lot probably can though.
>
On Wed, 09 Jan 2008 10:56:02 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> J.A. Magallón wrote:
> > HI all...
> >
> > On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
> > wrote:
> >
> >> It's been two weeks since rc6, but let's face it, with xmas and new years
> >>
Andi,
finally managed to get the time to review your CPA patchset, and i
fundamentally agree with most of the detail changes done in it. But here
are a few structural high-level observations:
- firstly, there's no rationale given. So we'll change ioremap()/etc.
from doing a cflush-range
* Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Thanks. Patch works, but needed to add asmregparm to the definitions
> as well, plus added default define into (updated
> patch below).
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
> Peter, any chance you could chime in here?
I have this patch to add swap_out/_in methods. I expect we can loosen
the requirement for swapcache pages and change the name a little.
previously posted here:
* Matthew <[EMAIL PROTECTED]> wrote:
> > I have been unable to reproduce your problem here, and I notice you have
> > the proprietary, highly invasive and closed-source Nvidia driver
> > installed in your kernel.
> >
> > Can you try using the "nv" or "vesa" (unaccelerated) Xorg drivers and
> >
>
> finally managed to get the time to review your CPA patchset, and i
> fundamentally agree with most of the detail changes done in it. But here
> are a few structural high-level observations:
>
> - firstly, there's no rationale given. So we'll change ioremap()/etc.
> from doing a cflush-range
On Wed, Jan 09, 2008 at 02:39:23PM +0800, Dave Young wrote:
> On Jan 9, 2008 2:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 9, 2008 2:13 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Jan 09, 2008 at 09:32:48AM +0800, Dave Young wrote:
> > > > On Jan 9, 2008 6:48 AM,
Hi Alasdair,
On Wednesday 09 January 2008 14:40, Alasdair G Kergon wrote:
> Device-mapper for example in dm_blk_ioctl(), has no need for BKL so
> drops it immediately, but it does need the inode parameter, so it is
> unable to switch as things stand.
So what stops you from changing to
On Thu, Jan 10 2008, Peter Zijlstra wrote:
>
> On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
>
> > Peter, any chance you could chime in here?
>
> I have this patch to add swap_out/_in methods. I expect we can loosen
> the requirement for swapcache pages and change the name a
On Thu, 2008-01-10 at 10:49 +0100, Jens Axboe wrote:
> On Thu, Jan 10 2008, Peter Zijlstra wrote:
> >
> > On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
> >
> > > Peter, any chance you could chime in here?
> >
> > I have this patch to add swap_out/_in methods. I expect we can
On Thu, Jan 10, 2008 at 10:31:26AM +0100, Ingo Molnar wrote:
>
> Andi,
>
> finally managed to get the time to review your CPA patchset, and i
> fundamentally agree with most of the detail changes done in it. But here
> are a few structural high-level observations:
I have a few changes and
On Thu, Jan 10, 2008 at 07:44:03PM +1000, Dave Airlie wrote:
> >
> > finally managed to get the time to review your CPA patchset, and i
> > fundamentally agree with most of the detail changes done in it. But here
> > are a few structural high-level observations:
> >
> > - firstly, there's no
> It seems the correct solution would be not to hijack __cpuinit
> (as your patch does), but to create a new annotation.
The rationale is that after suspend the CPU has to be reinitialized.
That is because it is essentially like a reboot. All the previous
CPU state is gone.
It doesn't need to
On Thu, Jan 03, 2008 at 07:43:43PM +0100, Andi Kleen wrote:
> On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
> > On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
> > >
> > > This avoids the requirement to mark a lot of initialization functions not
> > > __cpuinit just for
Andi Kleen wrote:
> > Can you explain the rationale behind that running on the BKL? What type
> > of
>
> It used to always run with the BKL because everything used to
> and originally nobody wanted to review all ioctl handlers in tree to see if
> they can run with more fine grained locking. A lot
On Thu, Jan 10 2008, Peter Zijlstra wrote:
>
> On Thu, 2008-01-10 at 10:49 +0100, Jens Axboe wrote:
> > On Thu, Jan 10 2008, Peter Zijlstra wrote:
> > >
> > > On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
> > >
> > > > Peter, any chance you could chime in here?
> > >
> > > I have
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
> Huh, that's a fairly negligible change on your system. Is that with or
> without the earlier patch? That doesn't appear to change much here.
> Guess I'll have to clean up my stats patch and send it to you.
Ok, if I apply both of the patches, I
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > problem, because the iowait problem disappeared today after the regular
> > Debian update. I'll try to install the old package versions to make it
> > show up again. Maybe that helps to debug it.
>
> Thank you. I'm running sid, ext2 as
* Dave Airlie <[EMAIL PROTECTED]> wrote:
> > - firstly, there's no rationale given. So we'll change ioremap()/etc.
> > from doing a cflush-range instruction instead of a WBINVD. But why?
> > WBINVD isnt particular fast (takes a few msecs), but why is that a
> > problem? Drivers dont do
On Wed, 9 Jan 2008, Matt Mackall wrote:
>
> slob: split free list by size
>
[snip]
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 7 Jan 2008, Matt Mackall wrote:
> slob: fix free block merging at head of subpage
>
> We weren't merging freed blocks at the beginning of the free list.
> Fixing this showed a 2.5% efficiency improvement in a userspace test
> harness.
[snip]
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
> So if I write my own driver and have never heard of ioctls running on BKL
> before I can rather be sure that I just can change the interface of the ioctl
> function, put it in unlocked_ioctl and are fine? Cool.
If you know the BKL is not needed in your code you should use unlocked_ioctl
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > WBINVD isnt particular fast (takes a few msecs), but why is that a
> > problem? Drivers dont do high-frequency ioremap-ing. It's
> > typically only done at driver/device startup and that's it.
>
> Actually graphics drivers can do higher
On Thu, Jan 10, 2008 at 11:04:43AM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > WBINVD isnt particular fast (takes a few msecs), but why is that a
> > > problem? Drivers dont do high-frequency ioremap-ing. It's
> > > typically only done at driver/device
Hi, Dan,
Thanks so much for your help!
> Since the fixups were straightforward I went ahead and pulled
> this patch
> out of -mm and rebased it on my async-tx patch queue for
> 2.6.25. Could
> you double check the result, I have only compile tested it?
>
> git pull
Hi,
On Wed, Jan 09, 2008 at 06:16:02PM +0900, Tejun Heo wrote:
> Please confirm the attached patch fixes the oops. I'll separate it into
> two patches and forward them to Greg. But bluetooth code also needs to
> be updated such that it moves the refcommX device before killing the
> connection
On Thu, Jan 10, 2008 at 10:58:57AM +0100, Andi Kleen wrote:
> > It seems the correct solution would be not to hijack __cpuinit
> > (as your patch does), but to create a new annotation.
>
> The rationale is that after suspend the CPU has to be reinitialized.
> That is because it is essentially
On Jan 10, 2008 7:55 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 07:44:03PM +1000, Dave Airlie wrote:
> > >
> > > finally managed to get the time to review your CPA patchset, and i
> > > fundamentally agree with most of the detail changes done in it. But here
> > > are a
On Thu, 2008-01-10 at 11:02 +0100, Jens Axboe wrote:
> On Thu, Jan 10 2008, Peter Zijlstra wrote:
> >
> > On Thu, 2008-01-10 at 10:49 +0100, Jens Axboe wrote:
> > > On Thu, Jan 10 2008, Peter Zijlstra wrote:
> > > >
> > > > On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
> > > >
>
On Thu, Jan 10, 2008 at 07:59:36AM +0800, Yi Yang wrote:
> Maybe this is a good idea, but i don't know the relationships between
> acpi devices, devices, pci devices and pnp devices. If we can merge all
> these things together, that will be a great job.
Let's not merge this yet, then, otherwise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Oleg Nesterov wrote:
> On 12/08, Eric W. Biederman wrote:
>> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>>
>>> ptrace_stop() decrements ->group_stop_count to "participate" in group stop.
>>> This looks very wrong to me, the task can in fact decrement
Thanks for the reply,
the patch doesn't work witch the patch utility, so I did it manually, hope this
was rigth:
static void aes_crypt_copy(const u8 *in, u8 *out, u32 *key, struct cword *cword)
{
u8 tmp[AES_BLOCK_SIZE * 2]
__attribute__
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> There's also unfortunately still one outstanding bug (triggeredb y
> some recent changes) on 32bit that makes the self test suite not pass
> currently.
ok. I'd expect there to be a whole lot of bugs triggered in this area.
We have to shape it in a
Harvey Harrison wrote:
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
Acked-by: Masami Hiramatsu <[EMAIL PROTECTED]>
> ---
> Ingo, you could/should probably fold this into Masami's kprobe
> unification patch.
The original code had these whitespace, because (I think)
On Thu, Jan 10, 2008 at 08:20:26PM +1000, Dave Airlie wrote:
> This is only possible as long as we know all the parts involved, for
> example on AMD we have problems with that
> over-eager prefetching so for drivers on AMD chipsets we have to do
> something else more than likely using
2008/1/10, Jakob Oestergaard <[EMAIL PROTECTED]>:
> On Thu, Jan 10, 2008 at 03:03:03AM +0300, Anton Salikhmetov wrote:
> ...
> > > I guess a third possible time (if we want to minimize the number of
> > > updates) would be when natural syncing of the file data to disk, by
> > > other things in the
Hi Matt,
On Thu, 10 Jan 2008, Pekka J Enberg wrote:
> I'll double check the results for SLUB next but it seems obvious that your
> patches are a net gain for SLOB and should be applied. One problem though
> with SLOB seems to be that its memory efficiency is not so stable. Any
> ideas why that
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > WBINVD isnt particular fast (takes a few msecs), but why is
> > > > that a problem? Drivers dont do high-frequency ioremap-ing.
> > > > It's typically only done at driver/device startup and that's
> > > > it.
> > >
> > > Actually
On Thu, Jan 10, 2008 at 07:54:38AM +0100, Ingo Molnar wrote:
>...
> it's a 2.6.24.1 candidate i believe. We trigger plenty of various
> crashes during x86.git maintenance and others hit various crashes in
> -mm, so by the time .1 is released we'll have it in .25 and can backport
> it. Most
On Thu, Jan 10, 2008 at 11:43:51AM +0100, Ingo Molnar wrote:
> > > - firstly, there's no rationale given. So we'll change ioremap()/etc.
> > > from doing a cflush-range instruction instead of a WBINVD. But why?
> >
> > - WBINVD is a very nasty operation. I was talking to some CPU people
> >
Masami Hiramatsu wrote:
> Harvey Harrison wrote:
>> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
>
> Acked-by: Masami Hiramatsu <[EMAIL PROTECTED]>
>
>> ---
>> Ingo, you could/should probably fold this into Masami's kprobe
>> unification patch.
>
> The original code had these whitespace,
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> If you have a "SELinux: policy loaded with handle_unknown=allow"
> message in your /var/log/messages, then new classes/perms that are not
> yet known to the policy will be allowed by default, so the operation
> will be permitted by the kernel.
I
On Thu, Jan 10, 2008 at 11:57:26AM +0100, Ingo Molnar wrote:
>
> > > > > WBINVD isnt particular fast (takes a few msecs), but why is
> > > > > that a problem? Drivers dont do high-frequency ioremap-ing.
> > > > > It's typically only done at driver/device startup and that's
> > > > >
Hello lkml,
I have problem with my computer: I have motherboard with AMD690G chipset
and nVidia VGA card. But I cannot set BIOS, to assign for VGA unique
IRQ. VGA card is sharing IRQ with two ohci_hcd (USB 1.1 controllers).
But when I want use for X proprietary nvidia driver, X didn't work with
> But your patch does:
>
> +config PM_CPUINIT
> + bool
> + depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
obj-$(CONFIG_PM)+= cpu.o
If it was changed to CONFIG_something else then yes that dependency
should be changed too.
-Andi
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > But your patch does:
> >
> > +config PM_CPUINIT
> > + bool
> > + depends on PM
>
> That is because arch/x86/power/cpu.c where this happens is currently
>
> obj-$(CONFIG_PM)+= cpu.o
>
> If it was changed
Jan Marek <[EMAIL PROTECTED]> writes:
>
> Is there a way to change IRQ for VGA (or for ohci_hcd instead of VGA)
> directly in Linux?
Linux normally cannot change the interrupts assigned by the BIOS
because it often requires chipset specific knowledge.
-Andi
--
To unsubscribe from this list: send
CC'ed linux-scsi and James,
On Thu, 10 Jan 2008 08:51:50 +
Nick Warne <[EMAIL PROTECTED]> wrote:
>
> Hi everybody - Happy New Year to you all!
>
> OK, updated to git rc7 yesterday - I now see this in syslog:
>
>"Driver 'sd' needs updating - please use bus_type methods"
>
> The
Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3)
The following series of patches create and populate the toplevel tests/
directory. This will henceforth be the place where all in-kernel tests
live.
All patches against 2.6.24-rc6-mm1
Ananth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, Jan 10, 2008 at 01:49:15AM -0800, Daniel Phillips wrote:
> So what stops you from changing to unlocked_ioctl for the main device
> mapper ctl_ioctl?
Nothing - patches to do this are queued for 2.6.25:
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > But your patch does:
> > >
> > > +config PM_CPUINIT
> > > + bool
> > > + depends on PM
> >
> > That is because arch/x86/power/cpu.c where this happens is
This patch series adds support for the touchscreen controllers provided
by Wolfson Microelectronics WM97xx series chips in both polled and
streaming modes.
These drivers have been maintained out of tree since 2003. During that
time the driver the primary maintainer was Liam Girdwood and a number
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Signed-off-by: Graeme Gregory <[EMAIL PROTECTED]>
Signed-off-by: Mike Arthur <[EMAIL PROTECTED]>
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Stanley Cai <[EMAIL PROTECTED]>
Cc: Rodolfo Giometti <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL
501 - 600 of 1050 matches
Mail list logo
