(no subject)

(no subject)

[A S]

  Hi,   There is some outdated messages around that imply that there was work being done to have the ESI Maya 44 PCI card work with ALSA.  However, it seems to have been stalled.  Can anyone confirm the status of this card with regard to ALSA?  I have the card and can get sound from it, but have been having trouble making it work properly in a xubuntu 11.04 + KXStudio setup.  I just want to make sure I'm not wasting my time with a card that will never work properly with a linux distro.   Many thanks.   		 	   		  

Re: (no subject)

[Clemens Ladisch]

A S wrote:
> There is some outdated messages around that imply that there was work
> being done to have the ESI Maya 44 PCI card work with ALSA.  However,
> it seems to have been stalled.  Can anyone confirm the status of this
> card with regard to ALSA? 

README.maya44 says:
| The following functions work, as tested by Rainer Zimmermann and Piotr
| Makowski:
| 
| - playback and capture at all sampling rates
| - input/output level
| - crossmixing
| - line/mic switch
| - phantom power switch
| - analogue monitor a.k.a bypass
| 
| The following functions *should* work, but are not fully tested:
| 
| - Channel 3+4 analogue - S/PDIF input switching
| - S/PDIF output
| - all inputs/outputs on the M/IO/DIO extension card
| - internal/external clock selection


Regards,
Clemens

(No Subject)

[Emilis Kiškis]

What did you do before the bug happened? (Steps to reproduce your issue)

1. Create a new worktree with `git worktree add new-worktree`
2. Modify files in the new worktree
3. Move new worktree back to main working tree (i.e. master)

What did you expect to happen? (Expected behavior)

I expected uncommited changes from `new-worktree` to merge with changes from `master`

What happened instead? (Actual behavior)

The changes from `new-worktree` were lost

What's different between what you expected and what actually happened?

The uncommited changes were lost instead of preserved

Anything else you want to add:

I lost 4 hours of work :(((

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.3 (Apple Git-145)
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64
compiler info: clang: 15.0.0 (clang-1500.1.0.2.5)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
pre-push

(No Subject)

[Oliver Webb]

subscribe dash

Re: (No Subject)

[Lawrence Velázquez]

On Wed, Feb 7, 2024, at 10:34 PM, Oliver Webb wrote:
> subscribe dash

To subscribe, resend this message to <majordomo@vger.kernel.org>.

-- 
vq

Re: (No Subject)

[Oliver Webb]

On Wednesday, February 7th, 2024 at 21:46, Lawrence Velázquez <vq@larryv.me> wrote:

> On Wed, Feb 7, 2024, at 10:34 PM, Oliver Webb wrote:
> 
> > subscribe dash
> 
> 
> To subscribe, resend this message to majordomo@vger.kernel.org.
Thanks, although the correct address appears to now be "dash+subscribe@vger.kernel.org",
since majordomo commands aren't supported anymore
> --
> vq

- Oliver Webb <aquahobbyist@proton.me>

Re: (No Subject)

[Lawrence Velázquez]

On Wed, Feb 7, 2024, at 11:04 PM, Oliver Webb wrote:
> Thanks, although the correct address appears to now be 
> "dash+subscribe@vger.kernel.org",
> since majordomo commands aren't supported anymore

Ah, I suppose that has something to do with the vger migration last
October.  The homepage (<http://gondor.apana.org.au/~herbert/dash/>)
should be updated then.

-- 
vq

(No Subject)

[John Moon]

Date: Tue, 30 Jan 2024 18:57:45 -0800
Subject: [PATCH] mailmap: switch email address for John Moon

Add current email address as QUIC email is no longer active.

Signed-off-by: John Moon <john@jmoon.dev>
---
 .mailmap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index 04998f7bda81..8ae00bd3708a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -289,6 +289,7 @@ Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
 John Crispin <john@phrozen.org> <blogic@openwrt.org>
 John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
 John Keeping <john@keeping.me.uk> <john@metanate.com>
+John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
 John Stultz <johnstul@us.ibm.com>
 <jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
-- 
2.43.0

(No Subject)

[martin]

Empty Message

(No Subject)

[youngbludproductions]

hi guys who wants to hear a good little story i made on the toilet

Re: (No Subject)

[youngbludproductions]

[Intro]
Desert you
Ooh-ooh-ooh-ooh
Hurt you

[Verse 1]
We're no strangers to love
You know the rules and so do I (Do I)
A full commitment's what I'm thinking of
You wouldn't get this from any other guy

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Verse 2]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it
See Rick Astley Live
Get tickets as low as $53
[Pre-Chorus]
And if you ask me how I'm feeling
Don't tell me you're too blind to see

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

[Post-Chorus]
Ooh (Give you up)
Ooh-ooh (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
Ooh-ooh
Never gonna give, never gonna give (Give you up)
[Bridge]
We've known each other for so long
Your heart's been aching, but you're too shy to say it (To say it)
Inside, we both know what's been going on (Going on)
We know the game, and we're gonna play it

[Pre-Chorus]
I just wanna tell you how I'm feeling
Gotta make you understand

[Chorus]
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you
Never gonna give you up
Never gonna let you down
Never gonna run around and desert you
Never gonna make you cry
Never gonna say goodbye
Never gonna tell a lie and hurt you

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

(no subject)

[Marc Kleine-Budde]

Subject: [PATCH 0/3] can: gs_usb: fix hardware timestamping issues
In-Reply-To:

Hello,

while playing around with the hardware timestamping code, I found some
issues, which are fixed in this series.

John, can you test if timestamping still works on your hardware.

regards,
Marc

Re: (No Subject)

[john]

> while playing around with the hardware timestamping code, I found some
> issues, which are fixed in this series.
> 
> John, can you test if timestamping still works on your hardware.

I've just tested the 3 patches and yes it still works. Thanks for picking up on those.

I see a potential issue with 3/3: the timer not being stopped if the USB start errors but I've replied in that thread.

Re: (No Subject)

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On 21.09.2022 07:07:26, john@jbrengineering.co.uk wrote:
> > while playing around with the hardware timestamping code, I found some
> > issues, which are fixed in this series.
> > 
> > John, can you test if timestamping still works on your hardware.
> 
> I've just tested the 3 patches and yes it still works. Thanks for
> picking up on those.

Thanks, can I add your Tested-by?

> I see a potential issue with 3/3: the timer not being stopped if the
> USB start errors but I've replied in that thread.

Fixed, see:

| https://lore.kernel.org/all/20220921081329.385509-1-mkl@pengutronix.de

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: (No Subject)

[john]

> Thanks, can I add your Tested-by?

Yep.

John.

(No Subject)

[loggervicky69]

subscribe

[PATCH v2 2/3] arm64: Support huge vmalloc mappings

[Kefeng Wang]

This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
vmalloc mappings.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 4 ++--
 arch/arm64/Kconfig                              | 1 +
 arch/arm64/kernel/module.c                      | 5 +++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7b2f900fd243..e3f9fd7ec106 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
 			precedence over memory_hotplug.memmap_on_memory.
 
 
-	hugevmalloc=	[PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+	hugevmalloc=	[KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
 			Format: { on | off }
 			Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
 
@@ -3424,7 +3424,7 @@
 
 	nohugeiomap	[KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
 
-	nohugevmalloc	[PPC] Disable kernel huge vmalloc mappings.
+	nohugevmalloc	[KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
 
 	nosmt		[KNL,S390] Disable symmetric multithreading (SMT).
 			Equivalent to smt=1.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3bb0b67292b5..c34bbb4482b0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -142,6 +142,7 @@ config ARM64
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
 	select HAVE_ARCH_COMPILER_H
+	select HAVE_ARCH_HUGE_VMALLOC
 	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 309a27553c87..af7b4cbace2b 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
 		module_alloc_end = MODULES_END;
 
 	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
-				module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
+				module_alloc_end, gfp_mask, PAGE_KERNEL,
+				VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
 	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
@@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
 		 */
 		p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
 				module_alloc_base + SZ_2G, GFP_KERNEL,
-				PAGE_KERNEL, 0, NUMA_NO_NODE,
+				PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
 				__builtin_return_address(0));
 
 	if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
-- 
2.26.2

Re: (No subject)

[William Kucharski]

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 

Re: (No subject)

[William Kucharski]

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 

Re: (No subject)

[William Kucharski]

You should also fix the existing typo in the documentation (inline):

> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig                              | 1 +
> arch/arm64/kernel/module.c                      | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
>            precedence over memory_hotplug.memmap_on_memory.
> 
> 
> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>            Format: { on | off }
>            Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.

"Reguires" should be "Requires." 

> 
> @@ -3424,7 +3424,7 @@
> 
>    nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
> 
> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
> 
>    nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>            Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
>    select HAVE_ARCH_AUDITSYSCALL
>    select HAVE_ARCH_BITREVERSE
>    select HAVE_ARCH_COMPILER_H
> +    select HAVE_ARCH_HUGE_VMALLOC
>    select HAVE_ARCH_HUGE_VMAP
>    select HAVE_ARCH_JUMP_LABEL
>    select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>        module_alloc_end = MODULES_END;
> 
>    p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>                NUMA_NO_NODE, __builtin_return_address(0));
> 
>    if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>         */
>        p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>                module_alloc_base + SZ_2G, GFP_KERNEL,
> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>                __builtin_return_address(0));
> 
>    if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> -- 
> 2.26.2
> 
> 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: (No subject)

[Kefeng Wang]

On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

Re: (No subject)

[Kefeng Wang]

On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: (No subject)

[Kefeng Wang]

On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig                              | 1 +
>> arch/arm64/kernel/module.c                      | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>>             precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> -    hugevmalloc=    [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> +    hugevmalloc=    [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>>             Format: { on | off }
>>             Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>>     nohugeiomap    [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> -    nohugevmalloc    [PPC] Disable kernel huge vmalloc mappings.
>> +    nohugevmalloc    [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>>     nosmt        [KNL,S390] Disable symmetric multithreading (SMT).
>>             Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>>     select HAVE_ARCH_AUDITSYSCALL
>>     select HAVE_ARCH_BITREVERSE
>>     select HAVE_ARCH_COMPILER_H
>> +    select HAVE_ARCH_HUGE_VMALLOC
>>     select HAVE_ARCH_HUGE_VMAP
>>     select HAVE_ARCH_JUMP_LABEL
>>     select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>>         module_alloc_end = MODULES_END;
>>
>>     p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> -                module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> +                module_alloc_end, gfp_mask, PAGE_KERNEL,
>> +                VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>>                 NUMA_NO_NODE, __builtin_return_address(0));
>>
>>     if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>>          */
>>         p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>>                 module_alloc_base + SZ_2G, GFP_KERNEL,
>> -                PAGE_KERNEL, 0, NUMA_NO_NODE,
>> +                PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>>                 __builtin_return_address(0));
>>
>>     if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> -- 
>> 2.26.2
>>
>>

(No Subject)

[Yadunandan Pillai]

subscribe bpf

(No Subject)

[Yassine Oudjana]

Date: Tue, 22 Jun 2021 20:08:25 +0400
Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name

Support for parsing the firmware-name property was added a while ago [1],
but the dt-bindings were never updated with the new property. This patch
adds it to all venus dt-bindings.

Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>

[1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
---
 .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
 5 files changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 59ab16ad12f1..cb1b866d9c37 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -80,6 +80,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
index 199f45217b4a..b8809325138f 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
@@ -107,6 +107,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 04013e5dd044..ffd3e2850366 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -99,6 +99,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 04b9af4db191..cd7a5e1374ce 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -94,6 +94,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
index 680f37726fdf..ae256238a637 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -108,6 +108,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
-- 
2.32.0

Re: (No Subject)

[Rob Herring]

On Tue, Jun 22, 2021 at 04:20:24PM +0000, Yassine Oudjana wrote:
> Date: Tue, 22 Jun 2021 20:08:25 +0400
> Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name
> 
> Support for parsing the firmware-name property was added a while ago [1],
> but the dt-bindings were never updated with the new property. This patch
> adds it to all venus dt-bindings.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> [1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
> ---
>  .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> index 59ab16ad12f1..cb1b866d9c37 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> @@ -80,6 +80,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1

Not an array.

Is there a specific pattern and/or default name you can specify?

> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> index 199f45217b4a..b8809325138f 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> @@ -107,6 +107,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index 04013e5dd044..ffd3e2850366 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -99,6 +99,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> index 04b9af4db191..cd7a5e1374ce 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> @@ -94,6 +94,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> index 680f37726fdf..ae256238a637 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> @@ -108,6 +108,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.32.0
> 
> 
> 

(No Subject)

[Nathan Ringo]

Updates for QEMU 6.0.0.

(No Subject)

[Caleb Connolly]

Subject: v2: arm64: dts: sm8150: start populating qups

The QUPs are rather sparse, lets add the zero-th and second qup nodes,
the iommus properties for all of them and the i2c nodes.

With this it's now possible to bringup the touchscreen on my
device, and without crashing!

Derived from OnePlus 7 Pro downstream kernel sources.

	Caleb
---
Of note, I'm only able to properly test i2c17, as that's what my
touchscreen is attached to. Enabling i2c18 causes my device to lockup
during probe, I suspect those pins are used for some other purpose on my
device.

Changes since v1:
 * Pick up Reviewed-By's from Vinod and Bhupesh
 * Squash second patch into first
 * Add iommus property to dt-binding docs for geni
 * Fix i2c19 being mistakenly enabled by default

Caleb Connolly (3):
      arm64: dts: qcom: sm8150: add other QUP nodes and iommus
      arm64: dts: qcom: sm8150: add i2c nodes
      dt-bindings: qcom: geni-se: document iommus

 arch/arm64/boot/dts/qcom/sm8150.dtsi | 549 +++++++++++++++++++++++++++++++++++
 1 file changed, 549 insertions(+)

Re: (No Subject)

[Dmitry Baryshkov]

On Sun, 21 Mar 2021 at 20:47, Caleb Connolly <caleb@connolly.tech> wrote:
>
> Subject: v2: arm64: dts: sm8150: start populating qups
>
> The QUPs are rather sparse, lets add the zero-th and second qup nodes,
> the iommus properties for all of them and the i2c nodes.
>
> With this it's now possible to bringup the touchscreen on my
> device, and without crashing!
>
> Derived from OnePlus 7 Pro downstream kernel sources.
>
>         Caleb

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> ---
> Of note, I'm only able to properly test i2c17, as that's what my
> touchscreen is attached to. Enabling i2c18 causes my device to lockup
> during probe, I suspect those pins are used for some other purpose on my
> device.
>
> Changes since v1:
>  * Pick up Reviewed-By's from Vinod and Bhupesh
>  * Squash second patch into first
>  * Add iommus property to dt-binding docs for geni
>  * Fix i2c19 being mistakenly enabled by default
>
> Caleb Connolly (3):
>       arm64: dts: qcom: sm8150: add other QUP nodes and iommus
>       arm64: dts: qcom: sm8150: add i2c nodes
>       dt-bindings: qcom: geni-se: document iommus
>
>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 549 +++++++++++++++++++++++++++++++++++
>  1 file changed, 549 insertions(+)
>
>


-- 
With best wishes
Dmitry

Re: [PATCH 8/8] mac80211: IBSS: send deauth when expiring inactive STAs

[linux-wireless]

I have good reason to believe that this patch is causing lockups on my machine.

This is because of what I believe to be a very unreliable PCIe connection to
my wireless adapter, which means that it has to be reconfigured regularly.

On kernels with this patch applied however, the kernel seems to get stuck in a
loop doing so, meanwhile spamming the journal with 'Failed
check-sdata-in-driver check' warnings at an astonishing rate.

By instructing the kernel to panic when it detects a hung task, I have been
able to obtain the following stack traces from the persistent store (ignore the
'Tainted' flag, that's just because I omitted a large number of identical
'Failed check-sdata-in-driver check' oopses before this final one):

[ 2227.321477] ------------[ cut here ]------------
[ 2227.321477] wlan0:  Failed check-sdata-in-driver check, flags: 0x0
[ 2227.321486] WARNING: CPU: 3 PID: 6972 at net/mac80211/driver-ops.h:17 drv_sta_state+0x241/0x3e0 [mac80211]
[ 2227.321486] Modules linked in: rfcomm af_packet ctr ccm algif_aead cbc des_generic libdes ecb bnep arc4 algif_skcipher cmac sha512_ssse3 sha512_generic msr md4 algif_hash af_alg nls_iso8859_1 nls_cp437 vfat fat joydev mousedev uvcvideo videobuf2_vmalloc snd_hda_codec_hdmi videobuf2_memops snd_hda_codec_realtek snd_hda_codec_generic videobuf2_v4l2 videobuf2_common btusb x86_pkg_temp_thermal intel_powerclamp coretemp btrtl btbcm iwlmvm crc32_pclmul dell_laptop ledtrig_audio ghash_clmulni_intel videodev dell_wmi btintel mc sparse_keymap mac80211 bluetooth i915 intel_wmi_thunderbolt libarc4 mei_hdcp mei_wdt iTCO_wdt lz4 watchdog dell_smm_hwmon dell_smbios dcdbas intel_rapl_msr ecdh_generic ecc crc16 dell_wmi_descriptor wmi_bmof aesni_intel ppdev cec libaes drm_kms_helper crypto_simd iwlwifi cryptd glue_helper drm intel_cstate intel_gtt e1000e agpgart deflate intel_uncore evdev input_leds efi_pstore tpm_tis pstore tpm_tis_core intel_rapl_perf i2c_algo_bit i2c_i801 snd_hda_intel cfg80211
[ 2227.321497]  fb_sys_fops led_class ptp efivars psmouse mac_hid snd_intel_dspcfg syscopyarea mei_me sysfillrect snd_hda_codec serio_raw sysimgblt snd_hda_core pps_core mei tpm snd_hwdep i2c_core processor_thermal_device 8250_pci intel_rapl_common intel_pch_thermal thermal battery rng_core wmi intel_soc_dts_iosf parport_pc parport video dell_smo8800 backlight int3400_thermal int3403_thermal intel_pmc_core int340x_thermal_zone acpi_thermal_rel acpi_pad ac dell_rbtn ip6table_nat rfkill button iptable_nat nf_nat zra xt_conntrack zsmalloc nf_conntrack nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter ip6table_raw iptable_raw xt_pkttype nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp ip6table_filter ip6_tables iptable_filter sch_fq_codel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore loop cpufreq_powersave tun tap macvlan bridge stp llc kvm_intel kvm irqbypass efivarfs ip_tables x_tables ipv6 nf_defrag_ipv6 crc_ccitt autofs4 poly1305_generic libpoly1305 poly1305_x86_64 chacha_generic
[ 2227.321510]  chacha_x86_64 libchacha bcachefs libcrc32c crc32c_generic zstd_compress xor lz4_compress zstd_decompress crc64 raid6_pq sd_mod t10_pi crc_t10dif crct10dif_generic ahci libahci libata rtsx_pci_sdmmc xhci_pci mmc_core scsi_mod xhci_hcd atkbd libps2 usbcore crct10dif_pclmul crct10dif_common rtsx_pci crc32c_intel usb_common rtc_cmos i8042 serio dm_mod
[ 2227.321516] CPU: 3 PID: 6972 Comm: kworker/3:2 Tainted: G        W         5.6.13 #1-NixOS
[ 2227.321517] Hardware name: Dell Inc. Latitude E5470/0C8FKJ, BIOS 1.19.3 08/20/2018
[ 2227.321520] Workqueue: events_freezable ieee80211_restart_work [mac80211]
[ 2227.321524] RIP: 0010:drv_sta_state+0x241/0x3e0 [mac80211]
[ 2227.321525] Code: 00 45 31 e4 e9 70 fe ff ff 48 8b 83 78 04 00 00 48 8d b3 98 04 00 00 48 c7 c7 d8 0c 40 c1 48 85 c0 48 0f 45 f0 e8 c1 08 8e ec <0f> 0b 41 bc fb ff ff ff e9 47 fe ff ff 65 8b 05 7b 4f c7 3e 89 c0
[ 2227.321526] RSP: 0018:ffffb1255eb43a88 EFLAGS: 00010282
[ 2227.321526] RAX: 0000000000000000 RBX: ffffa088030b28c0 RCX: 0000000000000007
[ 2227.321527] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffffa0886dd99980
[ 2227.321528] RBP: ffffa0880cdd07c0 R08: 00000000001ce0a4 R09: 0000000000000045
[ 2227.321528] R10: ffffb1255eb43938 R11: ffffb1255eb4393d R12: ffffa0880cdd07c0
[ 2227.321529] R13: 0000000000000004 R14: 0000000000000001 R15: 0000000000000003
[ 2227.321530] FS:  0000000000000000(0000) GS:ffffa0886dd80000(0000) knlGS:0000000000000000
[ 2227.321531] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2227.321531] CR2: 00007fbf74e2d000 CR3: 000000064abca002 CR4: 00000000003606e0
[ 2227.321532] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2227.321533] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2227.321533] Call Trace:
[ 2227.321538]  sta_info_move_state+0x18f/0x2b0 [mac80211]
[ 2227.321542]  __sta_info_destroy_part2+0x28/0x150 [mac80211]
[ 2227.321546]  __sta_info_flush+0x123/0x180 [mac80211]
[ 2227.321552]  ieee80211_set_disassoc+0xba/0x5b0 [mac80211]
[ 2227.321557]  ieee80211_mgd_deauth.cold+0x4a/0x1c2 [mac80211]
[ 2227.321562]  cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211]
[ 2227.321563]  ? mpihelp_addmul_1+0x23/0xc0
[ 2227.321568]  cfg80211_disconnect+0x98/0x1e0 [cfg80211]
[ 2227.321572]  cfg80211_leave+0x27/0x40 [cfg80211]
[ 2227.321576]  cfg80211_netdev_notifier_call+0x171/0x4e0 [cfg80211]
[ 2227.321578]  notifier_call_chain+0x4c/0x70
[ 2227.321579]  __dev_close_many+0x5f/0x110
[ 2227.321581]  dev_close_many+0x81/0x130
[ 2227.321581] Kernel panic - not syncing: hung_task: blocked tasks
[ 2227.321583] CPU: 0 PID: 32 Comm: khungtaskd Tainted: G        W         5.6.13 #1-NixOS
[ 2227.321583] Hardware name: Dell Inc. Latitude E5470/0C8FKJ, BIOS 1.19.3 08/20/2018
[ 2227.321584] Call Trace:
[ 2227.321586]  dump_stack+0x66/0x90
[ 2227.321587]  panic+0x101/0x2d7
[ 2227.321589]  watchdog+0x2c4/0x440
[ 2227.321590]  dev_close.part.0+0x3e/0x70
[ 2227.321593]  cfg80211_shutdown_all_interfaces+0x71/0xd0 [cfg80211]
[ 2227.321599]  ieee80211_reconfig+0xa2/0x1480 [mac80211]
[ 2227.321600]  ? try_to_del_timer_sync+0x4f/0x80
[ 2227.321602]  kthread+0xfb/0x130
[ 2227.321603]  ? hungtask_pm_notify+0x40/0x40
[ 2227.321604]  ? kthread_park+0x90/0x90
[ 2227.321605]  ret_from_fork+0x35/0x40
[ 2227.321610]  ieee80211_restart_work+0xb7/0xe0 [mac80211]
[ 2227.321612]  process_one_work+0x1e4/0x390
[ 2227.321613]  worker_thread+0x4d/0x3f0
[ 2227.321615]  kthread+0xfb/0x130
[ 2227.321616]  ? process_one_work+0x390/0x390
[ 2227.321617]  ? kthread_park+0x90/0x90
[ 2227.321619]  ret_from_fork+0x35/0x40
[ 2227.321620] ---[ end trace f9f5d799afd5a59f ]---
[ 2227.321623] Kernel Offset: 0x2cc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

(No Subject)

[hyperfekt]

Subject: Re: [PATCH 8/8] mac80211: IBSS: send deauth when expiring inactive STAs

After running a kernel without the patch some more, I can say that that only
seems to reduce the frequency of the lockups, instead of eliminating them.

I don't really feel capable of debugging this on my own, but the last kernel
version this problem does not occur on is 5.3.

(no subject)

[Vinod Koul]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

Bcc: 
Subject: Re: [usb:usb-testing 57/64] drivers/usb/host/xhci-pci.h:13:5:
 warning: no previous prototype for 'renesas_xhci_check_request_fw'
Reply-To: 
In-Reply-To: <202005191716.5gO1jQGg%lkp@intel.com>

On 19-05-20, 17:08, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> head:   df00731cffa0edb454ee0c490696ce0c1745e680
> commit: a66d21d7dba84deeaf3b296c43eafc11094b6f09 [57/64] usb: xhci: Add support for Renesas controller with memory
> config: m68k-randconfig-r012-20200519 (attached as .config)
> compiler: m68k-linux-gcc (GCC) 9.3.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout a66d21d7dba84deeaf3b296c43eafc11094b6f09
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot <lkp@intel.com>

Thanks for the report, yes missed making these symbols static when
CONFIG_USB_XHCI_PCI_RENESAS is not set

Greg,

Sending the patch now, and sorry for too much noise on these :(

-- 
~Vinod

(no subject)

[Ville Syrjälä]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Message-ID: <20200226115708.GH13686@intel.com>
References: <20200219203544.31013-1-ville.syrjala@linux.intel.com>
 <CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f@eucas1p2.samsung.com>
 <20200219203544.31013-5-ville.syrjala@linux.intel.com>
 <0f278771-79ce-fe23-e72c-3935dbe82d24@samsung.com>
 <20200225112114.GA13686@intel.com>
 <3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
 <20200225154506.GF13686@intel.com>
 <20200225192720.GG13686@intel.com>
 <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACRpkdZk9QEy+Kzkmy4BXiHB+aq9hprf=dmA_-R23yqH3NCt1g@mail.gmail.com>
X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)

On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> 
> > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
> 
> That's impressive :D
> 
> > Unfortunately it found a lot of strange stuff:
> 
> I will answer for the weirdness I caused.
> 
> I have long suspected that a whole bunch of the "simple" displays
> are not simple but contains a display controller and memory.
> That means that the speed over the link to the display and
> actual refresh rate on the actual display is asymmetric because
> well we are just updating a RAM, the resolution just limits how
> much data we are sending, the clock limits the speed on the
> bus over to the RAM on the other side.

IMO even in command mode mode->clock should probably be the actual
dotclock used by the display. If there's another clock for the bus
speed/etc. it should be stored somewhere else.

-- 
Ville Syrjälä
Intel

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Linus Walleij]

On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:

> > I have long suspected that a whole bunch of the "simple" displays
> > are not simple but contains a display controller and memory.
> > That means that the speed over the link to the display and
> > actual refresh rate on the actual display is asymmetric because
> > well we are just updating a RAM, the resolution just limits how
> > much data we are sending, the clock limits the speed on the
> > bus over to the RAM on the other side.
>
> IMO even in command mode mode->clock should probably be the actual
> dotclock used by the display. If there's another clock for the bus
> speed/etc. it should be stored somewhere else.

Good point. For the DSI panels we have the field hs_rate
for the HS clock in struct mipi_dsi_device which is based
on exactly this reasoning. And that is what I actually use for
setting the HS clock.

The problem is however that we in many cases have so
substandard documentation of these panels that we have
absolutely no idea about the dotclock. Maybe we should
just set it to 0 in these cases?

Yours,
Linus Walleij
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Ville Syrjälä]

On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> 
> > > I have long suspected that a whole bunch of the "simple" displays
> > > are not simple but contains a display controller and memory.
> > > That means that the speed over the link to the display and
> > > actual refresh rate on the actual display is asymmetric because
> > > well we are just updating a RAM, the resolution just limits how
> > > much data we are sending, the clock limits the speed on the
> > > bus over to the RAM on the other side.
> >
> > IMO even in command mode mode->clock should probably be the actual
> > dotclock used by the display. If there's another clock for the bus
> > speed/etc. it should be stored somewhere else.
> 
> Good point. For the DSI panels we have the field hs_rate
> for the HS clock in struct mipi_dsi_device which is based
> on exactly this reasoning. And that is what I actually use for
> setting the HS clock.
> 
> The problem is however that we in many cases have so
> substandard documentation of these panels that we have
> absolutely no idea about the dotclock. Maybe we should
> just set it to 0 in these cases?

Don't you always have a TE interrupt or something like that
available? Could just measure it from that if no better
information is available?

-- 
Ville Syrjälä
Intel

Re: (no subject)

[Linus Walleij]

On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> >
> > > > I have long suspected that a whole bunch of the "simple" displays
> > > > are not simple but contains a display controller and memory.
> > > > That means that the speed over the link to the display and
> > > > actual refresh rate on the actual display is asymmetric because
> > > > well we are just updating a RAM, the resolution just limits how
> > > > much data we are sending, the clock limits the speed on the
> > > > bus over to the RAM on the other side.
> > >
> > > IMO even in command mode mode->clock should probably be the actual
> > > dotclock used by the display. If there's another clock for the bus
> > > speed/etc. it should be stored somewhere else.
> >
> > Good point. For the DSI panels we have the field hs_rate
> > for the HS clock in struct mipi_dsi_device which is based
> > on exactly this reasoning. And that is what I actually use for
> > setting the HS clock.
> >
> > The problem is however that we in many cases have so
> > substandard documentation of these panels that we have
> > absolutely no idea about the dotclock. Maybe we should
> > just set it to 0 in these cases?
>
> Don't you always have a TE interrupt or something like that
> available? Could just measure it from that if no better
> information is available?

Yes and I did exactly that, so that is why this comment is in
the driver:

static const struct drm_display_mode sony_acx424akp_cmd_mode = {
(...)
        /*
         * Some desired refresh rate, experiments at the maximum "pixel"
         * clock speed (HS clock 420 MHz) yields around 117Hz.
         */
        .vrefresh = 60,

I got a review comment at the time saying 117 Hz was weird.
We didn't reach a proper conclusion on this:
https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=Lg@mail.gmail.com/

Thierry wasn't sure if 60Hz was good or not, so I just had to
go with something.

We could calculate the resulting pixel clock for ~117 Hz with
this resolution and put that in the clock field but ... don't know
what is the best?

Yours,
Linus Walleij
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Ville Syrjälä]

On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> > >
> > > > > I have long suspected that a whole bunch of the "simple" displays
> > > > > are not simple but contains a display controller and memory.
> > > > > That means that the speed over the link to the display and
> > > > > actual refresh rate on the actual display is asymmetric because
> > > > > well we are just updating a RAM, the resolution just limits how
> > > > > much data we are sending, the clock limits the speed on the
> > > > > bus over to the RAM on the other side.
> > > >
> > > > IMO even in command mode mode->clock should probably be the actual
> > > > dotclock used by the display. If there's another clock for the bus
> > > > speed/etc. it should be stored somewhere else.
> > >
> > > Good point. For the DSI panels we have the field hs_rate
> > > for the HS clock in struct mipi_dsi_device which is based
> > > on exactly this reasoning. And that is what I actually use for
> > > setting the HS clock.
> > >
> > > The problem is however that we in many cases have so
> > > substandard documentation of these panels that we have
> > > absolutely no idea about the dotclock. Maybe we should
> > > just set it to 0 in these cases?
> >
> > Don't you always have a TE interrupt or something like that
> > available? Could just measure it from that if no better
> > information is available?
> 
> Yes and I did exactly that, so that is why this comment is in
> the driver:
> 
> static const struct drm_display_mode sony_acx424akp_cmd_mode = {
> (...)
>         /*
>          * Some desired refresh rate, experiments at the maximum "pixel"
>          * clock speed (HS clock 420 MHz) yields around 117Hz.
>          */
>         .vrefresh = 60,
> 
> I got a review comment at the time saying 117 Hz was weird.
> We didn't reach a proper conclusion on this:
> https://lore.kernel.org/dri-devel/CACRpkdYW3YNPSNMY3A44GQn8DqK-n9TLvr7uipF7LM_DHZ5=Lg@mail.gmail.com/
> 
> Thierry wasn't sure if 60Hz was good or not, so I just had to
> go with something.
> 
> We could calculate the resulting pixel clock for ~117 Hz with
> this resolution and put that in the clock field but ... don't know
> what is the best?

I would vote for that approach.

-- 
Ville Syrjälä
Intel

Re: [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Ben Dooks]

On 20/12/2019 16:40, Dmitry Osipenko wrote:
> 20.12.2019 18:25, Ben Dooks пишет:
>> On 20/12/2019 15:02, Dmitry Osipenko wrote:
>>> 20.12.2019 17:56, Ben Dooks пишет:
>>>> On 20/12/2019 14:43, Dmitry Osipenko wrote:
>>>>> 20.12.2019 16:57, Jon Hunter пишет:
>>>>>>
>>>>>> On 20/12/2019 11:38, Ben Dooks wrote:
>>>>>>> On 20/12/2019 11:30, Jon Hunter wrote:
>>>>>>>>
>>>>>>>> On 25/11/2019 17:28, Dmitry Osipenko wrote:
>>>>>>>>> 25.11.2019 20:22, Dmitry Osipenko пишет:
>>>>>>>>>> 25.11.2019 13:37, Ben Dooks пишет:
>>>>>>>>>>> On 23/11/2019 21:09, Dmitry Osipenko wrote:
>>>>>>>>>>>> 18.10.2019 18:48, Ben Dooks пишет:
>>>>>>>>>>>>> From: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The tegra3 audio can support 24 and 32 bit sample sizes so add
>>>>>>>>>>>>> the
>>>>>>>>>>>>> option to the tegra30_i2s_hw_params to configure the S24_LE or
>>>>>>>>>>>>> S32_LE
>>>>>>>>>>>>> formats when requested.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: fixup merge of 24 and 32bit]
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: add pm calls around ytdm config]
>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: drop debug printing to dev_dbg]
>>>>>>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> squash 5aeca5a055fd ASoC: tegra: i2s: pm_runtime_get_sync() is
>>>>>>>>>>>>> needed
>>>>>>>>>>>>> in tdm code
>>>>>>>>>>>>>
>>>>>>>>>>>>> ASoC: tegra: i2s: pm_runtime_get_sync() is needed in tdm code
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>       sound/soc/tegra/tegra30_i2s.c | 25
>>>>>>>>>>>>> ++++++++++++++++++++-----
>>>>>>>>>>>>>       1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> index 73f0dddeaef3..063f34c882af 100644
>>>>>>>>>>>>> --- a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> +++ b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>> @@ -127,7 +127,7 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>           struct device *dev = dai->dev;
>>>>>>>>>>>>>           struct tegra30_i2s *i2s =
>>>>>>>>>>>>> snd_soc_dai_get_drvdata(dai);
>>>>>>>>>>>>>           unsigned int mask, val, reg;
>>>>>>>>>>>>> -    int ret, sample_size, srate, i2sclock, bitcnt;
>>>>>>>>>>>>> +    int ret, sample_size, srate, i2sclock, bitcnt, audio_bits;
>>>>>>>>>>>>>           struct tegra30_ahub_cif_conf cif_conf;
>>>>>>>>>>>>>             if (params_channels(params) != 2)
>>>>>>>>>>>>> @@ -137,8 +137,19 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>           switch (params_format(params)) {
>>>>>>>>>>>>>           case SNDRV_PCM_FORMAT_S16_LE:
>>>>>>>>>>>>>               val = TEGRA30_I2S_CTRL_BIT_SIZE_16;
>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>>               sample_size = 16;
>>>>>>>>>>>>>               break;
>>>>>>>>>>>>> +    case SNDRV_PCM_FORMAT_S24_LE:
>>>>>>>>>>>>> +        val = TEGRA30_I2S_CTRL_BIT_SIZE_24;
>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_24;
>>>>>>>>>>>>> +        sample_size = 24;
>>>>>>>>>>>>> +        break;
>>>>>>>>>>>>> +    case SNDRV_PCM_FORMAT_S32_LE:
>>>>>>>>>>>>> +        val = TEGRA30_I2S_CTRL_BIT_SIZE_32;
>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_32;
>>>>>>>>>>>>> +        sample_size = 32;
>>>>>>>>>>>>> +        break;
>>>>>>>>>>>>>           default:
>>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>>           }
>>>>>>>>>>>>> @@ -170,8 +181,8 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>           cif_conf.threshold = 0;
>>>>>>>>>>>>>           cif_conf.audio_channels = 2;
>>>>>>>>>>>>>           cif_conf.client_channels = 2;
>>>>>>>>>>>>> -    cif_conf.audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>> -    cif_conf.client_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>> +    cif_conf.audio_bits = audio_bits;
>>>>>>>>>>>>> +    cif_conf.client_bits = audio_bits;
>>>>>>>>>>>>>           cif_conf.expand = 0;
>>>>>>>>>>>>>           cif_conf.stereo_conv = 0;
>>>>>>>>>>>>>           cif_conf.replicate = 0;
>>>>>>>>>>>>> @@ -306,14 +317,18 @@ static const struct snd_soc_dai_driver
>>>>>>>>>>>>> tegra30_i2s_dai_template = {
>>>>>>>>>>>>>               .channels_min = 2,
>>>>>>>>>>>>>               .channels_max = 2,
>>>>>>>>>>>>>               .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>> -        .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> +        .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>           },
>>>>>>>>>>>>>           .capture = {
>>>>>>>>>>>>>               .stream_name = "Capture",
>>>>>>>>>>>>>               .channels_min = 2,
>>>>>>>>>>>>>               .channels_max = 2,
>>>>>>>>>>>>>               .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>> -        .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>> +        .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>           },
>>>>>>>>>>>>>           .ops = &tegra30_i2s_dai_ops,
>>>>>>>>>>>>>           .symmetric_rates = 1,
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> This patch breaks audio on Tegra30. I don't see errors
>>>>>>>>>>>> anywhere, but
>>>>>>>>>>>> there is no audio and reverting this patch helps. Please fix it.
>>>>>>>>>>>
>>>>>>>>>>> What is the failure mode? I can try and take a look at this some
>>>>>>>>>>> time
>>>>>>>>>>> this week, but I am not sure if I have any boards with an actual
>>>>>>>>>>> useful
>>>>>>>>>>> audio output?
>>>>>>>>>>
>>>>>>>>>> The failure mode is that there no sound. I also noticed that video
>>>>>>>>>> playback stutters a lot if movie file has audio track, seems
>>>>>>>>>> something
>>>>>>>>>> times out during of the audio playback. For now I don't have any
>>>>>>>>>> more info.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Oh, I didn't say how to reproduce it.. for example simply playing
>>>>>>>>> big_buck_bunny_720p_h264.mov in MPV has the audio problem.
>>>>>>>>>
>>>>>>>>> https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_h264.mov
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Given that the audio drivers uses regmap, it could be good to
>>>>>>>> dump the
>>>>>>>> I2S/AHUB registers while the clip if playing with and without this
>>>>>>>> patch
>>>>>>>> to see the differences. I am curious if the audio is now being
>>>>>>>> played as
>>>>>>>> 24 or 32-bit instead of 16-bit now these are available.
>>>>>>>>
>>>>>>>> You could also dump the hw_params to see the format while playing as
>>>>>>>> well ...
>>>>>>>>
>>>>>>>> $ /proc/asound/<scard-name>/pcm0p/sub0/hw_params
>>>>>>>
>>>>>>> I suppose it is also possible that the codec isn't properly doing >16
>>>>>>> bits and the fact we now offer 24 and 32 could be an issue. I've not
>>>>>>> got anything with an audio output on it that would be easy to test.
>>>>>>
>>>>>> I thought I had tested on a Jetson TK1 (Tegra124) but it was sometime
>>>>>> back. However, admittedly I may have only done simple 16-bit testing
>>>>>> with speaker-test.
>>>>>>
>>>>>> We do verify that all soundcards are detected and registered as
>>>>>> expected
>>>>>> during daily testing, but at the moment we don't have anything that
>>>>>> verifies actual playback.
>>>>>
>>>>> Please take a look at the attached logs.
>>>>
>>>> I wonder if we are falling into FIFO configuration issues with the
>>>> non-16 bit case.
>>>>
>>>> Can you try adding the following two patches?
>>>
>>> It is much better now! There is no horrible noise and no stuttering, but
>>> audio still has a "robotic" effect, like freq isn't correct.
>>
>> I wonder if there's an issue with FIFO stoking? I should also possibly
>> add the correctly stop FIFOs patch as well.
> 
> I'll be happy to try more patches.
> 
> Meanwhile sound on v5.5+ is broken and thus the incomplete patches
> should be reverted.

Have you checked if just removing the 24/32 bits from .formats in
the dai template and see if the problem continues? I will try and
see if I can find the code that does the fifo level checking and
see if the problem is in the FIFO fill or something else in the
audio hub setup.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

20.12.2019 20:06, Ben Dooks пишет:
> On 20/12/2019 16:40, Dmitry Osipenko wrote:
>> 20.12.2019 18:25, Ben Dooks пишет:
>>> On 20/12/2019 15:02, Dmitry Osipenko wrote:
>>>> 20.12.2019 17:56, Ben Dooks пишет:
>>>>> On 20/12/2019 14:43, Dmitry Osipenko wrote:
>>>>>> 20.12.2019 16:57, Jon Hunter пишет:
>>>>>>>
>>>>>>> On 20/12/2019 11:38, Ben Dooks wrote:
>>>>>>>> On 20/12/2019 11:30, Jon Hunter wrote:
>>>>>>>>>
>>>>>>>>> On 25/11/2019 17:28, Dmitry Osipenko wrote:
>>>>>>>>>> 25.11.2019 20:22, Dmitry Osipenko пишет:
>>>>>>>>>>> 25.11.2019 13:37, Ben Dooks пишет:
>>>>>>>>>>>> On 23/11/2019 21:09, Dmitry Osipenko wrote:
>>>>>>>>>>>>> 18.10.2019 18:48, Ben Dooks пишет:
>>>>>>>>>>>>>> From: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The tegra3 audio can support 24 and 32 bit sample sizes so
>>>>>>>>>>>>>> add
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> option to the tegra30_i2s_hw_params to configure the
>>>>>>>>>>>>>> S24_LE or
>>>>>>>>>>>>>> S32_LE
>>>>>>>>>>>>>> formats when requested.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Edward Cragg <edward.cragg@codethink.co.uk>
>>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: fixup merge of 24 and 32bit]
>>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: add pm calls around ytdm config]
>>>>>>>>>>>>>> [ben.dooks@codethink.co.uk: drop debug printing to dev_dbg]
>>>>>>>>>>>>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> squash 5aeca5a055fd ASoC: tegra: i2s:
>>>>>>>>>>>>>> pm_runtime_get_sync() is
>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>> in tdm code
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ASoC: tegra: i2s: pm_runtime_get_sync() is needed in tdm code
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>       sound/soc/tegra/tegra30_i2s.c | 25
>>>>>>>>>>>>>> ++++++++++++++++++++-----
>>>>>>>>>>>>>>       1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>>> b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>>> index 73f0dddeaef3..063f34c882af 100644
>>>>>>>>>>>>>> --- a/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>>> +++ b/sound/soc/tegra/tegra30_i2s.c
>>>>>>>>>>>>>> @@ -127,7 +127,7 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>>           struct device *dev = dai->dev;
>>>>>>>>>>>>>>           struct tegra30_i2s *i2s =
>>>>>>>>>>>>>> snd_soc_dai_get_drvdata(dai);
>>>>>>>>>>>>>>           unsigned int mask, val, reg;
>>>>>>>>>>>>>> -    int ret, sample_size, srate, i2sclock, bitcnt;
>>>>>>>>>>>>>> +    int ret, sample_size, srate, i2sclock, bitcnt,
>>>>>>>>>>>>>> audio_bits;
>>>>>>>>>>>>>>           struct tegra30_ahub_cif_conf cif_conf;
>>>>>>>>>>>>>>             if (params_channels(params) != 2)
>>>>>>>>>>>>>> @@ -137,8 +137,19 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>>           switch (params_format(params)) {
>>>>>>>>>>>>>>           case SNDRV_PCM_FORMAT_S16_LE:
>>>>>>>>>>>>>>               val = TEGRA30_I2S_CTRL_BIT_SIZE_16;
>>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>>>               sample_size = 16;
>>>>>>>>>>>>>>               break;
>>>>>>>>>>>>>> +    case SNDRV_PCM_FORMAT_S24_LE:
>>>>>>>>>>>>>> +        val = TEGRA30_I2S_CTRL_BIT_SIZE_24;
>>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_24;
>>>>>>>>>>>>>> +        sample_size = 24;
>>>>>>>>>>>>>> +        break;
>>>>>>>>>>>>>> +    case SNDRV_PCM_FORMAT_S32_LE:
>>>>>>>>>>>>>> +        val = TEGRA30_I2S_CTRL_BIT_SIZE_32;
>>>>>>>>>>>>>> +        audio_bits = TEGRA30_AUDIOCIF_BITS_32;
>>>>>>>>>>>>>> +        sample_size = 32;
>>>>>>>>>>>>>> +        break;
>>>>>>>>>>>>>>           default:
>>>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>>>           }
>>>>>>>>>>>>>> @@ -170,8 +181,8 @@ static int tegra30_i2s_hw_params(struct
>>>>>>>>>>>>>> snd_pcm_substream *substream,
>>>>>>>>>>>>>>           cif_conf.threshold = 0;
>>>>>>>>>>>>>>           cif_conf.audio_channels = 2;
>>>>>>>>>>>>>>           cif_conf.client_channels = 2;
>>>>>>>>>>>>>> -    cif_conf.audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>>> -    cif_conf.client_bits = TEGRA30_AUDIOCIF_BITS_16;
>>>>>>>>>>>>>> +    cif_conf.audio_bits = audio_bits;
>>>>>>>>>>>>>> +    cif_conf.client_bits = audio_bits;
>>>>>>>>>>>>>>           cif_conf.expand = 0;
>>>>>>>>>>>>>>           cif_conf.stereo_conv = 0;
>>>>>>>>>>>>>>           cif_conf.replicate = 0;
>>>>>>>>>>>>>> @@ -306,14 +317,18 @@ static const struct snd_soc_dai_driver
>>>>>>>>>>>>>> tegra30_i2s_dai_template = {
>>>>>>>>>>>>>>               .channels_min = 2,
>>>>>>>>>>>>>>               .channels_max = 2,
>>>>>>>>>>>>>>               .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>>> -        .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>> +        .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>>           },
>>>>>>>>>>>>>>           .capture = {
>>>>>>>>>>>>>>               .stream_name = "Capture",
>>>>>>>>>>>>>>               .channels_min = 2,
>>>>>>>>>>>>>>               .channels_max = 2,
>>>>>>>>>>>>>>               .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>>>>>>> -        .formats = SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>> +        .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>>>>>>>> +               SNDRV_PCM_FMTBIT_S16_LE,
>>>>>>>>>>>>>>           },
>>>>>>>>>>>>>>           .ops = &tegra30_i2s_dai_ops,
>>>>>>>>>>>>>>           .symmetric_rates = 1,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch breaks audio on Tegra30. I don't see errors
>>>>>>>>>>>>> anywhere, but
>>>>>>>>>>>>> there is no audio and reverting this patch helps. Please
>>>>>>>>>>>>> fix it.
>>>>>>>>>>>>
>>>>>>>>>>>> What is the failure mode? I can try and take a look at this
>>>>>>>>>>>> some
>>>>>>>>>>>> time
>>>>>>>>>>>> this week, but I am not sure if I have any boards with an
>>>>>>>>>>>> actual
>>>>>>>>>>>> useful
>>>>>>>>>>>> audio output?
>>>>>>>>>>>
>>>>>>>>>>> The failure mode is that there no sound. I also noticed that
>>>>>>>>>>> video
>>>>>>>>>>> playback stutters a lot if movie file has audio track, seems
>>>>>>>>>>> something
>>>>>>>>>>> times out during of the audio playback. For now I don't have any
>>>>>>>>>>> more info.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Oh, I didn't say how to reproduce it.. for example simply playing
>>>>>>>>>> big_buck_bunny_720p_h264.mov in MPV has the audio problem.
>>>>>>>>>>
>>>>>>>>>> https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_h264.mov
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Given that the audio drivers uses regmap, it could be good to
>>>>>>>>> dump the
>>>>>>>>> I2S/AHUB registers while the clip if playing with and without this
>>>>>>>>> patch
>>>>>>>>> to see the differences. I am curious if the audio is now being
>>>>>>>>> played as
>>>>>>>>> 24 or 32-bit instead of 16-bit now these are available.
>>>>>>>>>
>>>>>>>>> You could also dump the hw_params to see the format while
>>>>>>>>> playing as
>>>>>>>>> well ...
>>>>>>>>>
>>>>>>>>> $ /proc/asound/<scard-name>/pcm0p/sub0/hw_params
>>>>>>>>
>>>>>>>> I suppose it is also possible that the codec isn't properly
>>>>>>>> doing >16
>>>>>>>> bits and the fact we now offer 24 and 32 could be an issue. I've
>>>>>>>> not
>>>>>>>> got anything with an audio output on it that would be easy to test.
>>>>>>>
>>>>>>> I thought I had tested on a Jetson TK1 (Tegra124) but it was
>>>>>>> sometime
>>>>>>> back. However, admittedly I may have only done simple 16-bit testing
>>>>>>> with speaker-test.
>>>>>>>
>>>>>>> We do verify that all soundcards are detected and registered as
>>>>>>> expected
>>>>>>> during daily testing, but at the moment we don't have anything that
>>>>>>> verifies actual playback.
>>>>>>
>>>>>> Please take a look at the attached logs.
>>>>>
>>>>> I wonder if we are falling into FIFO configuration issues with the
>>>>> non-16 bit case.
>>>>>
>>>>> Can you try adding the following two patches?
>>>>
>>>> It is much better now! There is no horrible noise and no stuttering,
>>>> but
>>>> audio still has a "robotic" effect, like freq isn't correct.
>>>
>>> I wonder if there's an issue with FIFO stoking? I should also possibly
>>> add the correctly stop FIFOs patch as well.
>>
>> I'll be happy to try more patches.
>>
>> Meanwhile sound on v5.5+ is broken and thus the incomplete patches
>> should be reverted.
> 
> Have you checked if just removing the 24/32 bits from .formats in
> the dai template and see if the problem continues? 

It works.

> I will try and
> see if I can find the code that does the fifo level checking and
> see if the problem is in the FIFO fill or something else in the
> audio hub setup.

Ok
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Ben Dooks]

[snip]

I've just gone through testing.

Some simple data tests show 16 and 32-bits work.

The 24 bit case seems to be weird, it looks like the 24-bit expects
24 bit samples in 32 bit words. I can't see any packing options to
do 24 bit in 24 bit, so we may have to remove 24 bit sample support
(which is a shame)

My preference is to remove the 24-bit support and keep the 32 bit in.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

05.01.2020 03:04, Ben Dooks пишет:
> [snip]
> 
> I've just gone through testing.
> 
> Some simple data tests show 16 and 32-bits work.
> 
> The 24 bit case seems to be weird, it looks like the 24-bit expects
> 24 bit samples in 32 bit words. I can't see any packing options to
> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
> (which is a shame)
> 
> My preference is to remove the 24-bit support and keep the 32 bit in.
> 

Interesting.. Jon, could you please confirm that 24bit format isn't
usable on T30?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Ben Dooks]

On 2020-01-05 01:48, Dmitry Osipenko wrote:
> 05.01.2020 03:04, Ben Dooks пишет:
>> [snip]
>> 
>> I've just gone through testing.
>> 
>> Some simple data tests show 16 and 32-bits work.
>> 
>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>> 24 bit samples in 32 bit words. I can't see any packing options to
>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>> (which is a shame)
>> 
>> My preference is to remove the 24-bit support and keep the 32 bit in.
>> 
> 
> Interesting.. Jon, could you please confirm that 24bit format isn't
> usable on T30?

If there is an option of 24 packed into 32, then I think that would 
work.

I can try testing that with raw data on Monday.

-- 
Ben

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Ben Dooks]

On 05/01/2020 10:53, Ben Dooks wrote:
> 
> 
> On 2020-01-05 01:48, Dmitry Osipenko wrote:
>> 05.01.2020 03:04, Ben Dooks пишет:
>>> [snip]
>>>
>>> I've just gone through testing.
>>>
>>> Some simple data tests show 16 and 32-bits work.
>>>
>>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>>> 24 bit samples in 32 bit words. I can't see any packing options to
>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>>> (which is a shame)
>>>
>>> My preference is to remove the 24-bit support and keep the 32 bit in.
>>>
>>
>> Interesting.. Jon, could you please confirm that 24bit format isn't
>> usable on T30?
> 
> If there is an option of 24 packed into 32, then I think that would work.
> 
> I can try testing that with raw data on Monday.

I need to check some things, I assumed 24 was 24 packed bits, it looks
like the default is 24 in 32 bits so we may be ok. However I need to
re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE).

I'll follow up later,



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

06.01.2020 22:00, Ben Dooks пишет:
> On 05/01/2020 10:53, Ben Dooks wrote:
>>
>>
>> On 2020-01-05 01:48, Dmitry Osipenko wrote:
>>> 05.01.2020 03:04, Ben Dooks пишет:
>>>> [snip]
>>>>
>>>> I've just gone through testing.
>>>>
>>>> Some simple data tests show 16 and 32-bits work.
>>>>
>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>>>> 24 bit samples in 32 bit words. I can't see any packing options to
>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>>>> (which is a shame)
>>>>
>>>> My preference is to remove the 24-bit support and keep the 32 bit in.
>>>>
>>>
>>> Interesting.. Jon, could you please confirm that 24bit format isn't
>>> usable on T30?
>>
>> If there is an option of 24 packed into 32, then I think that would work.
>>
>> I can try testing that with raw data on Monday.
> 
> I need to check some things, I assumed 24 was 24 packed bits, it looks
> like the default is 24 in 32 bits so we may be ok. However I need to
> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE).
> 
> I'll follow up later,

Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly
looked through the TRM doc and got impression that AHUB could re-pack
data stream into something that codec supports, but maybe it's a wrong
impression.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Ben Dooks]

On 07/01/2020 01:39, Dmitry Osipenko wrote:
> 06.01.2020 22:00, Ben Dooks пишет:
>> On 05/01/2020 10:53, Ben Dooks wrote:
>>>
>>>
>>> On 2020-01-05 01:48, Dmitry Osipenko wrote:
>>>> 05.01.2020 03:04, Ben Dooks пишет:
>>>>> [snip]
>>>>>
>>>>> I've just gone through testing.
>>>>>
>>>>> Some simple data tests show 16 and 32-bits work.
>>>>>
>>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>>>>> 24 bit samples in 32 bit words. I can't see any packing options to
>>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>>>>> (which is a shame)
>>>>>
>>>>> My preference is to remove the 24-bit support and keep the 32 bit in.
>>>>>
>>>>
>>>> Interesting.. Jon, could you please confirm that 24bit format isn't
>>>> usable on T30?
>>>
>>> If there is an option of 24 packed into 32, then I think that would work.
>>>
>>> I can try testing that with raw data on Monday.
>>
>> I need to check some things, I assumed 24 was 24 packed bits, it looks
>> like the default is 24 in 32 bits so we may be ok. However I need to
>> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE).
>>
>> I'll follow up later,
> 
> Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly
> looked through the TRM doc and got impression that AHUB could re-pack
> data stream into something that codec supports, but maybe it's a wrong
> impression.
> _________________________________

I did a quick test with the following:

  sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
  sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
  sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5

The 16 and 32 work fine, the 24 is showing a playback output freq
of 440Hz instead of 500Hz... this suggests the clock is off, or there
is something else weird going on...

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Jon Hunter]

On 23/01/2020 19:38, Ben Dooks wrote:
> On 07/01/2020 01:39, Dmitry Osipenko wrote:
>> 06.01.2020 22:00, Ben Dooks пишет:
>>> On 05/01/2020 10:53, Ben Dooks wrote:
>>>>
>>>>
>>>> On 2020-01-05 01:48, Dmitry Osipenko wrote:
>>>>> 05.01.2020 03:04, Ben Dooks пишет:
>>>>>> [snip]
>>>>>>
>>>>>> I've just gone through testing.
>>>>>>
>>>>>> Some simple data tests show 16 and 32-bits work.
>>>>>>
>>>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>>>>>> 24 bit samples in 32 bit words. I can't see any packing options to
>>>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>>>>>> (which is a shame)
>>>>>>
>>>>>> My preference is to remove the 24-bit support and keep the 32 bit in.
>>>>>>
>>>>>
>>>>> Interesting.. Jon, could you please confirm that 24bit format isn't
>>>>> usable on T30?
>>>>
>>>> If there is an option of 24 packed into 32, then I think that would
>>>> work.
>>>>
>>>> I can try testing that with raw data on Monday.
>>>
>>> I need to check some things, I assumed 24 was 24 packed bits, it looks
>>> like the default is 24 in 32 bits so we may be ok. However I need to
>>> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE).
>>>
>>> I'll follow up later,
>>
>> Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly
>> looked through the TRM doc and got impression that AHUB could re-pack
>> data stream into something that codec supports, but maybe it's a wrong
>> impression.
>> _________________________________
> 
> I did a quick test with the following:
> 
>  sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
>  sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
>  sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
> 
> The 16 and 32 work fine, the 24 is showing a playback output freq
> of 440Hz instead of 500Hz... this suggests the clock is off, or there
> is something else weird going on...

I was looking at using sox to create such as file, but the above command
generates a S24_3LE file and not S24_LE file. The codec on Jetson-TK1
supports S24_LE but does not support S24_3LE and so I cannot test this.
Anyway, we really need to test S24_LE and not S24_3LE because this is
the problem that Dmitry is having.

Ben is S24_3LE what you really need to support?

Dmitry, does the following fix your problem?

diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
index dbed3c5408e7..92845c4b63f4 100644
--- a/sound/soc/tegra/tegra30_i2s.c
+++ b/sound/soc/tegra/tegra30_i2s.c
@@ -140,7 +140,7 @@ static int tegra30_i2s_hw_params(struct
snd_pcm_substream *substream,
                audio_bits = TEGRA30_AUDIOCIF_BITS_16;
                sample_size = 16;
                break;
-       case SNDRV_PCM_FORMAT_S24_LE:
+       case SNDRV_PCM_FORMAT_S24_3LE:
                val = TEGRA30_I2S_CTRL_BIT_SIZE_24;
                audio_bits = TEGRA30_AUDIOCIF_BITS_24;
                sample_size = 24;
@@ -318,7 +318,7 @@ static const struct snd_soc_dai_driver
tegra30_i2s_dai_template = {
                .channels_max = 2,
                .rates = SNDRV_PCM_RATE_8000_96000,
                .formats = SNDRV_PCM_FMTBIT_S32_LE |
-                          SNDRV_PCM_FMTBIT_S24_LE |
+                          SNDRV_PCM_FMTBIT_S24_3LE |
                           SNDRV_PCM_FMTBIT_S16_LE,
        },
        .capture = {
@@ -327,7 +327,7 @@ static const struct snd_soc_dai_driver
tegra30_i2s_dai_template = {
                .channels_max = 2,
                .rates = SNDRV_PCM_RATE_8000_96000,
                .formats = SNDRV_PCM_FMTBIT_S32_LE |
-                          SNDRV_PCM_FMTBIT_S24_LE |
+                          SNDRV_PCM_FMTBIT_S24_3LE |
                           SNDRV_PCM_FMTBIT_S16_LE,
        },
        .ops = &tegra30_i2s_dai_ops,

Jon

-- 
nvpublic

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

24.01.2020 19:50, Jon Hunter пишет:
> 
> On 23/01/2020 19:38, Ben Dooks wrote:
>> On 07/01/2020 01:39, Dmitry Osipenko wrote:
>>> 06.01.2020 22:00, Ben Dooks пишет:
>>>> On 05/01/2020 10:53, Ben Dooks wrote:
>>>>>
>>>>>
>>>>> On 2020-01-05 01:48, Dmitry Osipenko wrote:
>>>>>> 05.01.2020 03:04, Ben Dooks пишет:
>>>>>>> [snip]
>>>>>>>
>>>>>>> I've just gone through testing.
>>>>>>>
>>>>>>> Some simple data tests show 16 and 32-bits work.
>>>>>>>
>>>>>>> The 24 bit case seems to be weird, it looks like the 24-bit expects
>>>>>>> 24 bit samples in 32 bit words. I can't see any packing options to
>>>>>>> do 24 bit in 24 bit, so we may have to remove 24 bit sample support
>>>>>>> (which is a shame)
>>>>>>>
>>>>>>> My preference is to remove the 24-bit support and keep the 32 bit in.
>>>>>>>
>>>>>>
>>>>>> Interesting.. Jon, could you please confirm that 24bit format isn't
>>>>>> usable on T30?
>>>>>
>>>>> If there is an option of 24 packed into 32, then I think that would
>>>>> work.
>>>>>
>>>>> I can try testing that with raw data on Monday.
>>>>
>>>> I need to check some things, I assumed 24 was 24 packed bits, it looks
>>>> like the default is 24 in 32 bits so we may be ok. However I need to
>>>> re-write my test case which assumed it was 24bits in 3 bytes (S24_3LE).
>>>>
>>>> I'll follow up later,
>>>
>>> Okay, the S24_3LE isn't supported by RT5640 codec in my case. I briefly
>>> looked through the TRM doc and got impression that AHUB could re-pack
>>> data stream into something that codec supports, but maybe it's a wrong
>>> impression.
>>> _________________________________
>>
>> I did a quick test with the following:
>>
>>  sox -n -b 16 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
>>  sox -n -b 24 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
>>  sox -n -b 32 -c 2 -r 44100 /tmp/tmp.wav  synth sine 500 vol 0.5
>>
>> The 16 and 32 work fine, the 24 is showing a playback output freq
>> of 440Hz instead of 500Hz... this suggests the clock is off, or there
>> is something else weird going on...
> 
> I was looking at using sox to create such as file, but the above command
> generates a S24_3LE file and not S24_LE file. The codec on Jetson-TK1
> supports S24_LE but does not support S24_3LE and so I cannot test this.
> Anyway, we really need to test S24_LE and not S24_3LE because this is
> the problem that Dmitry is having.
> 
> Ben is S24_3LE what you really need to support?
> 
> Dmitry, does the following fix your problem?
> 
> diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
> index dbed3c5408e7..92845c4b63f4 100644
> --- a/sound/soc/tegra/tegra30_i2s.c
> +++ b/sound/soc/tegra/tegra30_i2s.c
> @@ -140,7 +140,7 @@ static int tegra30_i2s_hw_params(struct
> snd_pcm_substream *substream,
>                 audio_bits = TEGRA30_AUDIOCIF_BITS_16;
>                 sample_size = 16;
>                 break;
> -       case SNDRV_PCM_FORMAT_S24_LE:
> +       case SNDRV_PCM_FORMAT_S24_3LE:
>                 val = TEGRA30_I2S_CTRL_BIT_SIZE_24;
>                 audio_bits = TEGRA30_AUDIOCIF_BITS_24;
>                 sample_size = 24;
> @@ -318,7 +318,7 @@ static const struct snd_soc_dai_driver
> tegra30_i2s_dai_template = {
>                 .channels_max = 2,
>                 .rates = SNDRV_PCM_RATE_8000_96000,
>                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
> -                          SNDRV_PCM_FMTBIT_S24_LE |
> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>                            SNDRV_PCM_FMTBIT_S16_LE,
>         },
>         .capture = {
> @@ -327,7 +327,7 @@ static const struct snd_soc_dai_driver
> tegra30_i2s_dai_template = {
>                 .channels_max = 2,
>                 .rates = SNDRV_PCM_RATE_8000_96000,
>                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
> -                          SNDRV_PCM_FMTBIT_S24_LE |
> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>                            SNDRV_PCM_FMTBIT_S16_LE,
>         },
>         .ops = &tegra30_i2s_dai_ops,
> 
> Jon
> 

It should solve the problem in my particular case, but I'm not sure that
the solution is correct.

The v5.5 kernel is released now with the broken audio and apparently
getting 24bit to work won't be trivial (if possible at all). Ben, could
you please send a patch to fix v5.5 by removing the S24 support
advertisement from the driver?

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
> 24.01.2020 19:50, Jon Hunter пишет:

> >                 .rates = SNDRV_PCM_RATE_8000_96000,
> >                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
> > -                          SNDRV_PCM_FMTBIT_S24_LE |
> > +                          SNDRV_PCM_FMTBIT_S24_3LE |

> It should solve the problem in my particular case, but I'm not sure that
> the solution is correct.

If the format implemented by the driver is S24_3LE the driver should
advertise S24_3LE.

> The v5.5 kernel is released now with the broken audio and apparently
> getting 24bit to work won't be trivial (if possible at all). Ben, could
> you please send a patch to fix v5.5 by removing the S24 support
> advertisement from the driver?

Why is that the best fix rather than just advertising the format
implemented by the driver?

I really don't understand why this is all taking so long, this thread
just seems to be going round in interminable circles long after it
looked like the issue was understood.  I have to admit I've not read
every single message in the thread but it's difficult to see why it
doesn't seem to be making any progress.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

28.01.2020 15:13, Mark Brown пишет:
> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>> 24.01.2020 19:50, Jon Hunter пишет:
> 
>>>                 .rates = SNDRV_PCM_RATE_8000_96000,
>>>                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
> 
>> It should solve the problem in my particular case, but I'm not sure that
>> the solution is correct.
> 
> If the format implemented by the driver is S24_3LE the driver should
> advertise S24_3LE.

It should be S24_LE, but seems we still don't know for sure.

>> The v5.5 kernel is released now with the broken audio and apparently
>> getting 24bit to work won't be trivial (if possible at all). Ben, could
>> you please send a patch to fix v5.5 by removing the S24 support
>> advertisement from the driver?
> 
> Why is that the best fix rather than just advertising the format
> implemented by the driver?

The currently supported format that is known to work well is S16_LE.

I'm suggesting to drop the S24_LE and S32_LE that were added by the
applied patches simply because this series wasn't tested properly before
it was sent out and turned out that it doesn't work well.

> I really don't understand why this is all taking so long, this thread
> just seems to be going round in interminable circles long after it
> looked like the issue was understood.  I have to admit I've not read
> every single message in the thread but it's difficult to see why it
> doesn't seem to be making any progress.

Ben was trying to make a fix for the introduced problem, but it's not
easy as we see now.

Perhaps the best solution should be to revert all of the three applied
patches and try again later on, once all current problems will be resolved.

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Jon Hunter]

On 28/01/2020 17:42, Dmitry Osipenko wrote:
> 28.01.2020 15:13, Mark Brown пишет:
>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>> 24.01.2020 19:50, Jon Hunter пишет:
>>
>>>>                 .rates = SNDRV_PCM_RATE_8000_96000,
>>>>                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>
>>> It should solve the problem in my particular case, but I'm not sure that
>>> the solution is correct.
>>
>> If the format implemented by the driver is S24_3LE the driver should
>> advertise S24_3LE.
> 
> It should be S24_LE, but seems we still don't know for sure.

Why?

>>> The v5.5 kernel is released now with the broken audio and apparently
>>> getting 24bit to work won't be trivial (if possible at all). Ben, could
>>> you please send a patch to fix v5.5 by removing the S24 support
>>> advertisement from the driver?
>>
>> Why is that the best fix rather than just advertising the format
>> implemented by the driver?
> 
> The currently supported format that is known to work well is S16_LE.
> 
> I'm suggesting to drop the S24_LE and S32_LE that were added by the
> applied patches simply because this series wasn't tested properly before
> it was sent out and turned out that it doesn't work well.

S32_LE should be fine, however, I do have some concerns about S24_LE.

Jon

-- 
nvpublic

Re: [alsa-devel] [Linux-kernel] [PATCH v5 2/7] ASoC: tegra: Allow 24bit and 32bit samples

[Dmitry Osipenko]

28.01.2020 21:19, Jon Hunter пишет:
> 
> On 28/01/2020 17:42, Dmitry Osipenko wrote:
>> 28.01.2020 15:13, Mark Brown пишет:
>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>>> 24.01.2020 19:50, Jon Hunter пишет:
>>>
>>>>>                 .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>                 .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>>
>>>> It should solve the problem in my particular case, but I'm not sure that
>>>> the solution is correct.
>>>
>>> If the format implemented by the driver is S24_3LE the driver should
>>> advertise S24_3LE.
>>
>> It should be S24_LE, but seems we still don't know for sure.
> 
> Why?
/I think/ sound should be much more distorted if it was S24_3LE, but
maybe I'm wrong.

Re:

[Ben Dooks]

On 29/01/2020 00:17, Dmitry Osipenko wrote:
> 28.01.2020 21:19, Jon Hunter пишет:
>>
>> On 28/01/2020 17:42, Dmitry Osipenko wrote:
>>> 28.01.2020 15:13, Mark Brown пишет:
>>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>>>> 24.01.2020 19:50, Jon Hunter пишет:
>>>>
>>>>>>                  .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>                  .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>>>
>>>>> It should solve the problem in my particular case, but I'm not sure that
>>>>> the solution is correct.
>>>>
>>>> If the format implemented by the driver is S24_3LE the driver should
>>>> advertise S24_3LE.
>>>
>>> It should be S24_LE, but seems we still don't know for sure.
>>
>> Why?
> /I think/ sound should be much more distorted if it was S24_3LE, but
> maybe I'm wrong.

S24_3LE is IICC the wrong thing and we can't support it on the tegra3


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: (no subject)

[Clemens Ladisch]

Ben Dooks wrote:
> On 29/01/2020 00:17, Dmitry Osipenko wrote:
>> 28.01.2020 21:19, Jon Hunter пишет:
>>> On 28/01/2020 17:42, Dmitry Osipenko wrote:
>>>> 28.01.2020 15:13, Mark Brown пишет:
>>>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>>>>> 24.01.2020 19:50, Jon Hunter пишет:
>>>>>
>>>>>>>                  .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>                  .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>>>>
>>>>>> It should solve the problem in my particular case, but I'm not sure that
>>>>>> the solution is correct.
>>>>>
>>>>> If the format implemented by the driver is S24_3LE the driver should
>>>>> advertise S24_3LE.
>>>>
>>>> It should be S24_LE, but seems we still don't know for sure.
>>>
>>> Why?
>> /I think/ sound should be much more distorted if it was S24_3LE, but
>> maybe I'm wrong.
>
> S24_3LE is IICC the wrong thing and we can't support it on the tegra3

There are three ways of arranging 24-bit samples in memory:

S24_3LE: 24-bit samples in 24-bit words without padding
S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
S32_LE:  24-bit samples in 32-bit words, aligned to the MSB

It is very unlikely that your hardware implements S24_LE.

If a S32_LE driver wants to describe how many bits are actually used, it
should install a msbits constraint (snd_pcm_hw_constraint_msbits()).


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] (no subject)

[Ben Dooks]

On 30/01/2020 09:31, Clemens Ladisch wrote:
> Ben Dooks wrote:
>> On 29/01/2020 00:17, Dmitry Osipenko wrote:
>>> 28.01.2020 21:19, Jon Hunter пишет:
>>>> On 28/01/2020 17:42, Dmitry Osipenko wrote:
>>>>> 28.01.2020 15:13, Mark Brown пишет:
>>>>>> On Mon, Jan 27, 2020 at 10:20:25PM +0300, Dmitry Osipenko wrote:
>>>>>>> 24.01.2020 19:50, Jon Hunter пишет:
>>>>>>
>>>>>>>>                   .rates = SNDRV_PCM_RATE_8000_96000,
>>>>>>>>                   .formats = SNDRV_PCM_FMTBIT_S32_LE |
>>>>>>>> -                          SNDRV_PCM_FMTBIT_S24_LE |
>>>>>>>> +                          SNDRV_PCM_FMTBIT_S24_3LE |
>>>>>>
>>>>>>> It should solve the problem in my particular case, but I'm not sure that
>>>>>>> the solution is correct.
>>>>>>
>>>>>> If the format implemented by the driver is S24_3LE the driver should
>>>>>> advertise S24_3LE.
>>>>>
>>>>> It should be S24_LE, but seems we still don't know for sure.
>>>>
>>>> Why?
>>> /I think/ sound should be much more distorted if it was S24_3LE, but
>>> maybe I'm wrong.
>>
>> S24_3LE is IICC the wrong thing and we can't support it on the tegra3
> 
> There are three ways of arranging 24-bit samples in memory:
> 
> S24_3LE: 24-bit samples in 24-bit words without padding
> S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
> S32_LE:  24-bit samples in 32-bit words, aligned to the MSB
> 
> It is very unlikely that your hardware implements S24_LE.

Which is wrong, since this is exactly what the hardware implements.

The DMA fetches 32 bit words, and then the front end dispatches only
24 bits of these to the I2S/TDM

> 


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [alsa-devel] (no subject)

[Clemens Ladisch]

Ben Dooks wrote:
> On 30/01/2020 09:31, Clemens Ladisch wrote:
>> S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
>> S32_LE:  24-bit samples in 32-bit words, aligned to the MSB
>>
>> It is very unlikely that your hardware implements S24_LE.
>
> Which is wrong, since this is exactly what the hardware implements.
>
> The DMA fetches 32 bit words, and then the front end dispatches only
> 24 bits of these to the I2S/TDM

Which 24 bits?  Is the padding in the first byte (S32_LE) or in the
last byte (S24_LE)?


Regards,
Clemens

Re: [alsa-devel] (no subject)

[Ben Dooks]

On 2020-01-30 14:58, Clemens Ladisch wrote:
> Ben Dooks wrote:
>> On 30/01/2020 09:31, Clemens Ladisch wrote:
>>> S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
>>> S32_LE:  24-bit samples in 32-bit words, aligned to the MSB
>>> 
>>> It is very unlikely that your hardware implements S24_LE.
>> 
>> Which is wrong, since this is exactly what the hardware implements.
>> 
>> The DMA fetches 32 bit words, and then the front end dispatches only
>> 24 bits of these to the I2S/TDM
> 
> Which 24 bits?  Is the padding in the first byte (S32_LE) or in the
> last byte (S24_LE)?

I think the low 24 bits are sent from the 32 bit word.

Re: (no subject)

[Clemens Ladisch]

Ben Dooks wrote:
> On 2020-01-30 14:58, Clemens Ladisch wrote:
>> Ben Dooks wrote:
>>> On 30/01/2020 09:31, Clemens Ladisch wrote:
>>>> S24_LE:  24-bit samples in 32-bit words, aligned to the LSB
>>>> S32_LE:  24-bit samples in 32-bit words, aligned to the MSB
>>>>
>>>> It is very unlikely that your hardware implements S24_LE.
>>>
>>> Which is wrong, since this is exactly what the hardware implements.
>>>
>>> The DMA fetches 32 bit words, and then the front end dispatches only
>>> 24 bits of these to the I2S/TDM
>>
>> Which 24 bits?  Is the padding in the first byte (S32_LE) or in the
>> last byte (S24_LE)?
>
> I think the low 24 bits are sent from the 32 bit word.

This would indeed by S24_LE.  If you change the driver to say that it
supports _only_ S24_LE, is the data then played correctly?


Regards,
Clemens

(no subject)

[Rob Clark]

Hi Dave,

This time around:

+ OCMEM support to enable the couple generations that had shared OCMEM
  rather than GMEM exclusively for the GPU (late a3xx and I think basically
  all of a4xx).  Bjorn and Brian decided to land this through the drm
  tree to avoid having to coordinate merge requests.
+ a510 support, and various associated display support
+ the usual misc cleanups and fixes

The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce:
  Linux 5.4-rc2 (2019-10-06 14:27:30 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-11-05

for you to fetch changes up to e20c9284c8f212081afc28471daaac9b0d54252f:

  drm/msm/adreno: Add support for Adreno 510 GPU (2019-11-04 13:18:31 -0800)

----------------------------------------------------------------
AngeloGioacchino Del Regno (6):
      drm/msm/mdp5: Add optional TBU and TBU_RT clocks
      dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks
      drm/msm/mdp5: Add configuration for msm8x76
      drm/msm/dsi: Add configuration for 28nm PLL on family B
      drm/msm/dsi: Add configuration for 8x76
      drm/msm/adreno: Add support for Adreno 510 GPU

Arnd Bergmann (1):
      drm/msm: include linux/sched/task.h

Ben Dooks (2):
      drm/msm: make a5xx_show and a5xx_gpu_state_put static
      drm/msm/mdp5: make config variables static

Brian Masney (6):
      dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
      dt-bindings: display: msm: gmu: add optional ocmem property
      soc: qcom: add OCMEM driver
      drm/msm/gpu: add ocmem init/cleanup functions
      soc: qcom: ocmem: add missing includes
      drm/msm/hdmi: silence -EPROBE_DEFER warning

Drew Davenport (7):
      drm/msm/dpu: Remove unused variables
      drm/msm/dpu: Remove unused macro
      drm/msm/dpu: Remove unnecessary NULL checks
      drm/msm/dpu: Remove unnecessary NULL checks
      drm/msm/dpu: Remove unnecessary NULL checks
      drm/msm/dpu: Remove unnecessary NULL checks
      drm/msm: Remove unused function arguments

Krzysztof Wilczynski (1):
      drm/msm/dsi: Move static keyword to the front of declarations

Rob Clark (4):
      firmware: qcom: scm: add OCMEM lock/unlock interface
      firmware: qcom: scm: add support to restore secure config to qcm_scm-32
      drm/msm: fix rd dumping for split-IB1
      drm/msm: always dump buffer base/size

Sean Paul (1):
      drm/msm: Sanitize the modeset_is_locked checks in dpu

Stephan Gerhold (1):
      drm/msm/dsi: Implement qcom, dsi-phy-regulator-ldo-mode for 28nm PHY

zhengbin (11):
      drm/msm/dpu: Remove set but not used variable 'priv' in dpu_kms.c
      drm/msm/dpu: Remove set but not used variable 'priv' in
dpu_encoder_phys_vid.c
      drm/msm/dpu: Remove set but not used variable 'priv' in dpu_core_irq.c
      drm/msm/dpu: Remove set but not used variables 'dpu_cstate', 'priv'
      drm/msm/dpu: Remove set but not used variables 'cmd_enc', 'priv'
      drm/msm/dpu: Remove set but not used variables 'mode', 'dpu_kms', 'priv'
      drm/msm/mdp5: Remove set but not used variable 'fmt'
      drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup
      drm/msm/dsi: Remove set but not used variable 'lpx'
      drm/msm/dsi: Remove set but not used variable 'lp'
      drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in modeset_init

 .../devicetree/bindings/display/msm/gmu.txt        |  51 +++
 .../devicetree/bindings/display/msm/mdp5.txt       |   2 +
 .../devicetree/bindings/sram/qcom,ocmem.yaml       |  96 +++++
 drivers/firmware/qcom_scm-32.c                     |  52 ++-
 drivers/firmware/qcom_scm-64.c                     |  12 +
 drivers/firmware/qcom_scm.c                        |  53 +++
 drivers/firmware/qcom_scm.h                        |   9 +
 drivers/gpu/drm/msm/Kconfig                        |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c              |  28 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h              |   3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c              |  25 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h              |   3 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c              |  79 +++-
 drivers/gpu/drm/msm/adreno/a5xx_power.c            |   7 +
 drivers/gpu/drm/msm/adreno/adreno_device.c         |  15 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c            |  40 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h            |  15 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c       |  43 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c      |  21 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c           |  20 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c        |  39 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  15 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c            |  60 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h            |   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c           |   6 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c           |  10 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c           | 114 +++++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c          |   3 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c           |  23 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h           |   2 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c           |   2 -
 drivers/gpu/drm/msm/dsi/dsi_cfg.c                  |  28 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h                  |   1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c                 |   3 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c              |   8 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h              |   1 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c         |  60 ++-
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c                |   8 +-
 drivers/gpu/drm/msm/msm_gpu.c                      |   6 +-
 drivers/gpu/drm/msm/msm_gpummu.c                   |   6 +-
 drivers/gpu/drm/msm/msm_iommu.c                    |   6 +-
 drivers/gpu/drm/msm/msm_mmu.h                      |   4 +-
 drivers/gpu/drm/msm/msm_rd.c                       |  16 +-
 drivers/soc/qcom/Kconfig                           |  10 +
 drivers/soc/qcom/Makefile                          |   1 +
 drivers/soc/qcom/ocmem.c                           | 433 +++++++++++++++++++++
 include/linux/qcom_scm.h                           |  26 ++
 include/soc/qcom/ocmem.h                           |  65 ++++
 49 files changed, 1235 insertions(+), 307 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
 create mode 100644 drivers/soc/qcom/ocmem.c
 create mode 100644 include/soc/qcom/ocmem.h
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

(No subject)

[Lesia Kay Rivera]

[-- Attachment #1: Type: text/plain, Size: 4 bytes --]

Hi

[-- Attachment #2: Type: text/html, Size: 26 bytes --]

(No subject)

[Stephen K Jolley]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

All,



The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:



https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs



The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.



Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 309
unassigned or newcomer bugs.



We're hoping people may be able to spare some time now and again to help
out with these.  Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system.  There are also roughly four different "priority"
classes right now, “2.8”, “2.9’, "2.99" and "Future", the more
pressing/urgent issues being in "2.8" and then “2.9”.



Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp.pm@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

-- 

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(    *Cell*:                (208) 244-4460

* *Email*:                 *s
<stephen.k.jolley@intel.com>jolley.yp.pm@gmail.com <jolley.yp.pm@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 6589 bytes --]

(no subject)

[Giuliano Zannetti - ART S.p.A.]

Hi,

I have a performance related problem using the multi PCM plugin.


---------------------------------------------------------------------
    THE ISSUE
---------------------------------------------------------------------

The following scenario triggers the issue. The CPU load is up to 90%.

plug - - > upmix - - > multi - - > forward_dmix
                             - - > loopback_dmix

pcm.giuliano_plug
{
  type plug
  slave.pcm giuliano_upmix
  slave.channels 2
}

pcm.giuliano_upmix
{
  type route
  slave.pcm giuliano_multi
  slave.channels 4
  ttable.0.0 1
  ttable.0.1 1
  ttable.1.2 1
  ttable.1.3 1
}

pcm.giuliano_multi
{
  type multi
  slaves
  {
    slave0
    {
      pcm forward_dmix
      channels 2
    }
    slave1
    {
      pcm loopback_dmix
      channels 2
    }
  }
  bindings
  {
    0 {slave slave0 channel 0}
    1 {slave slave0 channel 1}
    2 {slave slave1 channel 0}
    3 {slave slave1 channel 1}
  }
  master 0
}

pcm.forward_dmix
{
  type dmix
  ipc_key 1000
  ipc_key_add_uid 1
  ipc_perm 0600
  slave.period_time 10000
  slave.period_size 480
  slave.buffer_size 1920
  slave.rate 48000
  slave.pcm "hw:0,0"
}

pcm.loopback_dmix
{
  type dmix
  ipc_key 1001
  ipc_key_add_uid 1
  ipc_perm 0600
  slave.period_time 10000
  slave.period_size 480
  slave.buffer_size 1920
  slave.rate 48000
  slave.pcm loopback_out
}

pcm.loopback_out
{
  type hw
  card Loopback
  device 0
  subdevice 0
}

pcm.loopback_dsnoop
{
  type dsnoop
  ipc_key 1002
  ipc_key_add_uid 1
  ipc_perm 0600
  slave.period_time 10000
  slave.period_size 480
  slave.buffer_size 1920
  slave.rate 48000
  slave.pcm loopback_in
}

pcm.loopback_in
{
  type hw
  card Loopback
  device 1
  subdevice 0
}

The following scenario does not trigger the issue. The CPU load is at most 2%.

plug - - > upmix - - > downmix - - > forward_dmix

pcm.giuliano_plug
{
  type plug
  slave.pcm giuliano_upmix
  slave.channels 2
}

pcm.giuliano_upmix
{
  type route
  slave.pcm giuliano_downmix
  slave.channels 4
  ttable.0.0 1
  ttable.0.1 1
  ttable.1.2 1
  ttable.1.3 1
}

pcm.giuliano_downmix
{
  type route
  slave.pcm forward_dmix
  slave.channels 2
  ttable.0.0 1
  ttable.1.1 1
  ttable.2.0 1
  ttable.3.1 1
}


---------------------------------------------------------------------
    DEBUG PRINTS IN FUNCTION snd_pcm_write_areas IN FILE pcm.c
---------------------------------------------------------------------

For each while iteration the log prints the available frames (avail) and the frames
to be written (size). In the multi scenario the several while iterations decrease the
performances and the CPU load is high. In the normal scenario i see that at most two iterations
of the while are needed. In other words, in the multi scenario the avail frames are not enough
to stop the loop. You can see below the prints: avail < size for 28 iterations. Note that
this behaviour does not occurs only at startup, but every time during the playback.

snd_pcm_sframes_t snd_pcm_write_areas(snd_pcm_t *pcm, const snd_pcm_channel_area_t *areas,
                      snd_pcm_uframes_t offset, snd_pcm_uframes_t size,
                      snd_pcm_xfer_areas_func_t func)
{
    snd_pcm_uframes_t xfer = 0;
    snd_pcm_sframes_t err = 0;
    snd_pcm_state_t state;

    if (size == 0)
        return 0;

    int giuliano_i = 0;

    __snd_pcm_lock(pcm); /* forced lock */
    while (size > 0) {
        snd_pcm_uframes_t frames;
        snd_pcm_sframes_t avail;
    _again:
        state = __snd_pcm_state(pcm);
        switch (state) {
        case SND_PCM_STATE_PREPARED:
        case SND_PCM_STATE_PAUSED:
            break;
        case SND_PCM_STATE_RUNNING:
            err = __snd_pcm_hwsync(pcm);
            if (err < 0)
                goto _end;
            break;
        default:
            err = pcm_state_to_error(state);
            if (!err)
                err = -EBADFD;
            goto _end;
        }
        avail = __snd_pcm_avail_update(pcm);

        fprintf(
            stderr,
            "giuliano | pcm.c | snd_pcm_write_areas | (%d) avail=%ld, size=%ld\n",
            giuliano_i, avail, size
        );
        giuliano_i ++;

        if (avail < 0) {
            err = avail;
            goto _end;
        }
        if (state == SND_PCM_STATE_RUNNING &&
            size > (snd_pcm_uframes_t)avail) {
            if (snd_pcm_may_wait_for_avail_min(pcm, avail)) {
                if (pcm->mode & SND_PCM_NONBLOCK) {
                    err = -EAGAIN;
                    goto _end;
                }

                err = snd_pcm_wait_nocheck(pcm, -1);

                if (err < 0)
                    break;

                goto _again;
            }
            /* the snd_pcm_may_wait_for_avail_min may check against the
             * updated hw.ptr (slaves), get the avail again here
             */
            avail = __snd_pcm_avail_update(pcm);
            if (avail < 0) {
                err = avail;
                goto _end;
            }
        }
        frames = size;
        if (frames > (snd_pcm_uframes_t) avail)
            frames = avail;
        if (! frames)
            break;
        err = func(pcm, areas, offset, frames);
        if (err < 0)
            break;
        frames = err;
        if (state == SND_PCM_STATE_PREPARED) {
            snd_pcm_sframes_t hw_avail = pcm->buffer_size - avail;
            hw_avail += frames;
            /* some plugins might automatically start the stream */
            state = __snd_pcm_state(pcm);
            if (state == SND_PCM_STATE_PREPARED &&
                hw_avail >= (snd_pcm_sframes_t) pcm->start_threshold) {
                err = __snd_pcm_start(pcm);
                if (err < 0)
                    goto _end;
            }
        }
        offset += frames;
        size -= frames;
        xfer += frames;
    }
_end:
    __snd_pcm_unlock(pcm);
    return xfer > 0 ? (snd_pcm_sframes_t) xfer : snd_pcm_check_error(pcm, err);
}


---------------------------------------------------------------------
    DEBUG PRINTS OUTPUT
---------------------------------------------------------------------

## Multi scenario ##

giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=1920
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=1920
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=1920, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=1440
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=1440
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=1440, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=960
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=960, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=480, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (2) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (3) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (4) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (5) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (6) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (7) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (8) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (9) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (10) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (11) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (12) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (13) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (14) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
giuliano | pcm.c | snd_pcm_write_areas | (15) avail=0, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=0
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 0
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (16) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (17) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (18) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (19) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (20) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (21) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (22) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (23) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (24) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (25) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (26) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 384
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=384
giuliano | pcm.c | snd_pcm_write_areas | (27) avail=384, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=1440
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=576
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=1440
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=576
giuliano | pcm.c | snd_pcm_write_areas | (28) avail=576, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=96
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=96, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=96
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 96
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=96
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=96, size=480
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=0, avail=960
giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=1, avail=96
*** snd_pcm_wait() FATAL ERROR!!!
avail_min = 480, avail_update = 96

## Normal scenario ##

giuliano | pcm.c | snd_pcm_write_areas | (0) avail=1920, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=1440, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=960, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480
giuliano | pcm.c | snd_pcm_write_areas | (0) avail=0, size=480
giuliano | pcm.c | snd_pcm_write_areas | (1) avail=480, size=480


---------------------------------------------------------------------
    DEBUG PRINTS IN FUNCTION snd_pcm_wait_nocheck IN FILE pcm.c
---------------------------------------------------------------------

As you can see in the debug prints above i have enabled the error message
in the function snd_pcm_wait_nocheck.

That message lead me to think that the issue is a poll related one, may be?

int snd_pcm_wait_nocheck(snd_pcm_t *pcm, int timeout)
{
  struct pollfd *pfd;
  unsigned short revents = 0;
  int npfds, err, err_poll;

  npfds = __snd_pcm_poll_descriptors_count(pcm);
  if (npfds <= 0 || npfds >= 16) {
    SNDERR("Invalid poll_fds %d\n", npfds);
    return -EIO;
  }
  pfd = alloca(sizeof(*pfd) * npfds);
  err = __snd_pcm_poll_descriptors(pcm, pfd, npfds);
  if (err < 0)
    return err;
  if (err != npfds) {
    SNDMSG("invalid poll descriptors %d\n", err);
    return -EIO;
  }
  do {
    __snd_pcm_unlock(pcm);
    err_poll = poll(pfd, npfds, timeout);
    __snd_pcm_lock(pcm);
    if (err_poll < 0) {
            if (errno == EINTR && !PCMINABORT(pcm))
                    continue;
      return -errno;
                }
    if (! err_poll)
      break;
    err = __snd_pcm_poll_revents(pcm, pfd, npfds, &revents);
    if (err < 0)
      return err;
    if (revents & (POLLERR | POLLNVAL)) {
      /* check more precisely */
      err = pcm_state_to_error(__snd_pcm_state(pcm));
      return err < 0 ? err : -EIO;
    }
  } while (!(revents & (POLLIN | POLLOUT)));
#if 1 /* very useful code to test poll related problems */
  {
    snd_pcm_sframes_t avail_update;
    __snd_pcm_hwsync(pcm);
    avail_update = __snd_pcm_avail_update(pcm);
    if (avail_update < (snd_pcm_sframes_t)pcm->avail_min) {
      printf("*** snd_pcm_wait() FATAL ERROR!!!\n");
      printf("avail_min = %li, avail_update = %li\n", pcm->avail_min, avail_update);
    }
  }
#endif
  return err_poll > 0 ? 1 : 0;
}
#endif


---------------------------------------------------------------------
    DEBUG PRINTS IN FUNCTION __snd_pcm_avail_update IN pcm_multi.c
---------------------------------------------------------------------

As you can see in the prints above, i put some debugs logs in the function
__snd_pcm_avail_update. I can read there the number of avail frames for each slave of
the multi. I see also that the minimum numbers of frames is taken among the slaves.

static snd_pcm_sframes_t snd_pcm_multi_avail_update(snd_pcm_t *pcm)
{
  snd_pcm_multi_t *multi = pcm->private_data;
  snd_pcm_sframes_t ret = LONG_MAX;

    snd_pcm_sframes_t giuliano_temp = 0;

  unsigned int i;
  for (i = 0; i < multi->slaves_count; ++i) {
    snd_pcm_sframes_t avail;
    avail = snd_pcm_avail_update(multi->slaves[i].pcm);
        fprintf(
            stderr,
            "giuliano | pcm_multi.c | snd_pcm_multi_avail_update | slave=%d, avail=%d\n",
            i, avail
        );
    if (avail < 0)
      return avail;
    if (ret > avail)
      ret = avail;
  }
  snd_pcm_multi_hwptr_update(pcm);

    return ret;
}



I hope that my debug prints are useful to find the issue.



Thanks

Giuliano Zannetti

(no subject)

[Sam Ravnborg]

The first three patches prepare for the removal of drmP.h.
The last patch remove use of drmP.h and replace with necessary
include files to fix build.

Build tested with various configs and various architectures.

I had preferred that the via driver was replaced by the
openchrome driver, but until we have it then we need
to deal with the legacy via driver when removing old cruft
in the drm subsystem.

v3:
- Use static inline functions for the read/write operations (Emil)
- Use dedicated *_mask_or() and *_mask_and() (Emil)
- Replace DRM_WAIT_ON in same path that introduces VIA_WAIT_ON (Emil)
- Collected r-b's
- Changelog adjustments
- Rebased on top of drm-misc-next

v2:
- Add a copy of DRM_WAIT_ON to the via driver, keeping
  the changes to this legacy driver to a minimum.
  This also gives much more confidence that the
  driver continues to work as there is no changes
  in logic. Therefore dropped "RFT".
- Added Cc: Michel Dänzer <michel@daenzer.net> to all
  patches, as Michael have commented on the series.

        Sam

Sam Ravnborg (4):
      drm/via: drop use of DRM(READ|WRITE) macros
      drm/via: copy DRM_WAIT_ON as VIA_WAIT_ON and use it
      drm/via: make via_drv.h self-contained
      drm/via: drop use of drmP.h

 drivers/gpu/drm/via/via_dma.c      | 43 +++++++++++---------
 drivers/gpu/drm/via/via_dmablit.c  | 41 ++++++++++---------
 drivers/gpu/drm/via/via_drv.c      |  7 +++-
 drivers/gpu/drm/via/via_drv.h      | 83 +++++++++++++++++++++++++++++++++++---
 drivers/gpu/drm/via/via_irq.c      | 54 +++++++++++++------------
 drivers/gpu/drm/via/via_map.c      |  6 ++-
 drivers/gpu/drm/via/via_mm.c       |  7 +++-
 drivers/gpu/drm/via/via_verifier.c | 22 +++++-----
 drivers/gpu/drm/via/via_video.c    |  5 ++-
 9 files changed, 182 insertions(+), 86 deletions(-)


_______________________________________________
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

(no subject)

[Андрей Бохонов]

[-- Attachment #1.1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 28 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Ralf Beck]

Jaroslav Kysela wrote:
>I just don't think that the mmap transfer mode is the culprit of the problems.
>The problem is that the PCI cards off-loads the DMA transfers completely
>without the extra framing required for those serial hardware interfaces which
>are handled in the audio driver and the other kernel stacks (USB etc.).

The source of all evil is the ring buffer.
It prevents all devices that require packet headers (Firewire/network based solutions) or that
use a variable amount of frames per packet (all asynchronous devices, especially asynchronous USB ISO endpoints)
from mapping their data directly into userspas memory without ever touching the audio data in it.

While this doesn't hurt performance to much with devices that offer only a few channels,
it has a massive effect on network based devices with possibly hundreds of channels of which only
a small number is used (e.g. record enabled) at a time.

The ringbuffer should be replaced by a buffer that holds the packets and a descriptor for how to find the data in it. Btw, alsa uses something similar already for the mmap handling.

The descriptor should consist of
x periods, containing y chunks with a max size, containing z channels, each of the channel described by a start address and step value within that chunk.

Examples:
PCI device; 2 periods, 1 chunks per period, max size 64 frames per chunk, 2 channels per chunk
USB device: 2 periods, 8 chunks (microframes) max size 8 frames (if at 44.1/48kHz), 2 channels per chunk,
Same for Firewire, AVB (each chunk possibly containing several AVB streams, i.e. ethernet packets), etc.

Period elapsed => the number of chunks forming a period have been received

snd_pcm_avail(_update) => return the sum of actual frames of the period

snd_pcm_mmap_commit => return the descriptor for one chunk, the number of frames of the chunk and a channel map for the chunk. The reason for the latter is that on ethernet based devices (AVB) there is bo guarantee that streams of different endpoints are received in the same order (but in the same interval window).
Alsa clients should then loop until they have processed all frames thar have been reported by snd_pcm_avail (instead of a period size number of frames).

Ah, and AM824 raw audio format, used by firewire and AVB, should by added to the list of audio formats, so conversion can be done in userspace.

Ralf


 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: (no subject)

[Pierre-Louis Bossart]

On 6/13/19 12:54 AM, Ralf Beck wrote:
> 
> Jaroslav Kysela wrote:
>> I just don't think that the mmap transfer mode is the culprit of the problems.
>> The problem is that the PCI cards off-loads the DMA transfers completely
>> without the extra framing required for those serial hardware interfaces which
>> are handled in the audio driver and the other kernel stacks (USB etc.).
> 
> The source of all evil is the ring buffer.
> It prevents all devices that require packet headers (Firewire/network based solutions) or that
> use a variable amount of frames per packet (all asynchronous devices, especially asynchronous USB ISO endpoints)
> from mapping their data directly into userspas memory without ever touching the audio data in it.
> 
> While this doesn't hurt performance to much with devices that offer only a few channels,
> it has a massive effect on network based devices with possibly hundreds of channels of which only
> a small number is used (e.g. record enabled) at a time.
> 
> The ringbuffer should be replaced by a buffer that holds the packets and a descriptor for how to find the data in it. Btw, alsa uses something similar already for the mmap handling.
> 
> The descriptor should consist of
> x periods, containing y chunks with a max size, containing z channels, each of the channel described by a start address and step value within that chunk.

You're assuming a reliable network where not a single packet is missing. 
I can bet that if you start adding support for packet-based audio some 
folks are going to want to support timestamps and missing packets, which 
would throw a large size monkey-wrench in your ideas of time reporting 
below.
Also note that you could rely on the compressed API to deal with packets 
as an interface between your applications and your hardware - even if 
the actual data is PCM. It's still based on a ring buffer but it doesn't 
have the built-in bytes-to-time relationship that the ALSA PCM API 
relies on.

> Examples:
> PCI device; 2 periods, 1 chunks per period, max size 64 frames per chunk, 2 channels per chunk
> USB device: 2 periods, 8 chunks (microframes) max size 8 frames (if at 44.1/48kHz), 2 channels per chunk,
> Same for Firewire, AVB (each chunk possibly containing several AVB streams, i.e. ethernet packets), etc.
> 
> Period elapsed => the number of chunks forming a period have been received
> 
> snd_pcm_avail(_update) => return the sum of actual frames of the period
> 
> snd_pcm_mmap_commit => return the descriptor for one chunk, the number of frames of the chunk and a channel map for the chunk. The reason for the latter is that on ethernet based devices (AVB) there is bo guarantee that streams of different endpoints are received in the same order (but in the same interval window).
> Alsa clients should then loop until they have processed all frames thar have been reported by snd_pcm_avail (instead of a period size number of frames).
> 
> Ah, and AM824 raw audio format, used by firewire and AVB, should by added to the list of audio formats, so conversion can be done in userspace.
> 
> Ralf
> 
> 
>   
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: (no subject)

[Jaroslav Kysela]

Dne 13. 06. 19 v 7:54 Ralf Beck napsal(a):
> 
> Jaroslav Kysela wrote:
>> I just don't think that the mmap transfer mode is the culprit of the problems.
>> The problem is that the PCI cards off-loads the DMA transfers completely
>> without the extra framing required for those serial hardware interfaces which
>> are handled in the audio driver and the other kernel stacks (USB etc.).
> 
> The source of all evil is the ring buffer.
> It prevents all devices that require packet headers (Firewire/network based solutions) or that
> use a variable amount of frames per packet (all asynchronous devices, especially asynchronous USB ISO endpoints)
> from mapping their data directly into userspas memory without ever touching the audio data in it.
> 
> While this doesn't hurt performance to much with devices that offer only a few channels,
> it has a massive effect on network based devices with possibly hundreds of channels of which only
> a small number is used (e.g. record enabled) at a time.
> 
> The ringbuffer should be replaced by a buffer that holds the packets and a descriptor for how to find the data in it. Btw, alsa uses something similar already for the mmap handling.
> 
> The descriptor should consist of
> x periods, containing y chunks with a max size, containing z channels, each of the channel described by a start address and step value within that chunk.
> 
> Examples:
> PCI device; 2 periods, 1 chunks per period, max size 64 frames per chunk, 2 channels per chunk
> USB device: 2 periods, 8 chunks (microframes) max size 8 frames (if at 44.1/48kHz), 2 channels per chunk,
> Same for Firewire, AVB (each chunk possibly containing several AVB streams, i.e. ethernet packets), etc.
> 
> Period elapsed => the number of chunks forming a period have been received
> 
> snd_pcm_avail(_update) => return the sum of actual frames of the period
> 
> snd_pcm_mmap_commit => return the descriptor for one chunk, the number of frames of the chunk and a channel map for the chunk. The reason for the latter is that on ethernet based devices (AVB) there is bo guarantee that streams of different endpoints are received in the same order (but in the same interval window).
> Alsa clients should then loop until they have processed all frames thar have been reported by snd_pcm_avail (instead of a period size number of frames).
> 
> Ah, and AM824 raw audio format, used by firewire and AVB, should by added to the list of audio formats, so conversion can be done in userspace.

You can create a new mmap type for the ALSA API and add the support code to
the ALSA PCM kernel and ALSA library to optimize the data handling for this
"special" hardware cases. It just moves the sample layout conversion from the
driver to the user space (ALSA library).

							Jaroslav
-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: (no subject)

[Philippe Proulx]

On Wed, Jun 12, 2019 at 11:22 PM Zvi Vered <veredz72@gmail.com> wrote:
>
> Hello,
>
> I'm trying to read the file "metadata".
> I read the struct:
>
> struct metadata_packet_header {
> uint32_t magic; /* 0x75D11D57 */
> uint8_t  uuid[16]; /* Unique Universal Identifier */
> uint32_t checksum; /* 0 if unused */
> uint32_t content_size; /* in bits */
> uint32_t packet_size; /* in bits */
> uint8_t  compression_scheme; /* 0 if unused */
> uint8_t  encryption_scheme; /* 0 if unused */
> uint8_t  checksum_scheme; /* 0 if unused */
> uint8_t  major; /* CTF spec major version number */
> uint8_t  minor; /* CTF spec minor version number */
> HEADER_END;
> };
>
> the magic is indeed 0x75D11D57.
> What is next struct I should read ?
> I would expect "packet context". Am I right ?
> what struct is it ?
>
> I want to write a simple babeltrace for windows.

Not to discourage you, but I think you're only beginning a very long
journey. Reading a CTF trace entails:

1. Depacketize the metadata stream to get the metadata text.

2. Parse the metadata text to get the appropriate trace, stream, clock,
   and event classes. That's a custom, and somewhat complex,
   domain-specific language called TSDL.

3. Use the classes found in 2. to decode each data stream. This involves
   decoding integer fields with custom sizes (for example, a 27-bit
   unsigned integer field), dynamically finding the lengths of
   sequences and the selectors of variants, updating the stream's clock,
   and much more.

4. Merge the events of the trace's data streams decoded in 3.  to get a
   monotonic sequence of events.

Add to this various fixes for known tracer bugs and support for features
such as trace file rotation and tracing session rotation.

Please don't attempt this.

We are currently polishing the Babeltrace 2 project which does all that,
and much more, for the Linux, macOS, and Windows platforms. Our goal is
to offer a flexible, plugin-based framework to read, manipulate, and
write traces in different formats.

Phil

> If I succeed, and you will find it relevant, I can upload this project.
>
> Thank you in advance,
> Zvika
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: (no subject)

[Zvi Vered]

[-- Attachment #1.1: Type: text/plain, Size: 2726 bytes --]

Hi Phil,

Can you please estimate when version 2 will be released ?

Can you please provide sample code that uses Babeltrace to read metadata,
channel ?

Thank you for the tip. You saved us many hours of work.

Best regards,
Zvika

On Thu, Jun 13, 2019, 07:06 Philippe Proulx <eeppeliteloop@gmail.com> wrote:

> On Wed, Jun 12, 2019 at 11:22 PM Zvi Vered <veredz72@gmail.com> wrote:
> >
> > Hello,
> >
> > I'm trying to read the file "metadata".
> > I read the struct:
> >
> > struct metadata_packet_header {
> > uint32_t magic; /* 0x75D11D57 */
> > uint8_t  uuid[16]; /* Unique Universal Identifier */
> > uint32_t checksum; /* 0 if unused */
> > uint32_t content_size; /* in bits */
> > uint32_t packet_size; /* in bits */
> > uint8_t  compression_scheme; /* 0 if unused */
> > uint8_t  encryption_scheme; /* 0 if unused */
> > uint8_t  checksum_scheme; /* 0 if unused */
> > uint8_t  major; /* CTF spec major version number */
> > uint8_t  minor; /* CTF spec minor version number */
> > HEADER_END;
> > };
> >
> > the magic is indeed 0x75D11D57.
> > What is next struct I should read ?
> > I would expect "packet context". Am I right ?
> > what struct is it ?
> >
> > I want to write a simple babeltrace for windows.
>
> Not to discourage you, but I think you're only beginning a very long
> journey. Reading a CTF trace entails:
>
> 1. Depacketize the metadata stream to get the metadata text.
>
> 2. Parse the metadata text to get the appropriate trace, stream, clock,
>    and event classes. That's a custom, and somewhat complex,
>    domain-specific language called TSDL.
>
> 3. Use the classes found in 2. to decode each data stream. This involves
>    decoding integer fields with custom sizes (for example, a 27-bit
>    unsigned integer field), dynamically finding the lengths of
>    sequences and the selectors of variants, updating the stream's clock,
>    and much more.
>
> 4. Merge the events of the trace's data streams decoded in 3.  to get a
>    monotonic sequence of events.
>
> Add to this various fixes for known tracer bugs and support for features
> such as trace file rotation and tracing session rotation.
>
> Please don't attempt this.
>
> We are currently polishing the Babeltrace 2 project which does all that,
> and much more, for the Linux, macOS, and Windows platforms. Our goal is
> to offer a flexible, plugin-based framework to read, manipulate, and
> write traces in different formats.
>
> Phil
>
> > If I succeed, and you will find it relevant, I can upload this project.
> >
> > Thank you in advance,
> > Zvika
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>

[-- Attachment #1.2: Type: text/html, Size: 3845 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: (no subject)

[Jonathan Rajotte-Julien]

Hi,

> Can you please estimate when version 2 will be released ?

When it is ready. A lot of work was done on that side in the last 6 month, the
list of bugs and stuff to get done is shrinking everyday.

> Can you please provide sample code that uses Babeltrace to read metadata,
> channel ?

The source code for decoding the metadata TSDL is available here [1] if I'm not
mistaken. The header is only the tip of the iceberg.

[1] https://github.com/efficios/babeltrace/tree/stable-1.5/formats/ctf/metadata

I'm not sure if we expose the metadata information directly to the API.

See [2] for the API documentation of babeltrace 1.5

[2] http://git.efficios.com/?p=babeltrace.git;a=blob;f=doc/API.txt;h=e13e6adf3545d306e36c2496dd2feb50479d1eea

> > >
> > > I want to write a simple babeltrace for windows.
> >

I'm not convinced that rewriting an open source project is the right way to go
about that. Even more when there is already efforts being conducted for supporting
Windows.

What is the end goal here? What are you trying to achieve?

Do you want a basic cli that can read traces and output text trace?
Do you want to build a tool around ctf and need a reader/writer lib?

Please provide context so that we can help you achieve your goal.

Cheers
-- 
Jonathan Rajotte-Julien
EfficiOS

Re: (no subject)

[Zvi Vered]

[-- Attachment #1.1: Type: text/plain, Size: 1791 bytes --]

Hi Jonathan,

I need a windows library (+ sample code that uses it) that can read events
from a pre-recorded CTF file created by ltt-ng (metadata, channels)
I think (not sure) that compiling babeltrace (e.g 1.5.23) with Mingw is not
simple.
As a start, the bootstrap, cannot run under windows.

Thank you,
Zvika




On Thu, Jun 13, 2019 at 6:38 PM Jonathan Rajotte-Julien <
jonathan.rajotte-julien@efficios.com> wrote:

> Hi,
>
> > Can you please estimate when version 2 will be released ?
>
> When it is ready. A lot of work was done on that side in the last 6 month,
> the
> list of bugs and stuff to get done is shrinking everyday.
>
> > Can you please provide sample code that uses Babeltrace to read metadata,
> > channel ?
>
> The source code for decoding the metadata TSDL is available here [1] if
> I'm not
> mistaken. The header is only the tip of the iceberg.
>
> [1]
> https://github.com/efficios/babeltrace/tree/stable-1.5/formats/ctf/metadata
>
> I'm not sure if we expose the metadata information directly to the API.
>
> See [2] for the API documentation of babeltrace 1.5
>
> [2]
> http://git.efficios.com/?p=babeltrace.git;a=blob;f=doc/API.txt;h=e13e6adf3545d306e36c2496dd2feb50479d1eea
>
> > > >
> > > > I want to write a simple babeltrace for windows.
> > >
>
> I'm not convinced that rewriting an open source project is the right way
> to go
> about that. Even more when there is already efforts being conducted for
> supporting
> Windows.
>
> What is the end goal here? What are you trying to achieve?
>
> Do you want a basic cli that can read traces and output text trace?
> Do you want to build a tool around ctf and need a reader/writer lib?
>
> Please provide context so that we can help you achieve your goal.
>
> Cheers
> --
> Jonathan Rajotte-Julien
> EfficiOS
>

[-- Attachment #1.2: Type: text/html, Size: 2658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

(no subject)

[Zvi Vered]

[-- Attachment #1.1: Type: text/plain, Size: 838 bytes --]

Hello,

I'm trying to read the file "metadata".
I read the struct:

struct metadata_packet_header {
uint32_t magic; /* 0x75D11D57 */
uint8_t  uuid[16]; /* Unique Universal Identifier */
uint32_t checksum; /* 0 if unused */
uint32_t content_size; /* in bits */
uint32_t packet_size; /* in bits */
uint8_t  compression_scheme; /* 0 if unused */
uint8_t  encryption_scheme; /* 0 if unused */
uint8_t  checksum_scheme; /* 0 if unused */
uint8_t  major; /* CTF spec major version number */
uint8_t  minor; /* CTF spec minor version number */
HEADER_END;
};

the magic is indeed 0x75D11D57.
What is next struct I should read ?
I would expect "packet context". Am I right ?
what struct is it ?

I want to write a simple babeltrace for windows.
If I succeed, and you will find it relevant, I can upload this project.

Thank you in advance,
Zvika

[-- Attachment #1.2: Type: text/html, Size: 1146 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

(No subject)

[B, Karthik]

[-- Attachment #1: Type: text/plain, Size: 6 bytes --]

STOP

[-- Attachment #2: Type: text/html, Size: 1656 bytes --]

(No Subject)

[rodomar705]

Already sent to alsa-user, however a developer asked to send this also on devel, so here it is:

I have audio stutters with an ALC892 Realtek Chipset on a B450 GAMING ELITE board from Gigabyte during acquisition (at least with microphone input, both front and back. Line in not tested). No issues with Windows.

After opening an issue and testing with a PulseAudio developer, he has determined that the issue is not within PulseAudio, but on ALSA.

There are already two issues about that on the bug tracker on Linux, namely this two:

ALC892: https://bugzilla.kernel.org/show_bug.cgi?id=203351
ALC1220: https://bugzilla.kernel.org/show_bug.cgi?id=195303

To me both appears to be identical, for this reason even if I have a ALC892 I’ve posted on the second one, just because it had more posts.

The particular thing is that acquiring with PulseAudio on Audacity show the problem, however using ALSA directly the issue is not present. Trying using arecord still present the issue from PulseAudio.

Tried to play with the parameters /sys/devices/audio to no avail. Compared the pinconfigs from Windows, they are identical.

Can someone try to help me fix the issue?

Sent with [ProtonMail](https://protonmail.com) Secure Email.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

(No subject)

[Mahesh Radhakrishnan]

From ada28379af24168c8901b525abec421c4cbbf70f Mon Sep 17 00:00:00 2001
From: Mahesh Radhakrishnan <m-radhakrishnan2@ti.com>
Date: Wed, 3 Apr 2019 15:05:41 -0400
Subject: [master][meta-processor-sdk][PATCH] board-rtos: SRCREV bump to
 01.00.10.04C

Signed-off-by: Mahesh Radhakrishnan <m-radhakrishnan2@ti.com>
---
 recipes-bsp/board-rtos/board-rtos_git.bbappend | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100644 recipes-bsp/board-rtos/board-rtos_git.bbappend

diff --git a/recipes-bsp/board-rtos/board-rtos_git.bbappend b/recipes-bsp/board-rtos/board-rtos_git.bbappend
new file mode 100644
index 0000000..6cb286e
--- /dev/null
+++ b/recipes-bsp/board-rtos/board-rtos_git.bbappend
@@ -0,0 +1,6 @@
+
+# Below commit ID corresponds to "DEV.BOARD.01.00.10.04C"
+BOARD_SRCREV = "e794b8d6a58dc800cb406b05f45b46652c9d4f4c"
+
+PV = "01.00.10.04C"
+PR = "r0"
-- 
1.9.1

(No subject)

[Marija Stojanovska]

[-- Attachment #1: Type: text/plain, Size: 26 bytes --]

mstojanovska09@gmail.com

[-- Attachment #2: Type: text/html, Size: 97 bytes --]

Re: [PATCH] wpa_supplicant: Changed systemd template units

[Richard Purdie]

On Tue, 2019-02-05 at 11:26 -0500, Joshua DeWeese wrote:
> From: Joshua DeWeese <jdeweese@hennypenny.com>
> 
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html#WantedBy=
> 
> When building root filesystems with any of the wpa_supplicant systemd
> template service files enabled (current default is to have them
> disabled) the
> systemd-native-fake script would not process the line:
> 
> Alias=multi-user.target.wants/wpa_supplicant@%i.service
> 
> appropriately due the the use of "%i."
> 
> According to the systemd documentation "WantedBy=foo.service in a
> service
> bar.service is mostly equivalent to
> Alias=foo.service.wants/bar.service in
> the same file." However, this is not really the intended purpose of
> install
> Aliases.
> 
> All lines of the form:
> 
> Alias=multi-user.target.wants/*%i.service
> 
> Were replaced with the following lines:
> 
> WantedBy=multi-user.target
> 
> Signed-off-by: Joshua DeWeese <jdeweese@hennypenny.com>

This patch doesn't seem to apply against master (which has 2.6, not
2.5)?

Cheers,

Richard

(No subject)

[Joshua DeWeese]

Here it is, updated to work with wpa-supplicant_2.6.bb.

-- >8 --
From 12d39342b00a1ad5536b105e23b9ea732bba5489 Mon Sep 17 00:00:00 2001
From: Joshua DeWeese <jdeweese@hennypenny.com>
Date: Tue, 5 Feb 2019 10:08:37 -0500
Subject: [PATCH] wpa_supplicant: Changed systemd template units

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#WantedBy=

When building root filesystems with any of the wpa_supplicant systemd
template service files enabled (current default is to have them disabled) the
systemd-native-fake script would not process the line:

Alias=multi-user.target.wants/wpa_supplicant@%i.service

appropriately due the the use of "%i."

According to the systemd documentation "WantedBy=foo.service in a service
bar.service is mostly equivalent to Alias=foo.service.wants/bar.service in
the same file." However, this is not really the intended purpose of install
Aliases.

All lines of the form:

Alias=multi-user.target.wants/*%i.service

Were replaced with the following lines:

WantedBy=multi-user.target

Signed-off-by: Joshua DeWeese <jdeweese@hennypenny.com>
---
 ...place-systemd-install-Alias-with-WantedBy.patch | 52 ++++++++++++++++++++++
 .../wpa-supplicant/wpa-supplicant_2.6.bb           |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch

diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch
new file mode 100644
index 0000000000..a476cf040e
--- /dev/null
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch
@@ -0,0 +1,52 @@
+From 94c401733a5a3d294cc412671166e6adfb409f53 Mon Sep 17 00:00:00 2001
+From: Joshua DeWeese <jdeweese@hennypenny.com>
+Date: Wed, 30 Jan 2019 16:19:47 -0500
+Subject: [PATCH] replace systemd install Alias with WantedBy
+
+According to the systemd documentation "WantedBy=foo.service in a
+service bar.service is mostly equivalent to
+Alias=foo.service.wants/bar.service in the same file." However,
+this is not really the intended purpose of install Aliases.
+
+Upstream-Status: Submitted [hostap@lists.infradead.org]
+
+Signed-off-by: Joshua DeWeese <jdeweese@hennypenny.com>
+---
+ wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in | 2 +-
+ wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in   | 2 +-
+ wpa_supplicant/systemd/wpa_supplicant.service.arg.in         | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
+index 03ac507..da69a87 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-nl80211-%I.conf -Dnl80211 -i%I
+ 
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant-nl80211@%i.service
++WantedBy=multi-user.target
+diff --git a/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
+index c8a744d..ca3054b 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-wired-%I.conf -Dwired -i%I
+ 
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant-wired@%i.service
++WantedBy=multi-user.target
+diff --git a/wpa_supplicant/systemd/wpa_supplicant.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
+index 7788b38..55d2b9c 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I
+ 
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant@%i.service
++WantedBy=multi-user.target
+-- 
+2.7.4
+
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
index aa4c4c2da0..c92ed4ab93 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
@@ -33,6 +33,7 @@ SRC_URI = "http://w1.fi/releases/wpa_supplicant-${PV}.tar.gz  \
            file://key-replay-cve-multiple7.patch \
            file://key-replay-cve-multiple8.patch \
            file://wpa_supplicant-CVE-2018-14526.patch \
+           file://0001-replace-systemd-install-Alias-with-WantedBy.patch \
           "
 SRC_URI[md5sum] = "091569eb4440b7d7f2b4276dbfc03c3c"
 SRC_URI[sha256sum] = "b4936d34c4e6cdd44954beba74296d964bc2c9668ecaa5255e499636fe2b1450"
-- 
2.11.0

(No subject)

[Antonio Santagiuliana]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Hi,
I am missing the steps required to add to an image the support for an RTC
plugged in to I2C1 interface, with autostart.
is there a page with instructions ?
thank you

[-- Attachment #2: Type: text/html, Size: 230 bytes --]

(No subject)

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

Hi,

Have you tried adding the feature through MACHINE_FEATURES variable? (
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-features-machine
and
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#var-MACHINE_FEATURES
).

A developer can probably provide more detailed information Antonio.

Thanks,
Scott

On Tue, Jan 29, 2019 at 8:12 AM Antonio Santagiuliana <
santantonioswap@gmail.com> wrote:

> Hi,
> I am missing the steps required to add to an image the support for an RTC
> plugged in to I2C1 interface, with autostart.
> is there a page with instructions ?
> thank you
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 1594 bytes --]

(no subject)

[Razvan Cojocaru]

This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).

The first patch introduces p2m_{init,free}_logdirty(), the second
allocates  a new logdirty rangeset for each new altp2m, and the
fourth propagates (under lock) changes to all p2ms.

Since the last version of the series, what has previously been
the first patch is already upstream, and two patches kindly
authored by George Dunlap have been appended. The patches
optimize the way rangeset changes are propagated in
change_type_range().

[PATCH V7 1/5] x86/mm: introduce p2m_{init,free}_logdirty()
[PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms
[PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early
[PATCH V7 4/5] p2m: Always use hostp2m when clipping rangesets
[PATCH V7 5/5] p2m: change_range_type: Only invalidate mapped gfns


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: (no subject)

[Razvan Cojocaru]

Apologies, the subject should have been, of course, "[PATCH V7 0/5] Fix
VGA logdirty related display freezes with altp2m", which I did paste in,
but ommited to uncomment.


Sorry,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

(No subject)

[Ankit Navik]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Hello,

I am facing an issue for my recipe during compilation.
Error:
|   The C compiler
|
|     "/usr/bin/clang-4.0"
|
|   is not able to compile a simple test program.

log file is attached.
I would appreciate any suggestions.

Regards,
Ankit

[-- Attachment #2: log.do_compile.5550 --]
[-- Type: application/octet-stream, Size: 12101 bytes --]

DEBUG: Executing shell function do_compile
NOTE: make -j 8 package
[  0%] Built target igdrcl_lib_release_sharings_enable
[  1%] Built target elflib
[  1%] Built target gmock-gtest
[  1%] Performing configure step for 'cclang'
[  1%] Built target biksim
[  2%] Built target igfx_gmmumd_dll
[  3%] Built target gmm_umd
[  5%] Built target igfx_gmmumd_excite
CMake Deprecation Warning at CMakeLists.txt:15 (cmake_policy):
  The OLD behavior for policy CMP0051 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


[  6%] Built target igfxgmmumd
[  6%] Built target LLVMDemangle
[  6%] Built target LLVMTableGen
[  6%] Built target check_headers
[  6%] Building custom target for Metadata Framework
[  6%] Built target MDAutogen
[  6%] Tablegenning GenISAIntrinsics.
[  7%] Built target obj.llvm-tblgen
[  7%] Built target GenISAIntrinsicsTablegen
[ 11%] Built target LLVMSupport
[ 12%] Built target GEDLibrary
[ 13%] Built target IGA_OLIB
[ 13%] Built target builtins_sources
[ 13%] Built target LLVMMCParser
[ 13%] Built target igdrcl_lib_mockable_sharings_enable
[ 16%] Built target SPIRV-Tools
[ 18%] Built target LLVMMC
[ 18%] Built target igdrcl_libult_cs
[ 20%] Built target igdrcl_libult
[ 20%] Built target test_dynamic_lib
[ 20%] Built target elflib_tests
[ 20%] Built target mock_gmm
[ 20%] Built target cloc_segfault_test
[ 20%] Built target cloc
[ 20%] Built target igdrcl_mocks
[ 20%] Built target igdrcl_libult_env
[ 20%] Built target LocalScheduler
[ 21%] Built target GMMULT
[ 21%] Built target IGA_SLIB
[ 21%] Built target IGA_DLL
Running cloc_segfault_test
[ 22%] Built target IGA_ENC_LIB
[ 23%] Built target cloc_tests
/bin/sh: /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/bin/cloc_segfault_test: No such file or directory
make[2]: *** [run_cloc_segfault_test] Error 127
make[1]: *** [unit_tests/offline_compiler/segfault_test/CMakeFiles/run_cloc_segfault_test.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Scanning dependencies of target Run_ULT
running ULTs
Scanning dependencies of target llvm-tblgen
[ 23%] Linking CXX executable ../../bin/llvm-tblgen
/bin/sh: ../../../../bin/GMMULT: No such file or directory
make[2]: *** [Run_ULT] Error 127
make[1]: *** [gmmlib/Source/GmmLib/ULT/CMakeFiles/Run_ULT.dir/all] Error 2
[ 31%] Built target igdrcl_lib_mockable
[ 40%] Built target igdrcl_lib_release
Scanning dependencies of target GenX_IR
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BinaryCISAEmission.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BinaryEncoding.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BinaryEncodingIGA.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Common_BinaryEncoding.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BinaryEncodingCNL.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BuildCISAIRImpl.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BuildIRImpl.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/ByteCodeReaderNG.cpp.o
-- The C compiler identification is Clang 4.0.1
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/DebugInfo.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/FlowGraph.cpp.o
-- The CXX compiler identification is Clang 4.0.1
-- The ASM compiler identification is unknown
-- Found assembler: /usr/bin/clang-4.0
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/CFGStructurizer.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Gen4_IR.cpp.o
-- Check for working C compiler: /usr/bin/clang-4.0
-- Check for working C compiler: /usr/bin/clang-4.0 -- broken
CMake Error at /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot-native/usr/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 (message):
  The C compiler

    "/usr/bin/clang-4.0"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp
    
    Run Build Command:"/home/ank/open-source-yocto/poky/build/tmp/hosttools/make" "cmTC_6d4df/fast"
    make[3]: Entering directory `/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp'
    make -f CMakeFiles/cmTC_6d4df.dir/build.make CMakeFiles/cmTC_6d4df.dir/build
    make[4]: Entering directory `/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_6d4df.dir/testCCompiler.c.o
    /usr/bin/clang-4.0   -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0=/usr/src/debug/compute-runtime/git-r0 -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot= -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot-native=   -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  --sysroot=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot    -o CMakeFiles/cmTC_6d4df.dir/testCCompiler.c.o   -c /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_6d4df
    /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot-native/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_6d4df.dir/link.txt --verbose=1
    /usr/bin/clang-4.0 -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0=/usr/src/debug/compute-runtime/git-r0 -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot= -fdebug-prefix-map=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot-native=   -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  --sysroot=/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot   -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now  CMakeFiles/cmTC_6d4df.dir/testCCompiler.c.o  -o cmTC_6d4df 
    /usr/bin/ld: /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/recipe-sysroot/usr/lib/crt1.o: unrecognized relocation (0x29) in section `.text'
    /usr/bin/ld: final link failed: Bad value
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[4]: *** [cmTC_6d4df] Error 1
    make[4]: Leaving directory `/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp'
    make[3]: *** [cmTC_6d4df/fast] Error 2
    make[3]: Leaving directory `/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeTmp'
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:47 (project)


-- Configuring incomplete, errors occurred!
See also "/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeOutput.log".
See also "/home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/build/igc/IGC/BiFModule/clang_build/src/CMakeFiles/CMakeError.log".
make[2]: *** [igc/IGC/BiFModule/clang_build/src/src/cclang-stamp/cclang-configure] Error 1
make[1]: *** [igc/IGC/BiFModule/clang_build/CMakeFiles/cclang.dir/all] Error 2
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/GraphColor.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/HWConformity.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/SendFusion.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/LocalDataflow.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/LocalRA.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Lowered_IR.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/main.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Optimizer.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/PhyRegCompute.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/PhyRegUsage.cpp.o
[ 40%] Built target llvm-tblgen
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/ReduceExecSize.cpp.o
[ 40%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/RegAlloc.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/SpillCode.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/SpillManagerGMRF.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/TranslationInterface.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/VISAKernelImpl.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/G4Verifier.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/LVN.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/ifcvt.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/PreDefinedVars.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/SpillCleanup.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Rematerialization.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/RPE.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Common_ISA_framework.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Common_ISA_util.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/IsaDescription.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/IsaDisassembly.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/IsaVerification.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Common_ISA.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/visaBuilder_export.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Arena.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/common.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Mem_Manager.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Option.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/BitSet.cpp.o
[ 41%] Building CXX object igc/IGC/visa/CMakeFiles/GenX_IR.dir/Timer.cpp.o
[ 41%] Linking CXX static library igfxcmjit64.a
[ 41%] Built target GenX_IR
make: *** [all] Error 2
ERROR: oe_runmake failed
WARNING: /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/temp/run.do_compile.5550:1 exit 1 from 'exit 1'
ERROR: Function failed: do_compile (log file is located at /home/ank/open-source-yocto/poky/build/tmp/work/corei7-64-poky-linux/compute-runtime/git-r0/temp/log.do_compile.5550)

(No subject)

[Satya Sampangi]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

Dear All,

How to run the task in the recipe file present in the custom layer,
*which executes all packages*, bypassing the task present in base
layers?

Thanks & Regards,

Satya

[-- Attachment #2: Type: text/html, Size: 293 bytes --]

(No subject)

[Angelo Dureghello]

This patch serie adds initial support for m68k architecture.
A Linux kernel build has been tested successfully using a local
meta layer, or kernel-yocto. 

(No subject)

[Burton, Ross]

I'm curious: the data sheet for the processor you mention in 4/4 says
that it ha 64K of RAM.  Are there other processors in the range, or
have you done incredible things?

Ross
On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
>
>
> This patch serie adds initial support for m68k architecture.
> A Linux kernel build has been tested successfully using a local
> meta layer, or kernel-yocto.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

(No subject)

[Andrea Adami]

On Thu, Oct 4, 2018 at 3:55 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> I'm curious: the data sheet for the processor you mention in 4/4 says
> that it ha 64K of RAM.  Are there other processors in the range, or
> have you done incredible things?
>
> Ross

Heh,

64K is the internal sram..
There is a sdram controller DDR2 and a 32bit FlexBus bus for ROM/RAM
so I bet there is more...
Cheers
Andrea

P.S. I will notice right now an old m68k acker...

>On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
> >
> >
> > This patch serie adds initial support for m68k architecture.
> > A Linux kernel build has been tested successfully using a local
> > meta layer, or kernel-yocto.
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

(No subject)

[Angelo Dureghello]

Hi Burton,

On Thu, Oct 04, 2018 at 02:55:37PM +0100, Burton, Ross wrote:
> I'm curious: the data sheet for the processor you mention in 4/4 says
> that it ha 64K of RAM.  Are there other processors in the range, or
> have you done incredible things?
>

64KB is the internal static ram (SRAM), that's commonly 4 to 64K
for this family (i.e. some recent arm reachs 512K).
Then there is the built-in SDRAM/DDR2 controller :)
where i connect 128MB of DDR2(SDRAM), but other boards may have more.

Linux runs fine in ColdFire family from a long time. Initially only
non-MMU uClinux, now also the mainline kernel with MMU enabled.
 
Regards,
Angelo
 
> Ross
> On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
> >
> >
> > This patch serie adds initial support for m68k architecture.
> > A Linux kernel build has been tested successfully using a local
> > meta layer, or kernel-yocto.
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

(no subject)

[Arnd Bergmann]

Hi Thomas,

Please pull the system call changes into a branch of the tip tree.
These are the ones I posted right after rc1, with the addition of
two bug fixes that were contributed by Guenther and the kbuild test
robot.

I've had the changes in linux-next since then and not received
any other bug reports or feedback.

I panicked a little at one point when I realized that there is
a sparc64 specific bug in some of my patches, but I then
found that at least this series is not affected at all.

        Arnd

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the Git repository at:

  git+ssh://git@ra.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038

for you to fetch changes up to 67314ec7b0250290cc85eaa7a2f88a8ddb9e8547:

  RISC-V: Request newstat syscalls (2018-09-05 22:44:21 +0200)

----------------------------------------------------------------
y2038: convert more syscalls

Here is another set of system call changes to prepare the change over to
64-bit time_t. As before, the strategy is to change system calls that
take a 'struct timespec' argument over to 'struct __kernel_timespec',
which for now is defined to be the same but will get redefined to use a
64-bit time_t argument once we are ready to modify the system call tables.

The major change from previous patches is that the plan is no longer
to directly use the 'compat' system calls for providing compatibility
with the existing 32-bit time_t based entry points. Instead, we rename
the compat code to something that makes more sense on 32-bit architectures,
e.g. compat_timespec becomes old_timespec32.

With the renamed types in place, we change over the 'stat' and 'utimes'
families of system calls, sched_rr_get_interval, recvmmsg and
rt_sigtimedwait. Another series for poll, select and io_pgetevents is
currently being tested.

----------------------------------------------------------------
Arnd Bergmann (14):
      y2038: remove unused time interfaces
      y2038: make do_gettimeofday() and get_seconds() inline
      y2038: globally rename compat_time to old_time32
      y2038: Remove newstat family from default syscall set
      y2038: Remove stat64 family from default syscall set
      asm-generic: Move common compat types to asm-generic/compat.h
      asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
      asm-generic: Remove empty asm/unistd.h
      y2038: Change sys_utimensat() to use __kernel_timespec
      y2038: Compile utimes()/futimesat() conditionally
      y2038: utimes: Rework #ifdef guards for compat syscalls
      y2038: sched: Change sched_rr_get_interval to use __kernel_timespec
      y2038: socket: Change recvmmsg to use __kernel_timespec
      y2038: signal: Change rt_sigtimedwait to use __kernel_timespec

Guenter Roeck (1):
      RISC-V: Request newstat syscalls

kbuild test robot (1):
      y2038: __get_old_timespec32() can be static

 arch/alpha/include/asm/unistd.h          |   2 ++
 arch/arc/include/uapi/asm/unistd.h       |   1 +
 arch/arm/include/asm/unistd.h            |   4 ++--
 arch/arm64/include/asm/compat.h          |  26 +++++---------------------
 arch/arm64/include/asm/stat.h            |   2 +-
 arch/arm64/include/asm/unistd.h          |   2 +-
 arch/arm64/include/uapi/asm/unistd.h     |   1 +
 arch/c6x/include/uapi/asm/unistd.h       |   1 +
 arch/h8300/include/uapi/asm/unistd.h     |   1 +
 arch/hexagon/include/uapi/asm/unistd.h   |   1 +
 arch/ia64/include/asm/unistd.h           |   3 +++
 arch/m68k/include/asm/unistd.h           |   2 +-
 arch/microblaze/include/asm/unistd.h     |   2 +-
 arch/mips/include/asm/compat.h           |  28 +++++-----------------------
 arch/mips/include/asm/unistd.h           |   3 ++-
 arch/mips/kernel/binfmt_elfn32.c         |  14 +++++++-------
 arch/mips/kernel/binfmt_elfo32.c         |  14 +++++++-------
 arch/nds32/include/uapi/asm/unistd.h     |   1 +
 arch/nios2/include/uapi/asm/unistd.h     |   1 +
 arch/openrisc/include/uapi/asm/unistd.h  |   1 +
 arch/parisc/include/asm/compat.h         |  24 +++++-------------------
 arch/parisc/include/asm/unistd.h         |   3 ++-
 arch/powerpc/include/asm/compat.h        |  24 +++++-------------------
 arch/powerpc/include/asm/unistd.h        |   3 ++-
 arch/powerpc/kernel/asm-offsets.c        |   8 ++++----
 arch/powerpc/oprofile/backtrace.c        |   2 +-
 arch/riscv/include/asm/unistd.h          |   1 +
 arch/s390/include/asm/compat.h           |  18 ++----------------
 arch/s390/include/asm/unistd.h           |   3 ++-
 arch/sh/include/asm/unistd.h             |   2 +-
 arch/sparc/include/asm/compat.h          |  25 +++++--------------------
 arch/sparc/include/asm/unistd.h          |   3 ++-
 arch/unicore32/include/uapi/asm/unistd.h |   1 +
 arch/x86/include/asm/compat.h            |  19 ++-----------------
 arch/x86/include/asm/unistd.h            |   3 ++-
 arch/xtensa/include/asm/unistd.h         |   2 +-
 fs/aio.c                                 |   8 ++++----
 fs/compat_binfmt_elf.c                   |   2 +-
 fs/read_write.c                          |   2 +-
 fs/select.c                              |  20 ++++++++++----------
 fs/stat.c                                |   3 +++
 fs/timerfd.c                             |  12 ++++++------
 fs/utimes.c                              |  73
+++++++++++++++++++++++++++++++++++--------------------------------------
 include/asm-generic/compat.h             |  24 +++++++++++++++++++++++-
 include/asm-generic/unistd.h             |  13 -------------
 include/linux/compat.h                   | 101
+++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------
 include/linux/compat_time.h              |  32 --------------------------------
 include/linux/elfcore-compat.h           |   8 ++++----
 include/linux/restart_block.h            |   4 ++--
 include/linux/socket.h                   |   4 ++--
 include/linux/syscalls.h                 |  21 ++++++++++++---------
 include/linux/time32.h                   |  78
+++++++++++++++++++++++++++++++++++++++++-------------------------------------
 include/linux/timekeeping.h              |  12 ------------
 include/linux/timekeeping32.h            |  53
+++++++----------------------------------------------
 include/uapi/asm-generic/unistd.h        |   2 ++
 ipc/mqueue.c                             |   8 ++++----
 ipc/msg.c                                |   6 +++---
 ipc/sem.c                                |  10 +++++-----
 ipc/shm.c                                |   6 +++---
 ipc/syscall.c                            |   2 +-
 ipc/util.h                               |   2 +-
 kernel/compat.c                          |   8 ++++----
 kernel/futex_compat.c                    |   2 +-
 kernel/sched/core.c                      |   8 ++++----
 kernel/signal.c                          |  19 ++++++++++---------
 kernel/time/hrtimer.c                    |   8 ++++----
 kernel/time/posix-stubs.c                |  18 +++++++++---------
 kernel/time/posix-timers.c               |  30 +++++++++++++++---------------
 kernel/time/time.c                       |  97
++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------
 kernel/time/timekeeping.c                |  24 ------------------------
 net/compat.c                             |  10 +++++-----
 net/socket.c                             |  18 ++++++++----------
 72 files changed, 398 insertions(+), 601 deletions(-)
 delete mode 100644 include/asm-generic/unistd.h
 delete mode 100644 include/linux/compat_time.h

Reply
Forward
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

(No subject)

[nishant poorswani]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

Hi. I'm looking to write a recipe which installs the wheel file directly.
Any idea how to go about it.

[-- Attachment #2: Type: text/html, Size: 132 bytes --]

(No subject)

[Eric Ruei]

From 65652cf6c1d896796e773b90642a867ee2c6ec77 Mon Sep 17 00:00:00 2001
From: Eric Ruei <e-ruei1@ti.com>
Date: Thu, 16 Aug 2018 17:20:05 -0400
Subject: [PATCH] img-pvr-sdk: bump SRCREV to pick up the valid arm64 PVR Tools

Signed-off-by: Eric Ruei <e-ruei1@ti.com>
---
 meta-arago-extras/recipes-graphics/img-pvr-sdk/img-pvr-sdk_3.3.2.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-arago-extras/recipes-graphics/img-pvr-sdk/img-pvr-sdk_3.3.2.bb b/meta-arago-extras/recipes-graphics/img-pvr-sdk/img-pvr-sdk_3.3.2.bb
index 9c563d2..2fbd386 100644
--- a/meta-arago-extras/recipes-graphics/img-pvr-sdk/img-pvr-sdk_3.3.2.bb
+++ b/meta-arago-extras/recipes-graphics/img-pvr-sdk/img-pvr-sdk_3.3.2.bb
@@ -7,9 +7,9 @@ CLEANBROKEN = "1"
 BRANCH = "master"
 
 SRC_URI = "git://git.ti.com/graphics/img-pvr-sdk.git;protocol=git;branch=${BRANCH}"
-SRCREV = "3e5c2fa3458a8cae4b6b8d62391fc32b708a2ed4"
+SRCREV = "7af5846a0989a1475548ca05f6984c817fb76adc"
 
-PR = "r13"
+PR = "r14"
 
 COMPATIBLE_MACHINE = "omap-a15|ti43x|ti33x|k3"
 
-- 
1.9.1

(No subject)

[Nathan Rossi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8415 bytes --]


,
 Manjukumar Harthikote Matha <manjukumar.harthikote-matha@xilinx.com>
Subject:
 [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This bbclass implements the device tree compilation for user provided
device trees. In order to use this class, it should be inherited in a
BSP recipe which provides the sources. The default setup enables
inclusion of kernel device tree sources (though can be disabled by the
recipe by overriding DT_INCLUDE or KERNEL_INCLUDE).

This provides an additional mechanism for BSPs to provide device trees
and device tree overlays for their target machines. Whilst still
enabling access to the kernel device trees for base SoC includes and
headers.

This approach to providing device trees has benefits for certain use
cases over patching the device trees into the kernel source.

* device trees are separated from kernel source, allows for selection of
kernel and or kernel versions without needing to explicitly patch the
kernel (or appending to the kernel recipes).

* providing device trees from separate sources, from the layer,
generated by the recipe or other recipes.

This class also implements some additional features that are not
available in the kernel-devicetree flow. This includes population of
device tree blobs into the sysroot which allows for other recipes to
consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree
overlay compilation and customizing DTC compilation args (boot
cpu/padding/etc.).

Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Acked-by: Martin Hundebøll <mnhu@prevas.dk>
---
In addition to this patch I have written some documentation for the
Yocto BSP guide that covers details about both methods.

The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly
like this class for some time. It has been very useful for out-of-kernel
device tree compilation as well as for a mechanism so that users of
Xilinx SoCs can provide their customizations (FPGA devices) and board
specific configuration. This compilation flow also makes sense for other
BSPs, which is the reason for creating this bbclass for common shared
use by other BSPs.

Examples of this classes usage can be seen for meta-xilinx:
https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
---
 meta/classes/devicetree.bbclass | 140 ++++++++++++++++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 meta/classes/devicetree.bbclass

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
new file mode 100644
index 0000000000..dbc83f2a1d
--- /dev/null
+++ b/meta/classes/devicetree.bbclass
@@ -0,0 +1,140 @@
+# This bbclass implements device tree compliation for user provided device tree
+# sources. The compilation of the device tree sources is the same as the kernel
+# device tree compilation process, this includes being able to include sources
+# from the kernel such as soc dtsi files or header files such as gpio.h. In
+# addition to device trees this bbclass also handles compilation of device tree
+# overlays.
+#
+# The output of this class behaves similar to how kernel-devicetree.bbclass
+# operates in that the output files are installed into /boot/devicetree.
+# However this class on purpose separates the deployed device trees into the
+# 'devicetree' subdirectory. This prevents clashes with the kernel-devicetree
+# output. Additionally the device trees are populated into the sysroot for
+# access via the sysroot from within other recipes.
+
+SECTION ?= "bsp"
+
+# The default inclusion of kernel device tree includes and headers means that
+# device trees built with them are at least GPLv2 (and in some cases dual
+# licensed). Default to GPLv2 if the recipe does not specify a license.
+LICENSE ?= "GPLv2"
+LIC_FILES_CHKSUM ?= "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "dtc-native"
+
+inherit deploy kernel-arch
+
+COMPATIBLE_MACHINE ?= "^$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+SYSROOT_DIRS += "/boot/devicetree"
+FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo"
+
+S = "${WORKDIR}"
+B = "${WORKDIR}/build"
+
+# Default kernel includes, these represent what are normally used for in-kernel
+# sources.
+KERNEL_INCLUDE ??= " \
+        ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
+        ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \
+        ${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
+        "
+
+DT_INCLUDE[doc] = "Search paths to be made available to both the device tree compiler and preprocessor for inclusion."
+DT_INCLUDE ?= "${DT_FILES_PATH} ${KERNEL_INCLUDE}"
+DT_FILES_PATH[doc] = "Defaults to source directory, can be used to select dts files that are not in source (e.g. generated)."
+DT_FILES_PATH ?= "${S}"
+
+DT_PADDING_SIZE[doc] = "Size of padding on the device tree blob, used as extra space typically for additional properties during boot."
+DT_PADDING_SIZE ??= "0x3000"
+DT_RESERVED_MAP[doc] = "Number of reserved map entires."
+DT_RESERVED_MAP ??= "8"
+DT_BOOT_CPU[doc] = "The boot cpu, defaults to 0"
+DT_BOOT_CPU ??= "0"
+
+DTC_FLAGS ?= "-R ${DT_RESERVED_MAP} -p ${DT_PADDING_SIZE} -b ${DT_BOOT_CPU}"
+DTC_PPFLAGS ?= "-nostdinc -undef -D__DTS__ -x assembler-with-cpp"
+DTC_OFLAGS ?= "-@ -H epapr"
+
+python () {
+    if d.getVar("KERNEL_INCLUDE"):
+        # auto add dependency on kernel tree, but only if kernel include paths
+        # are specified.
+        d.appendVarFlag("do_compile", "depends", " virtual/kernel:do_configure")
+}
+
+def expand_includes(varname, d):
+    import glob
+    includes = set()
+    # expand all includes with glob
+    for i in (d.getVar(varname) or "").split():
+        for g in glob.glob(i):
+            if os.path.isdir(g): # only add directories to include path
+                includes.add(g)
+    return includes
+
+def devicetree_source_is_overlay(path):
+    # determine if a dts file is an overlay by checking if it uses "/plugin/;"
+    with open(path, "r") as f:
+        for i in f:
+            if i.startswith("/plugin/;"):
+                return True
+    return False
+
+def devicetree_compile(dtspath, includes, d):
+    import subprocess
+    dts = os.path.basename(dtspath)
+    dtname = os.path.splitext(dts)[0]
+    bb.note("Processing {0} [{1}]".format(dtname, dts))
+
+    # preprocess
+    ppargs = d.getVar("BUILD_CPP").split()
+    ppargs += (d.getVar("DTC_PPFLAGS") or "").split()
+    for i in includes:
+        ppargs.append("-I{0}".format(i))
+    ppargs += ["-o", "{0}.pp".format(dts), dtspath]
+    bb.note("Running {0}".format(" ".join(ppargs)))
+    subprocess.run(ppargs, check = True)
+
+    # determine if the file is an overlay or not (using the preprocessed file)
+    isoverlay = devicetree_source_is_overlay("{0}.pp".format(dts))
+
+    # compile
+    dtcargs = ["dtc"] + (d.getVar("DTC_FLAGS") or "").split()
+    if isoverlay:
+        dtcargs += (d.getVar("DTC_OFLAGS") or "").split()
+    for i in includes:
+        dtcargs += ["-i", i]
+    dtcargs += ["-o", "{0}.{1}".format(dtname, "dtbo" if isoverlay else "dtb")]
+    dtcargs += ["-I", "dts", "-O", "dtb", "{0}.pp".format(dts)]
+    bb.note("Running {0}".format(" ".join(dtcargs)))
+    subprocess.run(dtcargs, check = True)
+
+python devicetree_do_compile() {
+    includes = expand_includes("DT_INCLUDE", d)
+    listpath = d.getVar("DT_FILES_PATH")
+    for dts in os.listdir(listpath):
+        if not dts.endswith(".dts"):
+            continue # skip non-.dts files
+        dtspath = os.path.join(listpath, dts)
+        devicetree_compile(dtspath, includes, d)
+}
+
+devicetree_do_install() {
+    for DTB_FILE in `ls *.dtb *.dtbo`; do
+        install -Dm 0644 ${B}/${DTB_FILE} ${D}/boot/devicetree/${DTB_FILE}
+    done
+}
+
+devicetree_do_deploy() {
+    for DTB_FILE in `ls *.dtb *.dtbo`; do
+        install -Dm 0644 ${B}/${DTB_FILE} ${DEPLOYDIR}/devicetree/${DTB_FILE}
+    done
+}
+addtask deploy before do_build after do_install
+
+EXPORT_FUNCTIONS do_compile do_install do_deploy
+
-- 
2.18.0

(no subject)

[Fritz Micheal.]

-- 
Do you need a loan at 2% interest rate for any reason ?
Every interested applicant should contact us via the below contact
details.
E-mails: fritzmicloanfirm@financier.com
firtzmicloanfirm@gmail.com

Yours Sincerely
Fritz Micheal.

(No subject)

[Eyal Reizer]

[-- Attachment #1: Type: text/plain, Size: 14 bytes --]

זקקקזס

[-- Attachment #2: Type: text/html, Size: 36 bytes --]

(No subject)

[Djordje Senicic]

Subject: [meta-arago][rocko/master][PATCH] tidl-api: Update test video clip

* Use real-life video clip and list of classes

Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
 meta-arago-extras/recipes-ti/tidl-api/tidl-api.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-arago-extras/recipes-ti/tidl-api/tidl-api.inc b/meta-arago-extras/recipes-ti/tidl-api/tidl-api.inc
index d2b570d..f1a34eb 100644
--- a/meta-arago-extras/recipes-ti/tidl-api/tidl-api.inc
+++ b/meta-arago-extras/recipes-ti/tidl-api/tidl-api.inc
@@ -8,4 +8,4 @@ GIT_PROTOCOL = "git"
 BRANCH = "master"
 
 SRC_URI = "${GIT_URI};protocol=${GIT_PROTOCOL};branch=${BRANCH}"
-SRCREV = "8bad8d86fd89fd8c482aa10ab89f3049337a9ca2"
+SRCREV = "06585057d0f47bb930647123557bc5a1506dabda"
-- 
1.9.1

(No subject)

[William Delacre]

Hi ! :-)

I’m facing issues when trying to run ‘bitbake python-twisted’ (do_compile
error)

Log says :
“Download error on https://pypi.python.org/simple/incremental/: [Errno -3]
Temporary failure in name resolution

............

distutils.errors.DistutilsError : Could not find suitable distribution for
Requirement.parse(‘incremental>=16.10.1’)”

First of all I’m not connected to internet, so I’ve pre-downloaded all the
required packages (twisted-17.9.0.tar.bz2 & incremental-17.5.0.tar.gz are
present in my build/downloads folder)

It’s the first time I have some “downloading issues” and I’m stuck on it
for a few hours now..

Any tips for me ?

Thanks in advance !

(No subject)

[Mark Asselstine]

On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
<williamdelacre@gmail.com> wrote:
> Hi ! :-)
>
> I’m facing issues when trying to run ‘bitbake python-twisted’ (do_compile
> error)
>
> Log says :
> “Download error on https://pypi.python.org/simple/incremental/: [Errno -3]
> Temporary failure in name resolution
>
> ............
>
> distutils.errors.DistutilsError : Could not find suitable distribution for
> Requirement.parse(‘incremental>=16.10.1’)”
>
> First of all I’m not connected to internet, so I’ve pre-downloaded all the
> required packages (twisted-17.9.0.tar.bz2 & incremental-17.5.0.tar.gz are
> present in my build/downloads folder)
>
> It’s the first time I have some “downloading issues” and I’m stuck on it
> for a few hours now..
>
> Any tips for me ?

Check all aspects of what you have manually downloaded and populated
in your downloads. My guess is that a checksum or some other detail
isn't matching and it is rejecting what you have and thus attempting
to re-download the file.

Mark

>
> Thanks in advance !
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[Mark Asselstine]

On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
<mark.asselstine@windriver.com> wrote:
> On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> <williamdelacre@gmail.com> wrote:
>> Hi ! :-)
>>
>> I’m facing issues when trying to run ‘bitbake python-twisted’ (do_compile
>> error)
>>
>> Log says :
>> “Download error on https://pypi.python.org/simple/incremental/: [Errno -3]
>> Temporary failure in name resolution

With the additional info you sent me along with a second look at the
error I can fairly confidently say I know what the issue is.

Python, like some other languages (ruby, go...) will attempt to
download dependencies/requirements if they are not present. This is
done "outside" of the bitbake system and thus will ignore
BB_NO_NETWORK and is generally a bad thing. It isn't quite host
contamination but it is very similar. What we do with our python
recipes in bitbake is review a python package's source setup.py,
requirements.txt...files in order to determine what other python
packages are needed, add them as RDEPENDS or similar in order to avoid
the python attempting to complete a download such as this.

In this case python-twisted 'requires' python-incremental but the
Rocko version of the python-twisted recipe lacks the needed assignment
to ensure this is available in the recipe sysroot and thus the
attempted download.

Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
[python-twisted: avoid downloading build dependencies] to Rocko and
you will be good to go. You should also follow up this thread with a
request to have this commit put onto Rocko to avoid others hitting the
same issue.

Mark

>>
>> ............
>>
>> distutils.errors.DistutilsError : Could not find suitable distribution for
>> Requirement.parse(‘incremental>=16.10.1’)”
>>
>> First of all I’m not connected to internet, so I’ve pre-downloaded all the
>> required packages (twisted-17.9.0.tar.bz2 & incremental-17.5.0.tar.gz are
>> present in my build/downloads folder)
>>
>> It’s the first time I have some “downloading issues” and I’m stuck on it
>> for a few hours now..
>>
>> Any tips for me ?
>
> Check all aspects of what you have manually downloaded and populated
> in your downloads. My guess is that a checksum or some other detail
> isn't matching and it is rejecting what you have and thus attempting
> to re-download the file.
>
> Mark
>
>>
>> Thanks in advance !
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[William Delacre]

Thanks a lot for the answer, it worked perfectly !

There is just one point I don’t really understand : why do we need to add a
dependency to ‘python-incremental-NATIVE’ ?

What would happen if I just add to the python-twisted recipe :

DEPENDS += “${PYTHON_PN}-incremental“

William

Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
mark.asselstine@windriver.com> a écrit :

> On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> <mark.asselstine@windriver.com> wrote:
> > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > <williamdelacre@gmail.com> wrote:
> >> Hi ! :-)
> >>
> >> I’m facing issues when trying to run ‘bitbake python-twisted’
> (do_compile
> >> error)
> >>
> >> Log says :
> >> “Download error on https://pypi.python.org/simple/incremental/: [Errno
> -3]
> >> Temporary failure in name resolution
>
> With the additional info you sent me along with a second look at the
> error I can fairly confidently say I know what the issue is.
>
> Python, like some other languages (ruby, go...) will attempt to
> download dependencies/requirements if they are not present. This is
> done "outside" of the bitbake system and thus will ignore
> BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> contamination but it is very similar. What we do with our python
> recipes in bitbake is review a python package's source setup.py,
> requirements.txt...files in order to determine what other python
> packages are needed, add them as RDEPENDS or similar in order to avoid
> the python attempting to complete a download such as this.
>
> In this case python-twisted 'requires' python-incremental but the
> Rocko version of the python-twisted recipe lacks the needed assignment
> to ensure this is available in the recipe sysroot and thus the
> attempted download.
>
> Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> [python-twisted: avoid downloading build dependencies] to Rocko and
> you will be good to go. You should also follow up this thread with a
> request to have this commit put onto Rocko to avoid others hitting the
> same issue.
>
> Mark
>
> >>
> >> ............
> >>
> >> distutils.errors.DistutilsError : Could not find suitable distribution
> for
> >> Requirement.parse(‘incremental>=16.10.1’)”
> >>
> >> First of all I’m not connected to internet, so I’ve pre-downloaded all
> the
> >> required packages (twisted-17.9.0.tar.bz2 & incremental-17.5.0.tar.gz
> are
> >> present in my build/downloads folder)
> >>
> >> It’s the first time I have some “downloading issues” and I’m stuck on it
> >> for a few hours now..
> >>
> >> Any tips for me ?
> >
> > Check all aspects of what you have manually downloaded and populated
> > in your downloads. My guess is that a checksum or some other detail
> > isn't matching and it is rejecting what you have and thus attempting
> > to re-download the file.
> >
> > Mark
> >
> >>
> >> Thanks in advance !
> >> --
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

(No subject)

[Mark Asselstine]

On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> Thanks a lot for the answer, it worked perfectly !
> 
> There is just one point I don’t really understand : why do we need to add a
> dependency to ‘python-incremental-NATIVE’ ?
> 
> What would happen if I just add to the python-twisted recipe :
> 
> DEPENDS += “${PYTHON_PN}-incremental“

This would assume that python is completely arch independent, which it is not. 
Assume for example python-incremental had some C extensions, using DEPENDS 
would build them for the target arch yet possibly attempt to run them on your 
build host. -native takes care of this.

Some may say this is a bit of a hack since the difference in ARCH *might* 
equate to a difference in behavior. But I have dealt with many python recipes 
and have yet to run into any scenario where this potential issue exists.

At least that is what I can recall at the moment. Unfortunately I have 
forgotten some of the subtleties that might be in play.

Mark

> 
> William
> 
> Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> 
> mark.asselstine@windriver.com> a écrit :
> > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > 
> > <mark.asselstine@windriver.com> wrote:
> > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > 
> > > <williamdelacre@gmail.com> wrote:
> > >> Hi ! :-)
> > >> 
> > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > 
> > (do_compile
> > 
> > >> error)
> > >> 
> > >> Log says :
> > >> “Download error on https://pypi.python.org/simple/incremental/: [Errno
> > 
> > -3]
> > 
> > >> Temporary failure in name resolution
> > 
> > With the additional info you sent me along with a second look at the
> > error I can fairly confidently say I know what the issue is.
> > 
> > Python, like some other languages (ruby, go...) will attempt to
> > download dependencies/requirements if they are not present. This is
> > done "outside" of the bitbake system and thus will ignore
> > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > contamination but it is very similar. What we do with our python
> > recipes in bitbake is review a python package's source setup.py,
> > requirements.txt...files in order to determine what other python
> > packages are needed, add them as RDEPENDS or similar in order to avoid
> > the python attempting to complete a download such as this.
> > 
> > In this case python-twisted 'requires' python-incremental but the
> > Rocko version of the python-twisted recipe lacks the needed assignment
> > to ensure this is available in the recipe sysroot and thus the
> > attempted download.
> > 
> > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > [python-twisted: avoid downloading build dependencies] to Rocko and
> > you will be good to go. You should also follow up this thread with a
> > request to have this commit put onto Rocko to avoid others hitting the
> > same issue.
> > 
> > Mark
> > 
> > >> ............
> > >> 
> > >> distutils.errors.DistutilsError : Could not find suitable distribution
> > 
> > for
> > 
> > >> Requirement.parse(‘incremental>=16.10.1’)”
> > >> 
> > >> First of all I’m not connected to internet, so I’ve pre-downloaded all
> > 
> > the
> > 
> > >> required packages (twisted-17.9.0.tar.bz2 & incremental-17.5.0.tar.gz
> > 
> > are
> > 
> > >> present in my build/downloads folder)
> > >> 
> > >> It’s the first time I have some “downloading issues” and I’m stuck on
> > >> it
> > >> for a few hours now..
> > >> 
> > >> Any tips for me ?
> > > 
> > > Check all aspects of what you have manually downloaded and populated
> > > in your downloads. My guess is that a checksum or some other detail
> > > isn't matching and it is rejecting what you have and thus attempting
> > > to re-download the file.
> > > 
> > > Mark
> > > 
> > >> Thanks in advance !
> > >> --
> > >> _______________________________________________
> > >> Openembedded-devel mailing list
> > >> Openembedded-devel@lists.openembedded.org
> > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[William Delacre]

Okay, it makes sense!

My question may seem stupid but then why don’t we always use ‘-native’ for
the dependencies ?

Is it because sometimes we know that the behavior of ‘foo’ and ‘foo-native’
would be the same, independently of the architecture ?

William

Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
mark.asselstine@windriver.com> a écrit :

> On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > Thanks a lot for the answer, it worked perfectly !
> >
> > There is just one point I don’t really understand : why do we need to
> add a
> > dependency to ‘python-incremental-NATIVE’ ?
> >
> > What would happen if I just add to the python-twisted recipe :
> >
> > DEPENDS += “${PYTHON_PN}-incremental“
>
> This would assume that python is completely arch independent, which it is
> not.
> Assume for example python-incremental had some C extensions, using DEPENDS
> would build them for the target arch yet possibly attempt to run them on
> your
> build host. -native takes care of this.
>
> Some may say this is a bit of a hack since the difference in ARCH *might*
> equate to a difference in behavior. But I have dealt with many python
> recipes
> and have yet to run into any scenario where this potential issue exists.
>
> At least that is what I can recall at the moment. Unfortunately I have
> forgotten some of the subtleties that might be in play.
>
> Mark
>
> >
> > William
> >
> > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> >
> > mark.asselstine@windriver.com> a écrit :
> > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > >
> > > <mark.asselstine@windriver.com> wrote:
> > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > >
> > > > <williamdelacre@gmail.com> wrote:
> > > >> Hi ! :-)
> > > >>
> > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > >
> > > (do_compile
> > >
> > > >> error)
> > > >>
> > > >> Log says :
> > > >> “Download error on https://pypi.python.org/simple/incremental/:
> [Errno
> > >
> > > -3]
> > >
> > > >> Temporary failure in name resolution
> > >
> > > With the additional info you sent me along with a second look at the
> > > error I can fairly confidently say I know what the issue is.
> > >
> > > Python, like some other languages (ruby, go...) will attempt to
> > > download dependencies/requirements if they are not present. This is
> > > done "outside" of the bitbake system and thus will ignore
> > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > contamination but it is very similar. What we do with our python
> > > recipes in bitbake is review a python package's source setup.py,
> > > requirements.txt...files in order to determine what other python
> > > packages are needed, add them as RDEPENDS or similar in order to avoid
> > > the python attempting to complete a download such as this.
> > >
> > > In this case python-twisted 'requires' python-incremental but the
> > > Rocko version of the python-twisted recipe lacks the needed assignment
> > > to ensure this is available in the recipe sysroot and thus the
> > > attempted download.
> > >
> > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > [python-twisted: avoid downloading build dependencies] to Rocko and
> > > you will be good to go. You should also follow up this thread with a
> > > request to have this commit put onto Rocko to avoid others hitting the
> > > same issue.
> > >
> > > Mark
> > >
> > > >> ............
> > > >>
> > > >> distutils.errors.DistutilsError : Could not find suitable
> distribution
> > >
> > > for
> > >
> > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > >>
> > > >> First of all I’m not connected to internet, so I’ve pre-downloaded
> all
> > >
> > > the
> > >
> > > >> required packages (twisted-17.9.0.tar.bz2 &
> incremental-17.5.0.tar.gz
> > >
> > > are
> > >
> > > >> present in my build/downloads folder)
> > > >>
> > > >> It’s the first time I have some “downloading issues” and I’m stuck
> on
> > > >> it
> > > >> for a few hours now..
> > > >>
> > > >> Any tips for me ?
> > > >
> > > > Check all aspects of what you have manually downloaded and populated
> > > > in your downloads. My guess is that a checksum or some other detail
> > > > isn't matching and it is rejecting what you have and thus attempting
> > > > to re-download the file.
> > > >
> > > > Mark
> > > >
> > > >> Thanks in advance !
> > > >> --
> > > >> _______________________________________________
> > > >> Openembedded-devel mailing list
> > > >> Openembedded-devel@lists.openembedded.org
> > > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
>
>
>

(No subject)

[S. Lockwood-Childs]

It depends on the role of the particular dependency:

* tool you need to run during build             <-- native dependency
* library you need to link against during build <-- target dependency

--SJLC

On Fri, Jul 27, 2018 at 06:25:27PM +0200, William Delacre wrote:
> Okay, it makes sense!
> 
> My question may seem stupid but then why don’t we always use ‘-native’ for
> the dependencies ?
> 
> Is it because sometimes we know that the behavior of ‘foo’ and ‘foo-native’
> would be the same, independently of the architecture ?
> 
> William
> 
> Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
> mark.asselstine@windriver.com> a écrit :
> 
> > On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > > Thanks a lot for the answer, it worked perfectly !
> > >
> > > There is just one point I don’t really understand : why do we need to
> > add a
> > > dependency to ‘python-incremental-NATIVE’ ?
> > >
> > > What would happen if I just add to the python-twisted recipe :
> > >
> > > DEPENDS += “${PYTHON_PN}-incremental“
> >
> > This would assume that python is completely arch independent, which it is
> > not.
> > Assume for example python-incremental had some C extensions, using DEPENDS
> > would build them for the target arch yet possibly attempt to run them on
> > your
> > build host. -native takes care of this.
> >
> > Some may say this is a bit of a hack since the difference in ARCH *might*
> > equate to a difference in behavior. But I have dealt with many python
> > recipes
> > and have yet to run into any scenario where this potential issue exists.
> >
> > At least that is what I can recall at the moment. Unfortunately I have
> > forgotten some of the subtleties that might be in play.
> >
> > Mark
> >
> > >
> > > William
> > >
> > > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> > >
> > > mark.asselstine@windriver.com> a écrit :
> > > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > > >
> > > > <mark.asselstine@windriver.com> wrote:
> > > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > > >
> > > > > <williamdelacre@gmail.com> wrote:
> > > > >> Hi ! :-)
> > > > >>
> > > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > > >
> > > > (do_compile
> > > >
> > > > >> error)
> > > > >>
> > > > >> Log says :
> > > > >> “Download error on https://pypi.python.org/simple/incremental/:
> > [Errno
> > > >
> > > > -3]
> > > >
> > > > >> Temporary failure in name resolution
> > > >
> > > > With the additional info you sent me along with a second look at the
> > > > error I can fairly confidently say I know what the issue is.
> > > >
> > > > Python, like some other languages (ruby, go...) will attempt to
> > > > download dependencies/requirements if they are not present. This is
> > > > done "outside" of the bitbake system and thus will ignore
> > > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > > contamination but it is very similar. What we do with our python
> > > > recipes in bitbake is review a python package's source setup.py,
> > > > requirements.txt...files in order to determine what other python
> > > > packages are needed, add them as RDEPENDS or similar in order to avoid
> > > > the python attempting to complete a download such as this.
> > > >
> > > > In this case python-twisted 'requires' python-incremental but the
> > > > Rocko version of the python-twisted recipe lacks the needed assignment
> > > > to ensure this is available in the recipe sysroot and thus the
> > > > attempted download.
> > > >
> > > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > > [python-twisted: avoid downloading build dependencies] to Rocko and
> > > > you will be good to go. You should also follow up this thread with a
> > > > request to have this commit put onto Rocko to avoid others hitting the
> > > > same issue.
> > > >
> > > > Mark
> > > >
> > > > >> ............
> > > > >>
> > > > >> distutils.errors.DistutilsError : Could not find suitable
> > distribution
> > > >
> > > > for
> > > >
> > > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > > >>
> > > > >> First of all I’m not connected to internet, so I’ve pre-downloaded
> > all
> > > >
> > > > the
> > > >
> > > > >> required packages (twisted-17.9.0.tar.bz2 &
> > incremental-17.5.0.tar.gz
> > > >
> > > > are
> > > >
> > > > >> present in my build/downloads folder)
> > > > >>
> > > > >> It’s the first time I have some “downloading issues” and I’m stuck
> > on
> > > > >> it
> > > > >> for a few hours now..
> > > > >>
> > > > >> Any tips for me ?
> > > > >
> > > > > Check all aspects of what you have manually downloaded and populated
> > > > > in your downloads. My guess is that a checksum or some other detail
> > > > > isn't matching and it is rejecting what you have and thus attempting
> > > > > to re-download the file.
> > > > >
> > > > > Mark
> > > > >
> > > > >> Thanks in advance !
> > > > >> --
> > > > >> _______________________________________________
> > > > >> Openembedded-devel mailing list
> > > > >> Openembedded-devel@lists.openembedded.org
> > > > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> >
> >
> >
> >
> -- 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[William Delacre]

Alright, thabks !

And I guess if it’s a tool I need during runtime on the target, I add it in
the RDPENDS variable ?

Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
écrit :

> It depends on the role of the particular dependency:
>
> * tool you need to run during build             <-- native dependency
> * library you need to link against during build <-- target dependency
>
> --SJLC
>
> On Fri, Jul 27, 2018 at 06:25:27PM +0200, William Delacre wrote:
> > Okay, it makes sense!
> >
> > My question may seem stupid but then why don’t we always use ‘-native’
> for
> > the dependencies ?
> >
> > Is it because sometimes we know that the behavior of ‘foo’ and
> ‘foo-native’
> > would be the same, independently of the architecture ?
> >
> > William
> >
> > Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
> > mark.asselstine@windriver.com> a écrit :
> >
> > > On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > > > Thanks a lot for the answer, it worked perfectly !
> > > >
> > > > There is just one point I don’t really understand : why do we need to
> > > add a
> > > > dependency to ‘python-incremental-NATIVE’ ?
> > > >
> > > > What would happen if I just add to the python-twisted recipe :
> > > >
> > > > DEPENDS += “${PYTHON_PN}-incremental“
> > >
> > > This would assume that python is completely arch independent, which it
> is
> > > not.
> > > Assume for example python-incremental had some C extensions, using
> DEPENDS
> > > would build them for the target arch yet possibly attempt to run them
> on
> > > your
> > > build host. -native takes care of this.
> > >
> > > Some may say this is a bit of a hack since the difference in ARCH
> *might*
> > > equate to a difference in behavior. But I have dealt with many python
> > > recipes
> > > and have yet to run into any scenario where this potential issue
> exists.
> > >
> > > At least that is what I can recall at the moment. Unfortunately I have
> > > forgotten some of the subtleties that might be in play.
> > >
> > > Mark
> > >
> > > >
> > > > William
> > > >
> > > > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> > > >
> > > > mark.asselstine@windriver.com> a écrit :
> > > > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > > > >
> > > > > <mark.asselstine@windriver.com> wrote:
> > > > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > > > >
> > > > > > <williamdelacre@gmail.com> wrote:
> > > > > >> Hi ! :-)
> > > > > >>
> > > > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > > > >
> > > > > (do_compile
> > > > >
> > > > > >> error)
> > > > > >>
> > > > > >> Log says :
> > > > > >> “Download error on https://pypi.python.org/simple/incremental/:
> > > [Errno
> > > > >
> > > > > -3]
> > > > >
> > > > > >> Temporary failure in name resolution
> > > > >
> > > > > With the additional info you sent me along with a second look at
> the
> > > > > error I can fairly confidently say I know what the issue is.
> > > > >
> > > > > Python, like some other languages (ruby, go...) will attempt to
> > > > > download dependencies/requirements if they are not present. This is
> > > > > done "outside" of the bitbake system and thus will ignore
> > > > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > > > contamination but it is very similar. What we do with our python
> > > > > recipes in bitbake is review a python package's source setup.py,
> > > > > requirements.txt...files in order to determine what other python
> > > > > packages are needed, add them as RDEPENDS or similar in order to
> avoid
> > > > > the python attempting to complete a download such as this.
> > > > >
> > > > > In this case python-twisted 'requires' python-incremental but the
> > > > > Rocko version of the python-twisted recipe lacks the needed
> assignment
> > > > > to ensure this is available in the recipe sysroot and thus the
> > > > > attempted download.
> > > > >
> > > > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > > > [python-twisted: avoid downloading build dependencies] to Rocko and
> > > > > you will be good to go. You should also follow up this thread with
> a
> > > > > request to have this commit put onto Rocko to avoid others hitting
> the
> > > > > same issue.
> > > > >
> > > > > Mark
> > > > >
> > > > > >> ............
> > > > > >>
> > > > > >> distutils.errors.DistutilsError : Could not find suitable
> > > distribution
> > > > >
> > > > > for
> > > > >
> > > > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > > > >>
> > > > > >> First of all I’m not connected to internet, so I’ve
> pre-downloaded
> > > all
> > > > >
> > > > > the
> > > > >
> > > > > >> required packages (twisted-17.9.0.tar.bz2 &
> > > incremental-17.5.0.tar.gz
> > > > >
> > > > > are
> > > > >
> > > > > >> present in my build/downloads folder)
> > > > > >>
> > > > > >> It’s the first time I have some “downloading issues” and I’m
> stuck
> > > on
> > > > > >> it
> > > > > >> for a few hours now..
> > > > > >>
> > > > > >> Any tips for me ?
> > > > > >
> > > > > > Check all aspects of what you have manually downloaded and
> populated
> > > > > > in your downloads. My guess is that a checksum or some other
> detail
> > > > > > isn't matching and it is rejecting what you have and thus
> attempting
> > > > > > to re-download the file.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > >> Thanks in advance !
> > > > > >> --
> > > > > >> _______________________________________________
> > > > > >> Openembedded-devel mailing list
> > > > > >> Openembedded-devel@lists.openembedded.org
> > > > > >>
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
> > >
> > >
> > >
> > >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

(No subject)

[Mark Asselstine]

On Friday, July 27, 2018 12:42:44 PM EDT William Delacre wrote:
> Alright, thabks !
> 
> And I guess if it’s a tool I need during runtime on the target, I add it in
> the RDPENDS variable ?

Correct.

Note as well that I did make a note of why the -native version of incremental 
was needed, to work around a circular dependency, as captured in the commit 
log.

In general with python we definitely make assumptions around arch independence 
and the strategy has survived most if not all we have thrown at it.

Mark

> 
> Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
> 
> écrit :
> > It depends on the role of the particular dependency:
> > 
> > * tool you need to run during build             <-- native dependency
> > * library you need to link against during build <-- target dependency
> > 
> > --SJLC
> > 
> > On Fri, Jul 27, 2018 at 06:25:27PM +0200, William Delacre wrote:
> > > Okay, it makes sense!
> > > 
> > > My question may seem stupid but then why don’t we always use ‘-native’
> > 
> > for
> > 
> > > the dependencies ?
> > > 
> > > Is it because sometimes we know that the behavior of ‘foo’ and
> > 
> > ‘foo-native’
> > 
> > > would be the same, independently of the architecture ?
> > > 
> > > William
> > > 
> > > Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
> > > 
> > > mark.asselstine@windriver.com> a écrit :
> > > > On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > > > > Thanks a lot for the answer, it worked perfectly !
> > > > > 
> > > > > There is just one point I don’t really understand : why do we need
> > > > > to
> > > > 
> > > > add a
> > > > 
> > > > > dependency to ‘python-incremental-NATIVE’ ?
> > > > > 
> > > > > What would happen if I just add to the python-twisted recipe :
> > > > > 
> > > > > DEPENDS += “${PYTHON_PN}-incremental“
> > > > 
> > > > This would assume that python is completely arch independent, which it
> > 
> > is
> > 
> > > > not.
> > > > Assume for example python-incremental had some C extensions, using
> > 
> > DEPENDS
> > 
> > > > would build them for the target arch yet possibly attempt to run them
> > 
> > on
> > 
> > > > your
> > > > build host. -native takes care of this.
> > > > 
> > > > Some may say this is a bit of a hack since the difference in ARCH
> > 
> > *might*
> > 
> > > > equate to a difference in behavior. But I have dealt with many python
> > > > recipes
> > > > and have yet to run into any scenario where this potential issue
> > 
> > exists.
> > 
> > > > At least that is what I can recall at the moment. Unfortunately I have
> > > > forgotten some of the subtleties that might be in play.
> > > > 
> > > > Mark
> > > > 
> > > > > William
> > > > > 
> > > > > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> > > > > 
> > > > > mark.asselstine@windriver.com> a écrit :
> > > > > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > > > > > 
> > > > > > <mark.asselstine@windriver.com> wrote:
> > > > > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > > > > > 
> > > > > > > <williamdelacre@gmail.com> wrote:
> > > > > > >> Hi ! :-)
> > > > > > >> 
> > > > > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > > > > > 
> > > > > > (do_compile
> > > > > > 
> > > > > > >> error)
> > > > > > >> 
> > > > > > >> Log says :
> > > > 
> > > > > > >> “Download error on https://pypi.python.org/simple/incremental/:
> > > > [Errno
> > > > 
> > > > > > -3]
> > > > > > 
> > > > > > >> Temporary failure in name resolution
> > > > > > 
> > > > > > With the additional info you sent me along with a second look at
> > 
> > the
> > 
> > > > > > error I can fairly confidently say I know what the issue is.
> > > > > > 
> > > > > > Python, like some other languages (ruby, go...) will attempt to
> > > > > > download dependencies/requirements if they are not present. This
> > > > > > is
> > > > > > done "outside" of the bitbake system and thus will ignore
> > > > > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > > > > contamination but it is very similar. What we do with our python
> > > > > > recipes in bitbake is review a python package's source setup.py,
> > > > > > requirements.txt...files in order to determine what other python
> > > > > > packages are needed, add them as RDEPENDS or similar in order to
> > 
> > avoid
> > 
> > > > > > the python attempting to complete a download such as this.
> > > > > > 
> > > > > > In this case python-twisted 'requires' python-incremental but the
> > > > > > Rocko version of the python-twisted recipe lacks the needed
> > 
> > assignment
> > 
> > > > > > to ensure this is available in the recipe sysroot and thus the
> > > > > > attempted download.
> > > > > > 
> > > > > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > > > > [python-twisted: avoid downloading build dependencies] to Rocko
> > > > > > and
> > > > > > you will be good to go. You should also follow up this thread with
> > 
> > a
> > 
> > > > > > request to have this commit put onto Rocko to avoid others hitting
> > 
> > the
> > 
> > > > > > same issue.
> > > > > > 
> > > > > > Mark
> > > > > > 
> > > > > > >> ............
> > > > > > >> 
> > > > > > >> distutils.errors.DistutilsError : Could not find suitable
> > > > 
> > > > distribution
> > > > 
> > > > > > for
> > > > > > 
> > > > > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > > > > >> 
> > > > > > >> First of all I’m not connected to internet, so I’ve
> > 
> > pre-downloaded
> > 
> > > > all
> > > > 
> > > > > > the
> > > > > > 
> > > > > > >> required packages (twisted-17.9.0.tar.bz2 &
> > > > 
> > > > incremental-17.5.0.tar.gz
> > > > 
> > > > > > are
> > > > > > 
> > > > > > >> present in my build/downloads folder)
> > > > > > >> 
> > > > > > >> It’s the first time I have some “downloading issues” and I’m
> > 
> > stuck
> > 
> > > > on
> > > > 
> > > > > > >> it
> > > > > > >> for a few hours now..
> > > > > > >> 
> > > > > > >> Any tips for me ?
> > > > > > > 
> > > > > > > Check all aspects of what you have manually downloaded and
> > 
> > populated
> > 
> > > > > > > in your downloads. My guess is that a checksum or some other
> > 
> > detail
> > 
> > > > > > > isn't matching and it is rejecting what you have and thus
> > 
> > attempting
> > 
> > > > > > > to re-download the file.
> > > > > > > 
> > > > > > > Mark
> > > > > > > 
> > > > > > >> Thanks in advance !
> > > > > > >> --
> > > > > > >> _______________________________________________
> > > > > > >> Openembedded-devel mailing list
> > > > > > >> Openembedded-devel@lists.openembedded.org
> > 
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > 
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[William Delacre]

Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
écrit :

> It depends on the role of the particular dependency:
>
> * tool you need to run during build             <-- native dependency
> * library you need to link against during build <-- target dependency


Thanks for the precision :-)

My question may seem a bit stupid but how do you know which is which ?
Let’s say I want to write a recipe to install any specific software on my
target, how do I choose the dependencies ?
I have to refer to the software Makefile/CMakeList ?

William

>
>
> --SJLC
>
> On Fri, Jul 27, 2018 at 06:25:27PM +0200, William Delacre wrote:
> > Okay, it makes sense!
> >
> > My question may seem stupid but then why don’t we always use ‘-native’
> for
> > the dependencies ?
> >
> > Is it because sometimes we know that the behavior of ‘foo’ and
> ‘foo-native’
> > would be the same, independently of the architecture ?
> >
> > William
> >
> > Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
> > mark.asselstine@windriver.com> a écrit :
> >
> > > On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > > > Thanks a lot for the answer, it worked perfectly !
> > > >
> > > > There is just one point I don’t really understand : why do we need to
> > > add a
> > > > dependency to ‘python-incremental-NATIVE’ ?
> > > >
> > > > What would happen if I just add to the python-twisted recipe :
> > > >
> > > > DEPENDS += “${PYTHON_PN}-incremental“
> > >
> > > This would assume that python is completely arch independent, which it
> is
> > > not.
> > > Assume for example python-incremental had some C extensions, using
> DEPENDS
> > > would build them for the target arch yet possibly attempt to run them
> on
> > > your
> > > build host. -native takes care of this.
> > >
> > > Some may say this is a bit of a hack since the difference in ARCH
> *might*
> > > equate to a difference in behavior. But I have dealt with many python
> > > recipes
> > > and have yet to run into any scenario where this potential issue
> exists.
> > >
> > > At least that is what I can recall at the moment. Unfortunately I have
> > > forgotten some of the subtleties that might be in play.
> > >
> > > Mark
> > >
> > > >
> > > > William
> > > >
> > > > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> > > >
> > > > mark.asselstine@windriver.com> a écrit :
> > > > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > > > >
> > > > > <mark.asselstine@windriver.com> wrote:
> > > > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > > > >
> > > > > > <williamdelacre@gmail.com> wrote:
> > > > > >> Hi ! :-)
> > > > > >>
> > > > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > > > >
> > > > > (do_compile
> > > > >
> > > > > >> error)
> > > > > >>
> > > > > >> Log says :
> > > > > >> “Download error on https://pypi.python.org/simple/incremental/:
> > > [Errno
> > > > >
> > > > > -3]
> > > > >
> > > > > >> Temporary failure in name resolution
> > > > >
> > > > > With the additional info you sent me along with a second look at
> the
> > > > > error I can fairly confidently say I know what the issue is.
> > > > >
> > > > > Python, like some other languages (ruby, go...) will attempt to
> > > > > download dependencies/requirements if they are not present. This is
> > > > > done "outside" of the bitbake system and thus will ignore
> > > > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > > > contamination but it is very similar. What we do with our python
> > > > > recipes in bitbake is review a python package's source setup.py,
> > > > > requirements.txt...files in order to determine what other python
> > > > > packages are needed, add them as RDEPENDS or similar in order to
> avoid
> > > > > the python attempting to complete a download such as this.
> > > > >
> > > > > In this case python-twisted 'requires' python-incremental but the
> > > > > Rocko version of the python-twisted recipe lacks the needed
> assignment
> > > > > to ensure this is available in the recipe sysroot and thus the
> > > > > attempted download.
> > > > >
> > > > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > > > [python-twisted: avoid downloading build dependencies] to Rocko and
> > > > > you will be good to go. You should also follow up this thread with
> a
> > > > > request to have this commit put onto Rocko to avoid others hitting
> the
> > > > > same issue.
> > > > >
> > > > > Mark
> > > > >
> > > > > >> ............
> > > > > >>
> > > > > >> distutils.errors.DistutilsError : Could not find suitable
> > > distribution
> > > > >
> > > > > for
> > > > >
> > > > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > > > >>
> > > > > >> First of all I’m not connected to internet, so I’ve
> pre-downloaded
> > > all
> > > > >
> > > > > the
> > > > >
> > > > > >> required packages (twisted-17.9.0.tar.bz2 &
> > > incremental-17.5.0.tar.gz
> > > > >
> > > > > are
> > > > >
> > > > > >> present in my build/downloads folder)
> > > > > >>
> > > > > >> It’s the first time I have some “downloading issues” and I’m
> stuck
> > > on
> > > > > >> it
> > > > > >> for a few hours now..
> > > > > >>
> > > > > >> Any tips for me ?
> > > > > >
> > > > > > Check all aspects of what you have manually downloaded and
> populated
> > > > > > in your downloads. My guess is that a checksum or some other
> detail
> > > > > > isn't matching and it is rejecting what you have and thus
> attempting
> > > > > > to re-download the file.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > >> Thanks in advance !
> > > > > >> --
> > > > > >> _______________________________________________
> > > > > >> Openembedded-devel mailing list
> > > > > >> Openembedded-devel@lists.openembedded.org
> > > > > >>
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
> > >
> > >
> > >
> > >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

(No subject)

[Mark Asselstine]

On Tuesday, July 31, 2018 7:54:22 AM EDT William Delacre wrote:
> Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
> 
> écrit :
> > It depends on the role of the particular dependency:
> > 
> > * tool you need to run during build             <-- native dependency
> > * library you need to link against during build <-- target dependency
> 
> Thanks for the precision :-)
> 
> My question may seem a bit stupid but how do you know which is which ?
> Let’s say I want to write a recipe to install any specific software on my
> target, how do I choose the dependencies ?
> I have to refer to the software Makefile/CMakeList ?

It is not always easy to see via code inspection. I would suggest keep a 
second build for a different arch than your build host, possibly ARM. Start by 
using the non-native DEPENDS and only if there is an issue with the ARM build 
look at using -native for a DEPENDS.

To be honest I haven't had to worry about this too much as it is rare to run 
into issues.

Mark

> 
> William
> 
> > --SJLC
> > 
> > On Fri, Jul 27, 2018 at 06:25:27PM +0200, William Delacre wrote:
> > > Okay, it makes sense!
> > > 
> > > My question may seem stupid but then why don’t we always use ‘-native’
> > 
> > for
> > 
> > > the dependencies ?
> > > 
> > > Is it because sometimes we know that the behavior of ‘foo’ and
> > 
> > ‘foo-native’
> > 
> > > would be the same, independently of the architecture ?
> > > 
> > > William
> > > 
> > > Le ven. 27 juil. 2018 à 18:16, Mark Asselstine <
> > > 
> > > mark.asselstine@windriver.com> a écrit :
> > > > On Friday, July 27, 2018 12:04:37 PM EDT William Delacre wrote:
> > > > > Thanks a lot for the answer, it worked perfectly !
> > > > > 
> > > > > There is just one point I don’t really understand : why do we need
> > > > > to
> > > > 
> > > > add a
> > > > 
> > > > > dependency to ‘python-incremental-NATIVE’ ?
> > > > > 
> > > > > What would happen if I just add to the python-twisted recipe :
> > > > > 
> > > > > DEPENDS += “${PYTHON_PN}-incremental“
> > > > 
> > > > This would assume that python is completely arch independent, which it
> > 
> > is
> > 
> > > > not.
> > > > Assume for example python-incremental had some C extensions, using
> > 
> > DEPENDS
> > 
> > > > would build them for the target arch yet possibly attempt to run them
> > 
> > on
> > 
> > > > your
> > > > build host. -native takes care of this.
> > > > 
> > > > Some may say this is a bit of a hack since the difference in ARCH
> > 
> > *might*
> > 
> > > > equate to a difference in behavior. But I have dealt with many python
> > > > recipes
> > > > and have yet to run into any scenario where this potential issue
> > 
> > exists.
> > 
> > > > At least that is what I can recall at the moment. Unfortunately I have
> > > > forgotten some of the subtleties that might be in play.
> > > > 
> > > > Mark
> > > > 
> > > > > William
> > > > > 
> > > > > Le ven. 27 juil. 2018 à 17:03, Mark Asselstine <
> > > > > 
> > > > > mark.asselstine@windriver.com> a écrit :
> > > > > > On Thu, Jul 26, 2018 at 3:40 PM, Mark Asselstine
> > > > > > 
> > > > > > <mark.asselstine@windriver.com> wrote:
> > > > > > > On Mon, Jul 23, 2018 at 8:28 AM, William Delacre
> > > > > > > 
> > > > > > > <williamdelacre@gmail.com> wrote:
> > > > > > >> Hi ! :-)
> > > > > > >> 
> > > > > > >> I’m facing issues when trying to run ‘bitbake python-twisted’
> > > > > > 
> > > > > > (do_compile
> > > > > > 
> > > > > > >> error)
> > > > > > >> 
> > > > > > >> Log says :
> > > > 
> > > > > > >> “Download error on https://pypi.python.org/simple/incremental/:
> > > > [Errno
> > > > 
> > > > > > -3]
> > > > > > 
> > > > > > >> Temporary failure in name resolution
> > > > > > 
> > > > > > With the additional info you sent me along with a second look at
> > 
> > the
> > 
> > > > > > error I can fairly confidently say I know what the issue is.
> > > > > > 
> > > > > > Python, like some other languages (ruby, go...) will attempt to
> > > > > > download dependencies/requirements if they are not present. This
> > > > > > is
> > > > > > done "outside" of the bitbake system and thus will ignore
> > > > > > BB_NO_NETWORK and is generally a bad thing. It isn't quite host
> > > > > > contamination but it is very similar. What we do with our python
> > > > > > recipes in bitbake is review a python package's source setup.py,
> > > > > > requirements.txt...files in order to determine what other python
> > > > > > packages are needed, add them as RDEPENDS or similar in order to
> > 
> > avoid
> > 
> > > > > > the python attempting to complete a download such as this.
> > > > > > 
> > > > > > In this case python-twisted 'requires' python-incremental but the
> > > > > > Rocko version of the python-twisted recipe lacks the needed
> > 
> > assignment
> > 
> > > > > > to ensure this is available in the recipe sysroot and thus the
> > > > > > attempted download.
> > > > > > 
> > > > > > Cherry pick commit b08b570c8624303acbb6bb064a7bda466a679df4
> > > > > > [python-twisted: avoid downloading build dependencies] to Rocko
> > > > > > and
> > > > > > you will be good to go. You should also follow up this thread with
> > 
> > a
> > 
> > > > > > request to have this commit put onto Rocko to avoid others hitting
> > 
> > the
> > 
> > > > > > same issue.
> > > > > > 
> > > > > > Mark
> > > > > > 
> > > > > > >> ............
> > > > > > >> 
> > > > > > >> distutils.errors.DistutilsError : Could not find suitable
> > > > 
> > > > distribution
> > > > 
> > > > > > for
> > > > > > 
> > > > > > >> Requirement.parse(‘incremental>=16.10.1’)”
> > > > > > >> 
> > > > > > >> First of all I’m not connected to internet, so I’ve
> > 
> > pre-downloaded
> > 
> > > > all
> > > > 
> > > > > > the
> > > > > > 
> > > > > > >> required packages (twisted-17.9.0.tar.bz2 &
> > > > 
> > > > incremental-17.5.0.tar.gz
> > > > 
> > > > > > are
> > > > > > 
> > > > > > >> present in my build/downloads folder)
> > > > > > >> 
> > > > > > >> It’s the first time I have some “downloading issues” and I’m
> > 
> > stuck
> > 
> > > > on
> > > > 
> > > > > > >> it
> > > > > > >> for a few hours now..
> > > > > > >> 
> > > > > > >> Any tips for me ?
> > > > > > > 
> > > > > > > Check all aspects of what you have manually downloaded and
> > 
> > populated
> > 
> > > > > > > in your downloads. My guess is that a checksum or some other
> > 
> > detail
> > 
> > > > > > > isn't matching and it is rejecting what you have and thus
> > 
> > attempting
> > 
> > > > > > > to re-download the file.
> > > > > > > 
> > > > > > > Mark
> > > > > > > 
> > > > > > >> Thanks in advance !
> > > > > > >> --
> > > > > > >> _______________________________________________
> > > > > > >> Openembedded-devel mailing list
> > > > > > >> Openembedded-devel@lists.openembedded.org
> > 
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > 
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[S. Lockwood-Childs]

On Tue, Jul 31, 2018 at 10:30:02AM -0400, Mark Asselstine wrote:
> On Tuesday, July 31, 2018 7:54:22 AM EDT William Delacre wrote:
> > Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
> > 
> > écrit :
> > > It depends on the role of the particular dependency:
> > > 
> > > * tool you need to run during build             <-- native dependency
> > > * library you need to link against during build <-- target dependency
> > 
> > Thanks for the precision :-)
> > 
> > My question may seem a bit stupid but how do you know which is which ?
> > Let’s say I want to write a recipe to install any specific software on my
> > target, how do I choose the dependencies ?
> > I have to refer to the software Makefile/CMakeList ?
> 
> It is not always easy to see via code inspection. I would suggest keep a 
> second build for a different arch than your build host, possibly ARM. Start by 
> using the non-native DEPENDS and only if there is an issue with the ARM build 
> look at using -native for a DEPENDS.
> 
> To be honest I haven't had to worry about this too much as it is rare to run 
> into issues.

Yes target build dependencies are more common, so this approach of defaulting
to target rather than native does make sense.

My other advice is to start out by reviewing the build instructions in the
README / INSTALL docs for the software package; if that package requires some
non-standard external build tool ("non-standard" meaning other than 
autotools / make etc) that would need to be listed as native dependency, 
that tool really should be mentioned in the build instructions.

--SJLC

(No subject)

[William Delacre]

Le mar. 31 juil. 2018 à 20:42, S. Lockwood-Childs <sjl@vctlabs.com> a
écrit :

> On Tue, Jul 31, 2018 at 10:30:02AM -0400, Mark Asselstine wrote:
> > On Tuesday, July 31, 2018 7:54:22 AM EDT William Delacre wrote:
> > > Le ven. 27 juil. 2018 à 18:40, S. Lockwood-Childs <sjl@vctlabs.com> a
> > >
> > > écrit :
> > > > It depends on the role of the particular dependency:
> > > >
> > > > * tool you need to run during build             <-- native dependency
> > > > * library you need to link against during build <-- target dependency
> > >
> > > Thanks for the precision :-)
> > >
> > > My question may seem a bit stupid but how do you know which is which ?
> > > Let’s say I want to write a recipe to install any specific software on
> my
> > > target, how do I choose the dependencies ?
> > > I have to refer to the software Makefile/CMakeList ?
> >
> > It is not always easy to see via code inspection. I would suggest keep a
> > second build for a different arch than your build host, possibly ARM.
> Start by
> > using the non-native DEPENDS and only if there is an issue with the ARM
> build
> > look at using -native for a DEPENDS.
> >
> > To be honest I haven't had to worry about this too much as it is rare to
> run
> > into issues.
>
> Yes target build dependencies are more common, so this approach of
> defaulting
> to target rather than native does make sense.
>
> My other advice is to start out by reviewing the build instructions in the
> README / INSTALL docs for the software package; if that package requires
> some
> non-standard external build tool ("non-standard" meaning other than
> autotools / make etc) that would need to be listed as native dependency,
> that tool really should be mentioned in the build instructions.
>
> --SJLC


This is exactly what I needed to know ! Thanks you all a lot !

>
>

(no subject)

[Christian König]

Next try of prework for unpinned DMA-buf operation.

Only send to intel-gfx to trigger unit tests on the following patches.

Christian.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[rosdi ablatiff]

[-- Attachment #1.1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 1 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[Dani Camps]

[-- Attachment #1.1: Type: text/plain, Size: 48 bytes --]


http://period.cloudstar.ca

Dani Camps



[-- Attachment #1.2: Type: text/html, Size: 1909 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop

(No subject)

[Parthiban Nallathambi]

As I lost the message ID of the actual request for bitbake recipe
for xscreensaver, I am sending in a separate email

(No subject)

[Rahul jangra]

Hi team
I am facing the issue when creat deb base core-image-full-cmdline he
is getting this error but when I switch to rpm easily to built.
kindly help me.

 Executing 'cd /home/nsspl/rpi/build/tmp/deploy/deb/all;
PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
packages . > Packages;/home/nsspl/rpi/build/tmp/hosttools/gzip -fcn
Packages > Packages.gz;PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
release . >> Release' ...
NOTE: Executing 'cd
/home/nsspl/rpi/build/tmp/deploy/deb/cortexa7hf-neon-vfpv4;
PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
packages . > Packages;/home/nsspl/rpi/build/tmp/hosttools/gzip -fcn
Packages > Packages.gz;PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
release . >> Release' ...
NOTE: Executing 'cd /home/nsspl/rpi/build/tmp/deploy/deb/raspberrypi3;
PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
packages . > Packages;/home/nsspl/rpi/build/tmp/hosttools/gzip -fcn
Packages > Packages.gz;PSEUDO_UNLOAD=1
/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-ftparchive
release . >> Release' ...
NOTE: Installing the following packages: locale-base-en-us locale-base-en-gb
NOTE: Installing the following packages: dpkg hello-mender
psplash-raspberrypi packagegroup-core-full-cmdline apt run-postinsts
mender packagegroup-core-boot packagegroup-core-ssh-openssh
kernel-devicetree shadow kernel-image-4.14.37 base-passwd
ERROR: Unable to install packages. Command
'/home/nsspl/rpi/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/apt-get
 install --force-yes --allow-unauthenticated dpkg hello-mender
psplash-raspberrypi packagegroup-core-full-cmdline apt run-postinsts
mender packagegroup-core-boot packagegroup-core-ssh-openssh
kernel-devicetree shadow kernel-image-4.14.37 base-passwd' returned
100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 packagegroup-core-full-cmdline : Depends:
packagegroup-core-full-cmdline-initscripts but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.

Regards

Rahul

(No subject)

[taborskikrzysztof]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]





Wysłano z telefonu Samsung

[-- Attachment #2: Type: text/html, Size: 286 bytes --]

(No subject)

[jan vermaete]

Hi,

I would like not to have the short githash in the Linux kernel name
and the /lib/modules directory.
Although, I prefer to inherit fsl-kernel-localversion in the bb file
for the linux kernel.

When setting 'SCMVERSION = "n"' in the local.conf file, I still had
the +g.... in the directory name of /lib/modules...

The following patch solved it for me.

br

From f67c79d669a9861f6f355717bcdabc918e1de03b Mon Sep 17 00:00:00 2001
From: Jan Vermaete <jan.vermaete@gmail.com>
Date: Wed, 25 Apr 2018 12:03:01 +0200
Subject: [PATCH 1/1] Do not add the short git hash to the kernel name when
 SCMVERSION is not set.

---
 classes/fsl-kernel-localversion.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/classes/fsl-kernel-localversion.bbclass
b/classes/fsl-kernel-localversion.bbclass
index c0306a0..ff1075e 100644
--- a/classes/fsl-kernel-localversion.bbclass
+++ b/classes/fsl-kernel-localversion.bbclass
@@ -28,7 +28,9 @@ do_preconfigure() {
     CONF_SED_SCRIPT=""

     kernel_conf_variable LOCALVERSION "\"${LOCALVERSION}\""
-    kernel_conf_variable LOCALVERSION_AUTO y
+    if [ "${SCMVERSION}" = "y" ]; then
+        kernel_conf_variable LOCALVERSION_AUTO y
+    fi

     sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'

-- 
2.7.4


-- 
Jan Vermaete
"For every complex problem there is an answer that is clear, simple,
and wrong." - H.L. Mencken

(No subject)

[Otavio Salvador]

On Wed, Apr 25, 2018 at 7:51 AM, jan vermaete <jan.vermaete@gmail.com> wrote:
> Hi,
>
> I would like not to have the short githash in the Linux kernel name
> and the /lib/modules directory.
> Although, I prefer to inherit fsl-kernel-localversion in the bb file
> for the linux kernel.
>
> When setting 'SCMVERSION = "n"' in the local.conf file, I still had
> the +g.... in the directory name of /lib/modules...
>
> The following patch solved it for me.

Is it possible for you to send the patch using git format-patch / git
send-patch or sending it as an attachment?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(No subject)

[jan vermaete]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

Please find attached the patch.
Br

On Wed, Apr 25, 2018 at 7:33 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Wed, Apr 25, 2018 at 7:51 AM, jan vermaete <jan.vermaete@gmail.com> wrote:
>> Hi,
>>
>> I would like not to have the short githash in the Linux kernel name
>> and the /lib/modules directory.
>> Although, I prefer to inherit fsl-kernel-localversion in the bb file
>> for the linux kernel.
>>
>> When setting 'SCMVERSION = "n"' in the local.conf file, I still had
>> the +g.... in the directory name of /lib/modules...
>>
>> The following patch solved it for me.
>
> Is it possible for you to send the patch using git format-patch / git
> send-patch or sending it as an attachment?
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[-- Attachment #2: 0001-Do-not-add-the-short-git-hash-to-the-kernel-name-whe.patch --]
[-- Type: application/octet-stream, Size: 898 bytes --]

From f67c79d669a9861f6f355717bcdabc918e1de03b Mon Sep 17 00:00:00 2001
From: Jan Vermaete <jver@oip.be>
Date: Wed, 25 Apr 2018 12:03:01 +0200
Subject: [PATCH 1/1] Do not add the short git hash to the kernel name when
 SCMVERSION is not set.

---
 classes/fsl-kernel-localversion.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/classes/fsl-kernel-localversion.bbclass b/classes/fsl-kernel-localversion.bbclass
index c0306a0..ff1075e 100644
--- a/classes/fsl-kernel-localversion.bbclass
+++ b/classes/fsl-kernel-localversion.bbclass
@@ -28,7 +28,9 @@ do_preconfigure() {
 	CONF_SED_SCRIPT=""
 
 	kernel_conf_variable LOCALVERSION "\"${LOCALVERSION}\""
-	kernel_conf_variable LOCALVERSION_AUTO y
+	if [ "${SCMVERSION}" = "y" ]; then
+		kernel_conf_variable LOCALVERSION_AUTO y
+	fi
 
 	sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
 
-- 
2.7.4

(No subject)

[Otavio Salvador]

On Thu, Apr 26, 2018 at 2:18 PM jan vermaete <jan.vermaete@gmail.com> wrote:

> Please find attached the patch.

I applied it to master after fixing up the commit log.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(No subject)

[Ruica Cristina]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

rocko..i tried to edit local.conf file and add 
package_Classes ?="package ipk"and it won't let me bitbake..i m kind of new in this and i don t know how to manage it..

[-- Attachment #2: Type: text/html, Size: 786 bytes --]

(No subject)

[Richard Purdie]

On Mon, 2018-03-26 at 21:17 +0000, Ruica Cristina wrote:
> rocko..
> i tried to edit local.conf file and add 
> 
> package_Classes ?="package ipk"
> and it won't let me bitbake..i m kind of new in this and i don t know
> how to manage it..

It would be useful to know the exact error. You do need to use the
right capitalisation though, like:

PACKAGE_CLASSES = "package_ipk"

Cheers,

Richard

(No subject)

[Stephano Cetola]

On 3/26/18 3:10 PM, Richard Purdie wrote:
> On Mon, 2018-03-26 at 21:17 +0000, Ruica Cristina wrote:
>> rocko..
>> i tried to edit local.conf file and add 
>>
>> package_Classes ?="package ipk"
>> and it won't let me bitbake..i m kind of new in this and i don t know
>> how to manage it..
> 
> It would be useful to know the exact error. You do need to use the
> right capitalisation though, like:
> 
> PACKAGE_CLASSES = "package_ipk"
> 
> Cheers,
> 
> Richard
> 

Also, here are some resources for you to look at while getting starting
with Yocto:

https://wiki.yoctoproject.org/wiki/Newcomers

Hope that helps!

Cheers,
Stephano

(no subject)

[twischer]

The following patch set will extend the JACK plugin to detect Xruns
and signal them to the user application.

This patch set is depending on
http://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/130987.html

(No subject)

[Volker Vogelhuber]

I currently have an image with six different partitions. See the 
following partition configuration:

># bootloader
>part /boot/EFI --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk mmcblk --fstype=vfat --label boot --active --align 1024 --size 20 --overhead-factor=1.0 --uuid="1EFC2AC2-449B-6ABB-AA63-7EA004446DF1"
>
>#--use-uuid
># primary / recovery image
>part / --source rootfs --rootfs-dir=image --exclude-path opt/something/ opt/else/ opt/somemore/ --ondisk mmcblk --fstype=ext4 --label primary_rootfs --align 1024 --size 768 --overhead-factor=1.0 --uuid="2779D408-1362-AEF5-AEB1-00BF5674C065"
>part /recovery --source rootfs --rootfs-dir=image-recovery --ondisk mmcblk --fstype=ext4 --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0 --uuid="528B6F25-5143-47B3-8D12-391820EAF1CF"
>
># additional partitions
>part /opt/something --source rootfs --rootfs-dir=image --rootfs-subdir=opt/something --ondisk mmcblk --fstype=ext4 --label persist --align 1024 --size 64 --overhead-factor=1.0 --use-uuid
>part /opt/else --source rootfs --rootfs-dir=image --rootfs-subdir=opt/else --ondisk mmcblk --fstype=ext4 --label de --align 1024 --size 256 --overhead-factor=1.0 --use-uuid
>part /opt/somemore --source rootfs --rootfs-dir=image --rootfs-subdir=opt/somemore --ondisk mmcblk --fstype=ext4 --label data --align 1024 --size 1700 --overhead-factor=1.0 --use-uuid
>
>bootloader --timeout=0 --ptable gpt --configfile="disk.cfg"

My problem is now that if I use the wic -e option to specify an image 
name as rootfs-dir I can not extract subdirectories from the rootfs 
to different partitions. Or at least I didn't found out a way.
That's why I added a rootfs-subdir option to wic that allows appending 
a rootfs dir to the one received by IMAGE_ROOTFS. I read something 
about spliting should be done on recipe level 
(https://lists.yoctoproject.org/pipermail/yocto/2016-March/029301.html), 
but I couldn't figure out how that should be done and that patch seems 
much easier for me.

(No Subject)

[n1had5]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Hello there I would like a couple of stickers for me and my sis (or just me because I am a greedy bastard and those stickers would probably look cool AF)
Name: Mohammad Ahmad Nihad
(but write محمد احمد نهاد محمد too if possible because it would be easier to deliver to me that way)
Address: ٢ شارع جلال شلش متفرع من تونس متفرع من الجزائر ،المعادي الجديدة ،القاهرة.
2 Galal Shalash street, Tounis street, Gazaer street, Maadi, Cairo
Thanks in advance and I will hopefully keep an eye on your project because (although I don't understand most of how it works and will probably not be able to use it) looks pretty damn interesting

[-- Attachment #2: Type: text/html, Size: 732 bytes --]

Re: (No Subject)

[Jason A. Donenfeld]

Hello,

Protip: don't send your address to public mailing lists.

I'd be happy to send you some stickers.

I'll try my best to write the Arabic letters like that; seems like a
fun challenge.

Regards,
Jason

Re: (No Subject)

[Jonathon Fernyhough]

[-- Attachment #1.1: Type: text/plain, Size: 169 bytes --]

On 26/11/17 00:25, Jason A. Donenfeld wrote:
> I'll try my best to write the Arabic letters like that; seems like a
> fun challenge.

Remember: right-to-left. ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

(no subject)

[futurelieswithin]

[-- Attachment #1.1: Type: text/plain, Size: 299 bytes --]

A story perhaps i remember snapping my fingers and at mr miagi request it actually makes things appear and quantasize then a paculiar planet red and orange appeared outa nowhere it was a Pic of what the earth looked like 13.6 billion years  



Sent from my Samsung Galaxy , an AT&T LTE smartphone

[-- Attachment #1.2: Type: text/html, Size: 577 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Chao Gao]

From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao <chao.gao@intel.com>
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
the same VT-d unit as the 'Traditional Functions' on the endpoint. To search
VT-d unit, the BDF of PF or the BDF of a traditional function may be used. And
it depends on whether the PF is an extended function or not.

Current code uses PCI_SLOT() to recognize an ARI 'Extended Funcion'. But it
is conceptually wrong w/o checking whether PF is an extended function and
would lead to match VFs of a RC endpoint to a wrong VT-d unit.

This patch uses VF's 'is_extfn' field to indicate whether the PF of this VF is
an extended function. The field helps to use correct BDF to search VT-d unit.

Reported-by: Crawford, Eric R <Eric.R.Crawford@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
---
v9:
 - check 'is_virtfn' first in pci_add_device() to avoid potential error if
 linux side sets VF's 'is_extfn'
 - comments changes to make it clear that we use VF's 'is_extfn' intentionally
 otherwise the patch seems like a workaround.

v8:
 - use "conceptually wrong", instead of "a corner case" in commit message
 - check 'is_virtfn' first in acpi_find_matched_drhd_unit()

v7:
 - Drop Eric's tested-by
 - Change commit message to be clearer
 - Re-use VF's is_extfn field
 - access PF's is_extfn field in locked area

---
 xen/drivers/passthrough/pci.c      | 14 ++++++++++----
 xen/drivers/passthrough/vtd/dmar.c | 12 ++++++------
 xen/include/xen/pci.h              |  1 +
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27bdb71..0e27e29 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -599,21 +599,24 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
     unsigned int slot = PCI_SLOT(devfn), func = PCI_FUNC(devfn);
     const char *pdev_type;
     int ret;
+    bool pf_is_extfn = false;
 
-    if (!info)
+    if ( !info )
         pdev_type = "device";
-    else if (info->is_extfn)
-        pdev_type = "extended function";
-    else if (info->is_virtfn)
+    else if ( info->is_virtfn )
     {
         pcidevs_lock();
         pdev = pci_get_pdev(seg, info->physfn.bus, info->physfn.devfn);
+        if ( pdev )
+            pf_is_extfn = pdev->info.is_extfn;
         pcidevs_unlock();
         if ( !pdev )
             pci_add_device(seg, info->physfn.bus, info->physfn.devfn,
                            NULL, node);
         pdev_type = "virtual function";
     }
+    else if ( info->is_extfn )
+        pdev_type = "extended function";
     else
     {
         info = NULL;
@@ -707,6 +710,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
                    seg, bus, slot, func, ctrl);
     }
 
+    /* VF's 'is_extfn' is used to indicate whether PF is an extended function */
+    if ( pdev->info.is_virtfn )
+        pdev->info.is_extfn = pf_is_extfn;
     check_pdev(pdev);
 
     ret = 0;
diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 82040dd..75c9c92 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -211,15 +211,15 @@ struct acpi_drhd_unit *acpi_find_matched_drhd_unit(const struct pci_dev *pdev)
     if ( pdev == NULL )
         return NULL;
 
-    if ( pdev->info.is_extfn )
+    if ( pdev->info.is_virtfn )
     {
-        bus = pdev->bus;
-        devfn = 0;
+        bus = pdev->info.physfn.bus;
+        devfn = pdev->info.is_extfn ? 0 : pdev->info.physfn.devfn;
     }
-    else if ( pdev->info.is_virtfn )
+    else if ( pdev->info.is_extfn )
     {
-        bus = pdev->info.physfn.bus;
-        devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : pdev->info.physfn.devfn;
+        bus = pdev->bus;
+        devfn = 0;
     }
     else
     {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 59b6e8a..4dd42ac 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -39,6 +39,7 @@
 #define PCI_SBDF3(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b, df))
 
 struct pci_dev_info {
+    /* VF's 'is_extfn' is used to show whether its PF an extended function */
     bool_t is_extfn;
     bool_t is_virtfn;
     struct {
-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

<no subject>

[Bharath Krishna]

subscribe ceph-devel

(no subject)

[Barr. Richard Williams]

-- 
I'd like you to be in custody of my late client's fortune.
My client died along with his family including his next-of-kin
The funds shall be used for investment under your management

Do reply for details.
Regards
Richard Williams
Email:rich19williams@gmail.com

(no subject)

[Barr. Richard Williams]

-- 
I'd like you to be in custody of my late client's fortune.
My client died along with his family including his next-of-kin
The funds shall be used for investment under your management

Do reply for details.
Regards
Richard Williams
Email:rich19williams@gmail.com

(no subject)

[Manonmani]

[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]

Is it possible to use VFB for paravirtualised Guest? How to display
Domain-U in physical monitor? I have added vfb in my Guest configuration
and it returns the following error :

Parsing config from
/etc/xen/arch_domU_1.cfg
libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model
/usr/lib/xen/b
in/qemu-dm is not executable: No such file or
directory
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: (null): spawn
failed (
rc=-3)

libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model
did n
ot start: -3

Thanks in advance.

Regards,
Joker

[-- Attachment #1.2: Type: text/html, Size: 916 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Raviprasad Gurikar]

[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]


Hi .

I am ravi student from Indian I working on the xen arm development . I have plan to run the xen arm on fastmodel. But I am getting problem in the rootfilesystem creation and debootstrap  for this link https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/RootFilesystem. I am not able to entry the chroot ; if give the commands like this 

Sudo chroot /mnt;
Getting error like – error ; no such file or directory /bin/bash.

Please help me . 
Sent from Mail for Windows 10


[-- Attachment #1.2: Type: text/html, Size: 2158 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

The reset control API has two modes: exclusive access, where the driver
expects to have full and immediate control over the state of the reset
line, and shared (clock-like) access, where drivers only request reset
deassertion while active, but don't care about the state of the reset line
while inactive.

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior.

This series converts all drivers that currently implicitly request
exclusive reset controls to the corresponding explicit API call. It is,
for the most part, generated from the following semantic patch:

@@
expression rstc, dev, id;
@@
-rstc = reset_control_get(dev, id);
+rstc = reset_control_get_exclusive(dev, id);
@@
expression rstc, dev, id;
@@
-rstc = reset_control_get_optional(dev, id);
+rstc = reset_control_get_optional_exclusive(dev, id);
@@
expression rstc, node, id;
@@
-rstc = of_reset_control_get(node, id);
+rstc = of_reset_control_get_exclusive(node, id);
@@
expression rstc, node, index;
@@
-rstc = of_reset_control_get_by_index(node, index);
+rstc = of_reset_control_get_exclusive_by_index(node, index);
@@
expression rstc, dev, id;
@@
-rstc = devm_reset_control_get(dev, id);
+rstc = devm_reset_control_get_exclusive(dev, id);
@@
expression rstc, dev, id;
@@
-rstc = devm_reset_control_get_optional(dev, id);
+rstc = devm_reset_control_get_optional_exclusive(dev, id);
@@
expression rstc, dev, index;
@@
-rstc = devm_reset_control_get_by_index(dev, index);
+rstc = devm_reset_control_get_exclusive_by_index(dev, index);

After all driver patches are applied, the temporary transition helpers
can be removed.

regards
Philipp

Philipp Zabel (102):
  ARM: rockchip: explicitly request exclusive reset control
  ARM: socfpga: explicitly request exclusive reset control
  MIPS: pci-mt7620: explicitly request exclusive reset control
  ahci: st: explicitly request exclusive reset control
  ata: sata_gemini: explicitly request exclusive reset control
  ata: ahci_tegra: explicitly request exclusive reset control
  bus: sunxi-rsb: explicitly request exclusive reset control
  bus: tegra-gmi: explicitly request exclusive reset control
  clk: sunxi: explicitly request exclusive reset control
  clk: tegra: explicitly request exclusive reset control
  clocksource/drivers/timer-stm32: explicitly request exclusive reset
    control
  clocksource/drivers/sun5i: explicitly request exclusive reset control
  crypto: rockchip: explicitly request exclusive reset control
  crypto: sun4i-ss - request exclusive reset control
  PM / devfreq: tegra: explicitly request exclusive reset control
  dmaengine: stm32-dma: explicitly request exclusive reset control
  dmaengine: sun6i: explicitly request exclusive reset control
  dmaengine: tegra-apb: explicitly request exclusive reset control
  drm: kirin: explicitly request exclusive reset control
  drm/nouveau/tegra: explicitly request exclusive reset control
  drm/rockchip: explicitly request exclusive reset control
  drm/sti: explicitly request exclusive reset control
  drm/stm: explicitly request exclusive reset control
  drm/sun4i: explicitly request exclusive reset control
  drm/tegra: explicitly request exclusive reset control
  gpu: host1x: explicitly request exclusive reset control
  i2c: mv64xxx: explicitly request exclusive reset control
  i2c: stm32f4: explicitly request exclusive reset control
  i2c: sun6i-pw2i: explicitly request exclusive reset control
  i2c: tegra: explicitly request exclusive reset control
  iio: adc: rockchip_saradc: explicitly request exclusive reset control
  iio: dac: stm32-dac-core: explicitly request exclusive reset control
  Input: tegra-kbc - request exclusive reset control
  coda: explicitly request exclusive reset control
  st-rc: explicitly request exclusive reset control
  stm32-dcmi: explicitly request exclusive reset control
  rc: sunxi-cir: explicitly request exclusive reset control
  mmc: dw_mmc: explicitly request exclusive reset control
  mmc: sdhci-st: explicitly request exclusive reset control
  mmc: sunxi: explicitly request exclusive reset control
  mmc: tegra: explicitly request exclusive reset control
  mtd: nand: sunxi: explicitly request exclusive reset control
  mtd: spi-nor: stm32-quadspi: explicitly request exclusive reset
    control
  net: dsa: mt7530: explicitly request exclusive reset control
  net: ethernet: hisi_femac: explicitly request exclusive reset control
  net: ethernet: hix5hd2_gmac: explicitly request exclusive reset
    control
  net: stmmac: explicitly request exclusive reset control
  net: stmmac: dwc-qos: explicitly request exclusive reset control
  ath10k: explicitly request exclusive reset control
  nvmem: lpc18xx-eeprom: explicitly request exclusive reset control
  PCI: dwc: pcie-qcom: explicitly request exclusive reset control
  PCI: imx6: explicitly request exclusive reset control
  PCI: tegra: explicitly request exclusive reset control
  PCI: rockchip: explicitly request exclusive reset control
  phy: berlin-usb: explicitly request exclusive reset control
  PCI: mediatek: explicitly request exclusive reset control
  phy: qcom-usb-hs: explicitly request exclusive reset control
  phy: rockchip-pcie: explicitly request exclusive reset control
  phy: rockchip-typec: explicitly request exclusive reset control
  phy: rockchip-usb: explicitly request exclusive reset control
  phy: sun4i-usb: explicitly request exclusive reset control
  phy: sun9i-usb: explicitly request exclusive reset control
  phy: tegra: explicitly request exclusive reset control
  phy: qcom-qmp: explicitly request exclusive reset control
  phy: qcom-qusb2: explicitly request exclusive reset control
  pinctrl: stm32: explicitly request exclusive reset control
  pinctrl: sunxi: explicitly request exclusive reset control
  pinctrl: tegra: explicitly request exclusive reset control
  pwm: hibvt: explicitly request exclusive reset control
  pwm: tegra: explicitly request exclusive reset control
  remoteproc/keystone: explicitly request exclusive reset control
  remoteproc: qcom: explicitly request exclusive reset control
  remoteproc: st: explicitly request exclusive reset control
  soc: mediatek: PMIC wrap: explicitly request exclusive reset control
  soc/tegra: pmc: explicitly request exclusive reset control
  spi: stm32: explicitly request exclusive reset control
  spi: sun6i: explicitly request exclusive reset control
  spi: tegra20-slink: explicitly request exclusive reset control
  spi: tegra114: explicitly request exclusive reset control
  spi: tegra20-sflash: explicitly request exclusive reset control
  staging: nvec: explicitly request exclusive reset control
  thermal: rockchip: explicitly request exclusive reset control
  thermal: tegra: explicitly request exclusive reset control
  serial: 8250_dw: explicitly request exclusive reset control
  serial: tegra: explicitly request exclusive reset control
  usb: chipidea: msm: explicitly request exclusive reset control
  usb: dwc2: explicitly request exclusive reset control
  usb: host: ehci-tegra: explicitly request exclusive reset control
  usb: host: xhci-tegra: explicitly request exclusive reset control
  usb: musb: sunxi: explicitly request exclusive reset control
  usb: phy: msm: explicitly request exclusive reset control
  usb: phy: qcom-8x16-usb: explicitly request exclusive reset control
  watchdog: asm9260: explicitly request exclusive reset control
  watchdog: mt7621: explicitly request exclusive reset control
  watchdog: rt2880: explicitly request exclusive reset control
  watchdog: zx2967: explicitly request exclusive reset control
  ASoC: img: explicitly request exclusive reset control
  ASoC: stm32: explicitly request exclusive reset control
  ASoC: sun4i: explicitly request exclusive reset control
  ASoC: tegra: explicitly request exclusive reset control
  Documentation: devres: add explicit exclusive/shared reset control
    request calls
  reset: finish transition to explicit exclusive reset control requests

 Documentation/driver-model/devres.txt              |  7 ++-
 arch/arm/mach-rockchip/platsmp.c                   |  2 +-
 arch/mips/pci/pci-mt7620.c                         |  2 +-
 drivers/ata/ahci_st.c                              |  6 +--
 drivers/ata/ahci_tegra.c                           |  8 ++--
 drivers/ata/sata_gemini.c                          |  4 +-
 drivers/bus/sunxi-rsb.c                            |  2 +-
 drivers/bus/tegra-gmi.c                            |  2 +-
 drivers/clk/sunxi/clk-sun9i-mmc.c                  |  2 +-
 drivers/clk/tegra/clk-dfll.c                       |  2 +-
 drivers/clocksource/timer-stm32.c                  |  2 +-
 drivers/clocksource/timer-sun5i.c                  |  2 +-
 drivers/crypto/rockchip/rk3288_crypto.c            |  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss-core.c            |  3 +-
 drivers/devfreq/tegra-devfreq.c                    |  2 +-
 drivers/dma/stm32-dma.c                            |  2 +-
 drivers/dma/sun6i-dma.c                            |  2 +-
 drivers/dma/tegra20-apb-dma.c                      |  2 +-
 drivers/fpga/altera-hps2fpga.c                     |  3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c    |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c             |  8 ++--
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c             |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |  4 +-
 drivers/gpu/drm/sti/sti_hdmi.c                     |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c                    |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c                    |  2 +-
 drivers/gpu/drm/stm/ltdc.c                         |  2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c              |  4 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c                 |  2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c                   |  2 +-
 drivers/gpu/drm/sun4i/sun6i_drc.c                  |  2 +-
 drivers/gpu/drm/sun4i/sun8i_mixer.c                |  2 +-
 drivers/gpu/drm/tegra/dc.c                         |  2 +-
 drivers/gpu/drm/tegra/dpaux.c                      |  3 +-
 drivers/gpu/drm/tegra/dsi.c                        |  2 +-
 drivers/gpu/drm/tegra/gr3d.c                       |  6 +--
 drivers/gpu/drm/tegra/hdmi.c                       |  2 +-
 drivers/gpu/drm/tegra/sor.c                        |  2 +-
 drivers/gpu/host1x/dev.c                           |  2 +-
 drivers/i2c/busses/i2c-mv64xxx.c                   |  2 +-
 drivers/i2c/busses/i2c-stm32f4.c                   |  2 +-
 drivers/i2c/busses/i2c-sun6i-p2wi.c                |  2 +-
 drivers/i2c/busses/i2c-tegra.c                     |  2 +-
 drivers/iio/adc/rockchip_saradc.c                  |  3 +-
 drivers/iio/dac/stm32-dac-core.c                   |  2 +-
 drivers/input/keyboard/tegra-kbc.c                 |  2 +-
 drivers/media/platform/coda/coda-common.c          |  3 +-
 drivers/media/platform/stm32/stm32-dcmi.c          |  2 +-
 drivers/media/rc/st_rc.c                           |  2 +-
 drivers/media/rc/sunxi-cir.c                       |  2 +-
 drivers/mmc/host/dw_mmc.c                          |  2 +-
 drivers/mmc/host/sdhci-st.c                        |  2 +-
 drivers/mmc/host/sdhci-tegra.c                     |  3 +-
 drivers/mmc/host/sunxi-mmc.c                       |  3 +-
 drivers/mtd/nand/sunxi_nand.c                      |  2 +-
 drivers/mtd/spi-nor/stm32-quadspi.c                |  2 +-
 drivers/net/dsa/mt7530.c                           |  3 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c        |  4 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c      |  6 +--
 .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c    |  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  |  3 +-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  4 +-
 drivers/net/wireless/ath/ath10k/ahb.c              | 15 ++++---
 drivers/nvmem/lpc18xx_eeprom.c                     |  2 +-
 drivers/pci/dwc/pci-imx6.c                         |  7 +--
 drivers/pci/dwc/pcie-qcom.c                        | 40 +++++++++--------
 drivers/pci/host/pci-tegra.c                       |  6 +--
 drivers/pci/host/pcie-mediatek.c                   |  2 +-
 drivers/pci/host/pcie-rockchip.c                   | 15 ++++---
 drivers/phy/allwinner/phy-sun4i-usb.c              |  2 +-
 drivers/phy/allwinner/phy-sun9i-usb.c              |  4 +-
 drivers/phy/marvell/phy-berlin-usb.c               |  2 +-
 drivers/phy/qualcomm/phy-qcom-qmp.c                |  4 +-
 drivers/phy/qualcomm/phy-qcom-qusb2.c              |  3 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c             |  3 +-
 drivers/phy/rockchip/phy-rockchip-pcie.c           |  2 +-
 drivers/phy/rockchip/phy-rockchip-typec.c          |  6 +--
 drivers/phy/rockchip/phy-rockchip-usb.c            |  2 +-
 drivers/phy/tegra/xusb-tegra210.c                  |  4 +-
 drivers/phy/tegra/xusb.c                           |  2 +-
 drivers/pinctrl/stm32/pinctrl-stm32.c              |  2 +-
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c        |  2 +-
 drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c        |  2 +-
 drivers/pinctrl/tegra/pinctrl-tegra-xusb.c         |  2 +-
 drivers/pwm/pwm-hibvt.c                            |  2 +-
 drivers/pwm/pwm-tegra.c                            |  2 +-
 drivers/remoteproc/keystone_remoteproc.c           |  2 +-
 drivers/remoteproc/qcom_q6v5_pil.c                 |  3 +-
 drivers/remoteproc/st_remoteproc.c                 |  6 ++-
 drivers/reset/core.c                               |  2 +-
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  5 ++-
 drivers/soc/tegra/pmc.c                            |  2 +-
 drivers/spi/spi-stm32.c                            |  2 +-
 drivers/spi/spi-sun6i.c                            |  2 +-
 drivers/spi/spi-tegra114.c                         |  2 +-
 drivers/spi/spi-tegra20-sflash.c                   |  2 +-
 drivers/spi/spi-tegra20-slink.c                    |  2 +-
 drivers/staging/nvec/nvec.c                        |  2 +-
 drivers/thermal/rockchip_thermal.c                 |  3 +-
 drivers/thermal/tegra/soctherm.c                   |  3 +-
 drivers/tty/serial/8250/8250_dw.c                  |  2 +-
 drivers/tty/serial/serial-tegra.c                  |  2 +-
 drivers/usb/chipidea/ci_hdrc_msm.c                 |  2 +-
 drivers/usb/dwc2/platform.c                        |  3 +-
 drivers/usb/host/ehci-tegra.c                      |  5 ++-
 drivers/usb/host/xhci-tegra.c                      |  6 ++-
 drivers/usb/musb/sunxi.c                           |  2 +-
 drivers/usb/phy/phy-msm-usb.c                      |  4 +-
 drivers/usb/phy/phy-qcom-8x16-usb.c                |  2 +-
 drivers/watchdog/asm9260_wdt.c                     |  2 +-
 drivers/watchdog/mt7621_wdt.c                      |  2 +-
 drivers/watchdog/rt2880_wdt.c                      |  2 +-
 drivers/watchdog/zx2967_wdt.c                      |  2 +-
 include/linux/reset.h                              | 50 ----------------------
 sound/soc/img/img-i2s-in.c                         |  2 +-
 sound/soc/img/img-i2s-out.c                        |  2 +-
 sound/soc/img/img-parallel-out.c                   |  2 +-
 sound/soc/img/img-spdif-in.c                       |  2 +-
 sound/soc/img/img-spdif-out.c                      |  2 +-
 sound/soc/stm/stm32_i2s.c                          |  2 +-
 sound/soc/stm/stm32_sai.c                          |  2 +-
 sound/soc/stm/stm32_spdifrx.c                      |  2 +-
 sound/soc/sunxi/sun4i-codec.c                      |  3 +-
 sound/soc/sunxi/sun4i-i2s.c                        |  2 +-
 sound/soc/sunxi/sun4i-spdif.c                      |  3 +-
 sound/soc/tegra/tegra30_ahub.c                     |  4 +-
 128 files changed, 226 insertions(+), 235 deletions(-)

-- 
2.11.0

Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Emilio López" <emilio@elopez.com.ar>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Alan Tull <atull@kernel.org>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Bin Liu <b-liu@ti.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Chen Feng <puck.chen@hisilicon.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: John Youn <johnyoun@synopsys.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Marc Dietrich <marvin24@gmx.de>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Moritz Fischer <moritz.fischer@ettus.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Peter Chen <Peter.Chen@nxp.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Cc: Rakesh Iyer <riyer@nvidia.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: alsa-devel@alsa-project.org
Cc: ath10k@lists.infradead.org
Cc: devel@driverdev.osuosl.org
Cc: dmaengine@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-fpga@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-remoteproc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-serial@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: nouveau@lists.freedesktop.org

(no subject)

[Heiko Stuebner]

Hi,

>   crypto: rockchip: explicitly request exclusive reset control
>   iio: adc: rockchip_saradc: explicitly request exclusive reset control
>   PCI: rockchip: explicitly request exclusive reset control
>   phy: rockchip-pcie: explicitly request exclusive reset control
>   phy: rockchip-typec: explicitly request exclusive reset control
>   phy: rockchip-usb: explicitly request exclusive reset control
>   thermal: rockchip: explicitly request exclusive reset control

for the driver-related Rockchip changes

Acked-by: Heiko Stuebner <heiko@sntech.de>

(no subject)

[Heiko Stuebner]

Hi,

>   crypto: rockchip: explicitly request exclusive reset control
>   iio: adc: rockchip_saradc: explicitly request exclusive reset control
>   PCI: rockchip: explicitly request exclusive reset control
>   phy: rockchip-pcie: explicitly request exclusive reset control
>   phy: rockchip-typec: explicitly request exclusive reset control
>   phy: rockchip-usb: explicitly request exclusive reset control
>   thermal: rockchip: explicitly request exclusive reset control

for the driver-related Rockchip changes

Acked-by: Heiko Stuebner <heiko@sntech.de>

(no subject)

[Heiko Stuebner]

Hi,

>   crypto: rockchip: explicitly request exclusive reset control
>   iio: adc: rockchip_saradc: explicitly request exclusive reset control
>   PCI: rockchip: explicitly request exclusive reset control
>   phy: rockchip-pcie: explicitly request exclusive reset control
>   phy: rockchip-typec: explicitly request exclusive reset control
>   phy: rockchip-usb: explicitly request exclusive reset control
>   thermal: rockchip: explicitly request exclusive reset control

for the driver-related Rockchip changes

Acked-by: Heiko Stuebner <heiko@sntech.de>

(No subject)

[Мар'ян Пріцак]

Hi all,

I'm trying to build an image that's supposed to be used as rootfs for
container.
Is there a way to build image rootfs without Linux kernel and modules?

BR,
Marian

(No subject)

[Josef Holzmayr]

Hi Maryan,

On 19.06.2017 16:57, Мар'ян Пріцак wrote:
> I'm trying to build an image that's supposed to be used as rootfs for
> container.
> Is there a way to build image rootfs without Linux kernel and modules?

The simplest solution is to just refer to linux-dummy:
https://layers.openembedded.org/layerindex/recipe/41/

If you're not in a hurry, I expect to push a layer doing exactly what 
you describe to github, as I'm working on that too.

Greetz
-- 
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

(No subject)

[Tamtamis, Panagiotis]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Hi Maryan,

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On
> Behalf Of Josef Holzmayr
> Sent: Monday, June 19, 2017 10:02 PM
> To: Мар'ян Пріцак; openembeded-devel
> Subject: Re: [oe] (no subject)
> 
> Hi Maryan,
> 
> On 19.06.2017 16:57, Мар'ян Пріцак wrote:
> > I'm trying to build an image that's supposed to be used as rootfs for
> > container.
> > Is there a way to build image rootfs without Linux kernel and modules?

I use the following in my image recipe:

FORCE_RO_REMOVE = "1"
ROOTFS_RO_UNNEEDED += " kernel-${LINUX_VERSION} kernel-image-${LINUX_VERSION} kernel-image-uimage-${LINUX_VERSION}"

With the above you force the image production to remove unwanted packets. You can add also the modules that you don't want.
See if this can work in your case also.

> 
> The simplest solution is to just refer to linux-dummy:
> https://layers.openembedded.org/layerindex/recipe/41/
> 
> If you're not in a hurry, I expect to push a layer doing exactly what you
> describe to github, as I'm working on that too.
> 
> Greetz
> --
> Josef Holzmayr
> Software Developer Embedded Systems
> 
> Tel: +49 8444 9204-48
> Fax: +49 8444 9204-50
> 
> R-S-I Elektrotechnik GmbH & Co. KG
> Woelkestrasse 11
> D-85301 Schweitenkirchen
> www.rsi-elektrotechnik.de
> ———————————————
> Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
> Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> Ust-IdNr: DE 128592548

Br,
Tamis

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4874 bytes --]

(No subject)

[Josef Holzmayr]

Hi Tamis,

On 20.06.2017 10:07, Tamtamis, Panagiotis wrote:
> I use the following in my image recipe:
> 
> FORCE_RO_REMOVE = "1"
> ROOTFS_RO_UNNEEDED += " kernel-${LINUX_VERSION} kernel-image-${LINUX_VERSION} kernel-image-uimage-${LINUX_VERSION}"

While that might work, it actually builds all the stuff and then only 
excludes it from the rootfs generation. But if we actually never ever 
want a kernel, why spend the compile time? :)

Greetz
-- 
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

(No subject)

[Tamtamis, Panagiotis]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Hello Josef,

> Hi Tamis,
>
> On 20.06.2017 10:07, Tamtamis, Panagiotis wrote:
> > I use the following in my image recipe:
> >
> > FORCE_RO_REMOVE = "1"
> > ROOTFS_RO_UNNEEDED += " kernel-${LINUX_VERSION} kernel-image-
> ${LINUX_VERSION} kernel-image-uimage-${LINUX_VERSION}"
>
> While that might work, it actually builds all the stuff and then only 
> excludes it
> from the rootfs generation. But if we actually never ever want a kernel, why
> spend the compile time? :)

I agree with you. Even if cross compiling in production server does not take 
that much time, it is not the optimal solution.
I will also see your layer at GitHub  :-).

Br,
Tamis


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4874 bytes --]

(No subject)

[Мар'ян Пріцак]

Thanks guys, linux-dummy worked for me.

BR,
Marian

On Tue, Jun 20, 2017 at 5:32 PM Tamtamis, Panagiotis <
panagiotis.tamtamis@unify.com> wrote:

> Hello Josef,
>
> > Hi Tamis,
> >
> > On 20.06.2017 10:07, Tamtamis, Panagiotis wrote:
> > > I use the following in my image recipe:
> > >
> > > FORCE_RO_REMOVE = "1"
> > > ROOTFS_RO_UNNEEDED += " kernel-${LINUX_VERSION} kernel-image-
> > ${LINUX_VERSION} kernel-image-uimage-${LINUX_VERSION}"
> >
> > While that might work, it actually builds all the stuff and then only
> > excludes it
> > from the rootfs generation. But if we actually never ever want a kernel,
> why
> > spend the compile time? :)
>
> I agree with you. Even if cross compiling in production server does not
> take
> that much time, it is not the optimal solution.
> I will also see your layer at GitHub  :-).
>
> Br,
> Tamis
>
>

<no subject>

[Stephen Bates]

subscribe fio

(No subject)

[Андрей Кононов]

[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]


i'm trying to build
bitbake fsl-image-multimedia-full -k
using  pyro repository and my image include QT5 library, but get error. The same configuration on  morty builded without errors
Parsing recipes: 100% |############################################################################################################################################################################################################################| Time: 0:19:36
Parsing of 2258 .bb files complete (0 cached, 2258 parsed). 3050 targets, 506 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "linuxmint-18.1"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "imx6qpsabreauto"
DISTRO = "poky"
DISTRO_VERSION = "2.3"
TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU = "hard"
meta 
meta-poky = "HEAD:31389f8b0088a8a83aa5e50f11359b39934e4640"
meta-oe 
meta-gnome 
meta-multimedia = "HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
meta-freescale = "HEAD:a65d13c315db447adda68b47faeb4c0afd0655b8"
meta-freescale-3rdparty = "HEAD:1f37698ac62945b6531a316ec1232af23cc6c050"
meta-freescale-distro = "HEAD:cd5c7a2539f40004f74126e9fdf08254fd9a6390"
meta-qt5 = "master:6605c48f3a900da26425ef31d83eb1c95d551531"
meta-ruby 
meta-networking 
meta-python 
meta-filesystems = "HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
Initialising tasks: 100% |#########################################################################################################################################################################################################################| Time: 0:02:40
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch: Command Error: 'quilt --quiltrc /media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0014-Add-IMX-GPU-support.patch
patching file mkspecs/linux-oe-g++/qmake.conf
Hunk #1 FAILED at 39.
1 out of 1 hunk FAILED -- rejects in file mkspecs/linux-oe-g++/qmake.conf
Patch 0014-Add-IMX-GPU-support.patch does not apply (enforce with -f)
ERROR: qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: /media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/temp/log.do_patch.8895
ERROR: Task (/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch) failed with exit code '1'
WARNING: ttf-arphic-uming-20080216-r6 do_populate_lic: ttf-arphic-uming: No generic license file exists for: Arphic-Public-License in any provider
NOTE: Tasks Summary: Attempted 5116 tasks of which 6 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

-- 
Андрей Кононов

[-- Attachment #2: Type: text/html, Size: 3433 bytes --]

(No subject)

[Petter Mabäcker]

[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]

 

Hi, 

After a quick look, it seems like the problem is related to
the Upgrade to Qt 5.8 that was done in pyro. 

commit: 333949a Upgrade
to Qt 5.8 (in meta-qt5) 

The above mentioned commit causes
'./dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase/0014-Add-IMX-GPU-support.patch'
(in meta-freescale) to fail. So this patch needs to be updated to match
the Qt 5.8 changes (that affects qmake.conf). 

BR Petter 

Petter
Mabäcker

Technux <petter@technux.se>
www.technux.se

2017-05-30 07:19
skrev Андрей Кононов: 

> i'm trying to build
> bitbake
fsl-image-multimedia-full -k
> using PYRO repository and my image
include QT5 library, but get error. The same configuration on MORTY
builded without errors 
> 
> Parsing recipes: 100%
|############################################################################################################################################################################################################################|
Time: 0:19:36
> Parsing of 2258 .bb files complete (0 cached, 2258
parsed). 3050 targets, 506 skipped, 0 masked, 0 errors.
> NOTE:
Resolving any missing task queue dependencies 
> 
> Build
Configuration:
> BB_VERSION = "1.34.0"
> BUILD_SYS = "x86_64-linux"
>
NATIVELSBSTRING = "linuxmint-18.1"
> TARGET_SYS =
"arm-poky-linux-gnueabi"
> MACHINE = "imx6qpsabreauto"
> DISTRO =
"poky"
> DISTRO_VERSION = "2.3"
> TUNE_FEATURES = "arm armv7a vfp thumb
neon callconvention-hard cortexa9"
> TARGET_FPU = "hard"
> meta 
>
meta-poky = "HEAD:31389f8b0088a8a83aa5e50f11359b39934e4640"
> meta-oe 
>
meta-gnome 
> meta-multimedia =
"HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
> meta-freescale =
"HEAD:a65d13c315db447adda68b47faeb4c0afd0655b8"
>
meta-freescale-3rdparty =
"HEAD:1f37698ac62945b6531a316ec1232af23cc6c050"
> meta-freescale-distro
= "HEAD:cd5c7a2539f40004f74126e9fdf08254fd9a6390"
> meta-qt5 =
"master:6605c48f3a900da26425ef31d83eb1c95d551531"
> meta-ruby 
>
meta-networking 
> meta-python 
> meta-filesystems =
"HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7" 
> 
> Initialising
tasks: 100%
|#########################################################################################################################################################################################################################|
Time: 0:02:40
> NOTE: Executing SetScene Tasks
> NOTE: Executing
RunQueue Tasks
> ERROR: qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch:
Command Error: 'quilt --quiltrc
/media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0 Output:
> Applying patch
0014-Add-IMX-GPU-support.patch
> patching file
mkspecs/linux-oe-g++/qmake.conf
> Hunk #1 FAILED at 39.
> 1 out of 1
hunk FAILED -- rejects in file mkspecs/linux-oe-g++/qmake.conf
> Patch
0014-Add-IMX-GPU-support.patch does not apply (enforce with -f)
> ERROR:
qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch: Function failed:
patch_do_patch
> ERROR: Logfile of failure stored in:
/media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/temp/log.do_patch.8895
>
ERROR: Task
(/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch)
failed with exit code '1'
> WARNING: ttf-arphic-uming-20080216-r6
do_populate_lic: ttf-arphic-uming: No generic license file exists for:
Arphic-Public-License in any provider
> NOTE: Tasks Summary: Attempted
5116 tasks of which 6 didn't need to be rerun and 1 failed. 
> 
>
Summary: 1 task failed:
>
/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch
>
Summary: There were 2 WARNING messages shown.
> Summary: There were 2
ERROR messages shown, returning a non-zero exit code. 
> 
> -- 
> Андрей
Кононов
 

[-- Attachment #2: Type: text/html, Size: 4451 bytes --]

(No subject)

[Андрей Кононов]

[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]


you right, when i take qt5 from morty branch everything builded ok

>Вторник, 30 мая 2017, 22:02 +03:00 от Petter Mabäcker < petter@technux.se >:
>
>Hi,
>After a quick look, it seems like the problem is related to the Upgrade to Qt 5.8 that was done in pyro.
>commit: 333949a Upgrade to Qt 5.8 (in meta-qt5)
>The above mentioned commit causes './dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase/0014-Add-IMX-GPU-support.patch' (in meta-freescale) to fail. So this patch needs to be updated to match the Qt 5.8 changes (that affects qmake.conf).
>BR Petter
> 
>Petter Mabäcker

Technux <petter@technux.se>
>www.technux.se
>
>2017-05-30 07:19 skrev Андрей Кононов:
>>i'm trying to build
>>bitbake fsl-image-multimedia-full -k
>>using  pyro repository and my image include QT5 library, but get error. The same configuration on  morty builded without errors
>>Parsing recipes: 100% |############################################################################################################################################################################################################################| Time: 0:19:36
>>Parsing of 2258 .bb files complete (0 cached, 2258 parsed). 3050 targets, 506 skipped, 0 masked, 0 errors.
>>NOTE: Resolving any missing task queue dependencies
>>Build Configuration:
>>BB_VERSION = "1.34.0"
>>BUILD_SYS = "x86_64-linux"
>>NATIVELSBSTRING = "linuxmint-18.1"
>>TARGET_SYS = "arm-poky-linux-gnueabi"
>>MACHINE = "imx6qpsabreauto"
>>DISTRO = "poky"
>>DISTRO_VERSION = "2.3"
>>TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
>>TARGET_FPU = "hard"
>>meta 
>>meta-poky = "HEAD:31389f8b0088a8a83aa5e50f11359b39934e4640"
>>meta-oe 
>>meta-gnome 
>>meta-multimedia = "HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
>>meta-freescale = "HEAD:a65d13c315db447adda68b47faeb4c0afd0655b8"
>>meta-freescale-3rdparty = "HEAD:1f37698ac62945b6531a316ec1232af23cc6c050"
>>meta-freescale-distro = "HEAD:cd5c7a2539f40004f74126e9fdf08254fd9a6390"
>>meta-qt5 = "master:6605c48f3a900da26425ef31d83eb1c95d551531"
>>meta-ruby 
>>meta-networking 
>>meta-python 
>>meta-filesystems = "HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
>>Initialising tasks: 100% |#########################################################################################################################################################################################################################| Time: 0:02:40
>>NOTE: Executing SetScene Tasks
>>NOTE: Executing RunQueue Tasks
>>ERROR: qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch: Command Error: 'quilt --quiltrc /media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
>>Applying patch 0014-Add-IMX-GPU-support.patch
>>patching file mkspecs/linux-oe-g++/qmake.conf
>>Hunk #1 FAILED at 39.
>>1 out of 1 hunk FAILED -- rejects in file mkspecs/linux-oe-g++/qmake.conf
>>Patch 0014-Add-IMX-GPU-support.patch does not apply (enforce with -f)
>>ERROR: qtbase-5.8.0+gitAUTOINC+49dc9aa409-r0 do_patch: Function failed: patch_do_patch
>>ERROR: Logfile of failure stored in: /media/barsuk/ext4.720/pyro/rootfs.systemd.qp/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.8.0+gitAUTOINC+49dc9aa409-r0/temp/log.do_patch.8895
>>ERROR: Task (/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch) failed with exit code '1'
>>WARNING: ttf-arphic-uming-20080216-r6 do_populate_lic: ttf-arphic-uming: No generic license file exists for: Arphic-Public-License in any provider
>>NOTE: Tasks Summary: Attempted 5116 tasks of which 6 didn't need to be rerun and 1 failed.
>>Summary: 1 task failed:
>>/media/barsuk/ext4.720/pyro/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb:do_patch
>>Summary: There were 2 WARNING messages shown.
>>Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>>
>>-- 
>>Андрей Кононов

[-- Attachment #2: Type: text/html, Size: 5000 bytes --]

[PATCH] openssh: Atomically generate host keys

[Joshua Watt]

Generating the host keys atomically prevents power interruptions during
the first boot from leaving the key files incomplete, which often
prevents users from being able to ssh into the device.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
 meta/recipes-connectivity/openssh/openssh/init     | 21 ++++------------
 .../openssh/openssh/sshd-check-key                 | 28 ++++++++++++++++++++++
 .../openssh/openssh/sshdgenkeys.service            | 16 ++++---------
 meta/recipes-connectivity/openssh/openssh_7.4p1.bb |  8 +++++++
 4 files changed, 44 insertions(+), 29 deletions(-)
 create mode 100644 meta/recipes-connectivity/openssh/openssh/sshd-check-key

diff --git a/meta/recipes-connectivity/openssh/openssh/init b/meta/recipes-connectivity/openssh/openssh/init
index 1f63725..22124a9 100644
--- a/meta/recipes-connectivity/openssh/openssh/init
+++ b/meta/recipes-connectivity/openssh/openssh/init
@@ -45,23 +45,10 @@ check_config() {
 }
 
 check_keys() {
-	# create keys if necessary
-	if [ ! -f $HOST_KEY_RSA ]; then
-		echo "  generating ssh RSA key..."
-		ssh-keygen -q -f $HOST_KEY_RSA -N '' -t rsa
-	fi
-	if [ ! -f $HOST_KEY_ECDSA ]; then
-		echo "  generating ssh ECDSA key..."
-		ssh-keygen -q -f $HOST_KEY_ECDSA -N '' -t ecdsa
-	fi
-	if [ ! -f $HOST_KEY_DSA ]; then
-		echo "  generating ssh DSA key..."
-		ssh-keygen -q -f $HOST_KEY_DSA -N '' -t dsa
-	fi
-	if [ ! -f $HOST_KEY_ED25519 ]; then
-		echo "  generating ssh ED25519 key..."
-		ssh-keygen -q -f $HOST_KEY_ED25519 -N '' -t ed25519
-	fi
+    @LIBEXECDIR@/sshd-check-key $HOST_KEY_RSA rsa
+    @LIBEXECDIR@/sshd-check-key $HOST_KEY_ECDSA ecdsa
+    @LIBEXECDIR@/sshd-check-key $HOST_KEY_DSA dsa
+    @LIBEXECDIR@/sshd-check-key $HOST_KEY_ED25519 ed25519
 }
 
 export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
diff --git a/meta/recipes-connectivity/openssh/openssh/sshd-check-key b/meta/recipes-connectivity/openssh/openssh/sshd-check-key
new file mode 100644
index 0000000..3495d98
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/sshd-check-key
@@ -0,0 +1,28 @@
+#! /bin/sh
+set -e
+
+NAME="$1"
+TYPE="$2"
+
+if [ -z "$NAME" ] || [ -z "$TYPE" ]; then
+    echo "Usage: $0 NAME TYPE"
+    exit 1;
+fi
+
+if [ ! -f "$NAME" ]; then
+    echo "  generating ssh $TYPE key..."
+    ssh-keygen -q -f "${NAME}.tmp" -N '' -t $TYPE
+
+    # Sync to ensure data is written to temp file before renaming
+    sync
+
+    # Move (Atomically rename) files
+    # Rename the .pub file first, since the check that triggers a
+    # key generation is based on the private file.
+    mv -f "${NAME}.tmp.pub" "${NAME}.pub"
+    sync
+
+    mv -f "${NAME}.tmp" "${NAME}"
+    sync
+fi
+
diff --git a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
index 148e6ad..af56404 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
+++ b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
@@ -1,22 +1,14 @@
 [Unit]
 Description=OpenSSH Key Generation
 RequiresMountsFor=/var /run
-ConditionPathExists=!/var/run/ssh/ssh_host_rsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_dsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_ecdsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_ed25519_key
-ConditionPathExists=!/etc/ssh/ssh_host_rsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_dsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_ecdsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_ed25519_key
 
 [Service]
 Environment="SYSCONFDIR=/etc/ssh"
 EnvironmentFile=-/etc/default/ssh
 ExecStart=@BASE_BINDIR@/mkdir -p $SYSCONFDIR
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_rsa_key -N '' -t rsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' -t dsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' -t ecdsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_ed25519_key -N '' -t ed25519
+ExecStart=@LIBEXECDIR@/sshd-check-key ${SYSCONFDIR}/ssh_host_rsa_key rsa
+ExecStart=@LIBEXECDIR@/sshd-check-key ${SYSCONFDIR}/ssh_host_dsa_key dsa
+ExecStart=@LIBEXECDIR@/sshd-check-key ${SYSCONFDIR}/ssh_host_ecdsa_key ecdsa
+ExecStart=@LIBEXECDIR@/sshd-check-key ${SYSCONFDIR}/ssh_host_ed25519_key ed25519
 Type=oneshot
 RemainAfterExit=yes
diff --git a/meta/recipes-connectivity/openssh/openssh_7.4p1.bb b/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
index c8093d4..ccd7a02 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.4p1.bb
@@ -25,6 +25,7 @@ SRC_URI = "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
            file://openssh-7.1p1-conditional-compile-des-in-cipher.patch \
            file://openssh-7.1p1-conditional-compile-des-in-pkcs11.patch \
            file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
+           file://sshd-check-key \
            "
 
 PAM_SRC_URI = "file://sshd"
@@ -124,7 +125,14 @@ do_install_append () {
 	sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
 		-e 's,@SBINDIR@,${sbindir},g' \
 		-e 's,@BINDIR@,${bindir},g' \
+		-e 's,@LIBEXECDIR@,${libexecdir}/${BPN},g' \
 		${D}${systemd_unitdir}/system/sshd.socket ${D}${systemd_unitdir}/system/*.service
+
+	sed -i -e 's,@LIBEXECDIR@,${libexecdir}/${BPN},g' \
+		${D}${sysconfdir}/init.d/sshd
+
+	install -d 644 ${D}${libexecdir}/${BPN}
+	install -m 0755 ${WORKDIR}/sshd-check-key ${D}${libexecdir}/${BPN}
 }
 
 do_install_ptest () {
-- 
2.9.3

(No subject)

[Joshua Watt]

No need to create a directory name "644"

(No subject)

[Andrej Rode]

This patchset adds python-mprpc and python-gsocketpool to meta-python.
mprpc is a messagepack RPC implementation for python.

(no subject)

[Seraphime Kirkovski]

<ian.jackson@eu.citrix.com>
Bcc: 
Subject: Re: [PATCH] libxc: fix segfault on uninitialized xch->fmem
Reply-To: 
In-Reply-To: <20170404101507.lohlu5rbx4jq5md2@citrix.com>

On Tue, Apr 04, 2017 at 11:15:07AM +0100, Wei Liu wrote:
> Since there are a few handles in xch, it would be better to initialise
> them all at once by doing:
> 
>     struct xc_interface_core xch_buf = { 0 }
> 
> >      xch->flags = open_flags;
> >      xch->dombuild_logger_file = 0;
> >      xc_clear_last_error(xch);
> > -- 
> > 2.11.0
> > 

Hi, thanks for the reply.

Literally 10 minutes after sending this, I thought that a bzero would
be better. Will send a V2 shortly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(No subject)

[Suneetha Lakshmi G]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]


suneetha.g@tataelxsi.co.in



[-- Attachment #2: Type: text/html, Size: 622 bytes --]

(no subject)

[Felix Bruns]

   Hello,

   I am working on embedded device (using an i.MX6  MCU) which has an
   external amplifier for sound amplification.

   Unfortunately I could not find information if and how the gain of
   hardware amplifiers are controlled by ALSA.
   Can somebody clarify or point me to an example?

   Thanks and kind regards,
   Felix Bruns

(no subject)

[Dmitry Rockosov]

[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]

Hi guys,

Do you know when *recognized* Virtual Interrupt on VM-Entry will be
delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery
is blocking by STI?

Previously, VMM used Interrupt-Window, but as I see in XEN code,
Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.

Does it mean, we will get Virtual Interrupt on the next VM-entry?

Thank you!

Best Regards,
Rockosov Dmitry

[-- Attachment #1.2: Type: text/html, Size: 676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On Mon, Feb 27, 2017 at 6:12 PM, Dmitry Rockosov <rockosov@gmail.com> wrote:
> Hi guys,
>
> Do you know when *recognized* Virtual Interrupt on VM-Entry will be
> delivered if Virtual-Interrupt Delivery is enabled and interrupt delivery is
> blocking by STI?
>
> Previously, VMM used Interrupt-Window, but as I see in XEN code,
> Interrupt-Window is not used when Virtual Interrupt Delivery is enabled.
>
> Does it mean, we will get Virtual Interrupt on the next VM-entry?

CC'ing the VMX maintainer.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[anders]

(no subject)

[dhara buch]

[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]

Hello,

I have installed Ubuntu 15.10 in which have installed Xen with source.

Booting is done with Xen as well as commands like xl infor, xl list are
also working fine.

For creating Virtual Machine, I have installed Virtual Machine Manager, but
when I try to run it, it gives error as follows:







*Unable to connect to libvirt.internal error: libxenlight state driver is
not activeVerify that: - A Xen host kernel was booted - The Xen service has
been started*

I tried by installing libvirt as
apt-get install libvirt-bin

but, still the same problem is found. Libvirtd service is also not getting
started.

Where am I lacking?

Thank you,

Dhara Buch

[-- Attachment #1.2: Type: text/html, Size: 823 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

On Fri, 2017-02-17 at 22:47 +0530, dhara buch wrote:
> Hello,
> 
> I have installed Ubuntu 15.10 in which have installed Xen with
> source.
> 
> Booting is done with Xen as well as commands like xl infor, xl list
> are also working fine.
> 
> For creating Virtual Machine, I have installed Virtual Machine
> Manager, but when I try to run it, it gives error as follows:
> 
> Unable to connect to libvirt.
> 
> internal error: libxenlight state driver is not active
> 
This means you have not installed the libvirt, libxl driver. Or that
you have, but trying to load it is failing.

There should be something in the libvirt logs.

However, since you said you've installed Xen from sources, you probably
need to build and install libvirt from sources too.

In fact, I don't know how exactly it is in Ubuntu, but in all the
distro I've tried, trying to install libvirt-daemon-driver-libxl (or
whatever the package is called), would fail, unless Xen hypervisor,
toolstack and libraries are also installed with the distro package
mamanger.

If that is not the case, install would either fail, or would bring in
those Xen packages, which would then either overrun or conflict with
your source installation.

> Verify that:
>  - A Xen host kernel was booted
>  - The Xen service has been started
> 
> I tried by installing libvirt as
> apt-get install libvirt-bin
> 
> but, still the same problem is found. Libvirtd service is also not
> getting started.
> 
> Where am I lacking?
> 
As said above. In all the distro I tried, when I build Xen from source,
I've always also had to build libvirt from sources.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[Norbert Manthey]

Dear Xen developers,

I would like to bring the attached two patches online, as they fix minor defects
in the upstream code base.

Best,
Norbert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Andrew Cooper]

On 17/02/17 10:47, Norbert Manthey wrote:
> Dear Xen developers,
>
> I would like to bring the attached two patches online, as they fix minor defects
> in the upstream code base.

Thankyou for the fixes; they are both good.

For future fixes, please can you CC the appropriate maintainers
(https://wiki.xen.org/wiki/Submitting_Xen_Project_Patches#Cc_the_maintainer_of_the_code_you_are_modifying),
and you probably want to join the xen-devel mailing list to avoid
getting held in moderation.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(No subject)

[Paulo Neves]

Hello Yocto list from time to time my builds are getting this error
and I can't understand why is this happening. Every package is in
local IO, only the sstate cache i think is in an NFS mount.

Can you hint me at why this error could come up in yocto do_rootfs?

ERROR: lfs-release-full-x86-64-build-pc-linux-gnu-1.0-r0 do_rootfs:
Unable to install packages. Command
'/workspace/builds/yoctobuild/tmp/sysroots/x86_64-linux/usr/bin/opkg
--volatile-cache -f
/workspace/builds/yoctobuild/tmp/work/x86_64_build_pc_linux_gnu-poky-linux/lfs-release-full-x86-64-build-pc-linux-gnu/1.0-r0/opkg.conf
-o /workspace/builds/yoctobuild/tmp/work/x86_64_build_pc_linux_gnu-poky-linux/lfs-release-full-x86-64-build-pc-linux-gnu/1.0-r0/rootfs
 --force_postinstall --prefer-arch-to-version   install run-postinsts
fullsysroot all-vcf-wmp' returned 255:
Collected errors:
 * opkg_install_pkg: Failed to download fullsysroot. Perhaps you need
to run 'opkg update'?
 * opkg_install: Cannot install package fullsysroot.
 Installing run-postinsts (1.0-r0) on root.

....

Best regards
Paulo Neves

(no subject)

[anders]

<no subject>

[Sirisha Guduru]

subscribe ceph-devel

(no subject)

[Tony Whittam]

[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]

Hi everyone,

I don't know if this is too specialised for this list. Anyway, no harm in
asking the question :-)

*Preamble*
Build: Yocto from the Apollo Lake BSP release *gold, *
Hardware: Oxbow Hill Rev B CRB with Intel Atom E3950 and 4GB DDR3 RAM (one
SODIMM)
Build: core-image-sato-sdk
Installed on the onboard eMMC.
OpenCL: installed user space drivers from SRB4 https://software.intel.
com/file/533571/download

I'm currently evaluating the Apollo Lake platform as a candidate to run our
embedded application. We already have this application running on less
powerful ARM based Linux systems with Mali GPU using OpenCL 1.2. We're now
evaluating the E3950 as a faster alternative. To evaluate the application I
need OpenCL 1.2 or later.

To verify the OpenCL installation I have built and run the Intel demo apps:
CapsBasic and Bitonic Sort. CapsBasic sees two devices: CPU and GPU and
Bitonic sort can run its kernels correctly on both the CPU and the GPU.

*The issue*
Simply put, the application has

   - thread 1 (feeder): has a loop that feeds data into OpenCL and queues
   kernels
   - thread 2 (consumer): waits for results and reads output data.
   - an OpenCL Host command queue with out-of-order execution enabled

When I run my app and select the GPU OpenCL device, the feeder thread *stalls
inside a blocking call to clEnqueueMapBuffer(). *At this point only one
thing has been queued on the command queue: a buffer unmap command for a
different buffer. This unmap is waiting for an OpenCL event that will
indicate data ready to be processed.

In contrast, when I run my app and select the *CPU OpenCL *device, it works
perfectly.

Does anyone have any ideas on

   1. what might be causing this problem running with the GPU?
   2. how to debug this on the Yocto platform?

Best regards,

Tony

-- 
Tony Whittam
Rapt Touch

-- 
Confidentiality Notice: 

The information contained in this message, including any attachments 
hereto, may be confidential and is intended to be read only by the 
individual or entity to whom this message is addressed. If the reader of 
this message is not the intended recipient or an agent or designee of the 
intended recipient, please note that any review, use, disclosure or 
distribution of this message or its attachments, in any form, is strictly 
prohibited. If you have received this message in error, please immediately 
notify the sender and/or Rapt Touch Ltd via email at info@rapttouch.com and 
delete or destroy any copy of this message and its attachments.

[-- Attachment #1.2: Type: text/html, Size: 4121 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 arch/x86/include/uapi/asm/Kbuild | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/Kbuild b/arch/x86/include/uapi/asm/Kbuild
index 3dec769cadf7..1c532b3f18ea 100644
--- a/arch/x86/include/uapi/asm/Kbuild
+++ b/arch/x86/include/uapi/asm/Kbuild
@@ -27,7 +27,6 @@ header-y += ldt.h
 header-y += mce.h
 header-y += mman.h
 header-y += msgbuf.h
-header-y += msr-index.h
 header-y += msr.h
 header-y += mtrr.h
 header-y += param.h
-- 
2.8.1

[PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 arch/arm/include/asm/types.h      | 40 ---------------------------------------
 arch/arm/include/uapi/asm/types.h | 40 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 40 deletions(-)
 delete mode 100644 arch/arm/include/asm/types.h
 create mode 100644 arch/arm/include/uapi/asm/types.h

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
deleted file mode 100644
index a53cdb8f068c..000000000000
--- a/arch/arm/include/asm/types.h
+++ /dev/null
@@ -1,40 +0,0 @@
-#ifndef _ASM_TYPES_H
-#define _ASM_TYPES_H
-
-#include <asm-generic/int-ll64.h>
-
-/*
- * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
- * unambiguous on ARM as you would expect. For the types below, there is a
- * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
- * and the kernel itself, which results in build errors if you try to build with
- * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
- * in order to use NEON intrinsics)
- *
- * As the typedefs for these types in 'stdint.h' are based on builtin defines
- * supplied by GCC, we can tweak these to align with the kernel's idea of those
- * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
- * source file (provided that -ffreestanding is used).
- *
- *                    int32_t         uint32_t               uintptr_t
- * bare metal GCC     long            unsigned long          unsigned int
- * glibc GCC          int             unsigned int           unsigned int
- * kernel             int             unsigned int           unsigned long
- */
-
-#ifdef __INT32_TYPE__
-#undef __INT32_TYPE__
-#define __INT32_TYPE__		int
-#endif
-
-#ifdef __UINT32_TYPE__
-#undef __UINT32_TYPE__
-#define __UINT32_TYPE__	unsigned int
-#endif
-
-#ifdef __UINTPTR_TYPE__
-#undef __UINTPTR_TYPE__
-#define __UINTPTR_TYPE__	unsigned long
-#endif
-
-#endif /* _ASM_TYPES_H */
diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h
new file mode 100644
index 000000000000..9435a42f575e
--- /dev/null
+++ b/arch/arm/include/uapi/asm/types.h
@@ -0,0 +1,40 @@
+#ifndef _UAPI_ASM_TYPES_H
+#define _UAPI_ASM_TYPES_H
+
+#include <asm-generic/int-ll64.h>
+
+/*
+ * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
+ * unambiguous on ARM as you would expect. For the types below, there is a
+ * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
+ * and the kernel itself, which results in build errors if you try to build with
+ * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
+ * in order to use NEON intrinsics)
+ *
+ * As the typedefs for these types in 'stdint.h' are based on builtin defines
+ * supplied by GCC, we can tweak these to align with the kernel's idea of those
+ * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
+ * source file (provided that -ffreestanding is used).
+ *
+ *                    int32_t         uint32_t               uintptr_t
+ * bare metal GCC     long            unsigned long          unsigned int
+ * glibc GCC          int             unsigned int           unsigned int
+ * kernel             int             unsigned int           unsigned long
+ */
+
+#ifdef __INT32_TYPE__
+#undef __INT32_TYPE__
+#define __INT32_TYPE__		int
+#endif
+
+#ifdef __UINT32_TYPE__
+#undef __UINT32_TYPE__
+#define __UINT32_TYPE__	unsigned int
+#endif
+
+#ifdef __UINTPTR_TYPE__
+#undef __UINTPTR_TYPE__
+#define __UINTPTR_TYPE__	unsigned long
+#endif
+
+#endif /* _UAPI_ASM_TYPES_H */
-- 
2.8.1

Re: [PATCH v2 0/7] uapi: export all headers under uapi directories

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.

Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.

> The patch 6 was spotted by code review: there is no in-tree user of this
> functionality.
> The last patch remove the use of header-y. Now all files under an uapi
> directory are exported.

Very nice!

> asm is a bit special, most of architectures export asm/<arch>/include/uapi/asm
> only, but there is two exceptions:
>  - cris which exports arch/cris/include/uapi/arch-v[10|32];

This is interesting, though not your problem. Maybe someone who understands
cris better can comment on this: How is the decision made about which of
the arch/user.h headers gets used? I couldn't find that in the sources,
but it appears to be based on kernel compile-time settings, which is
wrong for user space header files that should be independent of the kernel
config.

>  - tile which exports arch/tile/include/uapi/arch.
> Because I don't know if the output of 'make headers_install_all' can be changed,
> I introduce subdir-y in Kbuild file. The headers_install_all target copies all
> asm/<arch>/include/uapi/asm to usr/include/asm-<arch> but
> arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> prefixed (they are put asis in usr/include/). If it's acceptable to modify the
> output of 'make headers_install_all' to export asm headers in
> usr/include/asm-<arch>/asm, then I could remove this new subdir-y and exports
> everything under arch/<arch>/include/uapi/.

I don't know if anyone still uses "make headers_install_all", I suspect
distros these days all use "make headers_install", so it probably
doesn't matter much.

In case of cris, it should be easy enough to move all the contents of the
uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
only seem to be referenced from there.

For tile, I suspect that would not work as the arch/*.h headers are
apparently defined as interfaces for both user space and kernel.

> Note also that exported files for asm are a mix of files listed by:
>  - include/uapi/asm-generic/Kbuild.asm;
>  - arch/x86/include/uapi/asm/Kbuild;
>  - arch/x86/include/asm/Kbuild.
> This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> used by scripts/Makefile.asm-generic).
> 
> This series has been tested with a 'make headers_install' on x86 and a
> 'make headers_install_all'. I've checked the result of both commands.
> 
> This patch is built against linus tree. I don't know if it should be
> made against antoher tree.

The series should probably get merged through the kbuild tree, but testing
it on mainline is fine here.

	Arnd

[PATCH v3 0/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Here is the v3 of this series. The first 5 patches are just cleanup: some
exported headers were still under a non-uapi directory or (x86 case) were
wrongly exported.
The patch 6 was spotted by code review: there is no in-tree user of this
functionality.
Patches 7 and 8 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me ;-)

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas

(no subject)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

(no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

(no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

(No subject)

[Rohit Jindal]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

Please help.me adding support for JIT to openjdk 8 in arm architecture.

Immediate help is highly appreciated.

Rohit

[-- Attachment #2: Type: text/html, Size: 160 bytes --]

(no subject)

[Ronald Rojas]

The first 57 commits are merged from previous work done by 
George Dunlap at (https://github.com/gwd/schedbench) and 
implement manipulating Cpu pool. The last 2 commits merge 
his work onto the Xen tree and implement finding system 
information and throwing errors.

CC: xen-devel <xen-devel@lists.xen.org>
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: George Dunlap <george.dunlap@citrix.com>
CC: George Dunlap <dunlapg@umich.edu>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Stefano Stabellini]

On Wed, 28 Dec 2016, Ronald Rojas wrote:
> The first 57 commits are merged from previous work done by 
> George Dunlap at (https://github.com/gwd/schedbench) and 
> implement manipulating Cpu pool. The last 2 commits merge 
> his work onto the Xen tree and implement finding system 
> information and throwing errors.

You need to add your Signed-off-by to all patches you touched for
copyright reasons. In fact, usually people add their Signed-off-by to
all patches. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(no subject)

[胡瑞桓]

------------------------------------------------------------------------------

(no subject)

[Ronald Rojas]

Create a Makefile for the golang xenlight project, which will
allow users to access libxl functionality in Golang. Makefile 
rules were also added to tools/Makefile for the project to be 
built and installed. A template Golang file was also created 
for the project to be properly built. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH i-g-t v5 1/4] lib: add igt_dummyload

[Daniel Vetter]

On Fri, Nov 11, 2016 at 07:41:10PM +0200, Abdiel Janulgue wrote:
> A lot of igt testcases need some GPU workload to make sure a race
> window is big enough. Unfortunately having a fixed amount of
> workload leads to spurious test failures or overtly long runtimes
> on some fast/slow platforms. This library contains functionality
> to submit GPU workloads that should consume exactly a specific
> amount of time.
> 
> v2 : Add recursive batch feature from Chris
> v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
>      by adding a dummy reloc to the bo as suggested by Ville.
> v4:  Fix dependency reloc as write instead of read (Ville).
>      Fix wrong handling of batchbuffer start on ILK causing
>      test failure
> 
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
> ---
>  lib/Makefile.sources |   2 +
>  lib/igt.h            |   1 +
>  lib/igt_dummyload.c  | 276 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  lib/igt_dummyload.h  |  42 ++++++++

Did you check that your new docs do show up in the generated
documentation? Iirc you need to edit some xml under docs/.
-Daniel

>  4 files changed, 321 insertions(+)
>  create mode 100644 lib/igt_dummyload.c
>  create mode 100644 lib/igt_dummyload.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index e8e277b..7fc5ec2 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -75,6 +75,8 @@ lib_source_list =	 	\
>  	igt_draw.h		\
>  	igt_pm.c		\
>  	igt_pm.h		\
> +	igt_dummyload.c		\
> +	igt_dummyload.h		\
>  	uwildmat/uwildmat.h	\
>  	uwildmat/uwildmat.c	\
>  	$(NULL)
> diff --git a/lib/igt.h b/lib/igt.h
> index d751f24..a0028d5 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -32,6 +32,7 @@
>  #include "igt_core.h"
>  #include "igt_debugfs.h"
>  #include "igt_draw.h"
> +#include "igt_dummyload.h"
>  #include "igt_fb.h"
>  #include "igt_gt.h"
>  #include "igt_kms.h"
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> new file mode 100644
> index 0000000..b934fd5
> --- /dev/null
> +++ b/lib/igt_dummyload.c
> @@ -0,0 +1,276 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include "igt_dummyload.h"
> +#include <time.h>
> +#include <signal.h>
> +#include <sys/syscall.h>
> +
> +/**
> + * SECTION:igt_dummyload
> + * @short_description: Library for submitting GPU workloads
> + * @title: Dummyload
> + * @include: igt.h
> + *
> + * A lot of igt testcases need some GPU workload to make sure a race window is
> + * big enough. Unfortunately having a fixed amount of workload leads to
> + * spurious test failures or overtly long runtimes on some fast/slow platforms.
> + * This library contains functionality to submit GPU workloads that should
> + * consume exactly a specific amount of time.
> + */
> +
> +#define NSEC_PER_SEC 1000000000L
> +
> +#define gettid() syscall(__NR_gettid)
> +#define sigev_notify_thread_id _sigev_un._tid
> +
> +#define LOCAL_I915_EXEC_BSD_SHIFT      (13)
> +#define LOCAL_I915_EXEC_BSD_MASK       (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> +
> +#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> +
> +static void
> +fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_handle,
> +	    struct drm_i915_gem_relocation_entry *relocs, uint32_t count)
> +{
> +	memset(obj, 0, sizeof(*obj));
> +	obj->handle = gem_handle;
> +	obj->relocation_count = count;
> +	obj->relocs_ptr = (uintptr_t)relocs;
> +}
> +
> +static void
> +fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
> +	   uint32_t gem_handle, uint32_t offset,
> +	   uint32_t read_domains, uint32_t write_domains)
> +{
> +	reloc->target_handle = gem_handle;
> +	reloc->delta = 0;
> +	reloc->offset = offset * sizeof(uint32_t);
> +	reloc->presumed_offset = 0;
> +	reloc->read_domains = read_domains;
> +	reloc->write_domain = write_domains;
> +}
> +
> +
> +static uint32_t *batch;
> +
> +static uint32_t emit_recursive_batch(int fd, int engine, unsigned dep_handle)
> +{
> +	const int gen = intel_gen(intel_get_drm_devid(fd));
> +	struct drm_i915_gem_exec_object2 obj[2];
> +	struct drm_i915_gem_relocation_entry relocs[2];
> +	struct drm_i915_gem_execbuffer2 execbuf;
> +	unsigned engines[16];
> +	unsigned nengine, handle;
> +	int i = 0, reloc_count = 0, buf_count = 0;
> +
> +	buf_count = 0;
> +	nengine = 0;
> +	if (engine < 0) {
> +		for_each_engine(fd, engine)
> +			if (engine)
> +				engines[nengine++] = engine;
> +	} else {
> +		igt_require(gem_has_ring(fd, engine));
> +		engines[nengine++] = engine;
> +	}
> +	igt_require(nengine);
> +
> +	memset(&execbuf, 0, sizeof(execbuf));
> +	memset(obj, 0, sizeof(obj));
> +	memset(relocs, 0, sizeof(relocs));
> +
> +	execbuf.buffers_ptr = (uintptr_t) obj;
> +	handle = gem_create(fd, 4096);
> +	batch = gem_mmap__gtt(fd, handle, 4096, PROT_WRITE);
> +	gem_set_domain(fd, handle,
> +			I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
> +
> +	if (nengine == 1 && dep_handle > 0) {
> +		/* dummy write to dependency */
> +		fill_object(&obj[buf_count], dep_handle, NULL, 0);
> +		buf_count++;
> +
> +		fill_reloc(&relocs[reloc_count], dep_handle, i,
> +			   I915_GEM_DOMAIN_RENDER,
> +			   I915_GEM_DOMAIN_RENDER);
> +		batch[i++] = 0; /* reloc */
> +		reloc_count++;
> +		batch[i++] = MI_NOOP;
> +	}
> +
> +	if (gen >= 8) {
> +		batch[i++] = MI_BATCH_BUFFER_START | 1 << 8 | 1;
> +		/* recurse */
> +		fill_reloc(&relocs[reloc_count], handle, i,
> +			   I915_GEM_DOMAIN_COMMAND, 0);
> +		batch[i++] = 0;
> +		batch[i++] = 0;
> +	} else if (gen >= 6) {
> +		batch[i++] = MI_BATCH_BUFFER_START | 1 << 8;
> +		/* recurse */
> +		fill_reloc(&relocs[reloc_count], handle, i,
> +			   I915_GEM_DOMAIN_COMMAND, 0);
> +		batch[i++] = 0;
> +	} else {
> +		batch[i++] = MI_BATCH_BUFFER_START | 2 << 6 |
> +			((gen < 4) ? 1 : 0);
> +		/* recurse */
> +		fill_reloc(&relocs[reloc_count], handle, i,
> +			   I915_GEM_DOMAIN_COMMAND, 0);
> +		batch[i++] = 0;
> +		if (gen < 4)
> +			relocs[reloc_count].delta = 1;
> +	}
> +	reloc_count++;
> +
> +	fill_object(&obj[buf_count], handle, relocs, reloc_count);
> +	buf_count++;
> +
> +	for (i = 0; i < nengine; i++) {
> +		execbuf.flags &= ~ENGINE_MASK;
> +		execbuf.flags = engines[i];
> +		execbuf.buffer_count = buf_count;
> +		gem_execbuf(fd, &execbuf);
> +	}
> +
> +	return handle;
> +}
> +
> +static void sigiter(int sig, siginfo_t *info, void *arg)
> +{
> +	*batch = MI_BATCH_BUFFER_END;
> +	__sync_synchronize();
> +}
> +
> +static timer_t setup_batch_exit_timer(int64_t ns)
> +{
> +	timer_t timer;
> +	struct sigevent sev;
> +	struct sigaction act;
> +	struct itimerspec its;
> +
> +	memset(&sev, 0, sizeof(sev));
> +	sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
> +	sev.sigev_notify_thread_id = gettid();
> +	sev.sigev_signo = SIGRTMIN + 1;
> +	igt_assert(timer_create(CLOCK_MONOTONIC, &sev, &timer) == 0);
> +	igt_assert(timer > 0);
> +
> +	memset(&act, 0, sizeof(act));
> +	act.sa_sigaction = sigiter;
> +	act.sa_flags = SA_SIGINFO;
> +	igt_assert(sigaction(SIGRTMIN + 1, &act, NULL) == 0);
> +
> +	memset(&its, 0, sizeof(its));
> +	its.it_value.tv_sec = ns / NSEC_PER_SEC;
> +	its.it_value.tv_nsec = ns % NSEC_PER_SEC;
> +	igt_assert(timer_settime(timer, 0, &its, NULL) == 0);
> +
> +	return timer;
> +}
> +
> +/**
> + * igt_spin_batch:
> + * @fd: open i915 drm file descriptor
> + * @ns: amount of time in nanoseconds the batch executes after terminating.
> + *      If value is less than 0, execute batch forever.
> + * @engine: Ring to execute batch OR'd with execbuf flags. If value is less
> + *          than 0, execute on all available rings.
> + * @dep_handle: handle to a buffer object dependency. If greater than 0, add a
> + *              relocation entry to this buffer within the batch.
> + *
> + * Start a recursive batch on a ring that terminates after an exact amount
> + * of time has elapsed. Immediately returns a #igt_spin_t that contains the
> + * batch's handle that can be waited upon. The returned structure must be passed to
> + * igt_post_spin_batch() for post-processing.
> + *
> + * Returns:
> + * Structure with helper internal state for igt_post_spin_batch().
> + */
> +igt_spin_t igt_spin_batch(int fd, int64_t ns, int engine, unsigned dep_handle)
> +{
> +	timer_t timer;
> +	uint32_t handle = emit_recursive_batch(fd, engine, dep_handle);
> +	int64_t wait_timeout = 0;
> +	igt_assert_eq(gem_wait(fd, handle, &wait_timeout), -ETIME);
> +
> +	if (ns < 1) {
> +		if (ns == 0) {
> +			*batch = MI_BATCH_BUFFER_END;
> +			__sync_synchronize();
> +			return (igt_spin_t){ handle, batch, 0};
> +		}
> +		return (igt_spin_t){ handle, batch, 0 };
> +	}
> +	timer = setup_batch_exit_timer(ns);
> +
> +	return (igt_spin_t){ handle, batch, timer };
> +}
> +
> +/**
> + * igt_post_spin_batch:
> + * @fd: open i915 drm file descriptor
> + * @arg: spin batch state from igt_spin_batch()
> + *
> + * This function does the necessary post-processing after starting a recursive
> + * batch with igt_spin_batch().
> + */
> +void igt_post_spin_batch(int fd, igt_spin_t arg)
> +{
> +	if (arg.handle == 0)
> +		return;
> +
> +	if (arg.timer > 0)
> +		timer_delete(arg.timer);
> +
> +	gem_close(fd, arg.handle);
> +	munmap(arg.batch, 4096);
> +}
> +
> +
> +/**
> + * igt_spin_batch_wait:
> + * @fd: open i915 drm file descriptor
> + * @ns: amount of time in nanoseconds the batch executes after terminating.
> + *      If value is less than 0, execute batch forever.
> + * @engine: ring to execute batch OR'd with execbuf flags. If value is less
> + *          than 0, execute on all available rings.
> + * @dep_handle: handle to a buffer object dependency. If greater than 0, include
> + *              this buffer on the wait dependency
> + *
> + * This is similar to igt_spin_batch(), but waits on the recursive batch to finish
> + * instead of returning right away. The function also does the necessary
> + * post-processing automatically if set to timeout.
> + */
> +void igt_spin_batch_wait(int fd, int64_t ns, int engine, unsigned dep_handle)
> +{
> +	igt_spin_t spin = igt_spin_batch(fd, ns, engine, dep_handle);
> +	int64_t wait_timeout = ns + (0.5 * NSEC_PER_SEC);
> +	igt_assert_eq(gem_wait(fd, spin.handle, &wait_timeout), 0);
> +
> +	igt_post_spin_batch(fd, spin);
> +}
> diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
> new file mode 100644
> index 0000000..79ead2c
> --- /dev/null
> +++ b/lib/igt_dummyload.h
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#ifndef __IGT_DUMMYLOAD_H__
> +#define __IGT_DUMMYLOAD_H__
> +
> +typedef struct igt_spin {
> +	unsigned handle;
> +	uint32_t *batch;
> +	timer_t timer;
> +} igt_spin_t;
> +
> +
> +igt_spin_t igt_spin_batch(int fd, int64_t ns, int engine, unsigned dep_handle);
> +
> +void igt_post_spin_batch(int fd, igt_spin_t arg);
> +
> +void igt_spin_batch_wait(int fd, int64_t ns, int engine, unsigned dep_handle);
> +
> +
> +#endif /* __IGT_DUMMYLOAD_H__ */
> -- 
> 2.7.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[Abdiel Janulgue]

On 11.11.2016 18:16, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 07:41:10PM +0200, Abdiel Janulgue wrote:
>> A lot of igt testcases need some GPU workload to make sure a race
>> window is big enough. Unfortunately having a fixed amount of
>> workload leads to spurious test failures or overtly long runtimes
>> on some fast/slow platforms. This library contains functionality
>> to submit GPU workloads that should consume exactly a specific
>> amount of time.
>>
>> v2 : Add recursive batch feature from Chris
>> v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
>>      by adding a dummy reloc to the bo as suggested by Ville.
>> v4:  Fix dependency reloc as write instead of read (Ville).
>>      Fix wrong handling of batchbuffer start on ILK causing
>>      test failure
>>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
>> ---
>>  lib/Makefile.sources |   2 +
>>  lib/igt.h            |   1 +
>>  lib/igt_dummyload.c  | 276 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  lib/igt_dummyload.h  |  42 ++++++++
> 
> Did you check that your new docs do show up in the generated
> documentation? Iirc you need to edit some xml under docs/.
> -Daniel
> 

Yeah I missed that. Updated now to include the docs in generated
documentation.


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

<no subject>

[Bharath Krishna]

subscribe ceph-devel

(no subject)

[xerofoify]

(No subject)

[Amarnath Valluri]

As discussed offline with Joshua, Updated the patch to make the stateless
user home folder as build config option(--disable-stateless-home). 
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

(no subject)

[Alex Gershgorin]

[-- Attachment #1.1: Type: text/plain, Size: 1511 bytes --]

Hi everyone,

Our company use Atmel TPM AT97SC3205 - SPI interface.
Accordingly to datasheests it's compliant to Trusted Computing Group (TCG) Trusted Platform Module TPM) Version 1.2 Specification. Compliant with TCG PC Client-Specific TPM Interface Specification (TIS Version 1.3).
On my target board I'm running Kernel from git://git.infradead.org/users/jjs/linux-tpmdd.git   next head.
I have made some additional changes on my Device Tree.

spi1: spi@fc000000 {
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_spi1_default>;
                status = "okay";

                tpm_tis@0 {
                            compatible = "tcg,tpm_tis-spi";
                    reg = <0>;
                            spi-max-frequency = <10000000>;
                    };
            };

This is part of my kernel boot messages:
atmel_spi fc000000.spi: version: 0x311
atmel_spi fc000000.spi: Using dma0chan2 (tx) and dma0chan3 (rx) for DMA transfers
atmel_spi fc000000.spi: Using FIFO (16 data)
atmel_spi fc000000.spi: Atmel SPI Controller at 0xfc000000 (irq 36)
tpm tpm0: tpm_transmit: tpm_send: error -5
tpm_tis_spi: probe of spi32765.0 failed with error -5

I verified with an oscilloscope that all SPI bus signals are in order.

Following the above kernel boot messages - my question is :
    Can I use tpm_tis_spi device driver for AT97SC3205 device ?

Please advise and help with any directions.

Thanks in advance,
Alex Gershgorin






[-- Attachment #1.2: Type: text/html, Size: 3231 bytes --]

[-- Attachment #2: Type: text/plain, Size: 424 bytes --]

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: (no subject)

[Jarkko Sakkinen]

On Tue, Jul 19, 2016 at 08:34:20AM +0000, Alex Gershgorin wrote:
>    Hi everyone,
> 
>    Our company use Atmel TPM AT97SC3205 - SPI interface.
>    Accordingly to datasheests it's compliant to Trusted Computing Group (TCG)
>    Trusted Platform Module TPM) Version 1.2 Specification. Compliant with TCG
>    PC Client-Specific TPM Interface Specification (TIS Version 1.3).
>    On my target board I'm running Kernel from
>    git://git.infradead.org/users/jjs/linux-tpmdd.git   next head.
>    I have made some additional changes on my Device Tree.


Are you sure that it uses SPI hardware protocol and not TCG MMIO?
On PC the tranport could be LPC or SPI but the interface is TCG
one.

/Jarkko


>    spi1: spi@fc000000 {
>                    pinctrl-names = "default";
>                    pinctrl-0 = <&pinctrl_spi1_default>;
>                    status = "okay";
> 
>                    tpm_tis@0 {
>                                compatible = "tcg,tpm_tis-spi";
>                        reg = <0>;
>                                spi-max-frequency = <10000000>;
>                        };
>                };
> 
>    This is part of my kernel boot messages:
>    atmel_spi fc000000.spi: version: 0x311
>    atmel_spi fc000000.spi: Using dma0chan2 (tx) and dma0chan3 (rx) for DMA
>    transfers
>    atmel_spi fc000000.spi: Using FIFO (16 data)
>    atmel_spi fc000000.spi: Atmel SPI Controller at 0xfc000000 (irq 36)
>    tpm tpm0: tpm_transmit: tpm_send: error -5
>    tpm_tis_spi: probe of spi32765.0 failed with error -5
> 
>    I verified with an oscilloscope that all SPI bus signals are in order.
> 
>    Following the above kernel boot messages - my question is :
>        Can I use tpm_tis_spi device driver for AT97SC3205 device ?
> 
>    Please advise and help with any directions.
> 
>    Thanks in advance,
>    Alex Gershgorin

> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. http://sdm.link/zohodev2dev

> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev

(no subject)

[姚 å¿ å°†]

[-- Attachment #1.1: Type: text/plain, Size: 785 bytes --]

   Recently , I made a test to compare the performance of I/O between xen project and xenserver. I found the performance of xenserver is much better than that of xen project .

I want to find the reason why xenserver is better so I search through google.com. On the website www.xenproject.org<http://www.xenproject.org> , I found url http://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance and http://wiki.xenproject.org/wiki/Network_Throughput_and_Performance_Guide .
I set these parameters as the url given. But , it looks doesn’t work. The performance got no obvious improvement.

So , I send this mail to get some advise . will you help me ? if so , I’ll  be much appreciate.


发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用


[-- Attachment #1.2: Type: text/html, Size: 3309 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

(No subject)

[Julien CARBONNIER]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Hi all,

I'm building a custom image with mx6dl using branch 4.1.15-1.0.0_ga with 
qt5.5.1, gdb 7.9.1 and i have a problem to debug qt applications.
When i used the meta-toolchain-qt5 and try to launch my application i 
have the following message at start :

 >*running,thread-id="all"

dNOTE: INFERIOR STILL RUNNING IN STATE InferiorRunOk.

 >~"\nProgram received signal "

 >~"SIGSEGV, Segmentation fault.\n"

 >~"0x47559e24 in ?? ()\n"

 >*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x47559e24",func="??",args=[]},thread-id="1",stopped-threads="all",core="0"

dNOTE: INFERIOR SPONTANEOUS STOP

sStopped.

I try to backtrace the problem and i can't have informations.

<765bt

 >&"bt\n"

 >~"#-1 0x47559e24 in ?? ()\n"

 >~"Backtrace stopped: Cannot access memory at address 0x324e5a56\n"

 >765^done

When i set breakpoint in my main program at the first line the program 
has the same behavior. I use qt-creator to debug and i try without but 
it's the same problem ,could someone help me?

Thanks for all,
Re: Nouveau format signature électronique Best Regards Julien CARBONNIER

[-- Attachment #2: Type: text/html, Size: 4894 bytes --]

(no subject)

[George Dunlap]

On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percentage.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

The change looks good in itself; but it makes me realize that
technically by changing the trace format, the previous patch
introduced a regression which is fixed here.  There's a part of me
that's tempted to overlook it because it's minor, but on balance I
think we should try to be diligent with this sort of thing.

Could you re-send this with the trace change moved from the previous
patch to this patch?

If you don't make any other changes, you can retain the reviewed-by of
the previous patch, and add this one to this patch:

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1801 bytes --]

On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > in both xenalyze and formats (for xentrace_format).
> > 
> > In particular, in xenalyze, now that we have the precision
> > of the fixed point load values in the tracepoint, show both
> > the raw value and the (easier to interpreet) percentage.
> > 
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> The change looks good in itself; but it makes me realize that
> technically by changing the trace format, the previous patch
> introduced a regression which is fixed here.  There's a part of me
> that's tempted to overlook it because it's minor, but on balance I
> think we should try to be diligent with this sort of thing.
> 
Sure!

> Could you re-send this with the trace change moved from the previous
> patch to this patch?
> 
So, you're saying I should change both Xen, xentrace_format and
xenalyze.c all at once, in the same patch, right?

I'm asking just to double check, as, although I see your point,
separating things by component seemed a good thing to do to me, even at
the price you describe, and I've done it before. :-)

As said, I'm fine doing that, I just want to be sure this is what you
are asking.

> If you don't make any other changes, you can retain the reviewed-by
> of
> the previous patch, and add this one to this patch:
> 
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>
Ok, thanks.

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> <dario.faggioli@citrix.com> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the fixed point load values in the tracepoint, show both
>>> the raw value and the (easier to interpreet) percentage.
>>>
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> The change looks good in itself; but it makes me realize that
>> technically by changing the trace format, the previous patch
>> introduced a regression which is fixed here.  There's a part of me
>> that's tempted to overlook it because it's minor, but on balance I
>> think we should try to be diligent with this sort of thing.
>>
> Sure!
> 
>> Could you re-send this with the trace change moved from the previous
>> patch to this patch?
>>
> So, you're saying I should change both Xen, xentrace_format and
> xenalyze.c all at once, in the same patch, right?
> 
> I'm asking just to double check, as, although I see your point,
> separating things by component seemed a good thing to do to me, even at
> the price you describe, and I've done it before. :-)
> 
> As said, I'm fine doing that, I just want to be sure this is what you
> are asking.

I think it often does make sense to check things out by component.  And
of course before xenalyze was in tree, it doesn't matter when the change
was done.  I suppose I've always been prejudiced against
xentrace_format, which is why I'd never thought about regressions in it
(although I probably should have).

But now that xenalyze is in-tree, I think we want to avoid situations
where the in-tree xenalyze is broken, even just for one changeset, if we
can avoid it.

Thanks,
 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

On Thu, 2016-07-07 at 13:48 +0100, George Dunlap wrote:
> On 07/07/16 12:03, Dario Faggioli wrote:
> > On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> > > Could you re-send this with the trace change moved from the
> > > previous
> > > patch to this patch?
> > > 
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
> > 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if
> we
> can avoid it.
> 
Ok, this makes sense. Will do.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Ian Jackson]

George Dunlap writes ("Re:"):
> On 07/07/16 12:03, Dario Faggioli wrote:
> > So, you're saying I should change both Xen, xentrace_format and
> > xenalyze.c all at once, in the same patch, right?
...
> I think it often does make sense to check things out by component.  And
> of course before xenalyze was in tree, it doesn't matter when the change
> was done.  I suppose I've always been prejudiced against
> xentrace_format, which is why I'd never thought about regressions in it
> (although I probably should have).
> 
> But now that xenalyze is in-tree, I think we want to avoid situations
> where the in-tree xenalyze is broken, even just for one changeset, if we
> can avoid it.

This kind of situation is not that uncommon.  For any part of our
system where we don't offer a stable API, or at least one-way
intercompatibility, it is necessary to make incompatible changes both
in the producer and in all consumers.

(Sometimes this can mean a patch to xen.git needs to be combined with
a QEMU_TAG update for qemu-trad, too; in theory trying to decouple the
Xen API for qemu upstream.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 256 bytes --]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } 
 
http://nkaprehulte.thedahs.com/Brian_Neu


Brian Neu
Sent from Yahoo Mail for iPhone
 

[-- Attachment #2: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

(no subject)

[Jason Gunthorpe]

Bcc: 
Subject: Re: [PATCH 2/2 v3] tpm: Add TPM 2.0 support to the Nuvoton i2c
 driver (NPCT6xx family)
Reply-To: 
In-Reply-To: <1467174493-4190-3-git-send-email-andrew.zamansky-KrzQf0k3Iz9BDgjK7y7TUQ@public.gmane.org>

On Wed, Jun 29, 2016 at 07:28:13AM +0300, andrew zamansky wrote:
> -	chip->flags |= TPM_CHIP_FLAG_IRQ;
> +	if (client->irq)
> +		chip->flags |= TPM_CHIP_FLAG_IRQ;
> +

Oh.. this should be a seperate patch, it is a bug fix for the stuff
Jarkko just sent a pull request for:

commit 570a36097f302c0bae4fb5478f1287b9b3626155
Author: Christophe Ricard <christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date:   Thu Mar 31 22:56:56 2016 +0200

    tpm: drop 'irq' from struct tpm_vendor_specific

Jason

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

(no subject)

[Xieyingtai]

[-- Attachment #1.1.1: Type: text/plain, Size: 520 bytes --]


According to the process in select_checker() and get_state(), sysfs_get_timeout should return 1 in normal case.

---
libmultipath/discovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 126a54f..cd3443d 100644
--- a/libmultipath/discovery.c
+++ b/libmultipath/discovery.c
@@ -271,7 +271,7 @@ sysfs_get_timeout(struct path *pp, unsigned int *timeout)
   }
   *timeout = t;
-   return 0;
+   return 1;
}
 int
--
1.8.3.4

[-- Attachment #1.1.2: Type: text/html, Size: 7193 bytes --]

[-- Attachment #1.2: image001.gif --]
[-- Type: image/gif, Size: 1065 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 96 bytes --]


http://zefipago.aquasportsclub.com/wish <http://zefipago.aquasportsclub.com/wish>


Brian Neu


[-- Attachment #2: Type: text/plain, Size: 429 bytes --]

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

(no subject)

[Roger Pau Monné]

<George.Dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan 
Beulich <jbeulich@suse.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, 
Stefano Stabellini <sstabellini@kernel.org>, Tim Deegan <tim@xen.org>, Wei 
Liu <wei.liu2@citrix.com>
Bcc: 
Subject: Bump library names just after branching
Reply-To: 

Hello,

Currently we bump the shared library names just before the release, so ATM 
xen-unstable is still using the library names from the 4.6 release. This is 
an issue if someone wants to install both Xen 4.6 and xen-unstable in the 
same box (unless you use a different prefix/DESTDIR), because libraries from 
xen-unstable will replace the stable ones.

IMHO, it would make more sense to bump the library names just *after* we 
branch and open the tree for development again. We could even have the 
library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so 
that we don't need to go around the different library makefiles bumping the 
versions manually.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Nichole Neeley]

[-- Attachment #1.1: Type: text/plain, Size: 24 bytes --]

Morettaneeley@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 86 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(No subject)

[Nagi Chitta Reddy]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

Hi All,

I would like to know what is the stable SDK1.9 based BSP for Freescale
LS1021ATWR/LS1020ATWR SoC family.

I am trying with below repo command to get the tree, but i see issues as
below
////////////////////////
repo init -u https://github.com/Freescale/meta-freescale
fatal: manifest 'default.xml' not available
fatal: manifest default.xml not found
////////////////////////

Can someone tell me what exactly the problem.

Best Regards,
Nagi

[-- Attachment #2: Type: text/html, Size: 705 bytes --]

(No subject)

[Zhenhua Luo]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

The meta-freescale is a layer instead of a repo project, you can use meta-freescale layer or SDK ISOs(http://www.nxp.com/products/software-and-tools/run-time-software/linux-sdk/linux-sdk-for-qoriq-processors:SDKLINUX) for ls1021atwr support.


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Nagi Chitta Reddy
Sent: Saturday, March 19, 2016 12:56 AM
To: meta-freescale@lists.yoctoproject.org
Subject: [meta-freescale] (no subject)

Hi All,

I would like to know what is the stable SDK1.9 based BSP for Freescale LS1021ATWR/LS1020ATWR SoC family.

I am trying with below repo command to get the tree, but i see issues as below
////////////////////////
repo init -u https://github.com/Freescale/meta-freescale
fatal: manifest 'default.xml' not available
fatal: manifest default.xml not found
////////////////////////

Can someone tell me what exactly the problem.

Best Regards,
Nagi

[-- Attachment #2: Type: text/html, Size: 5150 bytes --]

(no subject)

[Safa Hamza]

[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

i'm trying to run xen on omap5 and installing some guests ..  it seems it
works and a xen boot dom0 as shown the screen shot
but with this arago project i can't download any package ..all commands
such as apt-get ,update ... are not found
i tried to have another file system but its not working ..
can you help me .. with which file system can i work
thanks

[-- Attachment #1.2: Type: text/html, Size: 437 bytes --]

[-- Attachment #2: dom0-boot.PNG --]
[-- Type: image/png, Size: 39281 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Safa Hamza]

[-- Attachment #1.1: Type: text/plain, Size: 470 bytes --]

i solve the problem

On Thu, Mar 17, 2016 at 1:20 PM, Safa Hamza <safahamza1@gmail.com> wrote:

> i'm trying to run xen on omap5 and installing some guests ..  it seems it
> works and a xen boot dom0 as shown the screen shot
> but with this arago project i can't download any package ..all commands
> such as apt-get ,update ... are not found
> i tried to have another file system but its not working ..
> can you help me .. with which file system can i work
> thanks
>

[-- Attachment #1.2: Type: text/html, Size: 830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Ayushi Arora]

[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

Hello,
As asked of in the previous mail, I tried compiling Xen from source.
I am not sure whether we can ask questions for the task given, but I have
been stuck at it from yesterday.
I followed all the steps, and wherever there was some problem, I looked up
that in wiki of Xen, but after building and installing that with ovmf
enabled in ./configure, I moved on to the network configuration, and on
rebooting after the configuration, it is showing ' ERROR: Can't find
hypervisor information in sysfs!' on xm list and brctl shows no bridge
enabled. On further checking, it showed 'ERROR: Not running inside Xen'.
I have tried finding the problem, and I will check this again but I can't
move forward until the hypervisor runs!
Not sure where to check for the error.

Thank you,

Ayushi.

[-- Attachment #1.2: Type: text/html, Size: 933 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(No subject)

[Joe MacDonald]

These four are bridge measures I took to get my images building again
while merging the backlog of meta-networking patches.  I'm now circling
back to clear out first the waf issue, which I think will resolve the
samba and libldb (and related library) errors, then start looking at the
excess of blacklisting we've had to do lately.

-- 
Joe MacDonald
:wq

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 254 bytes --]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important;  padding-left:1ex !important; background-color:white !important; }    http://nightcoffee.by/fellow.php   Brian Neu
Sent from Yahoo Mail for iPhone

[-- Attachment #2: Type: text/plain, Size: 413 bytes --]

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

(No subject)

[Baokang.Huang(黄宝亢)]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

  meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>



General information about the mailing list is at:



  https://lists.yoctoproject.org/listinfo/meta-freescale



If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at:



  https://lists.yoctoproject.org/options/meta-freescale/baokang.huang%40advantech.com.cn





You can also make such adjustments via email by sending a message to:



  meta-freescale-request@yoctoproject.org<mailto:meta-freescale-request@yoctoproject.org>



with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions.



You must know your password to change your options (including changing the password, itself) or to unsubscribe.  It is:



  nasiozut



Normally, Mailman will remind you of your yoctoproject.org mailing list passwords once every month, although you can disable this if you prefer.  This reminder will also include instructions on how to unsubscribe or change your account options.  There is also a button on your options page that will email your current password to you.



All the  best

黄宝亢
研华嵌入式核心运算事业群（RISC/ARM）
Tel: 0755-82124222#7043
MB:13714679353
地址：深圳市南山区科技南12路28号康佳研发大厦4层A-C
--------------------------------------------------------------------------------


[-- Attachment #2: Type: text/html, Size: 7039 bytes --]

(no subject)

[Ian Jackson]

I'm intending to be able to do database schema updates.  But I don't
want to play around with such code on a live database.  So I need a
test database.

Thus, a yak: arrangements to make a test database.

As I say, I have tested this and it now does the right things in,
apparently, the right order, and seems to leave things in a good state
even when it collapses halfway or is ^C'd.

In v2 I have addressed the comments, and added a couple of new safety
catches.  For ease of review these are mostly as followup patches to
the mg-schema-test-database script, rather than folded in.

Re: (no subject)

[Philippe Proulx]

Isn't there a libuuid development package for CentOS 5
instead of building it from source?

Like this: <http://pkgs.org/centos-5/epel-i386/uuid-devel-1.5.1-3.el5.i386.rpm.html>?

Really not a CentOS/RPM expert here.

Philippe Proulx


On Thu, Nov 26, 2015 at 10:20 PM, Zvi Vered <veredz72@gmail.com> wrote:
> Hello,
>
> I downloaded lttng-tools-2.7.0 and tried to run ./configure.
>
> I got the error message:
>
> ....
> checking for xml2-config... /home/zvivered/GNU/libxml2/release/bin/xml2-config
> checking for libxml - version >= 2.7.6... yes (version 2.7.7)
> checking for uuid_generate in -luuid... no
> checking for uuid_create in -lc... no
> configure: error: Cannot find libuuid uuid_generate nor libc
> uuid_create. Use LDFLAGS=-Ldir to specify their location.
>
> I'm working with Centos 5.5 (32).
> I downloaded libuuid-1.0.3.tar.gz from http://sourceforge.net/projects/libuuid/
> It solved the .configure problem. Is this the right download place ?
>
> Best regards,
> Z.V
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

(no subject)

[Zvi Vered]

Hello,

I downloaded lttng-tools-2.7.0 and tried to run ./configure.

I got the error message:

....
checking for xml2-config... /home/zvivered/GNU/libxml2/release/bin/xml2-config
checking for libxml - version >= 2.7.6... yes (version 2.7.7)
checking for uuid_generate in -luuid... no
checking for uuid_create in -lc... no
configure: error: Cannot find libuuid uuid_generate nor libc
uuid_create. Use LDFLAGS=-Ldir to specify their location.

I'm working with Centos 5.5 (32).
I downloaded libuuid-1.0.3.tar.gz from http://sourceforge.net/projects/libuuid/
It solved the .configure problem. Is this the right download place ?

Best regards,
Z.V

(no subject)

[Mr. Vincent Cheng]

-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

Re: [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id

[Martin Pohlack]

On 05.08.2015 10:58, Andrew Cooper wrote:
> On 05/08/15 09:50, Martin Pohlack wrote:
>> On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  tools/libxc/xc_private.c     |  3 +++
>>>  tools/misc/xen-xsplice.c     | 25 +++++++++++++++++++++++++
>>>  xen/common/kernel.c          | 11 +++++++++++
>>>  xen/common/version.c         |  5 +++++
>>>  xen/include/public/version.h |  4 ++++
>>>  xen/include/xen/compile.h.in |  1 +
>>>  xen/include/xen/version.h    |  1 +
>>>  7 files changed, 50 insertions(+)
>>>
>>> diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
>>> index 2ffebd9..7c039ca 100644
>>> --- a/tools/libxc/xc_private.c
>>> +++ b/tools/libxc/xc_private.c
>>> @@ -713,6 +713,9 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
>>>      case XENVER_commandline:
>>>          sz = sizeof(xen_commandline_t);
>>>          break;
>>> +    case XENVER_build_id:
>>> +        sz = sizeof(xen_build_id_t);
>>> +        break;
>>>      default:
>>>          ERROR("xc_version: unknown command %d\n", cmd);
>>>          return -EINVAL;
>>> diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
>>> index 7cf9879..dd8266c 100644
>>> --- a/tools/misc/xen-xsplice.c
>>> +++ b/tools/misc/xen-xsplice.c
>>> @@ -17,6 +17,7 @@ void show_help(void)
>>>              " <id> An unique name of payload. Up to 40 characters.\n"
>>>              "Commands:\n"
>>>              "  help                 display this help\n"
>>> +            "  build-id             display build-id of hypervisor.\n"
>>>              "  upload <id> <file>   upload file <cpuid> with <id> name\n"
>>>              "  list                 list payloads uploaded.\n"
>>>              "  apply <id>           apply <id> patch.\n"
>>> @@ -306,12 +307,36 @@ int action_func(int argc, char *argv[], unsigned int idx)
>>>  
>>>      return rc;
>>>  }
>>> +
>>> +static int build_id_func(int argc, char *argv[])
>>> +{
>>> +    xen_build_id_t build_id;
>>> +
>>> +    if ( argc )
>>> +    {
>>> +        show_help();
>>> +        return -1;
>>> +    }
>>> +
>>> +    memset(build_id, 0, sizeof(*build_id));
>>> +
>>> +    if ( xc_version(xch, XENVER_build_id, &build_id) < 0 )
>>> +    {
>>> +        printf("Failed to get build_id: %d(%s)\n", errno, strerror(errno));
>>> +        return -1;
>>> +    }
>>> +
>>> +    printf("%s\n", build_id);
>>> +    return 0;
>>> +}
>>> +
>>>  struct {
>>>      const char *name;
>>>      int (*function)(int argc, char *argv[]);
>>>  } main_options[] = {
>>>      { "help", help_func },
>>>      { "list", list_func },
>>> +    { "build-id", build_id_func },
>>>      { "upload", upload_func },
>>>  };
>>>  
>>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>>> index 6a3196a..e9d41b6 100644
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -357,6 +357,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>          if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
>>>              return -EFAULT;
>>>          return 0;
>>> +
>>> +    case XENVER_build_id:
>>> +    {
>>> +        xen_build_id_t build_id;
>>> +
>>> +        memset(build_id, 0, sizeof(build_id));
>>> +        safe_strcpy(build_id, xen_build_id());
>> You seem to want to store and transfer the build_id as a string.  Any
>> reason why we don't directly expose the build_id embedded by the linker
>> in binary format?
>>
>>> +        if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
>>> +            return -EFAULT;
>>> +        return 0;
>>> +    }
>> We should not expose the build_id to normal guests, but only to Dom0.
>>
>> A build_id uniquely identifies a specific build and I don't see how that
>> information would be required from DomU.  It might actually help an
>> attacker to build his return-oriented programming exploit against a
>> specific build.
>>
>> The normal version numbers should be enough to know about capabilities
>> and API.
> 
> It will need its own XSM hook, but need not be strictly limited to just
> dom0.
> 
>>
>>>      }
>>>  
>>>      return -ENOSYS;
>>> diff --git a/xen/common/version.c b/xen/common/version.c
>>> index b152e27..5c3dbb0 100644
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -55,3 +55,8 @@ const char *xen_banner(void)
>>>  {
>>>      return XEN_BANNER;
>>>  }
>>> +
>>> +const char *xen_build_id(void)
>>> +{
>>> +    return XEN_BUILD_ID;
>>> +}
>>> diff --git a/xen/include/public/version.h b/xen/include/public/version.h
>>> index 44f26b0..c863393 100644
>>> --- a/xen/include/public/version.h
>>> +++ b/xen/include/public/version.h
>>> @@ -83,6 +83,10 @@ typedef struct xen_feature_info xen_feature_info_t;
>>>  #define XENVER_commandline 9
>>>  typedef char xen_commandline_t[1024];
>>>  
>>> +#define XENVER_build_id 10
>>> +typedef char xen_build_id_t[1024];
>>> +#define XEN_BUILD_ID_LEN (sizeof(xen_build_id_t))
>>> +
>>>  #endif /* __XEN_PUBLIC_VERSION_H__ */
>>>  
>>>  /*
>>> diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
>>> index 440ecb2..939685e 100644
>>> --- a/xen/include/xen/compile.h.in
>>> +++ b/xen/include/xen/compile.h.in
>>> @@ -10,4 +10,5 @@
>>>  #define XEN_EXTRAVERSION	"@@extraversion@@"
>>>  
>>>  #define XEN_CHANGESET		"@@changeset@@"
>>> +#define XEN_BUILD_ID        "@@changeset@@"
>> That leads to a chicken and egg problem when embedding a real build_id.
>>  Some linker script magic seems to be required.  I will try to refine
>> the patch.
> 
> So funnily enough, I tried experimenting with this and it is fairly easy
> to get the basics done.
> 
> Further TODO which I havn't done yet is make the --build-id optional on
> finding a compatible `ld`, and some symbol magic to directly locate
> .note.gnu.build-id
> 
> However, this in addition to some of Konrad's original patch is a good
> start.
> 
> ~Andrew
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 5f24951..10938b2 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -112,7 +112,7 @@ $(TARGET)-syms: prelink.o xen.lds
> $(BASEDIR)/common/symbols-dummy.o
>             $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
>         $(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
>         $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> -       $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> +       $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id \
>             $(@D)/.$(@F).1.o -o $@
>         rm -f $(@D)/.$(@F).[0-9]*
>  
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 6553cff..46e6546 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -68,6 +68,13 @@ SECTIONS
>    } :text
>  
>    . = ALIGN(SMP_CACHE_BYTES);
> +  .notes : {
> +       __start_notes = .;
> +       *(.note.*)
> +       __end_notes = .;
> +  } :text
> +
> +  . = ALIGN(SMP_CACHE_BYTES);
>    .data.read_mostly : {
>         /* Exception table */
>         __start___ex_table = .;

And here is my version, also on-top of Konrad's series:

----------------------------------------------------------------------

[PATCH] xsplice: Use ld-embedded build-ids

Todo:
  * Should be moved to sysctl to only allow Dom0 access
  * Maybe convert to binary transport to userland instead of printable form

* use ld to actually embed the build ID
* convert to textual representation in hypervisor and report in
  printable form

Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
---
 xen/arch/x86/Makefile        |  4 ++--
 xen/arch/x86/xen.lds.S       |  5 +++++
 xen/common/kernel.c          | 33 +++++++++++++++++++++++++++++----
 xen/common/version.c         |  5 -----
 xen/include/xen/compile.h.in |  1 -
 5 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5f24951..f724bd8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -108,11 +108,11 @@ $(TARGET)-syms: prelink.o xen.lds
$(BASEDIR)/common/symbols-dummy.o
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
 	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
 	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \
 	    $(@D)/.$(@F).1.o -o $@
 	rm -f $(@D)/.$(@F).[0-9]*

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..2176782 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -67,6 +67,11 @@ SECTIONS
        *(.rodata.*)
   } :text

+  .note.gnu.build-id : {
+      __note_gnu_build_id_start = .;
+      *(.note.gnu.build-id)
+  } :text
+
   . = ALIGN(SMP_CACHE_BYTES);
   .data.read_mostly : {
        /* Exception table */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index e9d41b6..9814585 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -6,9 +6,11 @@

 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/elf.h>
 #include <xen/errno.h>
 #include <xen/version.h>
 #include <xen/sched.h>
+#include <xen/types.h>
 #include <xen/paging.h>
 #include <xen/nmi.h>
 #include <xen/guest_access.h>
@@ -227,6 +229,10 @@ void __init do_initcalls(void)
  * Simple hypercalls.
  */

+#define NT_GNU_BUILD_ID 3
+
+extern char * __note_gnu_build_id_start;  /* defined in linker script */
+
 DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)

     case XENVER_build_id:
     {
-        xen_build_id_t build_id;
+        xen_build_id_t ascii_id;
+        Elf_Note * n = (Elf_Note *)&__note_gnu_build_id_start;
+        char * binary_id;
+        int i;
+
+        memset(ascii_id, 0, sizeof(ascii_id));
+
+        /* check if we really have a build-id */
+        if ( NT_GNU_BUILD_ID != n->type )
+            return 0;
+
+        /* sanity check, name should be "GNU" for ld-generated build-id */
+        if ( 0 != strncmp(ELFNOTE_NAME(n), "GNU", n->namesz))
+            return 0;
+
+        binary_id = (char *)ELFNOTE_DESC(n);
+
+        /* convert to printable format */
+        for (i = 0; i < n->descsz && (i + 1) * 2 <
sizeof(xen_build_id_t); i++)
+        {
+            snprintf(&ascii_id[i * 2], 3, "%02hhx", binary_id[i]);
+        }

-        memset(build_id, 0, sizeof(build_id));
-        safe_strcpy(build_id, xen_build_id());
-        if ( copy_to_guest(arg, build_id, ARRAY_SIZE(build_id)) )
+        if ( copy_to_guest(arg, ascii_id, ARRAY_SIZE(ascii_id)) )
             return -EFAULT;
         return 0;
     }
diff --git a/xen/common/version.c b/xen/common/version.c
index 5c3dbb0..b152e27 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -55,8 +55,3 @@ const char *xen_banner(void)
 {
     return XEN_BANNER;
 }
-
-const char *xen_build_id(void)
-{
-    return XEN_BUILD_ID;
-}
diff --git a/xen/include/xen/compile.h.in b/xen/include/xen/compile.h.in
index 939685e..440ecb2 100644
--- a/xen/include/xen/compile.h.in
+++ b/xen/include/xen/compile.h.in
@@ -10,5 +10,4 @@
 #define XEN_EXTRAVERSION	"@@extraversion@@"

 #define XEN_CHANGESET		"@@changeset@@"
-#define XEN_BUILD_ID        "@@changeset@@"
 #define XEN_BANNER		\
-- 
2.5.0

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

(no subject)

[Martin Pohlack]

Sending again without MUA-mangled patch.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

(No subject)

[Edward Vidal]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

Hello All,Thanks to Ross Burton 
see the files https://github.com/develone/raspberrypi2_yocto.git

in recipe_myhdl folder.

Now have an rpm to install myhdl on a yocto build.
let me know if you have any questions.
  Edward Vidal Jr.
e-mail develone@sbcglobal.net
915-595-1613

[-- Attachment #2: Type: text/html, Size: 1300 bytes --]

(no subject)

[Mr. Vincent Cheng]

-- 
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country. Reply to
address: vincentche3434@gmail.com and I will let you know what is
required of you.

Best Regards,
Mr. Vincent Cheng
Your Brother

(No subject)

[Alvaro Martinez Tovar]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

Dear all,
I am working with Qt5.5.0 and QtCreator 3.4.2 open source. On the hardware side I work with a i.MX6 sabre platform for smart devices.
As a first aproach, after having created the image fsl-image-qt5 correctly (I think), I would like to run different examples by cross compiling and executing them on the SABRE platform. On my PC I run Ubuntu 14.04 LTS.
When I compile all the examples to run on the Ubuntu PC, they all work properly (bluetooth, qtquick ...)However, when I try to cross-compile and run them on the SABRE platform, I get execution errors with some of them.
However, when I try to run a bluetooth scanner, I get:./btscanner: error while loading shared libraries: libQt5Bluetooth.so.5: cannot open shared object file: No such file or directory 

And when I try to run a Qtquick example (dasboard), I get:Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable.Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable.QQmlApplicationEngine failed to load componentqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installedqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installedqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed Can you please give me any advice on what to do? I am stuck at this point.Which are the packages I should add to IMAGE_INSTALL_append??
 thank you in advance!Regards

[-- Attachment #2: Type: text/html, Size: 5155 bytes --]

(No subject)

[Felipe Tonello]

Hi Alvaro,

On Tue, Jul 14, 2015 at 4:24 PM, Alvaro Martinez Tovar
<alvaromartineztovar@yahoo.es> wrote:
> Dear all,
>
> I am working with Qt5.5.0 and QtCreator 3.4.2 open source. On the hardware
> side I work with a i.MX6 sabre platform for smart devices.
>
> As a first aproach, after having created the image fsl-image-qt5 correctly
> (I think), I would like to run different examples by cross compiling and
> executing them on the SABRE platform. On my PC I run Ubuntu 14.04 LTS.

Have you been able to create the SDK for that image?

>
> When I compile all the examples to run on the Ubuntu PC, they all work
> properly (bluetooth, qtquick ...)
> However, when I try to cross-compile and run them on the SABRE platform, I
> get execution errors with some of them.

How do you compile them? Using bitbake?

>
> However, when I try to run a bluetooth scanner, I get:
> ./btscanner: error while loading shared libraries: libQt5Bluetooth.so.5:
> cannot open shared object file: No such file or directory
>
> And when I try to run a Qtquick example (dasboard), I get:
> Qt Warning: Could not find a location of the system's Compose files.
> Consider setting the QTCOMPOSE environment variable.
> Qt Warning: Could not find a location of the system's Compose files.
> Consider setting the QTCOMPOSE environment variable.
> QQmlApplicationEngine failed to load component
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
>
> Can you please give me any advice on what to do? I am stuck at this point.
> Which are the packages I should add to IMAGE_INSTALL_append??

Well, It looks like some libraries and Qt5 modules are missing. You
can add packages using IMAGE_INSTALL += "package_name" in your
local.conf file and build the whole image. This will install all new
packages and its dependencies to the image.

If you really want to build your own image, the best practice is to
have a bbappend to that image or have your own image recipe in your
own layer.

Read this: http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-IMAGE_INSTALL

Felipe

(No subject)

[Alvaro Martinez Tovar]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

Dear all,I am working with Qt5.5.0 and QtCreator 3.4.2 open source. On the hardware side I work with a i.MX6 sabre platform for smart devices.As a first aproach, after having created the image fsl-image-qt5 correctly (I think), I would like to run different examples by cross compiling and executing them on the SABRE platform. On my PC I run Ubuntu 14.04 LTS.When I compile all the examples to run on the Ubuntu PC, they all work properly (bluetooth, qtquick ...)However, when I try to cross-compile and run them on the SABRE platform, I get execution errors with some of them.When I try to run a bluetooth scanner, I get:./btscanner: error while loading shared libraries: libQt5Bluetooth.so.5: cannot open shared object file: No such file or directory When I try to run a Qtquick example (dasboard), I get:Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable.Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable.QQmlApplicationEngine failed to load componentqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installedqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installedqrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installedqrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installedqrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed Can you please give me any advice on what to do? I am stuck at this point. thank you in advance!Regards

[-- Attachment #2: Type: text/html, Size: 3617 bytes --]

(No subject)

[Khem Raj]

On Mon, Jul 13, 2015 at 10:56 PM, Alvaro Martinez Tovar
<alvaromartineztovar@yahoo.es> wrote:
> Dear all,
> I am working with Qt5.5.0 and QtCreator 3.4.2 open source. On the hardware
> side I work with a i.MX6 sabre platform for smart devices.
> As a first aproach, after having created the image fsl-image-qt5 correctly
> (I think), I would like to run different examples by cross compiling and
> executing them on the SABRE platform. On my PC I run Ubuntu 14.04 LTS.
> When I compile all the examples to run on the Ubuntu PC, they all work
> properly (bluetooth, qtquick ...)
> However, when I try to cross-compile and run them on the SABRE platform, I
> get execution errors with some of them.
> When I try to run a bluetooth scanner, I get:
> ./btscanner: error while loading shared libraries: libQt5Bluetooth.so.5:
> cannot open shared object file: No such file or directory
> When I try to run a Qtquick example (dasboard), I get:
> Qt Warning: Could not find a location of the system's Compose files.
> Consider setting the QTCOMPOSE environment variable.
> Qt Warning: Could not find a location of the system's Compose files.
> Consider setting the QTCOMPOSE environment variable.
> QQmlApplicationEngine failed to load component
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
> qrc:/qml/dashboard.qml:45 module "QtQuick.Extras" is not installed
> qrc:/qml/dashboard.qml:43 module "QtQuick.Controls" is not installed
> qrc:/qml/dashboard.qml:44 module "QtQuick.Controls.Styles" is not installed
>
> Can you please give me any advice on what to do? I am stuck at this point.
>

you should use same version of qt that you are getting for meta-qt5
and 5.5 is not yet in there
the latest on master is 5.4

> thank you in advance!
> Regards
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

(no subject)

[E.Richiardone]

Hi all,

I am building a solution on a Debian platform that should playback an
audio recorded in G711 ulaw format. I am using Alsa to interfacing
with the audio device, it's a snd_cs5535audio. Below there is a
fragment of the code I am using.
I don't have any problems accessing the device using the "plughw:0,0"
device, where I can correctly set directly the ulaw 8000Hz format.

Now I was needing an multiband equalizer, and found that Alsa supports
some ladspa plugins, I choosed mbeq.
But if I use a device name different from "plughw:0,0", as for example
the "default" device or "plug", the final function snd_pcm_hw_params()
returns an error:
 "cannot set hw params (Invalid argument)"

I was thinking that maybe my problem is that only the "plughw" device
accept directly the G711 ulaw format.
Anyone can confirm my thought?
There is a way to access a device directly in G711 ulaw format that
can be equalized with a plugin?


My initialisation source code:

----------8<----------
// #define AUDIODEV "plughw:0,0"
#define AUDIODEV "default"

[...]

  pcm_name = strdup(AUDIODEV);

  if((err = snd_pcm_open(&playback_handle, pcm_name, stream, 0)) < 0){
    printf(" E> cannot open audio device %s (%s)\n", pcm_name,
snd_strerror(err));
    closeall(1);
  }
  if((err = snd_pcm_hw_params_any(playback_handle, hw_params)) < 0){
    printf(" E> cannot initialize hardware parameter structure
(%s)\n", snd_strerror(err));
    closeall(1);
  }
  if((err = snd_pcm_hw_params_set_access(playback_handle, hw_params,
SND_PCM_ACCESS_RW_INTERLEAVED)) < 0){
    printf(" E> cannot set access type (%s)\n", snd_strerror(err));
    closeall(1);
  }
  err = snd_pcm_hw_params_set_format(playback_handle, hw_params,
SND_PCM_FORMAT_MU_LAW);
  if(err < 0){
    printf(" E> cannot set ulaw format (%s)\n", snd_strerror(err));
    closeall(1);
  }
  val = 8000;
  if((err = snd_pcm_hw_params_set_rate_near(playback_handle,
hw_params, &val, 0)) < 0){
    printf(" E> cannot set rate (%s)\n", snd_strerror(err));
    closeall(1);
  }

[...]

  if((err = snd_pcm_hw_params(playback_handle, hw_params)) < 0){
    printf(" E> cannot set hw params (%s)\n", snd_strerror(err));
    closeall(1);
  }
---------->8----------

My /etc/asound.conf :

----------8<----------
defaults.ctl.card 0
defaults.ctl.device 0
defaults.pcm.card 0
defaults.pcm.device 0

ctl.equal {
   type equal;
   library "/usr/lib/ladspa/mbeq_1197.so";
   module "mbeq";
   controls "/usr/local/webif/.alsaequal.bin";
}

pcm.plugequal {
   type equal;
   slave.pcm "plughw:0,0";
   library "/usr/lib/ladspa/mbeq_1197.so";
   module "mbeq";
   controls "/usr/local/webif/.alsaequal.bin";
}

pcm.!default {
   type plug;
   slave.pcm plugequal;
   hint {
      show on
      description "Default equalized"
   }
}

pcm.dsp0 {
    type plug
    slave.pcm plugequal;
}
---------->8----------

Many thanks
Best Regards
--
E.Richiardone

[PATCH 2/2] drm/i915: Rework order of operations in {__intel, logical}_ring_prepare()

[Dave Gordon]

The original idea of preallocating the OLR was implemented in

> 9d773091 drm/i915: Preallocate next seqno before touching the ring

and the sequence of operations was to allocate the OLR, then wrap past
the end of the ring if necessary, then wait for space if necessary.
But subsequently intel_ring_begin() was refactored, in

> 304d695 drm/i915: Flush outstanding requests before allocating new seqno

to ensure that pending work that might need to be flushed used the old
and not the newly-allocated request. This changed the sequence to wrap
and/or wait, then allocate, although the comment still said
	/* Preallocate the olr before touching the ring */
which was no longer true as intel_wrap_ring_buffer() touches the ring.

However, with the introduction of dynamic pinning, in

> 7ba717c drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demand

came the possibility that the ringbuffer might not be pinned to the GTT
or mapped into CPU address space when intel_ring_begin() is called. It
gets pinned when the request is allocated, so it's now important that
this comes *before* anything that can write into the ringbuffer, in this
case intel_wrap_ring_buffer(), as this will fault if (a) the ringbuffer
happens not to be mapped, and (b) tail happens to be sufficiently close
to the end of the ring to trigger wrapping.

So the correct order is neither the original allocate-wait-pad-wait, nor
the subsequent wait-pad-wait-allocate, but wait-allocate-pad, avoiding
both the problems described in the two commits mentioned above.

As a bonus, we eliminate the special case where a single ring_begin()
might end up waiting twice (once to be able to wrap, and then again
if that still hadn't actually freed enough space for the request). We
just precalculate the total amount of space we'll need *including* any
for padding the end of the ring and wait for that much in one go :)

In the time since this code was written, it has all been cloned from
the original ringbuffer model to become the execbuffer code, in

> 82e104c drm/i915/bdw: New logical ring submission mechanism

So now we have to fix it in both paths ...

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c        |   64 +++++++++++++++----------------
 drivers/gpu/drm/i915/intel_ringbuffer.c |   63 +++++++++++++++---------------
 2 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 454e836..3ef5fb6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -740,39 +740,22 @@ intel_logical_ring_advance_and_submit(struct intel_ringbuffer *ringbuf,
 	execlists_context_queue(ring, ctx, ringbuf->tail, request);
 }
 
-static int logical_ring_wrap_buffer(struct intel_ringbuffer *ringbuf,
-				    struct intel_context *ctx)
-{
-	uint32_t __iomem *virt;
-	int rem = ringbuf->size - ringbuf->tail;
-
-	if (ringbuf->space < rem) {
-		int ret = logical_ring_wait_for_space(ringbuf, ctx, rem);
-
-		if (ret)
-			return ret;
-	}
-
-	virt = ringbuf->virtual_start + ringbuf->tail;
-	rem /= 4;
-	while (rem--)
-		iowrite32(MI_NOOP, virt++);
-
-	ringbuf->tail = 0;
-	intel_ring_update_space(ringbuf);
-
-	return 0;
-}
-
 static int logical_ring_prepare(struct intel_ringbuffer *ringbuf,
 				struct intel_context *ctx, int bytes)
 {
+	int fill = 0;
 	int ret;
 
+	/*
+	 * If the request will not fit between 'tail' and the effective
+	 * size of the ringbuffer, then we need to pad the end of the
+	 * ringbuffer with NOOPs, then start the request at the top of
+	 * the ring. This increases the total size that we need to check
+	 * for by however much is left at the end of the ring ...
+	 */
 	if (unlikely(ringbuf->tail + bytes > ringbuf->effective_size)) {
-		ret = logical_ring_wrap_buffer(ringbuf, ctx);
-		if (unlikely(ret))
-			return ret;
+		fill = ringbuf->size - ringbuf->tail;
+		bytes += fill;
 	}
 
 	if (unlikely(ringbuf->space < bytes)) {
@@ -781,6 +764,28 @@ static int logical_ring_prepare(struct intel_ringbuffer *ringbuf,
 			return ret;
 	}
 
+	/* Ensure we have a request before touching the ring */
+	if (!ringbuf->ring->outstanding_lazy_request) {
+		ret = i915_gem_request_alloc(ringbuf->ring, ctx);
+		if (ret)
+			return ret;
+	}
+
+	if (unlikely(fill)) {
+		uint32_t __iomem *virt = ringbuf->virtual_start + ringbuf->tail;
+
+		/* tail should not have moved */
+		if (WARN_ON(fill != ringbuf->size - ringbuf->tail))
+			fill = ringbuf->size - ringbuf->tail;
+
+		do
+			iowrite32(MI_NOOP, virt++);
+		while ((fill -= 4) > 0);
+
+		ringbuf->tail = 0;
+		intel_ring_update_space(ringbuf);
+	}
+
 	return 0;
 }
 
@@ -814,11 +819,6 @@ static int intel_logical_ring_begin(struct intel_ringbuffer *ringbuf,
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ctx);
-	if (ret)
-		return ret;
-
 	ringbuf->space -= num_dwords * sizeof(uint32_t);
 	return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a3406b2..4c0bc29 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2137,29 +2137,6 @@ static int ring_wait_for_space(struct intel_engine_cs *ring, int n)
 	return 0;
 }
 
-static int intel_wrap_ring_buffer(struct intel_engine_cs *ring)
-{
-	uint32_t __iomem *virt;
-	struct intel_ringbuffer *ringbuf = ring->buffer;
-	int rem = ringbuf->size - ringbuf->tail;
-
-	if (ringbuf->space < rem) {
-		int ret = ring_wait_for_space(ring, rem);
-		if (ret)
-			return ret;
-	}
-
-	virt = ringbuf->virtual_start + ringbuf->tail;
-	rem /= 4;
-	while (rem--)
-		iowrite32(MI_NOOP, virt++);
-
-	ringbuf->tail = 0;
-	intel_ring_update_space(ringbuf);
-
-	return 0;
-}
-
 int intel_ring_idle(struct intel_engine_cs *ring)
 {
 	struct drm_i915_gem_request *req;
@@ -2197,12 +2174,19 @@ static int __intel_ring_prepare(struct intel_engine_cs *ring,
 				int bytes)
 {
 	struct intel_ringbuffer *ringbuf = ring->buffer;
+	int fill = 0;
 	int ret;
 
+	/*
+	 * If the request will not fit between 'tail' and the effective
+	 * size of the ringbuffer, then we need to pad the end of the
+	 * ringbuffer with NOOPs, then start the request at the top of
+	 * the ring. This increases the total size that we need to check
+	 * for by however much is left at the end of the ring ...
+	 */
 	if (unlikely(ringbuf->tail + bytes > ringbuf->effective_size)) {
-		ret = intel_wrap_ring_buffer(ring);
-		if (unlikely(ret))
-			return ret;
+		fill = ringbuf->size - ringbuf->tail;
+		bytes += fill;
 	}
 
 	if (unlikely(ringbuf->space < bytes)) {
@@ -2211,6 +2195,28 @@ static int __intel_ring_prepare(struct intel_engine_cs *ring,
 			return ret;
 	}
 
+	/* Ensure we have a request before touching the ring */
+	if (!ringbuf->ring->outstanding_lazy_request) {
+		ret = i915_gem_request_alloc(ringbuf->ring, ctx);
+		if (ret)
+			return ret;
+	}
+
+	if (unlikely(fill)) {
+		uint32_t __iomem *virt = ringbuf->virtual_start + ringbuf->tail;
+
+		/* tail should not have moved */
+		if (WARN_ON(fill != ringbuf->size - ringbuf->tail))
+			fill = ringbuf->size - ringbuf->tail;
+
+		do
+			iowrite32(MI_NOOP, virt++);
+		while ((fill -= 4) > 0);
+
+		ringbuf->tail = 0;
+		intel_ring_update_space(ringbuf);
+	}
+
 	return 0;
 }
 
@@ -2229,11 +2235,6 @@ int intel_ring_begin(struct intel_engine_cs *ring,
 	if (ret)
 		return ret;
 
-	/* Preallocate the olr before touching the ring */
-	ret = i915_gem_request_alloc(ring, ring->default_context);
-	if (ret)
-		return ret;
-
 	ring->buffer->space -= num_dwords * sizeof(uint32_t);
 	return 0;
 }
-- 
1.7.9.5

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] Resolve issues with ringbuffer space management

[Dave Gordon]

Updates and supersedes the referenced patch,
	"Reinstate order of operations in {intel,logical}_ring_begin()"

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[Dave Gordon]

Updated version split into two. The first tidies up the _ring_prepare()
functions and removes the corner case where we might have had to wait
twice; the second is a temporary workaround to solve a kernel OOPS that
can occur if logical_ring_begin is called while the ringbuffer is not
mapped because there's no current request.

The latter will be superseded by the Anti-OLR patch series currently
in review. But this helps with GuC submission, which is better than
the execlist path at exposing the problematic case :(

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Daniel Vetter]

On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote:
> Updated version split into two. The first tidies up the _ring_prepare()
> functions and removes the corner case where we might have had to wait
> twice; the second is a temporary workaround to solve a kernel OOPS that
> can occur if logical_ring_begin is called while the ringbuffer is not
> mapped because there's no current request.
> 
> The latter will be superseded by the Anti-OLR patch series currently
> in review. But this helps with GuC submission, which is better than
> the execlist path at exposing the problematic case :(

Maintainer broken record: Lack of changelog makes it hard to figure out
what changed and which patches are the latest version. Even more so when
trying to catch up from vacation ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Jani Nikula]

On Wed, 17 Jun 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote:
>> Updated version split into two. The first tidies up the _ring_prepare()
>> functions and removes the corner case where we might have had to wait
>> twice; the second is a temporary workaround to solve a kernel OOPS that
>> can occur if logical_ring_begin is called while the ringbuffer is not
>> mapped because there's no current request.
>> 
>> The latter will be superseded by the Anti-OLR patch series currently
>> in review. But this helps with GuC submission, which is better than
>> the execlist path at exposing the problematic case :(
>
> Maintainer broken record: Lack of changelog makes it hard to figure out
> what changed and which patches are the latest version. Even more so when
> trying to catch up from vacation ...

Is it time we adopted Greg's <formletter> approach with copy-pasted
snippets from [1]...? See [2] for an example.

BR,
Jani.


[1] https://github.com/gregkh/gregkh-linux/blob/master/forms/patch_bot
[2] http://mid.gmane.org/20150612153842.GA12274@kroah.com

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Dave Gordon]

On 17/06/15 12:04, Daniel Vetter wrote:
> On Fri, Jun 12, 2015 at 09:25:36PM +0100, Dave Gordon wrote:
>> Updated version split into two. The first tidies up the _ring_prepare()
>> functions and removes the corner case where we might have had to wait
>> twice; the second is a temporary workaround to solve a kernel OOPS that
>> can occur if logical_ring_begin is called while the ringbuffer is not
>> mapped because there's no current request.
>>
>> The latter will be superseded by the Anti-OLR patch series currently
>> in review. But this helps with GuC submission, which is better than
>> the execlist path at exposing the problematic case :(
> 
> Maintainer broken record: Lack of changelog makes it hard to figure out
> what changed and which patches are the latest version. Even more so when
> trying to catch up from vacation ...
> -Daniel

Oops, that wasn't ready to go to the mailing list, that was just
supposed to go to myself so I could test whether the changes I'd made to
my git-format-patch and git-send-email settings worked! Hence lack of
subject line :(

And the settings obviously /weren't/ right; apart from it going to the
list, it didn't have the proper "Organisation" header, which was the
thing I was trying to update, as well as setting up proper definitions
so I could write "git send-email --identity=external --to=myself ..."

I think I got them all sorted out before sending the GuC submission
sequence though :)

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(No subject)

[Sharath M.]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]


HI,

We have interfaced ADV7180 decoder IC on IMX6Q sabrelite board through CSI0 interface and i am trying to include adv7180 driver provided with the LTIB. I have some questions related to this,
Ubuntu 10.04
Ltib 3.0.35
1) I am using mxc_v4l2_tvin.out unit test to capture video.
           When  I run the above test i get an error VIDIOC_DQBUF failed(Please check attached image file DQBUF_FAILED)
2)How to display the captured video on HDMI.


Regards,
Sharath

[-- Attachment #2: DQBUF_failed.png --]
[-- Type: image/png, Size: 139741 bytes --]

(No subject)

[Daiane Angolini]

On Wed, Jun 10, 2015 at 2:30 AM, Sharath M. <sharath@delopt.co.in> wrote:
>
> HI,
>
> We have interfaced ADV7180 decoder IC on IMX6Q sabrelite board through CSI0 interface and i am trying to include adv7180 driver provided with the LTIB. I have some questions related to this,
> Ubuntu 10.04
> Ltib 3.0.35

I would say, first thing is upgrading to 3.14.10 Release. If you need
links, please let me know

And, please, add a subject to your email, and next time you want to
share log, please use a paste tool like pastebin or similar.

Your question is a little bit off topic in this mailing list. Not that
we have a hard rule of topics... Well, if you really want to have an
answer to your exactly question, I suggest you to create a thread in
imx.community ;-)

Daiane


> 1) I am using mxc_v4l2_tvin.out unit test to capture video.
>            When  I run the above test i get an error VIDIOC_DQBUF failed(Please check attached image file DQBUF_FAILED)
> 2)How to display the captured video on HDMI.
>
>
> Regards,
> Sharath
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: (no subject)

[Simon Marchi]

Ah, this is because we need to add abi-debian-version.sh to the Ubuntu
package. I don't have time to do it right away, but perhaps Alexandre
(in CC) does :).

On 14 May 2015 at 15:33, Francis Rivest <francis.rivest13@gmail.com> wrote:
> Hello again,
>
> We tried to install the lttng-modules-dkms package using apt and the
> "ppa:lttng/ppa" repository, but we get the following information and error:
>
> Unpacking lttng-modules-dkms (from .../lttng-modules-dkms_2.6.x+
> stable+bzr727+pack22+201504291801~ubuntu12.04.1_all.deb) ...
> Setting up lttng-modules-dkms
> (2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1)
> ...
> Loading new
> lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1
> DKMS files...
> First Installation: checking all kernels...
> Building only for 3.13.0-32-generic
> Building initial module for 3.13.0-32-generic
> Error! Bad return status for module build on kernel: 3.13.0-32-generic
> (x86_64)
> Consult /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/make.log for more information.
>
>
> The contain of the make.log file is the following:
>
> DKMS make.log for
> lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1
> for kernel 3.13.0-32-generic (x86_64)
> Thu May 14 15:00:16 EDT 2015
> make: Entering directory `/usr/src/linux-headers-3.13.0-32-generic'
> /bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
> /bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-discard.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-overwrite.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-client.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-discard.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-overwrite.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-mmap-client.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-statedump-impl.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/wrapper/irqdesc.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/wrapper/fdtable.o
>    CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-events.o
> In file included from /var/lib/dkms/lttng-modules/2.
> 6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1/
> build/lttng-events.c:27:0:
> /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/wrapper/page_alloc.h:36:58: error:
> operator '+' has no right operand
> make[1]: *** [/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
> 201504291801~ubuntu12.04.1/build/lttng-events.o] Error 1
> make: *** [_module_/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+
> pack22+201504291801~ubuntu12.04.1/build] Error 2
> make: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'
>
>
> We know that "abi-debian-version.sh" isn't found and that might be the
> cause of our problem but it is supposed to be in the package...
>
> In addition we tried to include manually this file but it didn't work.
>
> Thanks again for helping me out.
>
> -Francis R
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>

Re: (no subject)

[Alexandre Montplaisir]

Hey,

Ok, after some investigation, I found the problem.

We specify "*" in the .install file, so I was wondering why that script 
was not being installed. Turns out that it gets ignored because it 
contains "debian" in its name. I assume the package building scripts 
want to ignore any debian/ folder that may be present in the original 
source. To do this, they probably use an unbounded regex, which also 
ignores anything that contains "debian". Oops!

If we rename that script to abi-version.sh for instance, both the file 
name and in the Makefile, then it installs fine. So I think the easiest 
is just to rename the script (either with a package patch, or upstream 
if they want to change it).

I get another compilation error on Vivid's kernel though, I'll look into 
that next.

Cheers,
Alexandre



On 2015-05-14 05:14 PM, Simon Marchi wrote:
> Ah, this is because we need to add abi-debian-version.sh to the Ubuntu
> package. I don't have time to do it right away, but perhaps Alexandre
> (in CC) does :).
>
> On 14 May 2015 at 15:33, Francis Rivest <francis.rivest13@gmail.com> wrote:
>> Hello again,
>>
>> We tried to install the lttng-modules-dkms package using apt and the
>> "ppa:lttng/ppa" repository, but we get the following information and error:
>>
>> Unpacking lttng-modules-dkms (from .../lttng-modules-dkms_2.6.x+
>> stable+bzr727+pack22+201504291801~ubuntu12.04.1_all.deb) ...
>> Setting up lttng-modules-dkms
>> (2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1)
>> ...
>> Loading new
>> lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1
>> DKMS files...
>> First Installation: checking all kernels...
>> Building only for 3.13.0-32-generic
>> Building initial module for 3.13.0-32-generic
>> Error! Bad return status for module build on kernel: 3.13.0-32-generic
>> (x86_64)
>> Consult /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/make.log for more information.
>>
>>
>> The contain of the make.log file is the following:
>>
>> DKMS make.log for
>> lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1
>> for kernel 3.13.0-32-generic (x86_64)
>> Thu May 14 15:00:16 EDT 2015
>> make: Entering directory `/usr/src/linux-headers-3.13.0-32-generic'
>> /bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
>> /bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-discard.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-overwrite.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-client.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-discard.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-overwrite.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-mmap-client.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-statedump-impl.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/wrapper/irqdesc.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/wrapper/fdtable.o
>>     CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-events.o
>> In file included from /var/lib/dkms/lttng-modules/2.
>> 6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1/
>> build/lttng-events.c:27:0:
>> /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/wrapper/page_alloc.h:36:58: error:
>> operator '+' has no right operand
>> make[1]: *** [/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
>> 201504291801~ubuntu12.04.1/build/lttng-events.o] Error 1
>> make: *** [_module_/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+
>> pack22+201504291801~ubuntu12.04.1/build] Error 2
>> make: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'
>>
>>
>> We know that "abi-debian-version.sh" isn't found and that might be the
>> cause of our problem but it is supposed to be in the package...
>>
>> In addition we tried to include manually this file but it didn't work.
>>
>> Thanks again for helping me out.
>>
>> -Francis R
>>
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>

(no subject)

[Francis Rivest]

[-- Attachment #1.1: Type: text/plain, Size: 3510 bytes --]

Hello again,

We tried to install the lttng-modules-dkms package using apt and the
"ppa:lttng/ppa" repository, but we get the following information and error:

Unpacking lttng-modules-dkms (from .../lttng-modules-dkms_2.6.x+
stable+bzr727+pack22+201504291801~ubuntu12.04.1_all.deb) ...
Setting up lttng-modules-dkms
(2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1)
...
Loading new lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu
12.04.1
DKMS files...
First Installation: checking all kernels...
Building only for 3.13.0-32-generic
Building initial module for 3.13.0-32-generic
Error! Bad return status for module build on kernel: 3.13.0-32-generic
(x86_64)
Consult /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/make.log for more information.


The contain of the make.log file is the following:

DKMS make.log for
lttng-modules-2.6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1
for kernel 3.13.0-32-generic (x86_64)
Thu May 14 15:00:16 EDT 2015
make: Entering directory `/usr/src/linux-headers-3.13.0-32-generic'
/bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
/bin/sh: 1: /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/abi-debian-version.sh: not found
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-discard.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-overwrite.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-client.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-discard.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-client-mmap-overwrite.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-ring-buffer-metadata-mmap-client.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-statedump-impl.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/wrapper/irqdesc.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/wrapper/fdtable.o
   CC [M]  /var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-events.o
In file included from /var/lib/dkms/lttng-modules/2.
6.x+stable+bzr727+pack22+201504291801~ubuntu12.04.1/
build/lttng-events.c:27:0:
/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/wrapper/page_alloc.h:36:58: error:
operator '+' has no right operand
make[1]: *** [/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+pack22+
201504291801~ubuntu12.04.1/build/lttng-events.o] Error 1
make: *** [_module_/var/lib/dkms/lttng-modules/2.6.x+stable+bzr727+
pack22+201504291801~ubuntu12.04.1/build] Error 2
make: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'


We know that "abi-debian-version.sh" isn't found and that might be the
cause of our problem but it is supposed to be in the package...

In addition we tried to include manually this file but it didn't work.

Thanks again for helping me out.

-Francis R

[-- Attachment #1.2: Type: text/html, Size: 15447 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

(no subject)

[Mika Kahola]

This series is revised based on Jani's good comments.
In this series the patch which read out DP link training
parameters from VBT is discarded as based on the comments
that I received.

Files changed:
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(No subject)

[Rickard Bremer]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

Hello,

Been encountering a new error during the day. The exact same configure did build one time before, but on the second build it started to crash.

Best Regards
Rickard

-------------------------------
jenkins@yocto:~/workspace/thesis-build-yocto/build$ bitbake core-image-minimal
Loading cache: 100% |######################################################################| ETA:  00:00:00
Loaded 2134 entries from dependency cache.
Parsing recipes: 100% |####################################################################| Time: 00:00:00
Parsing of 1651 .bb files complete (1649 cached, 2 parsed). 2135 targets, 49 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION        = "1.24.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS        = "x86_64-poky-linux"
MACHINE           = "congatec-qa3-64"
DISTRO            = "poky"
DISTRO_VERSION    = "1.7.1"
TUNE_FEATURES     = "m64 corei7"
TARGET_FPU        = ""
meta
meta-yocto
meta-yocto-bsp    = "dizzy:6e9632e9798d78587c9317554c5547ab3b53837c"
meta-intel
meta-valleyisland
meta-tlk          = "dizzy:c90fb613745cb31694144f6d2c240b4dda32ee58"
meta-congatec-x86 = "dizzy:095f6b1340c57252bcb1a42ab352dc2b4886b36e"
meta-rb           = "dizzy:6e9632e9798d78587c9317554c5547ab3b53837c"
meta-oe
meta-python
meta-networking   = "master:bb177c85a25d2b75583abe218396520c375f8f18"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Index creation command '/var/lib/jenkins/workspace/thesis-build-yocto/build/tmp/sysroots/x86_64-linux/usr/bin/createrepo --update -q /var/lib/jenkins/workspace/thesis-build-yocto/build/tmp/deploy/rpm/corei7_64' failed with return code 137:
Killed

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/thesis-build-yocto/build/tmp/work/congatec_qa3_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.26390
ERROR: Task 7 (/var/lib/jenkins/workspace/thesis-build-yocto/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2453 tasks of which 2452 didn't need to be rerun and 1 failed.
No currently running tasks (1867 of 2455)

Summary: 1 task failed:
  /var/lib/jenkins/workspace/thesis-build-yocto/meta/recipes-core/images/core-image-minimal.bb, do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.



[-- Attachment #2: Type: text/html, Size: 3895 bytes --]

(No subject)

[Raghavendra Kakarla]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

Hi Yocto Team,


Now I am working on the yocto sdk generation.


I am generated the yocto SDK using the yocto sdk script "bitbake core-image-minimal -c populate_sdk" command. With this command I am able to generte the installation script file and .manifest file.


I run the installation script file. After running installation script file it propts that following message:


Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.



After this i run the ". /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got the correct path.


After this i built wrote a small example and try to build with the sdk generated toolchain by running following command:


mipsel-poky-linux-gcc test.c


but i got the following errors:

**************************************************************************************************************************************************

/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crt1.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crti.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtbegin.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtend.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status


***********************************************************************************************************************************************************

Please help me to resolving this issue.


Thanks in advance.


Cheers,


Raghavendra Kakarla.



[-- Attachment #2: Type: text/html, Size: 6053 bytes --]

(No subject)

[Debasmita Lohar]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hello,
My yocto version is: 3.10.11-yocto-standard. I was trying to install git
1.8.1.2. While making git it is showing the following error:
Writing MYMETA.yml
    GEN git-add--interactive
make[2]: *** No rule to make target `/usr/lib/perl/5.14.3/CORE/config.h',
needed by `perl.mak'.  Stop.
make[1]: *** [instlibdir] Error 2
make: *** [git-add--interactive] Error 2
I am unable to fix this. Any help regarding this will be highly appreciated.
Thank you.
Debasmita Lohar

[-- Attachment #2: Type: text/html, Size: 742 bytes --]

(no subject)

[Konrad Rzeszutek Wilk]

I am proposing to put this in the 'staging-4.5' tree but would
appreciate an English speaker to take a look and make sure it
sounds good.

Thank you.

(no subject)

[arivumani]

[-- Attachment #1.1: Type: text/plain, Size: 194 bytes --]

> Forwarded Message:
http://econnoisseur.com/Sebastian.php?arivumani_gmail_com


...

> 1/2/2015 9:29:54 AM, arivumani@gmail.com wrote:
>>>> Truth is what stands the test of experience.

[-- Attachment #2: Type: text/plain, Size: 441 bytes --]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

(no subject)

[Minalkumar Patel]

[-- Attachment #1.1: Type: text/plain, Size: 117 bytes --]

i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me

[-- Attachment #1.2: Type: text/html, Size: 359 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Ian Campbell]

On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote:
> i got daily patch emails from xen-devel but i don't need on this email
> address so how to deactivate it please tell me

Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel

Ian.

(No subject)

[Fabrício Lélis]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Hi,

I have this problem:

Assuming /home/fabricio/qemuarm-sato is an nfs rootfs
Error: conflicting FSTYPE types [/home/fabricio/qemuarm-sato] and nfs

Anybody can help me?

Thanks in advance!

-- 
Fabrício Gutemberg Lélis de Melo
Master in Computer Science at UFCG
http://fabriciolelis.googlepages.com/

[-- Attachment #2: Type: text/html, Size: 602 bytes --]

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.333788346-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:46:00 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 6/6] rte_sched: dont put tabs in log messages
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=rte-sched-no-tab.patch

syslog does not like tabs in log messages; tab gets translated to #011

Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>


--- a/lib/librte_sched/rte_sched.c	2014-12-08 09:37:08.741006405 -0800
+++ b/lib/librte_sched/rte_sched.c	2014-12-08 09:37:56.641264631 -0800
@@ -495,10 +495,10 @@ rte_sched_port_log_pipe_profile(struct r
 	struct rte_sched_pipe_profile *p = port->pipe_profiles + i;
 
 	RTE_LOG(INFO, SCHED, "Low level config for pipe profile %u:\n"
-		"\tToken bucket: period = %u, credits per period = %u, size = %u\n"
-		"\tTraffic classes: period = %u, credits per period = [%u, %u, %u, %u]\n"
-		"\tTraffic class 3 oversubscription: weight = %hhu\n"
-		"\tWRR cost: [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu]\n",
+		"    Token bucket: period = %u, credits per period = %u, size = %u\n"
+		"    Traffic classes: period = %u, credits per period = [%u, %u, %u, %u]\n"
+		"    Traffic class 3 oversubscription: weight = %hhu\n"
+		"    WRR cost: [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu], [%hhu, %hhu, %hhu, %hhu]\n",
 		i,
 
 		/* Token bucket */
@@ -716,9 +716,9 @@ rte_sched_port_log_subport_config(struct
 	struct rte_sched_subport *s = port->subport + i;
 
 	RTE_LOG(INFO, SCHED, "Low level config for subport %u:\n"
-		"\tToken bucket: period = %u, credits per period = %u, size = %u\n"
-		"\tTraffic classes: period = %u, credits per period = [%u, %u, %u, %u]\n"
-		"\tTraffic class 3 oversubscription: wm min = %u, wm max = %u\n",
+		"    Token bucket: period = %u, credits per period = %u, size = %u\n"
+		"    Traffic classes: period = %u, credits per period = [%u, %u, %u, %u]\n"
+		"    Traffic class 3 oversubscription: wm min = %u, wm max = %u\n",
 		i,
 
 		/* Token bucket */

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.282719331-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:59 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 5/6] rte_sched: dont clear statistics when read
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=qos-no-clear.patch

Make rte_sched statistics API work like the ethernet statistics API.
Don't auto-clear statistics when read.

Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>

--- a/lib/librte_sched/rte_sched.c	2014-12-08 09:29:49.014821607 -0800
+++ b/lib/librte_sched/rte_sched.c	2014-12-08 09:35:45.568568267 -0800
@@ -924,9 +924,8 @@ rte_sched_subport_read_stats(struct rte_
 	}
 	s = port->subport + subport_id;
 
-	/* Copy subport stats and clear */
-	memcpy(stats, &s->stats, sizeof(struct rte_sched_subport_stats));
-	memset(&s->stats, 0, sizeof(struct rte_sched_subport_stats));
+	/* Copy subport stats */
+	*stats = s->stats;
 
 	/* Subport TC ovesubscription status */
 	*tc_ov = s->tc_ov;
@@ -935,6 +934,21 @@ rte_sched_subport_read_stats(struct rte_
 }
 
 int
+rte_sched_subport_stats_reset(struct rte_sched_port *port,
+			      uint32_t subport_id)
+{
+	struct rte_sched_subport *s;
+
+	/* Check user parameters */
+	if (port == NULL || subport_id >= port->n_subports_per_port)
+		return -1;
+
+	s = port->subport + subport_id;
+	memset(&s->stats, 0, sizeof(struct rte_sched_subport_stats));
+	return 0;
+}
+
+int
 rte_sched_queue_read_stats(struct rte_sched_port *port,
 	uint32_t queue_id,
 	struct rte_sched_queue_stats *stats,
@@ -953,9 +967,8 @@ rte_sched_queue_read_stats(struct rte_sc
 	q = port->queue + queue_id;
 	qe = port->queue_extra + queue_id;
 
-	/* Copy queue stats and clear */
-	memcpy(stats, &qe->stats, sizeof(struct rte_sched_queue_stats));
-	memset(&qe->stats, 0, sizeof(struct rte_sched_queue_stats));
+	/* Copy queue stats */
+	*stats = qe->stats;
 
 	/* Queue length */
 	*qlen = q->qw - q->qr;
@@ -963,6 +976,21 @@ rte_sched_queue_read_stats(struct rte_sc
 	return 0;
 }
 
+int
+rte_sched_queue_stats_reset(struct rte_sched_port *port,
+			    uint32_t queue_id)
+{
+	struct rte_sched_queue_extra *qe;
+
+	/* Check user parameters */
+	if (port == NULL || queue_id >= rte_sched_port_queues_per_port(port))
+		return -1;
+
+	qe = port->queue_extra + queue_id;
+	memset(&qe->stats, 0, sizeof(struct rte_sched_queue_stats));
+	return 0;
+}
+
 static inline uint32_t
 rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
 {
--- a/lib/librte_sched/rte_sched.h	2014-12-08 09:29:49.014821607 -0800
+++ b/lib/librte_sched/rte_sched.h	2014-12-08 09:30:29.426977482 -0800
@@ -312,6 +312,21 @@ rte_sched_subport_read_stats(struct rte_
 	struct rte_sched_subport_stats *stats,
 	uint32_t *tc_ov);
 
+
+/**
+ * Hierarchical scheduler subport statistics reset
+ *
+ * @param port
+ *   Handle to port scheduler instance
+ * @param subport_id
+ *   Subport ID
+ * @return
+ *   0 upon success, error code otherwise
+ */
+int
+rte_sched_subport_stats_reset(struct rte_sched_port *port,
+			      uint32_t subport_id);
+
 /**
  * Hierarchical scheduler queue statistics read
  *
@@ -333,6 +348,20 @@ rte_sched_queue_read_stats(struct rte_sc
 	struct rte_sched_queue_stats *stats,
 	uint16_t *qlen);
 
+/**
+ * Hierarchical scheduler queue statistics reset
+ *
+ * @param port
+ *   Handle to port scheduler instance
+ * @param queue_id
+ *   Queue ID within port scheduler
+ * @return
+ *   0 upon success, error code otherwise
+ */
+int
+rte_sched_queue_stats_reset(struct rte_sched_port *port,
+			    uint32_t queue_id);
+
 /*
  * Run-time
  *

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.232055974-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:58 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 4/6] rte_sched: keep track of RED drops
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=red-stats.patch

Add new statistic to keep track of drops due to RED.

Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>

--- a/lib/librte_sched/rte_sched.c	2014-12-08 09:28:37.810590895 -0800
+++ b/lib/librte_sched/rte_sched.c	2014-12-08 09:28:37.810590895 -0800
@@ -1028,7 +1028,9 @@ rte_sched_port_update_subport_stats(stru
 }
 
 static inline void
-rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port, uint32_t qindex, struct rte_mbuf *pkt)
+rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
+					    uint32_t qindex,
+					    struct rte_mbuf *pkt, uint32_t red)
 {
 	struct rte_sched_subport *s = port->subport + (qindex / rte_sched_port_queues_per_subport(port));
 	uint32_t tc_index = (qindex >> 2) & 0x3;
@@ -1036,6 +1038,9 @@ rte_sched_port_update_subport_stats_on_d
 
 	s->stats.n_pkts_tc_dropped[tc_index] += 1;
 	s->stats.n_bytes_tc_dropped[tc_index] += pkt_len;
+#ifdef RTE_SCHED_RED
+	s->stats.n_pkts_red_dropped[tc_index] += red;
+#endif
 }
 
 static inline void
@@ -1206,12 +1211,20 @@ rte_sched_port_enqueue_qwa(struct rte_sc
 	qlen = q->qw - q->qr;
 
 	/* Drop the packet (and update drop stats) when queue is full */
-	if (unlikely(rte_sched_port_red_drop(port, pkt, qindex, qlen) || (qlen >= qsize))) {
+	if (unlikely(rte_sched_port_red_drop(port, pkt, qindex, qlen))) {
+#ifdef RTE_SCHED_COLLECT_STATS
+		rte_sched_port_update_subport_stats_on_drop(port, qindex, pkt, 1);
+		rte_sched_port_update_queue_stats_on_drop(port, qindex, pkt, 1);
+#endif
 		rte_pktmbuf_free(pkt);
+	}
+
+	if (qlen >= qsize) {
 #ifdef RTE_SCHED_COLLECT_STATS
-		rte_sched_port_update_subport_stats_on_drop(port, qindex, pkt);
-		rte_sched_port_update_queue_stats_on_drop(port, qindex, pkt);
+		rte_sched_port_update_subport_stats_on_drop(port, qindex, pkt, 0);
+		rte_sched_port_update_queue_stats_on_drop(port, qindex, pkt, 0);
 #endif
+		rte_pktmbuf_free(pkt);
 		return 0;
 	}
 
--- a/lib/librte_sched/rte_sched.h	2014-12-08 09:28:37.810590895 -0800
+++ b/lib/librte_sched/rte_sched.h	2014-12-08 09:29:11.402692026 -0800
@@ -140,6 +140,9 @@ struct rte_sched_subport_stats {
 	                                      subport for each traffic class*/
 	uint32_t n_bytes_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE]; /**< Number of bytes dropped by the current
                                           subport for each traffic class due to subport queues being full or congested */
+#ifdef RTE_SCHED_RED
+	uint32_t n_pkts_red_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE]; /**< Number of packets dropped by red */
+#endif
 };
 
 /** Pipe configuration parameters. The period and credits_per_period parameters are measured
@@ -168,7 +171,9 @@ struct rte_sched_queue_stats {
 	/* Packets */
 	uint32_t n_pkts;                 /**< Number of packets successfully written to current queue */
 	uint32_t n_pkts_dropped;         /**< Number of packets dropped due to current queue being full or congested */
-
+#ifdef RTE_SCHED_RED
+	uint32_t n_pkts_red_dropped;
+#endif
 	/* Bytes */
 	uint32_t n_bytes;                /**< Number of bytes successfully written to current queue */
 	uint32_t n_bytes_dropped;        /**< Number of bytes dropped due to current queue being full or congested */

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.181685914-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:57 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 3/6] qos: make RED optional
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=qos-optional-red.patch

We want to be able to build with RTE_SCHED_RED enabled but
allow disabling RED on a per-queue basis at runtime. This is
handled by allowing RED min/max to be zero to indicate that
RED is not being used.

Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>


--- a/lib/librte_sched/rte_sched.c	2014-12-08 09:28:20.782545529 -0800
+++ b/lib/librte_sched/rte_sched.c	2014-12-08 09:28:20.782545529 -0800
@@ -636,6 +636,12 @@ rte_sched_port_config(struct rte_sched_p
 		uint32_t j;
 
 		for (j = 0; j < e_RTE_METER_COLORS; j++) {
+			/* if min/max are both zero, then RED is disabled */
+			if ((params->red_params[i][j].min_th |
+			     params->red_params[i][j].max_th) == 0) {
+				continue;
+			}
+
 			if (rte_red_config_init(&port->red_config[i][j],
 				params->red_params[i][j].wq_log2,
 				params->red_params[i][j].min_th,
@@ -1069,6 +1075,9 @@ rte_sched_port_red_drop(struct rte_sched
 	color = rte_sched_port_pkt_read_color(pkt);
 	red_cfg = &port->red_config[tc_index][color];
 
+	if ( (red_cfg->min_th | red_cfg->max_th) == 0)
+		return 0;
+
 	qe = port->queue_extra + qindex;
 	red = &qe->red;
 

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.130426937-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:56 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 2/6] ixgbe: support X540 VF
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=ixgbe-x540-vf.patch

Add missing setup for X540 MAC type when setting up VF.
Additional check exists in Linux driver but not in DPDK.

Signed-off-yb: Bill Hong <bhong-43mecJUBy8ZBDgjK7y7TUQ@public.gmane.org> 
Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>

--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c	2014-12-08 09:26:18.150170081 -0800
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c	2014-12-08 09:26:18.150170081 -0800
@@ -1911,7 +1911,8 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_
 	/*
 	 * Modification to set VFTDT for virtual function if vf is detected
 	 */
-	if (hw->mac.type == ixgbe_mac_82599_vf)
+	if (hw->mac.type == ixgbe_mac_82599_vf ||
+	    hw->mac.type == ixgbe_mac_X540_vf)
 		txq->tdt_reg_addr = IXGBE_PCI_REG_ADDR(hw, IXGBE_VFTDT(queue_idx));
 	else
 		txq->tdt_reg_addr = IXGBE_PCI_REG_ADDR(hw, IXGBE_TDT(txq->reg_idx));
@@ -2198,7 +2199,8 @@ ixgbe_dev_rx_queue_setup(struct rte_eth_
 	/*
 	 * Modified to setup VFRDT for Virtual Function
 	 */
-	if (hw->mac.type == ixgbe_mac_82599_vf) {
+	if (hw->mac.type == ixgbe_mac_82599_vf ||
+	    hw->mac.type == ixgbe_mac_X540_vf) {
 		rxq->rdt_reg_addr =
 			IXGBE_PCI_REG_ADDR(hw, IXGBE_VFRDT(queue_idx));
 		rxq->rdh_reg_addr =

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174651.064719116-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:55 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
 Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Subject: [PATCH 1/6] rte_log: remove unnecessary stubs
References: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Disposition: inline; filename=rte-log-unneeded-funct.patch

The read/seek/close stub functions are unnecessary on the
log stream.  Per glibc fopencookie man page:

       cookie_read_function_t *read
              If *read is a null pointer, then reads from  the  custom  stream
              always return end of file.

       cookie_seek_function_t *seek
              If *seek is a null pointer, then it is not possible  to  perform
              seek operations on the stream.

       cookie_close_function_t *close
              If  *close is NULL, then no special action is performed when the
              stream is closed.

Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>


--- a/lib/librte_eal/linuxapp/eal/eal_log.c	2014-12-08 09:25:23.725812125 -0800
+++ b/lib/librte_eal/linuxapp/eal/eal_log.c	2014-12-08 09:25:23.661811703 -0800
@@ -83,33 +83,8 @@ console_log_write(__attribute__((unused)
 	return ret;
 }
 
-static ssize_t
-console_log_read(__attribute__((unused)) void *c,
-		 __attribute__((unused)) char *buf,
-		 __attribute__((unused)) size_t size)
-{
-	return 0;
-}
-
-static int
-console_log_seek(__attribute__((unused)) void *c,
-		 __attribute__((unused)) off64_t *offset,
-		 __attribute__((unused)) int whence)
-{
-	return -1;
-}
-
-static int
-console_log_close(__attribute__((unused)) void *c)
-{
-	return 0;
-}
-
 static cookie_io_functions_t console_log_func = {
-	.read  = console_log_read,
 	.write = console_log_write,
-	.seek  = console_log_seek,
-	.close = console_log_close
 };
 
 /*
@@ -150,33 +125,8 @@ early_log_write(__attribute__((unused))
 	return ret;
 }
 
-static ssize_t
-early_log_read(__attribute__((unused)) void *c,
-	       __attribute__((unused)) char *buf,
-	       __attribute__((unused)) size_t size)
-{
-	return 0;
-}
-
-static int
-early_log_seek(__attribute__((unused)) void *c,
-	       __attribute__((unused)) off64_t *offset,
-	       __attribute__((unused)) int whence)
-{
-	return -1;
-}
-
-static int
-early_log_close(__attribute__((unused)) void *c)
-{
-	return 0;
-}
-
 static cookie_io_functions_t early_log_func = {
-	.read  = early_log_read,
 	.write = early_log_write,
-	.seek  = early_log_seek,
-	.close = early_log_close
 };
 static FILE *early_log_stream;
 

(no subject)

[dev-bounces-VfR2kkLFssw]

>From stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org Mon Dec  8 09:46:51 2014
Message-Id: <20141208174554.889069531-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
User-Agent: quilt/0.63-1
Date: Mon, 08 Dec 2014 09:45:54 -0800
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: [PATCH 0/6] Misc patches for DPDK 1.8

Doing a scan of our current release product to see which
patches still need to be sent upstream.  These are the ones
that don't fit into specific niches.

(no subject)

[Angelo Dureghello]

unsubscribe alsa-devel angelo70@gmail.com

(No subject)

[Otavio Salvador]

Hello,

We have a bould failure in master-next branch. It includes extra
plugins on the default images and this allow for easy spot of missing
support (so the work to include them).

The current failure is:

directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
glTexImage2D in -lGLESv2... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
eglGetError in -lEGL... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking
EGL/fbdev_window.h usability... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking
EGL/fbdev_window.h presence... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
EGL/fbdev_window.h... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
bcm_host_init in -lbcm_host... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
WAYLAND_EGL... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for
gnustep-config... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | checking for GNUstep... no
directfb fsl-image-machine-test@imx6qsabresd (3/3) | configure: error:
Could not find the required EGL libraries
directfb fsl-image-machine-test@imx6qsabresd (3/3) | Configure failed.
The contents of all config.log files follows to aid debugging
directfb fsl-image-machine-test@imx6qsabresd (3/3) | ERROR: oe_runconf failed
directfb fsl-image-machine-test@imx6qsabresd (3/3) | WARNING: exit
code 1 from a shell command.
directfb fsl-image-machine-test@imx6qsabresd (3/3) | ERROR: Function
failed: do_configure (log file is located at
.../build-directfb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/temp/log.do_configure.19456)

So, to reproduce it:

Backend: directfb
Machine: imx6qsabresd
Recipe: gstreamer1.0-plugins-bad
Branch: master-next

Could someone take a look?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(no subject)

[saulery]

Hello,

A little patch for cleanup Groff warning of dmsetup.8.in. Can you integrate it
please? Thanks.

Regards,

-- 
St?phane Aulery

(no subject)

[Cleveland Finance]

-- 
Cleveland Finance Loan give out Guarantee Business Loans, Automobile
Purchase Loans, House Purchase Loans and other Personal Loans E.T.C We 
give
out long term loan from One to Fifty years maximum with 1% interest 
rate.

Mrs. Jean L. McFarland.

(no subject)

[Cleveland Finance]

-- 
Cleveland Finance Loan give out Guarantee Business Loans, Automobile
Purchase Loans, House Purchase Loans and other Personal Loans E.T.C We 
give
out long term loan from One to Fifty years maximum with 1% interest 
rate.

Mrs. Jean L. McFarland.

(no subject)

[asd]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

Hi
On NV_40 on driver is sent instructions from NVE0 series
not right
I inspected register  9012c with nvtools
and appear instructions to start unneeded engines 
NVE0_CHANNEL_IND_ENGINE_PPP 
NVE0_CHANNEL_IND_ENGINE_BSP 
NVE0_CHANNEL_IND_ENGINE_ENC  

I put one barrier but not start dri.

[-- Attachment #2: nouveau_abi.patch --]
[-- Type: text/x-patch, Size: 1519 bytes --]

Index: master_local/drivers/gpu/drm/nouveau/nouveau_abi16.c
===================================================================
--- master_local.orig/drivers/gpu/drm/nouveau/nouveau_abi16.c	2014-08-01 00:51:43.000000000 +0300
+++ master_local/drivers/gpu/drm/nouveau/nouveau_abi16.c	2014-09-13 17:16:19.881489054 +0300
@@ -252,7 +252,12 @@
 	device = nv_device(abi16->device);
 	imem   = nouveau_instmem(device);
 	pfb    = nouveau_fb(device);
-
+	printk(KERN_INFO "fb_ctxdma_handle %x\n", init->fb_ctxdma_handle);
+	printk(KERN_INFO "tt_ctxdma_handle %x\n", init->tt_ctxdma_handle);
+	printk(KERN_INFO "channel %x\n", init->channel);
+	printk(KERN_INFO "pushbuf_domains %x\n", init->pushbuf_domains);
+	printk(KERN_INFO "notifier_handle %x\n", init->notifier_handle);
+	printk(KERN_INFO "nr_subchan %x\n", init->nr_subchan);
 	/* hack to allow channel engine type specification on kepler */
 	if (device->card_type >= NV_E0) {
 		if (init->fb_ctxdma_handle != ~0)
@@ -265,6 +270,18 @@
 		if (init->fb_ctxdma_handle == NVE0_CHANNEL_IND_ENGINE_GR)
 			init->tt_ctxdma_handle = 1;
 	}
+	
+	if (device->card_type < NV_50) {
+		if (init->fb_ctxdma_handle = 0x00000008)
+			return nouveau_abi16_put(abi16, -EINVAL);
+
+		if (init->fb_ctxdma_handle = 0x00000004)
+			return nouveau_abi16_put(abi16, -EINVAL);
+
+		if (init->fb_ctxdma_handle = 0x00000040)
+			return nouveau_abi16_put(abi16, -EINVAL);
+	}
+		 
 
 	if (init->fb_ctxdma_handle == ~0 || init->tt_ctxdma_handle == ~0)
 		return nouveau_abi16_put(abi16, -EINVAL);

[-- Attachment #3: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: (no subject)

[Ilia Mirkin]

What problem are you trying to solve? Perhaps you can start by
describing the symptoms, providing logs, etc?

On Sat, Sep 13, 2014 at 11:24 AM, asd <asd-jrA/B3VWHiL2D7C+UIOg5A@public.gmane.org> wrote:
> Hi
> On NV_40 on driver is sent instructions from NVE0 series
> not right
> I inspected register  9012c with nvtools
> and appear instructions to start unneeded engines
> NVE0_CHANNEL_IND_ENGINE_PPP
> NVE0_CHANNEL_IND_ENGINE_BSP
> NVE0_CHANNEL_IND_ENGINE_ENC
>
> I put one barrier but not start dri.
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Re: (no subject)

[Martin Peres]

On 13/09/2014 17:32, Ilia Mirkin wrote:
> What problem are you trying to solve? Perhaps you can start by
> describing the symptoms, providing logs, etc?
Ilia,

That's the third time he contacts us to fix "bugs" without giving any 
details.
He then refuses to answer back.

He is either a troll or desperately trying to push patches with his name 
on it.
In any case, this patch is utterly wrong as the ifs are not even 
conditions, they
are assignments.

Asd, please stop wasting our time and try trolling somewhere else. If 
you are
not a troll, then answer us before sending another patch!

Martin

(no subject)

[US-ARMEE]

-- 
Hallo Freund
Ich bin Sgt Edward Hatton, ein amerikanischer Soldat, der derzeit in 
Kabul Afghanistan dienen. Sie vertraut werden können?; Kann ich $ 5,5 
Millionen Us-Dollar in Ihre Obhut anzuvertrauen? Ich wird dich dieser 
Transaktion mehr aufzuklären, sobald ich von Ihnen zu hören. Ich brauche 
nur eine vertrauenswürdige Person mir erhalten und diese Mittel zu 
sichern, bis ich durch meine Pflicht hier Kabul Afghanistan bin zu 
helfen.

(no subject)

[US-ARMEE]

-- 
Hallo Freund
Ich bin Sgt Edward Hatton, ein amerikanischer Soldat, der derzeit in 
Kabul Afghanistan dienen. Sie vertraut werden können?; Kann ich $ 5,5 
Millionen Us-Dollar in Ihre Obhut anzuvertrauen? Ich wird dich dieser 
Transaktion mehr aufzuklären, sobald ich von Ihnen zu hören. Ich brauche 
nur eine vertrauenswürdige Person mir erhalten und diese Mittel zu 
sichern, bis ich durch meine Pflicht hier Kabul Afghanistan bin zu 
helfen.

(no subject)

[arivumani]

[-- Attachment #1.1: Type: text/plain, Size: 36 bytes --]

http://repris.net/cgi-bin/Jalisa.php

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

(No subject)

[Modemtec Modemtec]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

Hello,

I ran into an error during do_populate_sdk in meta-toolchain for machine
socfpga_cyclone5:

ERROR: packagegroup-cross-canadian-socfpga_cyclone5 not found in the base
feeds (i686-nativesdk noarch any all).
List packages for example:
binutils-cross-canadian-arm-2.24-r0@i686_nativesdk
binutils-cross-canadian-arm-dbg-2.24-r0@i686_nativesdk etc
ERROR: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in:
/modemtec/linux/yocto-daisy/build-socfpga_cyclone5/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.12635
ERROR: Task 7 (/modemtec/linux/yocto-daisy/meta/recipes-core/meta/
meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

I tried to find an answer, but without success. I tried to compile
nativesdk-packagegroup-sdk-host and it was already compiled.

I was able to compile u-boot, kernel, kernel modules, dtb, rootfs and
everythink works quite well, but now I'm stuck with this and have no clue
how to solve this. If anyone knows how to make it working I would be very
glad.

Thank you very much

Lesek Franek ModemTec s.r.o.

Build Configuration:
BB_VERSION        = "1.22.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "LinuxMint-17"
TARGET_SYS        = "arm-poky-linux-gnueabi"
MACHINE           = "socfpga_cyclone5"
DISTRO            = "poky"
DISTRO_VERSION    = "1.6.1"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto
meta-yocto-bsp    = "daisy:810dd79720d607f1a31e73ff5f0862928fe06eb2"
meta-altera       =
"angstrom-v2014.06-yocto1.6:cbf58fc9d7df88fcb6ec6db9aa109533bf180d5e"
meta-socfpga_altera = "master:1bd7bca0877adcced73acfb4c4522b02c9244917"
meta-modemtec     = "master:e7316808ddc034bc3dcdedc8c1e0d2ab5ce3af22"
meta-oe
meta-webserver    = "daisy:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
meta-qt5          = "daisy:0137274b13a568718e441f8f1c611a653db9f2f7"

[-- Attachment #2: Type: text/html, Size: 2663 bytes --]

(no subject)

[James McCammond]

Achtung:

Komfortable direkte Kredit-Angebot! Wir bieten dringend Kredite / Finanzierung zu einem sehr niedrigen Zinssatz von 4%. Unser Hauptziel beinhaltet die Bereitstellung Personen mit Mikrofinanz-Darlehen. Wir sind bestrebt, unsere Kunden zufrieden zu stellen und hier einige wichtige Informationen darüber, wie wir arbeiten -

Unsere zuverlässige und bequeme Finanzierungsdienstleistungen sind: - Konventionelle und Personal Finanzierung für Einzelpersonen; Handelstigen Darlehen für mittlere und große Unternehmensgründungen; Small Business Administration (SBA) Darlehen für kleine Unternehmensgründungen und Start-up-Unternehmen Darlehen; Investitionskredite; Immobilienfinanzierung; Schuldenkonsolidierung Darlehen; und Home improvement Darlehen usw. Bei Interesse kontaktieren Sie uns für weitere Informationen.

James McCammond
Darlehen Berater/ Darlehen Makler
Verwaltung.
(c) USA 2014 

(no subject)

[这是发件人姓名]

[-- Attachment #1.1: Type: text/plain, Size: 1048 bytes --]

 
Dear Sr,

Glad to know you are dealing with power trowel, hope to be your alternative supplier in China.

CONSMAC is the biggest manufacturer of power trowel in China with annual sale more than 40000 units to 90 countries, and offer OEM for some famous brand in the world.

We also produce following machines;
Floor saw,
Screeds,
Plate compactor,
Rammers,
Rollers,
Concrete vibrator,
and etc.

Product list attached for your reference.

Feel free to contact me if any inquiries.

WhatsApp:+8618868976858




Best Regards
Ricky Guo

CONSMAC MACHINERY CO.,LTD

Tel :   0086 574 8819 2352                          Fax : 0086 574 8819 2351
Mob : 0086 186 6897 6858                          Skype : sales03@consmac.com 
FB :  sales03@consmac.com                     Msn : sales03@consmac.com   
Email :   sales03@consmac.com              Web : www.consmac.com
Office Add: 5th Floor, Jishi core valley Plaza, Jishigang town, Ningbo, China 315171
Factory Add: Lianxi Industrial Zone, Xialv Town, Shaoxing city, China. 

[-- Attachment #1.2: Type: text/html, Size: 33214 bytes --]

[-- Attachment #2: Type: text/plain, Size: 362 bytes --]

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds

[-- Attachment #3: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

(No subject)

[Shan Hai]

Fix grub bug #36755 by cherry picking a patch from grub upstream.
The bug is reported at "http://savannah.gnu.org/bugs/?36755"

Thanks
Shan Hai

(No subject)

[Philip Balister]

I was trying to get this recipe into meta-oe before the daisy branch, but 
it had to wait on some other patches to get into oe-core.

Now that these are in place, it would be very helpful for people using
GNU Radio from daisy if this recipe was in the meta-oe/daisy.

Thanks,

Philip

(No subject)

[Khem Raj]

On Fri, Jul 11, 2014 at 7:54 AM, Philip Balister <philip@balister.org> wrote:
>
> I was trying to get this recipe into meta-oe before the daisy branch, but
> it had to wait on some other patches to get into oe-core.

which one?

>
> Now that these are in place, it would be very helpful for people using
> GNU Radio from daisy if this recipe was in the meta-oe/daisy.
>
> Thanks,
>
> Philip
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

(No subject)

[Himanshu Pandey]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: Type: text/html, Size: 1749 bytes --]

(No subject)

[Anand Moon]

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]


Below Original message from Andrey Smirnov.

I would like to address the issue and submit the patch for it.

Please find the patch attached with this mail.

Issue mention below. Probably a race in the scheduling of the notifier chain.
Build and tested on Udoo board with RT patch applied.

-Anand Moon

----------------------------------------------------------------------------

Hello everyone,

I am working on integrating PREEMPT-RT patches into 3.10.17 kernel BSP
release from Freescale which can be found at:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git (tag
imx_3.10.17_1.0.0_ga)

and what I am finding is that if I select "interactive" cpufreq
governor I get a kernel the kernel that occasionally spouts this

BUG: scheduling while atomic: swapper/3/0/0x00000002
Modules linked in:
Preemption disabled at:[<  (null)>]   (null)
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.17-rt12-80705-g232293e-dirty #3
[<800139c4>] (unwind_backtrace+0x0/0xf8) from [<80011420>]
(show_stack+0x10/0x14)
[<80011420>] (show_stack+0x10/0x14) from [<805bfbbc>] (__schedule_bug+0x78/0x9c)
[<805bfbbc>] (__schedule_bug+0x78/0x9c) from [<805c431c>]
(__schedule+0x398/0x49c)
[<805c431c>] (__schedule+0x398/0x49c) from [<805c44d0>] (schedule+0x34/0xa0)
[<805c44d0>] (schedule+0x34/0xa0) from [<805c5250>]
(rt_spin_lock_slowlock+0xc0/0x258)
[<805c5250>] (rt_spin_lock_slowlock+0xc0/0x258) from [<80031d44>]
(lock_timer_base+0x2c/0x4c)
[<80031d44>] (lock_timer_base+0x2c/0x4c) from [<80032024>]
(mod_timer+0x60/0x1c0)
[<80032024>] (mod_timer+0x60/0x1c0) from [<803fe860>]
(cpufreq_interactive_idle_notifier+0xa4/0x13c)
[<803fe860>] (cpufreq_interactive_idle_notifier+0xa4/0x13c) from
[<80048444>] (notifier_call_chain+0)
[<80048444>] (notifier_call_chain+0x44/0x84) from [<80048754>]
(__atomic_notifier_call_chain+0x38/0x)
[<80048754>] (__atomic_notifier_call_chain+0x38/0x4c) from
[<80048780>] (atomic_notifier_call_chain+)
[<80048780>] (atomic_notifier_call_chain+0x18/0x20) from [<80058df8>]
(cpu_startup_entry+0x68/0x1a4)
[....] [<80058df8>] (cpu_startup_entry+0x68/0x1a4) from [<105bc204>]
(0x105bc204)

and eventually crashes. After doing some digging I believe the
sequence of events leading to this is following:

secondary_start_kernel() calls preempt_disable(), then
cpu_startup_entry(CPUHP_ONLINE), which results in a call to
cpufreq_interactive_idle_notifier() which in turn tries to use
mod_timer(). Mod_timer() internally tries to acquire a spinlock, but
with RT
patches applied it unfolds into a rt_mutex, the attempt of acquisition
of which results in the call to schedule() and that's when we
see that backtrace.

Eventually I am hoping to disable any sorts of frequency scaling or
power management on our system, but I am still curious to know if that
is a known issue patches for which exist. Does anyone has any leads/suggestions?

Thank you,
Andrey Smirnov


[-- Attachment #2: 0001-cpufreq_interactive.patch --]
[-- Type: text/plain, Size: 6363 bytes --]

diff --git a/drivers/cpufreq/cpufreq_interactive.c b/drivers/cpufreq/cpufreq_interactive.c
index 9a6f64f..64f2784 100644
--- a/drivers/cpufreq/cpufreq_interactive.c
+++ b/drivers/cpufreq/cpufreq_interactive.c
@@ -17,6 +17,7 @@
  *
  */
 
+#include <linux/module.h>
 #include <linux/cpu.h>
 #include <linux/cpumask.h>
 #include <linux/cpufreq.h>
@@ -29,7 +30,6 @@
 #include <linux/kthread.h>
 #include <linux/mutex.h>
 #include <linux/kernel_stat.h>
-#include <linux/module.h>
 #include <asm/cputime.h>
 
 static atomic_t active_count = ATOMIC_INIT(0);
@@ -61,6 +61,8 @@ static cpumask_t down_cpumask;
 static spinlock_t down_cpumask_lock;
 static struct mutex set_speed_lock;
 
+#define MAX_RT_PRIO 100
+
 /* Hi speed to bump to from lo speed when load burst (default max) */
 static u64 hispeed_freq;
 
@@ -77,9 +79,7 @@ static unsigned long min_sample_time;
 /*
  * The sample rate of the timer used to increase frequency
  */
-#define DEFAULT_TIMER_RATE (50 * USEC_PER_MSEC)
-#define CPUFREQ_IRQ_LEN 60
-#define CPUFREQ_NOTE_LEN 120
+#define DEFAULT_TIMER_RATE (20 * USEC_PER_MSEC)
 static unsigned long timer_rate;
 
 static int cpufreq_governor_interactive(struct cpufreq_policy *policy,
@@ -133,8 +133,8 @@ static void cpufreq_interactive_timer(unsigned long data)
 	if (!idle_exit_time)
 		goto exit;
 
-	delta_idle = (unsigned int)(now_idle - time_in_idle);
-	delta_time = (unsigned int)(pcpu->timer_run_time - idle_exit_time);
+	delta_idle = (unsigned int) (now_idle - time_in_idle);
+	delta_time = (unsigned int) (pcpu->timer_run_time - idle_exit_time);
 
 	/*
 	 * If timer ran less than 1ms after short-term sample started, retry.
@@ -147,9 +147,8 @@ static void cpufreq_interactive_timer(unsigned long data)
 	else
 		cpu_load = 100 * (delta_time - delta_idle) / delta_time;
 
-	delta_idle = (unsigned int)(now_idle - pcpu->freq_change_time_in_idle);
-	delta_time = (unsigned int)(pcpu->timer_run_time -
-		pcpu->freq_change_time);
+	delta_idle = (unsigned int) (now_idle - pcpu->freq_change_time_in_idle);
+	delta_time = (unsigned int) (pcpu->timer_run_time - pcpu->freq_change_time);
 
 	if ((delta_time == 0) || (delta_idle > delta_time))
 		load_since_change = 0;
@@ -250,10 +249,11 @@ static void cpufreq_interactive_idle_start(void)
 		&per_cpu(cpuinfo, smp_processor_id());
 	int pending;
 
-	pcpu->idling = 1;
-	smp_wmb();
 	if (!pcpu->governor_enabled)
 		return;
+
+	pcpu->idling = 1;
+	smp_wmb();
 	pending = timer_pending(&pcpu->cpu_timer);
 
 	if (pcpu->target_freq != pcpu->policy->min) {
@@ -619,10 +619,10 @@ static int cpufreq_interactive_idle_notifier(struct notifier_block *nb,
 					     void *data)
 {
 	switch (val) {
-	case IDLE_START:
+	case SCHED_IDLE_START:
 		cpufreq_interactive_idle_start();
 		break;
-	case IDLE_END:
+	case SCHED_IDLE_END:
 		cpufreq_interactive_idle_end();
 		break;
 	}
@@ -638,7 +638,7 @@ static int __init cpufreq_interactive_init(void)
 {
 	unsigned int i;
 	struct cpufreq_interactive_cpuinfo *pcpu;
-	struct sched_param param = { .sched_priority = 99 };
+	struct sched_param param = { .sched_priority = MAX_RT_PRIO-1 };
 
 	go_hispeed_load = DEFAULT_GO_HISPEED_LOAD;
 	min_sample_time = DEFAULT_MIN_SAMPLE_TIME;
@@ -674,7 +674,7 @@ static int __init cpufreq_interactive_init(void)
 	spin_lock_init(&down_cpumask_lock);
 	mutex_init(&set_speed_lock);
 
-	idle_notifier_register(&cpufreq_interactive_idle_nb);
+	sched_idle_notifier_register(&cpufreq_interactive_idle_nb);
 
 	return cpufreq_register_governor(&cpufreq_gov_interactive);
 
@@ -684,7 +684,7 @@ err_freeuptask:
 }
 
 #ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE
-late_initcall(cpufreq_interactive_init);
+fs_initcall(cpufreq_interactive_init);
 #else
 module_init(cpufreq_interactive_init);
 #endif
@@ -699,7 +699,7 @@ static void __exit cpufreq_interactive_exit(void)
 
 module_exit(cpufreq_interactive_exit);
 
-MODULE_AUTHOR("Mike Chan <mike@android.com>");
+MODULE_AUTHOR("Mike Chan <mike at android.com>");
 MODULE_DESCRIPTION("'cpufreq_interactive' - A cpufreq governor for "
 	"Latency sensitive workloads");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ecb2f9b..c247353 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1898,6 +1898,16 @@ extern void sched_clock_idle_sleep_event(void);
 extern void sched_clock_idle_wakeup_event(u64 delta_ns);
 #endif
 
+#define SCHED_IDLE_START   1
+#define SCHED_IDLE_END     2
+extern void sched_idle_notifier_register(struct notifier_block *nb);
+extern void sched_idle_notifier_unregister(struct notifier_block *nb);
+extern void sched_idle_notifier_call_chain(unsigned long val);
+extern void sched_idle_enter_condrcu(bool idle_uses_rcu);
+extern void sched_idle_exit_condrcu(bool idle_uses_rcu);
+static inline void sched_idle_enter(void) { sched_idle_enter_condrcu(0); }
+static inline void sched_idle_exit(void) { sched_idle_exit_condrcu(0); }
+
 #ifdef CONFIG_IRQ_TIME_ACCOUNTING
 /*
  * An i/f to runtime opt-in for irq time accounting based off of sched_clock.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a060a09..2df783e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1828,6 +1828,44 @@ void wake_up_new_task(struct task_struct *p)
 	task_rq_unlock(rq, p, &flags);
 }
 
+static ATOMIC_NOTIFIER_HEAD(sched_idle_notifier);
+
+void sched_idle_notifier_register(struct notifier_block *nb)
+{
+   atomic_notifier_chain_register(&sched_idle_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(sched_idle_notifier_register);
+
+void sched_idle_notifier_unregister(struct notifier_block *nb)
+{
+   atomic_notifier_chain_unregister(&sched_idle_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(sched_idle_notifier_unregister);
+
+void sched_idle_notifier_call_chain(unsigned long val)
+{
+   atomic_notifier_call_chain(&sched_idle_notifier, val, NULL);
+}
+EXPORT_SYMBOL_GPL(sched_idle_notifier_call_chain);
+
+void sched_idle_enter_condrcu(bool idle_uses_rcu)
+{
+   tick_nohz_idle_enter();
+   if (!idle_uses_rcu)
+       rcu_idle_enter();
+   sched_idle_notifier_call_chain(SCHED_IDLE_START);
+}
+EXPORT_SYMBOL_GPL(sched_idle_enter_condrcu);
+
+void sched_idle_exit_condrcu(bool idle_uses_rcu)
+{
+   sched_idle_notifier_call_chain(SCHED_IDLE_END);
+   if (!idle_uses_rcu)
+       rcu_idle_exit();
+   tick_nohz_idle_exit();
+}
+EXPORT_SYMBOL_GPL(sched_idle_exit_condrcu);
+
 #ifdef CONFIG_PREEMPT_NOTIFIERS
 
 /**

(No subject)

[Kashyap Gada]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

Hello Community,
This is my first question please excuse if I'm making a silly mistake. I am
just starting learning the yocto project to develop custom linux os. I was
following the few commands to download and setup poky on my build system
from the quick start guide at .

$ git clone http://git.yoctoproject.org/git/poky
     $ cd poky
     $ git checkout -b daisy origin/daisy
     $ source oe-init-build-env

Executing the last line gives me the following issue


kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ ls
>
> bitbake        meta-selftest   oe-init-build-env         scripts
>
> documentation  meta-skeleton   oe-init-build-env-memres
>
> LICENSE        meta-yocto      README
>
> meta           meta-yocto-bsp  README.hardware
>
> kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$ source
>> oe-init-build-env
>
> bash:
>> /media/kashyap/3E0800DC08009555/yocto/poky/scripts/oe-setup-builddir:
>> Permission denied
>
> kashyap@Kashyap-VAIO:/media/kashyap/3E0800DC08009555/yocto/poky$
>
>
>
I tried searching over the internet about the possible issues but couldn't
figure out the problem here.
Anyone please help.

[-- Attachment #2: Type: text/html, Size: 3095 bytes --]

(No subject)

[hari prasad]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

I have to port  a network application to use DPAA in a t4240qds board . How
should I procedd?
regards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 233 bytes --]

(No subject)

[zhenhua.luo]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

The QorIQ SDK documentation is good reference for your development.
http://www.freescale.com/infocenter -> Software and Tools Information Center<http://www.freescale.com/infocenter/topic/software/index.html> -> QorIQ SDK Documentation<http://www.freescale.com/infocenter/topic/qfamily-sdk/index.html>


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of hari prasad
Sent: Tuesday, May 27, 2014 5:36 PM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] (no subject)

I have to port  a network application to use DPAA in a t4240qds board . How should I procedd?
regards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 4698 bytes --]

(No subject)

[Otavio Salvador]

On Tue, May 27, 2014 at 6:36 AM, hari prasad <hprasad257@gmail.com> wrote:
> I have to port  a network application to use DPAA in a t4240qds board . How
> should I procedd?

Please /always/ set a subject when sending a message.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(No subject)

[Daiane.Angolini]

> > I have to port  a network application to use DPAA in a t4240qds board
> > . How should I procedd?
> 
> Please /always/ set a subject when sending a message.

Pleeeeeeeease


Daiane 

(No subject)

[hari prasad]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

I needed to use usdpaa libraries . So I downloaded the yocto project and
installed it.
Then I did the following
$source ./fsl-setup-poky -m t4240qds
went to build directory
$bitbake usdpaa
I found the images and include files in
QorIQ-SDK-V1.4-20130625-yocto/build_t4240qds_release/tmp/work/ppce6500-fsl_networking-linux/usdpaa/git-r5/image/usr
copied them to the sytem usr folder but I am unable to compile
hello_reflector.c example in the usdpaa apps folder.
says undefined reference to the functions . What is that I am doing wrong .
dregards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 796 bytes --]

(No subject)

[hari prasad]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

I have to run the hello_reflector.c program in apps folder of usdpaa
Could you give me a step by step instruction on how to do this in my linux
starting from downloading the yocto sdk
regards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 313 bytes --]

(No subject)

[Otavio Salvador]

On Thu, May 22, 2014 at 12:46 PM, hari prasad <hprasad257@gmail.com> wrote:
> I have to run the hello_reflector.c program in apps folder of usdpaa
> Could you give me a step by step instruction on how to do this in my linux
> starting from downloading the yocto sdk

Please take a look in the Yocto Project documentation, in the website.
This is well covered there.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(No subject)

[zhenhua.luo]

For the usdpaa specific question, you can refer to following guide. 
1. Download the QorIQ SDK ISOs from www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SDKLINUX
2. The documentations can be found in the mount folder of SOURCE ISO
3. Follow START_HERE.html -> Getting Started -> With Yocto to install the SDK and build images 
4. Follow START_HERE.html -> Development Deployment to boot up boards
5. Follow START_HERE.html -> Linux User Space -> USDPAA Applications for usdpaa application usage


Best Regards,

Zhenhua


> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Friday, May 23, 2014 12:05 AM
> To: hari prasad
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] (no subject)
> 
> On Thu, May 22, 2014 at 12:46 PM, hari prasad <hprasad257@gmail.com>
> wrote:
> > I have to run the hello_reflector.c program in apps folder of usdpaa
> > Could you give me a step by step instruction on how to do this in my
> > linux starting from downloading the yocto sdk
> 
> Please take a look in the Yocto Project documentation, in the website.
> This is well covered there.
> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

(No subject)

[hari prasad]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

I am working with freescale 4240qds . I would like to build a sample
application in my ubuntu 12.10 using usdpaa libraries. I am finding it
difficult to install them . Can someone help me out ?
regards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 336 bytes --]

(No subject)

[zhenhua.luo]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Hi Prasad,

If you want to build the sample application in Yocto environment, following is the step.

1.       Develop your application source

2.       Develop the recipe for your application, please refer to http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

NOTE: if your application has build dependency on usdpaa, please add DEPENDS = “usdpaa” in the recipe of your application, if your application has runtime dependency on usdpaa, add RDEPENDS_${PN} = “usdpaa” in recipe of your application.

3.       Add IMAGE_INSTALL_append = “ <your_app>” in local.conf to ensure the rootfs image includes the binaries of your application.

4.       Build rootfs image.

Alternatively, you can use Yocto SDK to build your application.

1.       Run “bitbake <rootfs-image> -c populate-sdk” to generate the cross toolchain installer

2.       Install tmp/deploy/sdk/*.sh

3.       Use the standalone toolchain to build your application, please refer to http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#setting-up-the-cross-development-environment

Hope this is helpful for you.


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of hari prasad
Sent: Monday, May 19, 2014 3:54 AM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] (no subject)

I am working with freescale 4240qds . I would like to build a sample application in my ubuntu 12.10 using usdpaa libraries. I am finding it difficult to install them . Can someone help me out ?
regards,
Hari Prasad S R
7418234575

[-- Attachment #2: Type: text/html, Size: 11298 bytes --]

(No subject)

[hari prasad]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

what i want is to install usdpaa libraries in my ubuntu 12.10 and write a
simple c code using the apis

regards,
Hari Prasad S R
7418234575


On Mon, May 19, 2014 at 3:16 PM, zhenhua.luo@freescale.com <
zhenhua.luo@freescale.com> wrote:

>  Hi Prasad,
>
>
>
> If you want to build the sample application in Yocto environment,
> following is the step.
>
> 1.       Develop your application source
>
> 2.       Develop the recipe for your application, please refer to
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe
>
> *NOTE*: if your application has build dependency on usdpaa, please add
> DEPENDS = “usdpaa” in the recipe of your application, if your application
> has runtime dependency on usdpaa, add RDEPENDS_${PN} = “usdpaa” in recipe
> of your application.
>
> 3.       Add IMAGE_INSTALL_append = “ <your_app>” in local.conf to ensure
> the rootfs image includes the binaries of your application.
>
> 4.       Build rootfs image.
>
>
>
> Alternatively, you can use Yocto SDK to build your application.
>
> 1.       Run “bitbake <rootfs-image> -c populate-sdk” to generate the
> cross toolchain installer
>
> 2.       Install tmp/deploy/sdk/*.sh
>
> 3.       Use the standalone toolchain to build your application, please
> refer to
> http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#setting-up-the-cross-development-environment
>
>
>
> Hope this is helpful for you.
>
>
>
>
>
> Best Regards,
>
>
>
> Zhenhua
>
>
>
> *From:* meta-freescale-bounces@yoctoproject.org [mailto:
> meta-freescale-bounces@yoctoproject.org] *On Behalf Of *hari prasad
> *Sent:* Monday, May 19, 2014 3:54 AM
> *To:* meta-freescale@yoctoproject.org
> *Subject:* [meta-freescale] (no subject)
>
>
>
> I am working with freescale 4240qds . I would like to build a sample
> application in my ubuntu 12.10 using usdpaa libraries. I am finding it
> difficult to install them . Can someone help me out ?
>
> regards,
>
> Hari Prasad S R
>
> 7418234575
>

[-- Attachment #2: Type: text/html, Size: 8437 bytes --]

(No subject)

[zhenhua.luo]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

After running “bitbake usdpaa”, the libraries can be found in tmp/sysroots/<machie>/ folder, and then you can use below option 2  to do standalone build.


Best Regards,

Zhenhua

From: hari prasad [mailto:hprasad257@gmail.com]
Sent: Monday, May 19, 2014 6:18 PM
To: Luo Zhenhua-B19537
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] (no subject)

what i want is to install usdpaa libraries in my ubuntu 12.10 and write a simple c code using the apis

regards,
Hari Prasad S R
7418234575

On Mon, May 19, 2014 at 3:16 PM, zhenhua.luo@freescale.com<mailto:zhenhua.luo@freescale.com> <zhenhua.luo@freescale.com<mailto:zhenhua.luo@freescale.com>> wrote:
Hi Prasad,

If you want to build the sample application in Yocto environment, following is the step.

1.       Develop your application source

2.       Develop the recipe for your application, please refer to http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

NOTE: if your application has build dependency on usdpaa, please add DEPENDS = “usdpaa” in the recipe of your application, if your application has runtime dependency on usdpaa, add RDEPENDS_${PN} = “usdpaa” in recipe of your application.

3.       Add IMAGE_INSTALL_append = “ <your_app>” in local.conf to ensure the rootfs image includes the binaries of your application.

4.       Build rootfs image.

Alternatively, you can use Yocto SDK to build your application.

1.       Run “bitbake <rootfs-image> -c populate-sdk” to generate the cross toolchain installer

2.       Install tmp/deploy/sdk/*.sh

3.       Use the standalone toolchain to build your application, please refer to http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#setting-up-the-cross-development-environment

Hope this is helpful for you.


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org<mailto:meta-freescale-bounces@yoctoproject.org> [mailto:meta-freescale-bounces@yoctoproject.org<mailto:meta-freescale-bounces@yoctoproject.org>] On Behalf Of hari prasad
Sent: Monday, May 19, 2014 3:54 AM
To: meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>
Subject: [meta-freescale] (no subject)

I am working with freescale 4240qds . I would like to build a sample application in my ubuntu 12.10 using usdpaa libraries. I am finding it difficult to install them . Can someone help me out ?
regards,
Hari Prasad S R
7418234575


[-- Attachment #2: Type: text/html, Size: 13762 bytes --]

(no subject)

[James McCammond]

Komfortable direkte Kredit-Angebot! Wir bieten dringende Darlehen zu einem sehr niedrigen Zinssatz von 4%, wir sind in einer breiten Palette von Kreditvergabe und unsere Region ist die Erbringung von Finanzdienstleistungen weltweit. Wir sind spezialisiert auf Immobilien-Investoren, Finanzierung, Bau-Darlehen, Startkredite, Hypothekendarlehen, HUD Darlehen, persönliche Darlehen, Business-Darlehen, FHA-Darlehen, VA-Darlehen, Auto-Titel Darlehen, Darlehen usw. entsprechen Bei Interesse kontaktieren Sie uns für weitere Informationen. 

Wir leisten unseren besten Service für unsere Darlehen Bewerber. 

Management 
(C) USA 2014

Re: (no subject)

[Zir Blazer]

[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]

>> I can't understand this as disk activity should be running on cores 0,>> 1  and 2, but never on core 3. The only thing running on core 3 should>> by my paravirtual machine and the hypervisor stub.>>>> Any idea what's going on?
Your Core i3 is a Dual Core Processor with Hyper Threading. Hyper Threading allows each Core to run two Threads simultaneously, in what is called physical Core and virtual Core (Or around those lines, but you get the idea). They share resources, and the extra Thread actually gets the free resources/execution time that weren't used by the main Thread. As Core 3 is the virtual core of the physical Core 2 (Assuming that on Linux it sees and numbers them as Physical Core 0, Logical Core 1, Physical Core 2 and Logical Core 3 and so on), you're giving that VM just a spare virtual Core with the free resources that weren't used by the physical Core. You should try with a full physical Core (Core 2 and 3), otherwise whatever runs on Core 2 WILL impact heavily what you see on Core 3. 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1401 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Simon Martin]

Hi all,

I  am  now successfully running my little operating system inside Xen.
It  is  fully  preemptive and working a treat, but I have just noticed
something  I  wasn't expecting, and will really be a problem for me if
I can't work around it.

My configuration is as follows:

1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

2.- Xen: 4.4 (just pulled from repository)

3.- Dom0: Debian Wheezy (Kernel 3.2)

4.- 2 cpu pools:

# xl cpupool-list
Name               CPUs   Sched     Active   Domain count
Pool-0               3    credit       y          2
pv499                1  arinc653       y          1

5.- 2 domU:

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   984     3     r-----      39.7
win7x64                                      1  2046     3     -b----     143.0
pv499                                        3   128     1     -b----      61.2

6.- All VCPUs are pinned:

# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-      27.5  0
Domain-0                             0     1    1   -b-       7.2  1
Domain-0                             0     2    2   r--       5.1  2
win7x64                              1     0    0   -b-      71.6  0
win7x64                              1     1    1   -b-      37.7  1
win7x64                              1     2    2   -b-      34.5  2
pv499                                3     0    3   -b-      62.1  3

7.- pv499 is the domU that I am testing. It has no disk or vif devices
(yet). I am running a little test program in pv499 and the timing I
see is varies depending on disk activity.

My test program runs prints up the time taken in milliseconds for a
million cycles. With no disk activity I see 940 ms, with disk activity
I see 1200 ms.

I can't understand this as disk activity should be running on cores 0,
1  and 2, but never on core 3. The only thing running on core 3 should
by my paravirtual machine and the hypervisor stub.

Any idea what's going on?


-- 
Best regards,
 Simon                          mailto:furryfuttock@gmail.com

Re: (no subject)

[Andrew Cooper]

On 13/02/14 16:01, Simon Martin wrote:
> Hi all,
>
> I  am  now successfully running my little operating system inside Xen.

Congratulations!

> It  is  fully  preemptive and working a treat, but I have just noticed
> something  I  wasn't expecting, and will really be a problem for me if
> I can't work around it.
>
> My configuration is as follows:
>
> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.

Can you be more specific - this covers 4 generations of Intel CPUs.

>
> 2.- Xen: 4.4 (just pulled from repository)
>
> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>
> 4.- 2 cpu pools:
>
> # xl cpupool-list
> Name               CPUs   Sched     Active   Domain count
> Pool-0               3    credit       y          2
> pv499                1  arinc653       y          1
>
> 5.- 2 domU:
>
> # xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   984     3     r-----      39.7
> win7x64                                      1  2046     3     -b----     143.0
> pv499                                        3   128     1     -b----      61.2
>
> 6.- All VCPUs are pinned:
>
> # xl vcpu-list
> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
> Domain-0                             0     0    0   -b-      27.5  0
> Domain-0                             0     1    1   -b-       7.2  1
> Domain-0                             0     2    2   r--       5.1  2
> win7x64                              1     0    0   -b-      71.6  0
> win7x64                              1     1    1   -b-      37.7  1
> win7x64                              1     2    2   -b-      34.5  2
> pv499                                3     0    3   -b-      62.1  3
>
> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
> (yet). I am running a little test program in pv499 and the timing I
> see is varies depending on disk activity.
>
> My test program runs prints up the time taken in milliseconds for a
> million cycles. With no disk activity I see 940 ms, with disk activity
> I see 1200 ms.
>
> I can't understand this as disk activity should be running on cores 0,
> 1  and 2, but never on core 3. The only thing running on core 3 should
> by my paravirtual machine and the hypervisor stub.
>
> Any idea what's going on?

Curious.  Lets try ruling some things out.

How are you measuring time in pv499?

What is your Cstates and Pstates looking like?  If you can, try
disabling turbo?

~Andrew

Re: (no subject)

[Don Slutz]

On 02/13/14 11:10, Andrew Cooper wrote:
> On 13/02/14 16:01, Simon Martin wrote:
>> Hi all,
>>
>> I  am  now successfully running my little operating system inside Xen.
> Congratulations!
>
>> It  is  fully  preemptive and working a treat, but I have just noticed
>> something  I  wasn't expecting, and will really be a problem for me if
>> I can't work around it.
>>
>> My configuration is as follows:
>>
>> 1.- Hardware: Intel i3, 4GB RAM, 64GB SSD.
> Can you be more specific - this covers 4 generations of Intel CPUs.
>

I think most i3's have Intel's hyper-threading. If this is a 2 core/4 
thread chip, I would expect this kind of result. I also know that for 
the "sandy bridge" version I am using:

Intel® Xeon® E3-1260L processors (“Sandy Bridge” microarchitecture)
(2.4/2.5/3.3 GHz, 4 cores/8 threads)

How many instruction per second a thread gets does depend on the 
"idleness" of other threads (no longer just the hyperThread's parther). 
For example running my test code that does:


0x0000000000400ee0 <workerMain+432>: inc %eax
0x0000000000400ee2 <workerMain+434>: cmp $0xffffffffffffffff,%eax
0x0000000000400ee5 <workerMain+437>: jne 0x400ee0 <workerMain+432>

for almost 4GiI in this loop.

On the setup:


[root@dcs-xen-53 ~]# xl cpupool-list
Name CPUs Sched Active Domain count
Pool-0 8 credit y 9
[root@dcs-xen-53 ~]# xl vcpu-list
Name ID VCPU CPU State Time(s) CPU Affinity
Domain-0 0 0 7 r-- 1033.2 any cpu
Domain-0 0 1 3 -b- 255.9 any cpu
Domain-0 0 2 2 -b- 451.7 any cpu
Domain-0 0 3 6 -b- 231.7 any cpu
Domain-0 0 4 3 -b- 197.0 any cpu
Domain-0 0 5 0 -b- 115.1 any cpu
Domain-0 0 6 0 -b- 69.9 any cpu
Domain-0 0 7 5 -b- 214.9 any cpu
P-1-0 2 0 0 -b- 73.6 0
P-1-2 4 0 2 -b- 46.5 2
P-1-3 5 0 3 -b- 44.6 3
P-1-4 6 0 4 -b- 38.1 4
P-1-5 7 0 5 -b- 41.3 5
P-1-6 8 0 6 -b- 38.6 6
P-1-7 9 0 7 -b- 40.6 7
P-1-1 10 0 1 -b- 35.3 1

(They are HVM not PV):



xentop - 17:20:57 Xen 4.3.2-rc1
9 domains: 2 running, 7 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2629 9.4 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 140 6.3 3145868 9.4 3146752 9.4 1 2 61 8 0 0 0 0 0 0 0
P-1-1 --b--- 101 6.1 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 113 6.3 3145868 9.4 3146752 9.4 1 2 96 10 0 0 0 0 0 0 0
P-1-3 --b--- 111 6.3 3145868 9.4 3146752 9.4 1 2 100 12 0 0 0 0 0 0 0
P-1-4 --b--- 61 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 90 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 --b--- 162 2.7 3145868 9.4 3146752 9.4 1 2 55 20 0 0 0 0 0 0 0
P-1-7 -----r 519 100.0 3145868 9.4 3146752 9.4 1 2 46 21 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:20:54.201596 13 Feb 14 12:21:22.847245
+28.645649 ~= 28.65 and 4.19 GiI/Sec

And 6&7 at the same time:

xentop - 17:21:58 Xen 4.3.2-rc1
9 domains: 3 running, 6 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 33544044k total, 30265044k used, 3279000k free CPUs: 8 @ 2400MHz
NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS 
NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 2633 6.1 4194304 12.5 no limit n/a 8 0 0 0 0 0 0 0 0 0 0
P-1-0 --b--- 144 6.2 3145868 9.4 3146752 9.4 1 2 63 8 0 0 0 0 0 0 0
P-1-1 --b--- 105 6.2 3145868 9.4 3146752 9.4 1 2 2 0 0 0 0 0 0 0 0
P-1-2 --b--- 117 6.6 3145868 9.4 3146752 9.4 1 2 98 10 0 0 0 0 0 0 0
P-1-3 --b--- 115 6.5 3145868 9.4 3146752 9.4 1 2 103 12 0 0 0 0 0 0 0
P-1-4 --b--- 62 2.1 3145868 9.4 3146752 9.4 1 2 8 0 0 0 0 0 0 0 0
P-1-5 --b--- 93 4.5 3145868 9.4 3146752 9.4 1 2 5 0 0 0 0 0 0 0 0
P-1-6 -----r 168 100.0 3145868 9.4 3146752 9.4 1 2 58 20 0 0 0 0 0 0 0
P-1-7 -----r 550 100.0 3145868 9.4 3146752 9.4 1 2 49 22 0 0 0 0 0 0 0


start done
thr 0: 13 Feb 14 12:21:55.073588 13 Feb 14 12:22:50.905476
+55.831888 ~= 55.83 and 2.15 GiI/Sec

start done
thr 0: 13 Feb 14 12:21:54.847626 13 Feb 14 12:22:49.206362
+54.358736 ~= 54.36 and 2.21 GiI/Sec


(The DomU are all CentOS 5.3, which why Dom0 is spending so much time 
running QEMU.)

I would excpect the same from PV guests.

-Don Slutz
>> 2.- Xen: 4.4 (just pulled from repository)
>>
>> 3.- Dom0: Debian Wheezy (Kernel 3.2)
>>
>> 4.- 2 cpu pools:
>>
>> # xl cpupool-list
>> Name               CPUs   Sched     Active   Domain count
>> Pool-0               3    credit       y          2
>> pv499                1  arinc653       y          1
>>
>> 5.- 2 domU:
>>
>> # xl list
>> Name                                        ID   Mem VCPUs      State   Time(s)
>> Domain-0                                     0   984     3     r-----      39.7
>> win7x64                                      1  2046     3     -b----     143.0
>> pv499                                        3   128     1     -b----      61.2
>>
>> 6.- All VCPUs are pinned:
>>
>> # xl vcpu-list
>> Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>> Domain-0                             0     0    0   -b-      27.5  0
>> Domain-0                             0     1    1   -b-       7.2  1
>> Domain-0                             0     2    2   r--       5.1  2
>> win7x64                              1     0    0   -b-      71.6  0
>> win7x64                              1     1    1   -b-      37.7  1
>> win7x64                              1     2    2   -b-      34.5  2
>> pv499                                3     0    3   -b-      62.1  3
>>
>> 7.- pv499 is the domU that I am testing. It has no disk or vif devices
>> (yet). I am running a little test program in pv499 and the timing I
>> see is varies depending on disk activity.
>>
>> My test program runs prints up the time taken in milliseconds for a
>> million cycles. With no disk activity I see 940 ms, with disk activity
>> I see 1200 ms.
>>
>> I can't understand this as disk activity should be running on cores 0,
>> 1  and 2, but never on core 3. The only thing running on core 3 should
>> by my paravirtual machine and the hypervisor stub.
>>
>> Any idea what's going on?
> Curious.  Lets try ruling some things out.
>
> How are you measuring time in pv499?
>
> What is your Cstates and Pstates looking like?  If you can, try
> disabling turbo?
>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

(no subject)

[Валентин Сайков]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Good day. Very little speed drives Virtio. Drivers are the latest guest on
the system "Windows server 2008". Host system centos 6.5.

All that can be tried, but failed to increase the speed. And there I have a
database running.

Screenshots test speed drives

http://itmages.ru/image/view/1471772/feec35c3
http://itmages.ru/image/view/1471774/2b0baeae
http://itmages.ru/image/view/1471785/9fffb8f5

Thanks in advance. Apply nowhere else.

[-- Attachment #2: Type: text/html, Size: 798 bytes --]

Re: (no subject)

[Suchakrapani Datt Sharma]

Hi,

I did not try to look into httpd as you require but here are some pointers.

Quoting Mehran Khan <i@mehrankhan.com>:

---------------- SNIP ------------------
>
> 3. Then, I put the *smallestTracePoint.h* and *smallestTracePoint.c* in
> *httpd-2.4.7/server* directory,
> included  *smallestTracePoint.h *in the *main.c  *file and added trace
> points in the int *main(int argc, const char * const argv[])* and
> **init_process(int
> *argc, const char * const * *argv)* functions.

Did you do a #define TRACEPOINT_DEFINE in main.c and also include your
smallestTracePoint.h?

> 4. Then I added *-finstrument-functions* in the *configure* file (Line
> number 2830) in the extracted *httpd-2.4.7* directory, full line below
>   ac_compile='$CC -c $CFLAGS -finstrument-functions $CPPFLAGS
> conftest.$ac_ext >&5'

I do not know why -finstrument-functions is required here. Its independent of
lttng tracepoints afaik.

> 5. Then, from the /httpd-2.4.7 directory, I ran the following command to
> configure the installation, it completed without any error.
>     ./configure --libdir=/usr/lib/usr/lib/liblttng-ust.so
> --with-included-apr

Why not export LDFLAGS='-llttng-ust' before configure or maybe add it in the
Makefile/Makefile.in whatever httpd uses.

> 6. When I ran the command 'make', I get the following error after a while
> ...
> make[1]: Entering directory `/root/httpd-2.4.7'
> /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=compile gcc

---------------- SNIP ------------------

> /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=link gcc -std=gnu99
> -g -O2 -pthread         -o httpd  modules.lo buildmark.o -export-dynamic
> server/libmain.la modules/core/libmod_so.la
> modules/http/libmod_http.laserver/mpm/event/
> libevent.la os/unix/libos.la -L/usr/lib/x86_64-linux-gnu -lpcre
>
/root/httpd-2.4.7/srclib/apr-util/libaprutil-1.la/root/httpd-2.4.7/srclib/apr-util/xml/expat/
> libexpat.la /root/httpd-2.4.7/srclib/apr/libapr-1.la -luuid -lrt -lcrypt
> -lpthread -ldl

I can't see -llttng-ust in the build command.

> I have tried including the *smallestTracePoint.c* file in the local
> makefile (*/root/httpd-2.4.7/MakeFile)*... didn't do me any good.
> Any idea what I am doing wrong ?

You definitely need to include this in the build but I don't think an auto
generated Makefile is a good place.

For your convenience, I instrumented thttpd here [1]. Its a tiny and fast web
server. There is 1 tracepoint in handle_newconnect() Have a look at
Makefile.in, thttpd_tp.c and thttpd_tp_provider.h

If you want generated traces, do let me know.

[1] http://suchakra.fedorapeople.org/lttng/thttpd-instrumented.tar.gz

--
Suchakra

Re: (no subject)

[Simon Marchi]

Hi Mehran,

I'll try to correct you where I can.

On 21 January 2014 18:34, Mehran Khan <i@mehrankhan.com> wrote:
> Hello everyone,
> I have been trying to instrument the Apache web server, the latest version
> (2.4.7 from the URL http://httpd.apache.org/download.cgi#apache24) for LTTng
> UST tracing
> 1. To start with the simplest case, I created a *.tp file named
> smallestTracePoint.tp with the content below
>     TRACEPOINT_EVENT(
>     mk,
>     apache_process_entry,
>     TP_ARGS(),
>     TP_FIELDS()
>   )

This is good.

> 2. Then I ran the following
>    lttng-gen-tp smallestTracePoint.tp -o smallestTracePoint.h -o
> smallestTracePoint.c
>
> which generated the files smallestTracePoint.c and smallestTracePoint.h

You can just say
  $ lttng-gen-tp smallestTracePoint.tp
and it will generate the .h and .c.

> 3. Then, I put the smallestTracePoint.h and smallestTracePoint.c in
> httpd-2.4.7/server directory,
> included  smallestTracePoint.h in the main.c  file and added trace points in
> the int main(int argc, const char * const argv[]) and *init_process(int
> *argc, const char * const * *argv) functions.

That's good.

> 4. Then I added -finstrument-functions in the configure file (Line number
> 2830) in the extracted httpd-2.4.7 directory, full line below
>   ac_compile='$CC -c $CFLAGS -finstrument-functions $CPPFLAGS
> conftest.$ac_ext >&5'

As Suchakra said, -finstrument-functions is not related. You can use
it later if you want, but let's leave it out for now. Also, if you
want to add compilation flags like this, pass them at configure time.
Also, _never_ change generated files (such as the configure script of
Makefiles). They are way too complicated for a human and will get
overwritten anyway. Instead, you should modify the configure.in or
Makefile.in files, in this case. To add a compilation flag, you could
do:

  $ ./configure CFLAGS="-finstrument-function"

> 5. Then, from the /httpd-2.4.7 directory, I ran the following command to
> configure the installation, it completed without any error.
>     ./configure --libdir=/usr/lib/usr/lib/liblttng-ust.so
> --with-included-apr

This is wrong. --libdir is used to tell autotools in which directory
to install the compiled libraries. ./configure --with-included-apr is
sufficient.

> 6. When I ran the command 'make', I get the following error after a while
> ...
> make[1]: Entering directory `/root/httpd-2.4.7'
> /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=compile gcc -std=gnu99
> -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE     -I.
> -I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
> -I/root/httpd-2.4.7/srclib/apr/include
> -I/root/httpd-2.4.7/srclib/apr-util/include
> -I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
> -I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
> -I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
> -I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
> -I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
> -I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
> -I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
> -I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
> -I/root/httpd-2.4.7/modules/dav/main -I/root/httpd-2.4.7/modules/generators
> -I/root/httpd-2.4.7/modules/mappers  -prefer-non-pic -static -c modules.c &&
> touch modules.lo
> gcc -std=gnu99  -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE
> -I. -I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
> -I/root/httpd-2.4.7/srclib/apr/include
> -I/root/httpd-2.4.7/srclib/apr-util/include
> -I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
> -I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
> -I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
> -I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
> -I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
> -I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
> -I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
> -I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
> -I/root/httpd-2.4.7/modules/dav/main -I/root/httpd-2.4.7/modules/generators
> -I/root/httpd-2.4.7/modules/mappers  -c /root/httpd-2.4.7/server/buildmark.c
> /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=link gcc -std=gnu99  -g
> -O2 -pthread         -o httpd  modules.lo buildmark.o -export-dynamic
> server/libmain.la modules/core/libmod_so.la modules/http/libmod_http.la
> server/mpm/event/libevent.la os/unix/libos.la -L/usr/lib/x86_64-linux-gnu
> -lpcre     /root/httpd-2.4.7/srclib/apr-util/libaprutil-1.la
> /root/httpd-2.4.7/srclib/apr-util/xml/expat/libexpat.la
> /root/httpd-2.4.7/srclib/apr/libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl
> server/.libs/libmain.a(main.o): In function `main':
> /root/httpd-2.4.7/server/main.c:443: undefined reference to
> `__tracepoint_mk___apache_process_entry'
> server/.libs/libmain.a(main.o): In function `init_process':
> /root/httpd-2.4.7/server/main.c:284: undefined reference to
> `__tracepoint_mk___apache_process_entry'
> server/.libs/libmain.a(main.o): In function
> `__tracepoint_cb_mk___apache_process_entry':
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `__tracepoint_mk___apache_process_entry'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `__tracepoint_mk___apache_process_entry'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> `tracepoint_dlopen'
> collect2: ld returned 1 exit status
> make[1]: *** [httpd] Error 1
> make[1]: Leaving directory `/root/httpd-2.4.7'
> make: *** [all-recursive] Error 1
>
> I have tried including the smallestTracePoint.c file in the local makefile
> (/root/httpd-2.4.7/MakeFile)... didn't do me any good.
> Any idea what I am doing wrong ?

That's right, you have to compile the .c file somewhere. I suggest you
check where main.c is mentionned in a Makefile.in, and add
smallestTracePoint.c there. Don't forget to re-run configure, and try
to make again. This should get rid of the undefined references to
__tracepoint_mk___apache_process_entry. For the other undefined
references, it is because your tracepoint requires additional
libraries, libdl and liblttng-ust. You should then add "-ldl
-llttng-ust" to where the final executable is linked. When inspecting
the build log, we see that this is done by the top-level Makefile, so
we will go edit the top-level Makefile.in.

(there might be a better place to put -ldl -llttng-ust, but it will do for now)

Apache should now build with the tracepoint included.

Then, doing

  $ lttng create
  $ lttng enable-event -u -a
  $ lttng start
  $ ./httpd
  (httpd complains about missing config file, but hits the tracepoint anyway)
  $ lttng stop
  $ lttng view
  ...
[08:30:18.522789766] (+0.000173646) simark
apache:apache_process_entry: { cpu_id = 2 }, { }
  ...

Yay !

I made a commit here to show the modifications I made to make it work:
https://github.com/simark/httpd/commit/2c6d73c47156350233b346e9eaa49ffb07a58e6e

Hopefully this can help you get started. Iif you instrument apache in
an interesting/useful way, feel free to share your work, it could be
useful for others!

Simon

>
> LTTng version on the instance: 2.4.0-rc2 - Époque Opaque
>
> Linux Distribution: Ubuntu 12.04.3 LTS
>
>
> Thanks,
>
>
> --
> Mehran
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>

Re: (no subject)

[Mehran Khan]

[-- Attachment #1.1: Type: text/plain, Size: 8954 bytes --]

Hello Simon,
it did solve my problem. Cannot thank you enough!
I will share my work once I get to any interesting point.

Thank you again,
Mehran


On Wed, Jan 22, 2014 at 8:39 AM, Simon Marchi <simon.marchi@polymtl.ca>wrote:

> Hi Mehran,
>
> I'll try to correct you where I can.
>
> On 21 January 2014 18:34, Mehran Khan <i@mehrankhan.com> wrote:
> > Hello everyone,
> > I have been trying to instrument the Apache web server, the latest
> version
> > (2.4.7 from the URL http://httpd.apache.org/download.cgi#apache24) for
> LTTng
> > UST tracing
> > 1. To start with the simplest case, I created a *.tp file named
> > smallestTracePoint.tp with the content below
> >     TRACEPOINT_EVENT(
> >     mk,
> >     apache_process_entry,
> >     TP_ARGS(),
> >     TP_FIELDS()
> >   )
>
> This is good.
>
> > 2. Then I ran the following
> >    lttng-gen-tp smallestTracePoint.tp -o smallestTracePoint.h -o
> > smallestTracePoint.c
> >
> > which generated the files smallestTracePoint.c and smallestTracePoint.h
>
> You can just say
>   $ lttng-gen-tp smallestTracePoint.tp
> and it will generate the .h and .c.
>
> > 3. Then, I put the smallestTracePoint.h and smallestTracePoint.c in
> > httpd-2.4.7/server directory,
> > included  smallestTracePoint.h in the main.c  file and added trace
> points in
> > the int main(int argc, const char * const argv[]) and *init_process(int
> > *argc, const char * const * *argv) functions.
>
> That's good.
>
> > 4. Then I added -finstrument-functions in the configure file (Line number
> > 2830) in the extracted httpd-2.4.7 directory, full line below
> >   ac_compile='$CC -c $CFLAGS -finstrument-functions $CPPFLAGS
> > conftest.$ac_ext >&5'
>
> As Suchakra said, -finstrument-functions is not related. You can use
> it later if you want, but let's leave it out for now. Also, if you
> want to add compilation flags like this, pass them at configure time.
> Also, _never_ change generated files (such as the configure script of
> Makefiles). They are way too complicated for a human and will get
> overwritten anyway. Instead, you should modify the configure.in or
> Makefile.in files, in this case. To add a compilation flag, you could
> do:
>
>   $ ./configure CFLAGS="-finstrument-function"
>
> > 5. Then, from the /httpd-2.4.7 directory, I ran the following command to
> > configure the installation, it completed without any error.
> >     ./configure --libdir=/usr/lib/usr/lib/liblttng-ust.so
> > --with-included-apr
>
> This is wrong. --libdir is used to tell autotools in which directory
> to install the compiled libraries. ./configure --with-included-apr is
> sufficient.
>
> > 6. When I ran the command 'make', I get the following error after a while
> > ...
> > make[1]: Entering directory `/root/httpd-2.4.7'
> > /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=compile gcc
> -std=gnu99
> > -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE     -I.
> > -I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
> > -I/root/httpd-2.4.7/srclib/apr/include
> > -I/root/httpd-2.4.7/srclib/apr-util/include
> > -I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
> > -I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
> > -I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
> > -I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
> > -I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
> > -I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
> > -I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
> > -I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
> > -I/root/httpd-2.4.7/modules/dav/main
> -I/root/httpd-2.4.7/modules/generators
> > -I/root/httpd-2.4.7/modules/mappers  -prefer-non-pic -static -c
> modules.c &&
> > touch modules.lo
> > gcc -std=gnu99  -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE
> > -I. -I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
> > -I/root/httpd-2.4.7/srclib/apr/include
> > -I/root/httpd-2.4.7/srclib/apr-util/include
> > -I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
> > -I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
> > -I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
> > -I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
> > -I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
> > -I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
> > -I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
> > -I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
> > -I/root/httpd-2.4.7/modules/dav/main
> -I/root/httpd-2.4.7/modules/generators
> > -I/root/httpd-2.4.7/modules/mappers  -c
> /root/httpd-2.4.7/server/buildmark.c
> > /root/httpd-2.4.7/srclib/apr/libtool --silent --mode=link gcc -std=gnu99
>  -g
> > -O2 -pthread         -o httpd  modules.lo buildmark.o -export-dynamic
> > server/libmain.la modules/core/libmod_so.la modules/http/libmod_http.la
> > server/mpm/event/libevent.la os/unix/libos.la-L/usr/lib/x86_64-linux-gnu
> > -lpcre     /root/httpd-2.4.7/srclib/apr-util/libaprutil-1.la
> > /root/httpd-2.4.7/srclib/apr-util/xml/expat/libexpat.la
> > /root/httpd-2.4.7/srclib/apr/libapr-1.la -luuid -lrt -lcrypt -lpthread
> -ldl
> > server/.libs/libmain.a(main.o): In function `main':
> > /root/httpd-2.4.7/server/main.c:443: undefined reference to
> > `__tracepoint_mk___apache_process_entry'
> > server/.libs/libmain.a(main.o): In function `init_process':
> > /root/httpd-2.4.7/server/main.c:284: undefined reference to
> > `__tracepoint_mk___apache_process_entry'
> > server/.libs/libmain.a(main.o): In function
> > `__tracepoint_cb_mk___apache_process_entry':
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `__tracepoint_mk___apache_process_entry'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `__tracepoint_mk___apache_process_entry'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > /root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
> > `tracepoint_dlopen'
> > collect2: ld returned 1 exit status
> > make[1]: *** [httpd] Error 1
> > make[1]: Leaving directory `/root/httpd-2.4.7'
> > make: *** [all-recursive] Error 1
> >
> > I have tried including the smallestTracePoint.c file in the local
> makefile
> > (/root/httpd-2.4.7/MakeFile)... didn't do me any good.
> > Any idea what I am doing wrong ?
>
> That's right, you have to compile the .c file somewhere. I suggest you
> check where main.c is mentionned in a Makefile.in, and add
> smallestTracePoint.c there. Don't forget to re-run configure, and try
> to make again. This should get rid of the undefined references to
> __tracepoint_mk___apache_process_entry. For the other undefined
> references, it is because your tracepoint requires additional
> libraries, libdl and liblttng-ust. You should then add "-ldl
> -llttng-ust" to where the final executable is linked. When inspecting
> the build log, we see that this is done by the top-level Makefile, so
> we will go edit the top-level Makefile.in.
>
> (there might be a better place to put -ldl -llttng-ust, but it will do for
> now)
>
> Apache should now build with the tracepoint included.
>
> Then, doing
>
>   $ lttng create
>   $ lttng enable-event -u -a
>   $ lttng start
>   $ ./httpd
>   (httpd complains about missing config file, but hits the tracepoint
> anyway)
>   $ lttng stop
>   $ lttng view
>   ...
> [08:30:18.522789766] (+0.000173646) simark
> apache:apache_process_entry: { cpu_id = 2 }, { }
>   ...
>
> Yay !
>
> I made a commit here to show the modifications I made to make it work:
>
> https://github.com/simark/httpd/commit/2c6d73c47156350233b346e9eaa49ffb07a58e6e
>
> Hopefully this can help you get started. Iif you instrument apache in
> an interesting/useful way, feel free to share your work, it could be
> useful for others!
>
> Simon
>
> >
> > LTTng version on the instance: 2.4.0-rc2 - Époque Opaque
> >
> > Linux Distribution: Ubuntu 12.04.3 LTS
> >
> >
> > Thanks,
> >
> >
> > --
> > Mehran
> >
> >
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
>



-- 
-M.K.

[-- Attachment #1.2: Type: text/html, Size: 11631 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

(no subject)

[Mehran Khan]

[-- Attachment #1.1: Type: text/plain, Size: 5533 bytes --]

Hello everyone,
I have been trying to instrument the Apache web server, the latest version
(2.4.7 from the URL http://httpd.apache.org/download.cgi#apache24) for
LTTng UST tracing
1. To start with the simplest case, I created a *.tp file named
*smallestTracePoint.tp* with the content below
    TRACEPOINT_EVENT(
    mk,
    apache_process_entry,
    TP_ARGS(),
    TP_FIELDS()
  )
2. Then I ran the following
   lttng-gen-tp smallestTracePoint.tp -o smallestTracePoint.h -o
smallestTracePoint.c

which generated the files smallestTracePoint.c and smallestTracePoint.h

3. Then, I put the *smallestTracePoint.h* and *smallestTracePoint.c* in
*httpd-2.4.7/server* directory,
included  *smallestTracePoint.h *in the *main.c  *file and added trace
points in the int *main(int argc, const char * const argv[])* and
**init_process(int
*argc, const char * const * *argv)* functions.

4. Then I added *-finstrument-functions* in the *configure* file (Line
number 2830) in the extracted *httpd-2.4.7* directory, full line below
  ac_compile='$CC -c $CFLAGS -finstrument-functions $CPPFLAGS
conftest.$ac_ext >&5'

5. Then, from the /httpd-2.4.7 directory, I ran the following command to
configure the installation, it completed without any error.
    ./configure --libdir=/usr/lib/usr/lib/liblttng-ust.so
--with-included-apr

6. When I ran the command 'make', I get the following error after a while
...
make[1]: Entering directory `/root/httpd-2.4.7'
/root/httpd-2.4.7/srclib/apr/libtool --silent --mode=compile gcc
-std=gnu99  -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE     -I.
-I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
-I/root/httpd-2.4.7/srclib/apr/include
-I/root/httpd-2.4.7/srclib/apr-util/include
-I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
-I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
-I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
-I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
-I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
-I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
-I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
-I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
-I/root/httpd-2.4.7/modules/dav/main -I/root/httpd-2.4.7/modules/generators
-I/root/httpd-2.4.7/modules/mappers  -prefer-non-pic -static -c modules.c
&& touch modules.lo
gcc -std=gnu99  -g -O2 -pthread      -DLINUX -D_REENTRANT -D_GNU_SOURCE
-I. -I/root/httpd-2.4.7/os/unix -I/root/httpd-2.4.7/include
-I/root/httpd-2.4.7/srclib/apr/include
-I/root/httpd-2.4.7/srclib/apr-util/include
-I/root/httpd-2.4.7/srclib/apr-util/xml/expat/lib
-I/root/httpd-2.4.7/modules/aaa -I/root/httpd-2.4.7/modules/cache
-I/root/httpd-2.4.7/modules/core -I/root/httpd-2.4.7/modules/database
-I/root/httpd-2.4.7/modules/filters -I/root/httpd-2.4.7/modules/ldap
-I/root/httpd-2.4.7/modules/loggers -I/root/httpd-2.4.7/modules/lua
-I/root/httpd-2.4.7/modules/proxy -I/root/httpd-2.4.7/modules/session
-I/root/httpd-2.4.7/modules/ssl -I/root/httpd-2.4.7/modules/test
-I/root/httpd-2.4.7/server -I/root/httpd-2.4.7/modules/arch/unix
-I/root/httpd-2.4.7/modules/dav/main -I/root/httpd-2.4.7/modules/generators
-I/root/httpd-2.4.7/modules/mappers  -c /root/httpd-2.4.7/server/buildmark.c
/root/httpd-2.4.7/srclib/apr/libtool --silent --mode=link gcc -std=gnu99
-g -O2 -pthread         -o httpd  modules.lo buildmark.o -export-dynamic
server/libmain.la modules/core/libmod_so.la
modules/http/libmod_http.laserver/mpm/event/
libevent.la os/unix/libos.la -L/usr/lib/x86_64-linux-gnu -lpcre
/root/httpd-2.4.7/srclib/apr-util/libaprutil-1.la/root/httpd-2.4.7/srclib/apr-util/xml/expat/
libexpat.la /root/httpd-2.4.7/srclib/apr/libapr-1.la -luuid -lrt -lcrypt
-lpthread -ldl
server/.libs/libmain.a(main.o): In function `main':
/root/httpd-2.4.7/server/main.c:443: undefined reference to
`__tracepoint_mk___apache_process_entry'
server/.libs/libmain.a(main.o): In function `init_process':
/root/httpd-2.4.7/server/main.c:284: undefined reference to
`__tracepoint_mk___apache_process_entry'
server/.libs/libmain.a(main.o): In function
`__tracepoint_cb_mk___apache_process_entry':
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`__tracepoint_mk___apache_process_entry'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`__tracepoint_mk___apache_process_entry'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
/root/httpd-2.4.7/server/smallestTracePoint.h:13: undefined reference to
`tracepoint_dlopen'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Error 1
make[1]: Leaving directory `/root/httpd-2.4.7'
make: *** [all-recursive] Error 1

I have tried including the *smallestTracePoint.c* file in the local
makefile (*/root/httpd-2.4.7/MakeFile)*... didn't do me any good.
Any idea what I am doing wrong ?


LTTng version on the instance: 2.4.0-rc2 - Époque Opaque

Linux Distribution: Ubuntu 12.04.3 LTS


Thanks,


-- 
Mehran

[-- Attachment #1.2: Type: text/html, Size: 9033 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[PATCH] drm/i915: (VLV2) Fix the hotplug detection bits

[Todd Previte]

These bits are in reverse order in the header from those defined in
the specification. Change the bit positions for ports B and D to
correctly match the spec.
---
 drivers/gpu/drm/i915/i915_reg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 10ecf90..2d77b51 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2083,9 +2083,9 @@
  * Please check the detailed lore in the commit message for for experimental
  * evidence.
  */
-#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 29)
+#define   PORTD_HOTPLUG_LIVE_STATUS               (1 << 27)
 #define   PORTC_HOTPLUG_LIVE_STATUS               (1 << 28)
-#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 27)
+#define   PORTB_HOTPLUG_LIVE_STATUS               (1 << 29)
 #define   PORTD_HOTPLUG_INT_STATUS		(3 << 21)
 #define   PORTC_HOTPLUG_INT_STATUS		(3 << 19)
 #define   PORTB_HOTPLUG_INT_STATUS		(3 << 17)
-- 
1.8.3.2

(no subject)

[Todd Previte]

Addresses the comments and feedback herein. VLV2 and gen4 have separate bit
definitions now. The correct bits are selected in gen4x_dp_detect() based on
the detected platform.

(no subject)

[Konrad Rzeszutek Wilk]

This had been posted way way back:  https://lkml.org/lkml/2013/1/16/696

and the discussion about it was:
 - If there are no uses of v2, then why not rip out the support for it.
   [b/c the work for it would be in the networking code and I am still
    hoping that will be done?]
 - Why not do all of this in the toolstack. Enforce that the guest
   can only use v1 ".. if the backend isn't going to make use of them."
   (Matt).
   I am not sure how one would set up the plumbing to properly figure out
   whether the backend (say a driver domain) would communicate to hypervisor
   or XenBus that it is going to use v1 only if it has not yet started.
   (It would not have started b/c the guest hasn't started yet).

   My thinking is that once the frontend and backend start using the
   esoteric features of v2 we can rip this patch out. And also implement
   the proper code for PVHVM/PVH to actually use v2 grants.

(no subject)

[Oravil Nair]

[-- Attachment #1.1: Type: text/plain, Size: 242 bytes --]

Hi,

i915_gem_object_pin(), during i915 driver create, seems to write to the
memory written by BIOS. Where can the start address be specified to
allocate memory so that the memory written by BIOS is not overwritten at
initialization?

Thanks

[-- Attachment #1.2: Type: text/html, Size: 331 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: (no subject)

[Daniel Vetter]

On Mon, Dec 30, 2013 at 07:59:49AM +0530, Oravil Nair wrote:
> Hi,
> 
> i915_gem_object_pin(), during i915 driver create, seems to write to the
> memory written by BIOS. Where can the start address be specified to
> allocate memory so that the memory written by BIOS is not overwritten at
> initialization?

I guess you want Jesse's patches to save the screen contents from the BIOS
modeset setup? But tbh I'm not clear at all what exactly you're talking
about.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

(no subject)

[Ian Jackson]

This series removes the usleeps and waiting loops in libxl_dom.c and
replaces them with event-callback code.

Firstly, some documentation of things I had to reverse-engineer:
 01/23 xen: Document XEN_DOMCTL_subscribe
 02/23 xen: Document that EVTCHNOP_bind_interdomain signals
 03/23 docs: Document event-channel-based suspend protocol
 04/23 libxc: Document xenctrl.h event channel calls
Arguably these might be 4.4 material (hence the CC to George).

We want some additional libxl event facilities:
 05/23 libxl: init: Provide a gc later in libxl_ctx_alloc
 06/23 libxl: init: libxl__poller_init and _get take gc
 07/23 libxl: events: const-correct *_inuse, *_isregistered
 08/23 libxl: events: Provide libxl__xswait_*
 09/23 libxl: events: Use libxl__xswait_* in spawn code
 10/23 libxl: events: Provide libxl__ev_evtchn*

We need to clean up some unfortunate code in libxc:
 11/23 libxc: suspend: Rename, improve xc_suspend_evtchn_init
 12/23 libxc: suspend: Fix suspend event channel locking

We do some shuffling around of the libxl suspend control flow:
 13/23 libxl: suspend: Async libxl__domain_suspend_callback
 14/23 libxl: suspend: Async domain_suspend_callback_common
 15/23 libxl: suspend: Reorg domain_suspend_callback_common
 16/23 libxl: suspend: New libxl__domain_pvcontrol_xspath
 17/23 libxl: suspend: New domain_suspend_pvcontrol_acked
No functional change in those five.  These changes are broken down
just to make the changes reviewable.

Finally, we can start to work on the event code, removing the bugs,
usleeps and loops one at a time:
 18/23 libxl: suspend: domain_suspend_callback_common xs errs
 19/23 libxl: suspend: Async xenstore pvcontrol wait
 20/23 libxl: suspend: Abolish usleeps in domain suspend wait
 21/23 libxl: suspend: Fix suspend wait corner cases
 22/23 libxl: suspend: Async evtchn wait
 23/23 libxl: suspend: Apply guest timeout in evtchn case

I have tested this with a Debian pvops kernel (xenstore pvcontrol
suspend signalling) and OpenSUSE 11 (event channel suspend
signalling).

Shriram: I haven't really touched the Remus-specific code here but
this series ought to be suitable for you to base things on, assuming
my co-maintainers like the general approach.

Thanks,
Ian.

Re: (no subject)

[George Dunlap]

On 12/17/2013 06:35 PM, Ian Jackson wrote:
> This series removes the usleeps and waiting loops in libxl_dom.c and
> replaces them with event-callback code.
>
> Firstly, some documentation of things I had to reverse-engineer:
>   01/23 xen: Document XEN_DOMCTL_subscribe
>   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
>   03/23 docs: Document event-channel-based suspend protocol
>   04/23 libxc: Document xenctrl.h event channel calls
> Arguably these might be 4.4 material (hence the CC to George).

These document pretty important aspects of behavior (fixing what might 
be considered documentation bugs), and obviously can have no functional 
impact.  I guess the only risk is that they might be wrong and mislead 
someone, but I think that's pretty low. :-)

These four:

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Re: (no subject)

[Ian Campbell]

On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > This series removes the usleeps and waiting loops in libxl_dom.c and
> > replaces them with event-callback code.
> >
> > Firstly, some documentation of things I had to reverse-engineer:
> >   01/23 xen: Document XEN_DOMCTL_subscribe
> >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> >   03/23 docs: Document event-channel-based suspend protocol
> >   04/23 libxc: Document xenctrl.h event channel calls
> > Arguably these might be 4.4 material (hence the CC to George).
> 
> These document pretty important aspects of behavior (fixing what might 
> be considered documentation bugs), and obviously can have no functional 
> impact.  I guess the only risk is that they might be wrong and mislead 
> someone, but I think that's pretty low. :-)
> 
> These four:
> 
> Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

They look good to me too:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Re: (no subject)

[Ian Campbell]

On Wed, 2013-12-18 at 13:35 +0000, Ian Campbell wrote:
> On Wed, 2013-12-18 at 11:19 +0000, George Dunlap wrote:
> > On 12/17/2013 06:35 PM, Ian Jackson wrote:
> > > This series removes the usleeps and waiting loops in libxl_dom.c and
> > > replaces them with event-callback code.
> > >
> > > Firstly, some documentation of things I had to reverse-engineer:
> > >   01/23 xen: Document XEN_DOMCTL_subscribe
> > >   02/23 xen: Document that EVTCHNOP_bind_interdomain signals
> > >   03/23 docs: Document event-channel-based suspend protocol
> > >   04/23 libxc: Document xenctrl.h event channel calls
> > > Arguably these might be 4.4 material (hence the CC to George).
> > 
> > These document pretty important aspects of behavior (fixing what might 
> > be considered documentation bugs), and obviously can have no functional 
> > impact.  I guess the only risk is that they might be wrong and mislead 
> > someone, but I think that's pretty low. :-)
> > 
> > These four:
> > 
> > Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> They look good to me too:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

And I've now applied just those 4 docs changes.

Ian.

(no subject)

[Adel Amani]

[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

 Hello
I attach tow pic of code and error.
I try to dirty_count in function of csched_credit.c calculate... :-( But I confront to error.
now can you help me?
Thanks.

Adel Amani
M.Sc. Candidate@Computer Engineering Department, University of Isfahan
Email: A.Amani@eng.ui.ac.ir

[-- Attachment #1.2: Type: text/html, Size: 2122 bytes --]

[-- Attachment #2: pic1.png --]
[-- Type: image/png, Size: 104979 bytes --]

[-- Attachment #3: pic2.JPG --]
[-- Type: image/jpeg, Size: 11865 bytes --]

[-- Attachment #4: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(No subject)

[Flanagan, Elizabeth]

All,

With the failures we saw last night on the dylan point release, we're going to
ask folks to switch QA efforts to the dylan point release which should be
finished building shortly. The build appliance will be built out of
band in order to fix
some autobuilder build issues on it and then added to the rc2 area.

http://autobuilder.yoctoproject.org/pub/releases/dora-10.0.1.rc2

bitbake     1484905373ad717cedcaef37a0addde034ebdc60
eclipse-poky-juno     2fa1c58940141a3c547c8790b8a6832167e8eb66
eclipse-poky-kepler     ad74249895f882a8f00bdeef7a0f7c18998cc43e
meta-fsl-arm     c7cc5d5f451c9d12df9f11314f4a58ecc347b1f5
meta-fsl-ppc     b5732aeadc9eb0de933f52d0949412e12f8486bd
meta-intel     c86e39dd06571458c7dee6cf289d5b470c98f4bd
meta-minnow     edf75553643face7a0dd5b16085d59a90eb4af8d
meta-qt3     4772424ab69908d4e3b9d6d4717ca889468e6acd
oecore     d68c267f3387d7fe221d3c5653a66db8b1f78fd8
poky     7a0033cc4e1f590c5a936671f351a1b251e16726

-- 
Elizabeth Flanagan
Yocto Project
Build and Release

(no subject)

[SANTANDER ASSET FINANCE PLC]

-- 
Do you need a Loan to start or expand your business ? We give Business
Loans upto £100 million if you need funding please send sumary of your
Project to our email below: krisparker.loanagency@aim.com
Dr. Kris Parker

(No subject)

[Jacob Kroon]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

Hi,

I use the following regularly for cleaning up my build/ dir:

sstate-cache-management.sh
cleanup-workdir
wipe-sysroot

When building from sstate cache, I always get this warning:

WARNING: Setscene task 96
(/home/jkroon/Projects/oe-devel/build/../meta-fsl-arm-extra/recipes-kernel/linux/
linux-wandboard_3.0.35.bb, do_populate_sysroot_setscene) failed with exit
code '1' - real task will be run instead

And looking at the log-file for do_populate_sysroot_setscene I see:

[...snip...]
DEBUG: Shell function sstate_unpack_package finished
DEBUG: Staging files from
/home/jkroon/Projects/oe-devel/build/tmp-eglibc/work/wandboard_solo-oe-linux-gnueabi/linux-wandboard/3.0.35-r0/sysroot-destdir
to /home/jkroon/Projects/oe-devel/build/tmp-eglibc/sysroots/wandboard-solo
DEBUG: Executing shell function kernelscripts_sstate_postinst
NOTE: make scripts
make: arm-oe-linux-gnueabi-gcc: Command not found
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
make: arm-oe-linux-gnueabi-gcc: Command not found
  HOSTCC  scripts/genksyms/genksyms.o
  SHIPPED scripts/genksyms/lex.c
  SHIPPED scripts/genksyms/parse.h
  SHIPPED scripts/genksyms/keywords.c
  HOSTCC  scripts/genksyms/lex.o
  SHIPPED scripts/genksyms/parse.c
  HOSTCC  scripts/genksyms/parse.o
  HOSTLD  scripts/genksyms/genksyms
  CC      scripts/mod/empty.o
/bin/sh: arm-oe-linux-gnueabi-gcc: command not found
make[2]: *** [scripts/mod/empty.o] Error 127
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2
ERROR: oe_runmake failed
WARNING:
/home/jkroon/Projects/oe-devel/build/tmp-eglibc/work/wandboard_solo-oe-linux-gnueabi/linux-wandboard/3.0.35-r0/temp/run.kernelscripts_sstate_postinst.9263:1
exit 1 from
  [ "populate_sysroot_setscene" = "populate_sysroot" -o
"populate_sysroot_setscene" = "populate_sysroot_setscene" ]
DEBUG: Python function do_populate_sysroot_setscene finished

So it seems I don't have the cross-compiler set up at this point. Is the
kernel recipe missing some sort of dependency perhaps ?

  -- Jacob

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

(No subject)

[Jacob Kroon]

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

... and about 2 secs after I sent the previous mail I see a patch posted on
oe-core mailing list that most likely fixes the warning.
sorry for the noise
Jacob


On Tue, Nov 19, 2013 at 6:43 PM, Jacob Kroon <jacob.kroon@gmail.com> wrote:

> Hi,
>
> I use the following regularly for cleaning up my build/ dir:
>
> sstate-cache-management.sh
> cleanup-workdir
> wipe-sysroot
>
> When building from sstate cache, I always get this warning:
>
> WARNING: Setscene task 96
> (/home/jkroon/Projects/oe-devel/build/../meta-fsl-arm-extra/recipes-kernel/linux/
> linux-wandboard_3.0.35.bb, do_populate_sysroot_setscene) failed with exit
> code '1' - real task will be run instead
>
> And looking at the log-file for do_populate_sysroot_setscene I see:
>
> [...snip...]
> DEBUG: Shell function sstate_unpack_package finished
> DEBUG: Staging files from
> /home/jkroon/Projects/oe-devel/build/tmp-eglibc/work/wandboard_solo-oe-linux-gnueabi/linux-wandboard/3.0.35-r0/sysroot-destdir
> to /home/jkroon/Projects/oe-devel/build/tmp-eglibc/sysroots/wandboard-solo
> DEBUG: Executing shell function kernelscripts_sstate_postinst
> NOTE: make scripts
> make: arm-oe-linux-gnueabi-gcc: Command not found
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/kconfig/conf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf --silentoldconfig Kconfig
> make: arm-oe-linux-gnueabi-gcc: Command not found
>   HOSTCC  scripts/genksyms/genksyms.o
>   SHIPPED scripts/genksyms/lex.c
>   SHIPPED scripts/genksyms/parse.h
>   SHIPPED scripts/genksyms/keywords.c
>   HOSTCC  scripts/genksyms/lex.o
>   SHIPPED scripts/genksyms/parse.c
>   HOSTCC  scripts/genksyms/parse.o
>   HOSTLD  scripts/genksyms/genksyms
>   CC      scripts/mod/empty.o
> /bin/sh: arm-oe-linux-gnueabi-gcc: command not found
> make[2]: *** [scripts/mod/empty.o] Error 127
> make[1]: *** [scripts/mod] Error 2
> make: *** [scripts] Error 2
> ERROR: oe_runmake failed
> WARNING:
> /home/jkroon/Projects/oe-devel/build/tmp-eglibc/work/wandboard_solo-oe-linux-gnueabi/linux-wandboard/3.0.35-r0/temp/run.kernelscripts_sstate_postinst.9263:1
> exit 1 from
>   [ "populate_sysroot_setscene" = "populate_sysroot" -o
> "populate_sysroot_setscene" = "populate_sysroot_setscene" ]
> DEBUG: Python function do_populate_sysroot_setscene finished
>
> So it seems I don't have the cross-compiler set up at this point. Is the
> kernel recipe missing some sort of dependency perhaps ?
>
>   -- Jacob
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
>


-- 
  -- Jacob

[-- Attachment #2: Type: text/html, Size: 3732 bytes --]

(no subject)

[Jim Durand]

[-- Attachment #1.1: Type: text/plain, Size: 1189 bytes --]

See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen 4.2.3. Perhaps we cannot live migrate across major revs?

[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:89) [xc_save]: /usr/lib64/xen/bin/xc_save 4 35 0 0 5
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Saving memory pages: iter 1   0%ERROR Internal error: Error when writing to state file (5) (errno 104)
[2013-11-13 11:49:00 xend 29149] INFO (XendCheckpoint:353) Save exit rc=1
[2013-11-13 11:49:00 xend 29149] ERROR (XendCheckpoint:133) Save failed on domain Pasiphae2 (35).
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 110, in save
    forkHelper(cmd, fd, saveInputHandler, False)
  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 341, in forkHelper
    raise XendError("%s failed" % string.join(cmd))
XendError: /usr/lib64/xen/bin/xc_save 4 35 0 0 5 failed
[2013-11-13 11:49:00 xend.XendDomainInfo 29149] DEBUG (XendDomainInfo:2206) XendDomainInfo.resumeDomain(35)
[2013-11-13 11:49:00 xend 29149] DEBUG (XendCheckpoint:136) XendCheckpoint.save: resumeDomain



Thank you!
Jim

[-- Attachment #1.2: Type: text/html, Size: 3554 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[George Dunlap]

On Wed, Nov 13, 2013 at 7:02 PM, Jim Durand <jdurand@hrsg.ca> wrote:
> See log errors below, trying to live migrate VM's from Xen 3.1.2 -> Xen
> 4.2.3. Perhaps we cannot live migrate across major revs?

According to http://wiki.xen.org/wiki/Xen_Version_Compatibility :

"Xen supports migration (including live migration and save restore)
both within a stable release branch (e.g. between any versions in the
4.2.x branch) and from one major release to the next (e.g. from
release N to releaseN+1). This allows one to upgrade a pool of Xen
hosts by evacuating and upgrading the hosts one by one.

"Although it is not formally supported skipping a major release (e.g.
migration from release N to release N+2) may often work. "

Unfortunately that would mean 3.1 -> 3.2 -> 3.3 -> 3.4 -> 4.0 -> 4.1
-> 4.2... at that point shutting down the VM and starting it back up
again looks like the more attractive option.

 -George

(No subject)

[Otavio Salvador]

Subject: Updates to meta-fsl-arm-extra (dora) in 2013-10-19
Hello,

I pushed following updates:

commit 1a9cd5ef40580eca705b53b8dcb7b92baa73d293
Author: Otavio Salvador <otavio@ossystems.com.br>
Date:   Tue Oct 15 16:43:39 2013 -0300

    gk802: Remove board support
    
    The gk802 is not being actively maintained at this moment and it lacks
    support for current GPU version.
    
    This patch remove the board and specific recipes and can be reverted
    later when a better support is provided for this board.
    
    Change-Id: I0575c244945d7b4ee78ac47aae5c4a5d0bfbd793
    Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>

Regards,

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

(No subject)

[João Henrique Freitas]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Hello,

I am new to TI boards.

Could I use meta-ti (master) and yocto (1.5, dora) ? Any issue combining
these two versions?

My target platform is am3517-evm.

Thanks.
-- 
João Henrique Ferreira de Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil

[-- Attachment #2: Type: text/html, Size: 498 bytes --]

(No subject)

[Denys Dmytriyenko]

On Tue, Oct 08, 2013 at 11:19:33AM -0300, João Henrique Freitas wrote:
> Hello,
> 
> I am new to TI boards.
> 
> Could I use meta-ti (master) and yocto (1.5, dora) ? Any issue combining
> these two versions?

Since dora release is not out yet, I haven't branched off meta-ti yet. So, 
meta-ti/master should still work with oe-core/dora for now. 


> My target platform is am3517-evm.

The only problem I could see is that am3517-evm is an old platform that uses 
2.6.37 kernel and may not be fully compatible with modern user-space. There 
were some syscall requirements in latest udev/systemd that are not compatible 
with that old kernel...

-- 
Denys

"Kernel access of bad area" in kernel module

[Jack]

Hi,
I want to set/reset GPIO registers in freescale p1022 processor. I saw a
hello-mod kernel module in yocto and I added it to my image and it worked.
According to hello-mod kernel module, I created GPIO module like hello-mod.
But it GPIO module failed when I run it in kernel level. I checked several
times addresses of registers and it seems accurate. 
My code is here :


#include <linux/module.h>

int init_module(void)
{
	volatile uint32_t * Guts_Pmuxcr;
	volatile uint32_t * Gpio3_Gpdir;
	volatile uint32_t * Gpio3_Gpdat;
	
	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000

       // GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
	Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
      
        // GPIO3_GPDIR: GPIO3 direction register
	Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);

        // GPIO3_GPDAT: GPIO3 data register
	Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208); 
	 

	// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to "1"
	*(Guts_Pmuxcr) = 0x00000010;
	 

	// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to '1'
	*(Gpio3_Gpdir) = 0x00200000;
	
	 
	// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
	*(Gpio3_Gpdat) = 0x00000000;
	
	printk("Hello World!\n");
	return 0;
}

void cleanup_module(void)
{
	printk("Goodbye Cruel World!\n");
}

MODULE_LICENSE("GPL");


When I write insmod GPIO.ko in the terminal I get error these errors:

Unable to handle kernel paging request for data at address 0xff7e0060
faulting instruction address: 0xf107e05c
Oops: Kernel access of bad area, sig: 11 [#1]
..........
.........


How can I solve this problem?

Re: "Kernel access of bad area" in kernel module

[Anders Darander]

Jack <jackrubby2010@gmail.com> wrote:
>Hi,
>I want to set/reset GPIO registers in freescale p1022 processor. I saw
>a
>hello-mod kernel module in yocto and I added it to my image and it
>worked.
>According to hello-mod kernel module, I created GPIO module like
>hello-mod.
>But it GPIO module failed when I run it in kernel level. I checked
>several
>times addresses of registers and it seems accurate. 
>My code is here :
>
>
>#include <linux/module.h>
>
>int init_module(void)
>{
>	volatile uint32_t * Guts_Pmuxcr;
>	volatile uint32_t * Gpio3_Gpdir;
>	volatile uint32_t * Gpio3_Gpdat;
>	
>	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000
>
>    // GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
>	Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
>      
>        // GPIO3_GPDIR: GPIO3 direction register
>	Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
>
>        // GPIO3_GPDAT: GPIO3 data register
>	Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208); 

You should generally a of trying to dereference physical addresses, or you should explicitly declare them as such. 

If suggest looking for some info on using GPIO on your CPU. Unfortunately, I've not used the p1022, so I can't really help you. 

http://linuxppc.10917.n7.nabble.com/Re-GPIO-IRQ-on-P1022-td59356.html discusses some IRQ issues, though you should be able to use the codes as an example of the GPIO framework and how to use it. 

Cheers, 
Anders 

>
>	// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to "1"
>	*(Guts_Pmuxcr) = 0x00000010;
>


>
>	// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to
>'1'
>	*(Gpio3_Gpdir) = 0x00200000;
>	
>	 
>	// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
>	*(Gpio3_Gpdat) = 0x00000000;
>	
>	printk("Hello World!\n");
>	return 0;
>}
>
>void cleanup_module(void)
>{
>	printk("Goodbye Cruel World!\n");
>}
>
>MODULE_LICENSE("GPL");
>
>
>When I write insmod GPIO.ko in the terminal I get error these errors:
>
>Unable to handle kernel paging request for data at address 0xff7e0060
>faulting instruction address: 0xf107e05c
>Oops: Kernel access of bad area, sig: 11 [#1]
>..........
>.........
>
>
>How can I solve this problem?
>
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

-- 
Anders Darander
ChargeStorm AB          Tel: +46 702 44 84 36
Laxholmstorget 3        Email: anders@chargestorm.se
602 21 Norrköping       Web: www.chargestorm.se

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

(No subject)

[Jack]

Anders Darander <anders@...> writes:

> 
> 
> Jack <jackrubby2010 <at> gmail.com> wrote:
> >Hi,
> >I want to set/reset GPIO registers in freescale p1022 processor. I saw
> >a
> >hello-mod kernel module in yocto and I added it to my image and it
> >worked.
> >According to hello-mod kernel module, I created GPIO module like
> >hello-mod.
> >But it GPIO module failed when I run it in kernel level. I checked
> >several
> >times addresses of registers and it seems accurate. 
> >My code is here :
> >
> >
> >#include <linux/module.h>
> >
> >int init_module(void)
> >{
> >	volatile uint32_t * Guts_Pmuxcr;
> >	volatile uint32_t * Gpio3_Gpdir;
> >	volatile uint32_t * Gpio3_Gpdat;
> >	
> >	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000
> >
> >    // GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
> >	Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
> >      
> >        // GPIO3_GPDIR: GPIO3 direction register
> >	Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
> >
> >        // GPIO3_GPDAT: GPIO3 data register
> >	Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208); 
> 
> You should generally a of trying to dereference physical addresses, or you
should explicitly declare them
> as such. 
> 
> If suggest looking for some info on using GPIO on your CPU. Unfortunately,
I've not used the p1022, so I can't
> really help you. 
> 
> http://linuxppc.10917.n7.nabble.com/Re-GPIO-IRQ-on-P1022-td59356.html
discusses some IRQ
> issues, though you should be able to use the codes as an example of the
GPIO framework and how to use it. 
> 
> Cheers, 
> Anders 
> 
> >
> >	// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to "1"
> >	*(Guts_Pmuxcr) = 0x00000010;
> >
> 
> >
> >	// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to
> >'1'
> >	*(Gpio3_Gpdir) = 0x00200000;
> >	
> >	 
> >	// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
> >	*(Gpio3_Gpdat) = 0x00000000;
> >	
> >	printk("Hello World!\n");
> >	return 0;
> >}
> >
> >void cleanup_module(void)
> >{
> >	printk("Goodbye Cruel World!\n");
> >}
> >
> >MODULE_LICENSE("GPL");
> >
> >
> >When I write insmod GPIO.ko in the terminal I get error these errors:
> >
> >Unable to handle kernel paging request for data at address 0xff7e0060
> >faulting instruction address: 0xf107e05c
> >Oops: Kernel access of bad area, sig: 11 [#1]
> >..........
> >.........
> >
> >
> >How can I solve this problem?
> >
> >
> >_______________________________________________
> >yocto mailing list
> >yocto <at> yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/yocto
> 

Thanks Anders,

But I have this problem not only for GPIOs, but also for other registers.
For example, I tried to change DTW bits of PROCTL register in eSDH but I get
"Kernel access of bad area" again. My simple code is here :

#include <linux/module.h>

int init_module(void)
{
	
	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000
	
	volatile uint32_t * eSDH_PROCTL = (volatile uint32_t *)(0xFF72E028);

	*(eSDH_PROCTL) = 0x00000002;

	return 0;
}

void cleanup_module(void)
{
	printk("Goodbye Cruel World!\n");
}

MODULE_LICENSE("GPL");

What should I do? Can you help me?

(No subject)

[Anders Darander]

Jack <jackrubby2010@gmail.com> wrote:
>Anders Darander <anders@...> writes:
>
>Thanks Anders,
>
>But I have this problem not only for GPIOs, but also for other
>registers.

Well, my comment about dereferencing physical addresses using *-only, wasn't restricted to GPIO's only. It was regarding physical addresses in general... 

Once again, I've not used this platform, this I'm not able to be too specific. 

>For example, I tried to change DTW bits of PROCTL register in eSDH but
>I get
>"Kernel access of bad area" again. My simple code is here :

>int init_module(void)
>{
>	
>	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000
>	
>	volatile uint32_t * eSDH_PROCTL = (volatile uint32_t *)(0xFF72E028);
>
>	*(eSDH_PROCTL) = 0x00000002;

I think that you should try to look at some code from the kernel that accesses registers on your platform. For instance http://lxr.free-electrons.com/source/sound/soc/fsl/p1022_ds.c?v=3.4 (this is just a randomly chosen file that relates to P1022. 

Have a look at how guts_phys is declared, as well as how guts later on is both declared and initialized from guts_phys. 
When the registers are actually read / written, this driver uses the clrsetbits_XX. These functions then implements the actual reading and writing of the registers. 

(Note again, I've just looked at this file and p1022 for a couple of minutes). 

Cheers, 
Anders 

-- 
ChargeStorm AB / eStorm 

(No subject)

[Jack]

Anders Darander <anders@...> writes:

> 
> 
> Jack <jackrubby2010@...> wrote:
> >Anders Darander <anders <at> ...> writes:
> >
> >Thanks Anders,
> >
> >But I have this problem not only for GPIOs, but also for other
> >registers.
> 
> Well, my comment about dereferencing physical addresses using *-only,
wasn't restricted to GPIO's only.
> It was regarding physical addresses in general... 
> 
> Once again, I've not used this platform, this I'm not able to be too
specific. 
> 
> >For example, I tried to change DTW bits of PROCTL register in eSDH but
> >I get
> >"Kernel access of bad area" again. My simple code is here :
> 
> >int init_module(void)
> >{
> >	
> >	// e500 Core View To Power Architecture CCSR: 0x0_FF70_0000
> >	
> >	volatile uint32_t * eSDH_PROCTL = (volatile uint32_t *)(0xFF72E028);
> >
> >	*(eSDH_PROCTL) = 0x00000002;
> 
> I think that you should try to look at some code from the kernel that
accesses registers on your platform. For
> instance
http://lxr.free-electrons.com/source/sound/soc/fsl/p1022_ds.c?v=3.4 (this is
just a
> randomly chosen file that relates to P1022. 
> 
> Have a look at how guts_phys is declared, as well as how guts later on is
both declared and initialized from
> guts_phys. 
> When the registers are actually read / written, this driver uses the
clrsetbits_XX. These functions then
> implements the actual reading and writing of the registers. 
> 
> (Note again, I've just looked at this file and p1022 for a couple of
minutes). 
> 
> Cheers, 
> Anders 
> 

Thank you very much Anders for useful comments and replies,

I saw the link that you mentioned and I could write in pmuxcr register. So
writing to register problem almost has solved. But I have some problems yet.

I read fsl_guts.h in powerpc architecture and saw Global Utility Registers
like gpiocr as GPIO Control Register, gpindr as General-Purpose Input Data
Register and gpoutdr as General-Purpose Output Data Register. But in GPIO
registers in p1022 reference manual we have GPDIR register to set specify
GPIO direction and GPDAT register for GPIO data register. We have only one
register for data but fsl_guts.h defines two register for input an output data.
 

Does gpiocr work as GPDIR?

For GPDAT, which of the two registers I should use? gpindr or gpoutdr?

 
Thanks,

Best regards. 

(no subject)

[David Vrabel]

This is an RFC of Linux guest-side implementation of the FIFO-based
event channel ABI described in this design document:

http://xenbits.xen.org/people/dvrabel/event-channels-E.pdf

Refer also to the Xen series.

Remaining work:

* Add an function to set a event channel's priority and use this to
  set the VIRQ timer to the highest priority.

Patch 1 is a obvious refactoring of common code.

Patch 2-6 prepare for supporting multiple ABIs.

Patch 7 adds the low-level evtchn_ops hooks.

Patch 8-9 add an additional hook for ABI-specific per-port setup
(used for expanding the event array as more event are bound).

Patch 10 allows many more event channels to be supported by altering
how the event channel to irq map is allocated.  Note that other
factors limit the number of supported IRQs (IRQs is 8192 + 64 *
NR_CPUS).

Patch 11 is some trival refactoring.

Patch 12-13 add the ABI and the implementation.

David

(No subject)

[arun kumar]

(No subject)

[Andy Ng]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

Dear List,

I try to build Poky and the final rootfs image doesn't not mount with the
following problem:

----------------------8<-------------------------8<------------------------------
BIFS: mounted UBI device 0, volume 0, name "polatisnic-rootfs"
UBIFS: mounted read-only
UBIFS: file system size:   10737408 bytes (10485 KiB, 10 MiB, 82 LEBs)
UBIFS: journal size:       1964160 bytes (1918 KiB, 1 MiB, 15 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root:  0 bytes (0 KiB)
VFS: Mounted root (ubifs filesystem) readonly on device 0:14.
devtmpfs: mounted
Freeing init memory: 208K
INIT: version 2.88 booting
mount: permission denied (are you root?)
mount: permission denied (are you root?)
grep: /proc/filesystems: No such file or directory
mount: permission denied (are you root?)
grep: /proc/mounts: No such file or directory
grep: /proc/mounts: No such file or directory
Remounting root file system...
mount: can't read '/etc/mtab': No such file or directory
------------------------8<-----------------------------------8<------------------

After a bit of research, I have found out that the busybox was populated in
the rootfs
under ownership of "andreas:andreas" instead of "root:root", and its
symbolic links under "root:root"

I fixed manually the ownership and it booted  up.

Does anyone knows what might be going wrong in my build process?

Any guidance would be very helpful.

Thank you
Andreas

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

(no subject)

[yvxiang]

[-- Attachment #1.1: Type: text/plain, Size: 147 bytes --]

Hi,Agya,

Now I need to measure the downtime while doing a live migration. I saw your
mail before about this topic.  How did you measure the time?

[-- Attachment #1.2: Type: text/html, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[yvxiang]

[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]

So sorry,I forgot the subject..


2013/8/14 yvxiang <linyvxiang@gmail.com>

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

[-- Attachment #1.2: Type: text/html, Size: 829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[agya naila]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

Hi,

In my case I used the live migration for VoIP service. I make a simple
measurement by using wireshark,  I generate the call and then shut down one
of my virtual machine. Then using packet captured via wireshark I generate
the jitter using telephony RTP stream anaysis. If you read the report you
may see the maximum delta that correlated to the downtime in my case for my
voip service.

Best Regards,


Agya


On Wed, Aug 14, 2013 at 9:28 AM, yvxiang <linyvxiang@gmail.com> wrote:

> Hi,Agya,
>
> Now I need to measure the downtime while doing a live migration. I saw
> your mail before about this topic.  How did you measure the time?
>

[-- Attachment #1.2: Type: text/html, Size: 1207 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Chih-Chung Chang]

This is a revised patch which also checks if the mic is external.

(No subject)

[Joe MacDonald]

Forwarding a patch I received last week from Colin Walters.  Initially I
thought it was duplicating the patch for cyrus-sasl from Roy Li, but it
actaully seems to be solving a related problem that isn't quite the same.
If anything, it looks like perhaps the earlier change may make the thing
Colin was fixing more common.

-- 
-Joe MacDonald.
:wq

(no subject)

[Tim Deegan]

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
Reply-To: 
In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>

At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> Everywhere currently passes "sy"stem, so no actual change.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

[PATCH 08/10] xen: arm: add scope to dsb and dmb macros

[Ian Campbell]

Everywhere currently passes "sy"stem, so no actual change.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain.c                |    2 +-
 xen/arch/arm/gic.c                   |    8 ++++----
 xen/arch/arm/mm.c                    |    2 +-
 xen/arch/arm/platforms/vexpress.c    |    6 +++---
 xen/arch/arm/smpboot.c               |    2 +-
 xen/arch/arm/time.c                  |    2 +-
 xen/drivers/video/arm_hdlcd.c        |    2 +-
 xen/include/asm-arm/arm32/flushtlb.h |    8 ++++----
 xen/include/asm-arm/arm32/io.h       |    4 ++--
 xen/include/asm-arm/arm32/page.h     |    4 ++--
 xen/include/asm-arm/arm64/io.h       |    4 ++--
 xen/include/asm-arm/arm64/page.h     |    4 ++--
 xen/include/asm-arm/page.h           |    4 ++--
 xen/include/asm-arm/system.h         |   16 ++++++++--------
 14 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4c434a1..0bd8f6b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -44,7 +44,7 @@ void idle_loop(void)
         local_irq_disable();
         if ( cpu_is_haltable(smp_processor_id()) )
         {
-            dsb();
+            dsb("sy");
             wfi();
         }
         local_irq_enable();
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 177560e..42095ee 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -432,7 +432,7 @@ void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
 
     ASSERT(mask < 0x100); /* The target bitmap only supports 8 CPUs */
 
-    dsb();
+    dsb("sy");
 
     GICD[GICD_SGIR] = GICD_SGI_TARGET_LIST
         | (mask<<GICD_SGI_TARGET_SHIFT)
@@ -449,7 +449,7 @@ void send_SGI_self(enum gic_sgi sgi)
 {
     ASSERT(sgi < 16); /* There are only 16 SGIs */
 
-    dsb();
+    dsb("sy");
 
     GICD[GICD_SGIR] = GICD_SGI_TARGET_SELF
         | sgi;
@@ -459,7 +459,7 @@ void send_SGI_allbutself(enum gic_sgi sgi)
 {
    ASSERT(sgi < 16); /* There are only 16 SGIs */
 
-   dsb();
+   dsb("sy");
 
    GICD[GICD_SGIR] = GICD_SGI_TARGET_OTHERS
        | sgi;
@@ -546,7 +546,7 @@ static int __setup_irq(struct irq_desc *desc, unsigned int irq,
 
     desc->action  = new;
     desc->status &= ~IRQ_DISABLED;
-    dsb();
+    dsb("sy");
 
     desc->handler->startup(desc);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 3f049cb..b287a9b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -324,7 +324,7 @@ void __cpuinit setup_virt_paging(void)
 #define WRITE_TTBR(ttbr)                                                \
     flush_xen_text_tlb();                                               \
     WRITE_SYSREG64(ttbr, TTBR0_EL2);                                    \
-    dsb(); /* ensure memory accesses do not cross over the TTBR0 write */ \
+    dsb("sy"); /* ensure memory accesses do not cross over the TTBR0 write */ \
     /* flush_xen_text_tlb contains an initial isb which ensures the     \
      * write to TTBR0 has completed. */                                 \
     flush_xen_text_tlb()
diff --git a/xen/arch/arm/platforms/vexpress.c b/xen/arch/arm/platforms/vexpress.c
index 8fc30c4..6f6869e 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -46,7 +46,7 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int write,
     /* wait for complete flag to be set */
     do {
         stat = syscfg[V2M_SYS_CFGSTAT/4];
-        dsb();
+        dsb("sy");
     } while ( !(stat & V2M_SYS_CFG_COMPLETE) );
 
     /* check error status and return error flag if set */
@@ -111,10 +111,10 @@ static void vexpress_reset(void)
 
     /* switch to slow mode */
     iowritel(sp810, 0x3);
-    dsb(); isb();
+    dsb("sy"); isb();
     /* writing any value to SCSYSSTAT reg will reset the system */
     iowritel(sp810 + 4, 0x1);
-    dsb(); isb();
+    dsb("sy"); isb();
 
     iounmap(sp810);
 }
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 727e09f..b88355f 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -211,7 +211,7 @@ void stop_cpu(void)
     local_irq_disable();
     cpu_is_dead = 1;
     /* Make sure the write happens before we sleep forever */
-    dsb();
+    dsb("sy");
     isb();
     while ( 1 )
         wfi();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 4ed7882..2c254f4 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -252,7 +252,7 @@ void udelay(unsigned long usecs)
     s_time_t deadline = get_s_time() + 1000 * (s_time_t) usecs;
     while ( get_s_time() - deadline < 0 )
         ;
-    dsb();
+    dsb("sy");
     isb();
 }
 
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
index 72979ea..5c09b0e 100644
--- a/xen/drivers/video/arm_hdlcd.c
+++ b/xen/drivers/video/arm_hdlcd.c
@@ -77,7 +77,7 @@ void (*video_puts)(const char *) = vga_noop_puts;
 
 static void hdlcd_flush(void)
 {
-    dsb();
+    dsb("sy");
 }
 
 static int __init get_color_masks(const char* bpp, struct color_masks **masks)
diff --git a/xen/include/asm-arm/arm32/flushtlb.h b/xen/include/asm-arm/arm32/flushtlb.h
index 14e8827..2776375 100644
--- a/xen/include/asm-arm/arm32/flushtlb.h
+++ b/xen/include/asm-arm/arm32/flushtlb.h
@@ -4,22 +4,22 @@
 /* Flush local TLBs, current VMID only */
 static inline void flush_tlb_local(void)
 {
-    dsb();
+    dsb("sy");
 
     WRITE_CP32((uint32_t) 0, TLBIALLIS);
 
-    dsb();
+    dsb("sy");
     isb();
 }
 
 /* Flush local TLBs, all VMIDs, non-hypervisor mode */
 static inline void flush_tlb_all_local(void)
 {
-    dsb();
+    dsb("sy");
 
     WRITE_CP32((uint32_t) 0, TLBIALLNSNHIS);
 
-    dsb();
+    dsb("sy");
     isb();
 }
 
diff --git a/xen/include/asm-arm/arm32/io.h b/xen/include/asm-arm/arm32/io.h
index ec7e0ff..cb0bc96 100644
--- a/xen/include/asm-arm/arm32/io.h
+++ b/xen/include/asm-arm/arm32/io.h
@@ -30,14 +30,14 @@ static inline uint32_t ioreadl(const volatile void __iomem *addr)
     asm volatile("ldr %1, %0"
                  : "+Qo" (*(volatile uint32_t __force *)addr),
                    "=r" (val));
-    dsb();
+    dsb("sy");
 
     return val;
 }
 
 static inline void iowritel(const volatile void __iomem *addr, uint32_t val)
 {
-    dsb();
+    dsb("sy");
     asm volatile("str %1, %0"
                  : "+Qo" (*(volatile uint32_t __force *)addr)
                  : "r" (val));
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index e573502..f8dfbd3 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -67,13 +67,13 @@ static inline void flush_xen_data_tlb(void)
 static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
 {
     unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
+    dsb("sy"); /* Ensure preceding are visible */
     while ( va < end ) {
         asm volatile(STORE_CP32(0, TLBIMVAHIS)
                      : : "r" (va) : "memory");
         va += PAGE_SIZE;
     }
-    dsb(); /* Ensure completion of the TLB flush */
+    dsb("sy"); /* Ensure completion of the TLB flush */
     isb();
 }
 
diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index ec041cd..0a100ad 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -24,14 +24,14 @@ static inline uint32_t ioreadl(const volatile void __iomem *addr)
     uint32_t val;
 
     asm volatile("ldr %w0, [%1]" : "=r" (val) : "r" (addr));
-    dsb();
+    dsb("sy");
 
     return val;
 }
 
 static inline void iowritel(const volatile void __iomem *addr, uint32_t val)
 {
-    dsb();
+    dsb("sy");
     asm volatile("str %w0, [%1]" : : "r" (val), "r" (addr));
 }
 
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 28748d3..aca1590 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -60,13 +60,13 @@ static inline void flush_xen_data_tlb(void)
 static inline void flush_xen_data_tlb_range_va(unsigned long va, unsigned long size)
 {
     unsigned long end = va + size;
-    dsb(); /* Ensure preceding are visible */
+    dsb("sy"); /* Ensure preceding are visible */
     while ( va < end ) {
         asm volatile("tlbi vae2is, %0;"
                      : : "r" (va>>PAGE_SHIFT) : "memory");
         va += PAGE_SIZE;
     }
-    dsb(); /* Ensure completion of the TLB flush */
+    dsb("sy"); /* Ensure completion of the TLB flush */
     isb();
 }
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index cd38956..eb007ac 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -284,10 +284,10 @@ extern size_t cacheline_bytes;
 static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 {
     void *end;
-    dsb();           /* So the CPU issues all writes to the range */
+    dsb("sy");           /* So the CPU issues all writes to the range */
     for ( end = p + size; p < end; p += cacheline_bytes )
         asm volatile (__flush_xen_dcache_one(0) : : "r" (p));
-    dsb();           /* So we know the flushes happen before continuing */
+    dsb("sy");           /* So we know the flushes happen before continuing */
 }
 
 /* Macro for flushing a single small item.  The predicate is always
diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h
index 89c61ef..68efba9 100644
--- a/xen/include/asm-arm/system.h
+++ b/xen/include/asm-arm/system.h
@@ -13,16 +13,16 @@
 #define wfi()           asm volatile("wfi" : : : "memory")
 
 #define isb()           asm volatile("isb" : : : "memory")
-#define dsb()           asm volatile("dsb sy" : : : "memory")
-#define dmb()           asm volatile("dmb sy" : : : "memory")
+#define dsb(scope)      asm volatile("dsb " scope : : : "memory")
+#define dmb(scope)      asm volatile("dmb " scope : : : "memory")
 
-#define mb()            dsb()
-#define rmb()           dsb()
-#define wmb()           dsb()
+#define mb()            dsb("sy")
+#define rmb()           dsb("sy")
+#define wmb()           dsb("sy")
 
-#define smp_mb()        dmb()
-#define smp_rmb()       dmb()
-#define smp_wmb()       dmb()
+#define smp_mb()        dmb("sy")
+#define smp_rmb()       dmb("sy")
+#define smp_wmb()       dmb("sy")
 
 #define xchg(ptr,x) \
         ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
-- 
1.7.2.5

Re: (no subject)

[Tim Deegan]

Oops, a wandering newline seems to have got into the headers here. :)

Tim.

At 12:32 +0100 on 04 Jul (1372941166), Tim Deegan wrote:
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] [PATCH 08/10] xen: arm: add scope to dsb and dmb macros
> Reply-To: 
> In-Reply-To: <1372435856-14040-8-git-send-email-ian.campbell@citrix.com>
> 
> At 17:10 +0100 on 28 Jun (1372439454), Ian Campbell wrote:
> > Everywhere currently passes "sy"stem, so no actual change.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

(no subject)

[Divya Kapil]

How can i change migration code in xen?

Re: (no subject)

[Ian Campbell]

On Wed, 2013-06-26 at 17:12 +0530, Divya Kapil wrote:
> How can i change migration code in xen?

I'm sorry but your question is so vague as to be unanswerable with
anything other than a snide remark like "with vi or emacs".

http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

Ian.

(no subject)

[wei.liu2]

We would like you to answer the following questions (feel free to
write up your own report if you're a power user):

* What's the sotware setup?
  * Dom0: e.g. 64 bit CentOS 6.2
  * DomU: e.g. Debian Wheezy
  * Xen: e.g. 4.1 installed with apt-get / 4.2 compiled from tarball
  * toolstack: xl / xm / libvirt ...

* What's the hardware setup?

* What were you trying to achieve?

* What commands did you run?

* What's the expected outcome?

* What's the actual outcome?

[No subject]

[Giovane]

http://alexanderlattagardens.co.uk/gdjxy/mevffylewqfsthznvp.hfkvrosf

(no subject)

[Antonio Quartulli]

Hello David,

this is another small patch for net/linux-3.10. It is preventing a double free
of the bat_counters in case of mesh initialisation failure.

Sorry for sending such small pull requests (I guess this is not that bad since
they target net :-)), but these are small glitches we are finding while testing
new features.

Please pull or let me know if there is any problem.

Thanks a lot,
	Antonio


The following changes since commit 3ccfc1b1d2fa78f8ece83646027982916fcc794b:

  Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2013-05-20 14:05:22 -0700)

are available in the git repository at:


  git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem

for you to fetch changes up to f69ae770e74df420fbcf93aae81b30a5dcc73b7d:

  batman-adv: Avoid double freeing of bat_counters (2013-05-21 21:34:36 +0200)

----------------------------------------------------------------
Included change:
- fix double free in case of failure during mesh initialisation

----------------------------------------------------------------
Martin Hundebøll (1):
      batman-adv: Avoid double freeing of bat_counters

 net/batman-adv/main.c           | 1 +
 net/batman-adv/soft-interface.c | 1 +
 2 files changed, 2 insertions(+)

Re: (no subject)

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Tue, May 21, 2013 at 09:53:54PM +0200, Antonio Quartulli wrote:
> Hello David,

Sorry but git-send-email fooled me. Subject was supposed to be:

pull request for net: batman-adv 2013-05-21

Regards,

> 
> this is another small patch for net/linux-3.10. It is preventing a double free
> of the bat_counters in case of mesh initialisation failure.
> 
> Sorry for sending such small pull requests (I guess this is not that bad since
> they target net :-)), but these are small glitches we are finding while testing
> new features.
> 
> Please pull or let me know if there is any problem.
> 
> Thanks a lot,
> 	Antonio

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

(no subject)

[Feng Tang]

Bcc: 
Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on system time step changes
Reply-To: 

Hi David,

> From: David Vrabel <david.vrabel@citrix.com>
> Date: 2013/5/14
> Subject: Re: [PATCH 2/3] timekeeping: sync persistent clock and RTC on
> system time step changes
> To: John Stultz <john.stultz@linaro.org>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Konrad
> Rzeszutek Wilk <konrad.wilk@oracle.com>, Thomas Gleixner
> <tglx@linutronix.de>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
> 
> 
> On 14/05/13 01:40, John Stultz wrote:
> > On 05/13/2013 10:56 AM, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> The persistent clock or the RTC is only synchronized with system time
> >> every 11 minutes if NTP is running.  This gives a window where the
> >> persistent clock may be incorrect after a step change in the time
> >> (such as on first boot).
> >>
> >> This particularly affects Xen guests as until an update to the control
> >> domain's persistent clock, new guests will start with the incorrect
> >> system time.
> >>
> >> When there is a step change in the system time, call
> >> update_persistent_clock or rtc_set_ntp_time() to synchronize the
> >> persistent clock or RTC to the new system time.
> >
> > I'm sorry, this isn't quite making sense to me. Could you further
> > describe the exact problematic behavior you're seeing here, and why its
> > a problem?
> 
> The Xen wallclock is used as the persistent clock for Xen guests.  This
> is initialized (by Xen) with the CMOS RTC at the start of day.  If the
> RTC is incorrect then guests will see an incorrect wallclock time until
> dom0 has corrected it.
> 
> Currently dom0 only updates the Xen wallclock with the 11 min periodic
> work when NTP is synced.  This leaves a window where newly started
> guests will see an incorrect wallclock time.  This can cause guests to
> fail to start correctly if the wallclock is now behind what it was when
> the guest last started. (e.g., fsck of its disk fails as its last mount
> time appears to be far into the future).

Is it possible for Xen to resync its wallclock time from the RTC device
whenever it gets a request of starting a new guest? as usually a new
guest OS needs to get the time base from Xen's wallclock anyway.

Thanks,
Feng

(no subject)

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

> Subject: Looking for volunteer to help man LinuxCon Japan booth (1-2 hours
> a day)
>
> Dear Community member,
>
> the Xen Project was planning to have a booth at LinuxCon Japan this year
> (for more information, see
> http://events.linuxfoundation.org/events/linuxcon-japan/<https://mail.citrix.com/owa/redir.aspx?C=dnbPGSChGEWoACoWH_QLpH7EveZxG9BIE6cabrXu0jA-wgQqxbnVAgQREizU60s78z6uEa6Tkac.&URL=http%3a%2f%2fevents.linuxfoundation.org%2fevents%2flinuxcon-japan%2f>).
We are
> looking for one or two users (or developers of Xen) to help out a couple
> of hours a day on the Xen Project booth. I am looking for people who know
> Xen, XAPI or XCP, speak Japanese and want to spend an hour or two a day
> on the booth with me and a few other community members. If this is you,
> please get in touch!
>
> I will be able to get you a free conference pass for LinuxCon. If this is
> you and you would like to attend LinuxCon, but cannot afford it, we do
have
> a number of travel stipends available. In that case, please also send me
> an e-mail.
>
> Best Regards
> Lars


-----

みなさま、こんにちは

The Xen Community ManagerのLars Kurthです。



The Xen Projectコミュニティでは、5/29 - 31 椿山荘で開催されるLinuxCon Japan / CloudOpen Japan
にて展示ブースを出す予定です。

https://events.linuxfoundation.jp/events/linuxcon-japan

https://events.linuxfoundation.jp/events/cloudopen-japan



そこで展示ブーススタッフを募集しています。OSS Xenの開発者、ユーザー、

その他関連各位で、半日でも、１日でもお時間が取れる方がいらっしゃれば

ご連絡いただければと思います。



もちろん、ブーススタッフとして協力いただける方には、

LinuxCon Japan / CloudOpen Japan のFree Passチケットをお渡しします。



よろしくお願いいたします。



連絡先

Lars Kurth lars.kurth@citrix.com  (英語)
Kimihiko Kitase Kimihiko.Kitase@citrix.co.jp (日本語)

[-- Attachment #1.2: Type: text/html, Size: 8578 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Lonnie Cumberland]

[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]

Greetings All,

I am very new to Xen but have spent a considerable amount of time
researching various emulators and simulators like QEMU, Virtualbox, Bochs,
etc.... to find out which may be good for a project that I am interested in
moving towards related to the x86_64 platform.

It seems that XEN may be the best solution as I need something that can be
billed as a Type I and also Type II emulator. Xen and HXen meet these goals.

Now I am entering the learning curve to get a feel for the source code but
had a question related to the layout of Xen.

I am trying to understand where the main init functions are in Xen as for
example in QEMU they are in the v1.c file and as to where the mian loops
are for the hypervisor are to loop through the vCPU's.

I am also trying to get a feel for where the memory allocation functions
are in Xen.

Also, in the Xen 4.2.1 distro, is qemu called for each HPV.

Please forgive these questions if they should be obvious to me, but I would
like to get a good feel for the booting sequence and control loops that Xen
has to utilize.

I have read a number of documents on the website that give me briev
overview of how Xen operates with  Dom0 and DomU guests but now it is time
for me to get a feel for the sources so that I might be able to learn and
contribute to the effort of a very wonderful hypervisor.

Any guidance or help would be greatly appreciated.

Kind Regards and have a great day,
Lonnie T. Cumberland

[-- Attachment #1.2: Type: text/html, Size: 1866 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[jacek burghardt]

[-- Attachment #1.1: Type: text/plain, Size: 250 bytes --]

Does xcp supports assignment of USB or xen-api ? I know that spice allows
for USB redirection. Also remote desktop supports redirection of devices. I
like using android devices with xen hosted servers as remote desktop
exports my SD cards to server.

[-- Attachment #1.2: Type: text/html, Size: 258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[Mina Jafari]

[-- Attachment #1.1: Type: text/plain, Size: 3275 bytes --]

I can't install any guest vm,(I'm trying this on Fedora13 and kernel
3.2.7,compiled as dom0 and xen 4.1.2)
virt-manager connect to xen but when trying to create a new guest it
fails with this error:

Unable to complete install: 'POST operation failed: xend_post: error
from xen daemon: (xend.err 'Device 0 (vif) could not be connected.
Hotplug scripts not working.')'
operation failed: xend_post: error from xen daemon: (xend.err 'Device
0 (vif) could not be connected. Hotplug scripts not working.')
Traceback (most recent call last):
  File "/usr/share/virt-manager/
virtManager/create.py", line 1567, in
do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1023, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1088, in _do_install
    "install")
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line
1059, in _create_guest
    dom = self.conn.createLinux(start_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1277, in
createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Device 0 (vif) could not be connected. Hotplug scripts not
working.')

and the same problem when creating by commandline.

I'v set up a bridge:
brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0024e8e7bd75       no              eth0
virbr0          8000.000000000000       yes


ifcfg-br0  file :
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=yes



ifconfig
br0       Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          inet6 addr: fe80::224:e8ff:fee7:bd75/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:554 (554.0 b)

eth0      Link encap:Ethernet  HWaddr 00:24:E8:E7:BD:75
          UP BROADCAST MULTICAST  MTU:9000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:36 Base address:0x8000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:131950 errors:0 dropped:0 overruns:0 frame:0
          TX packets:131950 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15243838 (14.5 MiB)  TX bytes:15243838 (14.5 MiB)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:#.#.#.#  Bcast:#.#.#.#  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[-- Attachment #1.2: Type: text/html, Size: 3829 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Daniel Vetter]

[-- Attachment #1.1: Type: text/plain, Size: 1354 bytes --]

Hi all,

Two things:
- Please _always_ include a public mailing list when reporting bugs, your
dear maintainer sometimes slacks off.
- We need to see the error_state before we can assess what kind of hang you
have (it's like gettting a SIGSEGV for a normal program, no two gpu hangs
are the same ...).

Cheers, Daniel

On Wed, Apr 3, 2013 at 5:42 PM, Dihan Wickremasuriya <
dwickremasuriya@rethinkrobotics.com> wrote:

> Hi Chris/Daniel,
>
> This is Dihan from Rethink Robotics and we were hoping you could help with
> the GPU hang problem in the i915 driver mentioned in bug #26345:
> https://bugs.freedesktop.org/show_bug.cgi?id=26345
>
> We are running into the same problem with the 3.8.5 kernel (which has the
> fix mentioned in comment #153 of the bug report) when running a Qt 5
> application in Gentoo. At times the entire X session would freeze. The
> x11-perf tests described in the bug report run without any issues though.
>
> Would you happen to know whether this is because of an issue in the driver
> that is not currently being addressed by the fix? I have attached the Xorg
> log, the dmesg output and i915_error_state from a hung session. Please let
> me know if you need any more info. Thanks in advance!
>
> Best regards,
> Dihan
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[-- Attachment #1.2: Type: text/html, Size: 2095 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(No subject)

[Florin Cristian Dan]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hello,
Ok, so in the last days, i've managest to bake my own sato-emenlow image,
and runed it on my machine wich is a PEB2739 (Intel Atom Z510 based).I'm
intrested now in developing some industrial applications, like different
types of masurement gauges.  Now i wonder if yocto project has suport for
java and how its done, as far as i am, i'have read that there would some
meta-java layer, but i'm not sure what to do further, where to get it, and
how the development proces would go.
 Can someone please give me some advices.

Best regards

[-- Attachment #2: Type: text/html, Size: 606 bytes --]

(no subject)

[digvijay chauhan]

[-- Attachment #1.1: Type: text/plain, Size: 627 bytes --]

Hello,
            I am trying to install xen4.2 but when ifire make tools command
it gives me,

Cloning into 'seabios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out

make[3]: *** [seabios-dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
make: *** [install-tools] Error 2


so how can i overcome it.

regards,
DigvijaySingh

[-- Attachment #1.2: Type: text/html, Size: 842 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Ian Campbell]

Digvijay,

You have cross posted this message to multiple lists I have already
asked you not to do this on at least one occasion.

You have also CCd various people, including myself, seemingly at random,
*and* posted the same message three times in quick succession.

Please stop this antisocial behaviour.

Post to a single list (xen-users@ in the common case for the sorts of
questions you are asking) and wait a reasonable amount of time (i.e.
measured in days) for a response before pinging.

Ian.

Re: (no subject)

[Pasi Kärkkäinen]

On Fri, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote:
>    Hello,
>                I am trying to install xen4.2 but when ifire make tools
>    command it gives me,
> 
>    Cloning into 'seabios-dir-remote.tmp'...
>    fatal: unable to connect to [1]xenbits.xen.org:
>    [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out
> 

So maybe your firewall is blocking the connection? 

-- Pasi

>    make[3]: *** [seabios-dir] Error 128
>    make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/
>    firmware'
>    make[2]: *** [subdir-install-firmware] Error 2
>    make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make[1]: *** [subdirs-install] Error 2
>    make[1]: Leaving directory `/home/ce/xen-4.2.0/tools'
>    make: *** [install-tools] Error 2
> 
>    so how can i overcome it.
> 
>    regards,
>    DigvijaySingh
> 
> References
> 
>    Visible links
>    1. http://xenbits.xen.org/
>    2. http://xenbits.xen.org/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

(No subject)

[Tarek El-Sherbiny]

[-- Attachment #1: Type: text/plain, Size: 62 bytes --]

http://www.microsoft-careers.com/key/motion-capture-job.html

[-- Attachment #2: Type: text/html, Size: 162 bytes --]

Re: (no subject)

[pedro noticioso]

[-- Attachment #1.1: Type: text/plain, Size: 66 bytes --]

http://www.directbuypromotions.com/tmp/lifeblog.php?rgmqnob231xpeb

[-- Attachment #1.2: Type: text/html, Size: 305 bytes --]

[-- Attachment #2: Type: text/plain, Size: 238 bytes --]

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Mondo-devel mailing list
Mondo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mondo-devel

(No subject)

[Jeremy Stashluk]

Update the dependencies so that gst-fsl-plugin is built and packaged before the
do_configure step for this package.

(No subject)

[Belisko Marek]

http://www.prinzicase.com/qnyigp.php?s=ot

(No subject)

[Belisko Marek]

http://www.prinzicase.com/qnyigp.php?s=ot

(No subject)

[Iorga, Cristian]

Hello, this is spam.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Belisko Marek
Sent: Tuesday, February 12, 2013 2:15 AM
To: yocto@
Subject: [yocto] Fwd:
[Link removed!]
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

(No subject)

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On Tue, Feb 12, 2013 at 9:37 AM, Iorga, Cristian
<cristian.iorga@intel.com>wrote:

> Hello, this is spam.
>
>
It's more than a spam - it's a virus. Belisko, check your computer.

-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12

[-- Attachment #2: Type: text/html, Size: 1086 bytes --]

(No subject)

[Belal, Awais]

[-- Attachment #1.1: Type: text/plain, Size: 693 bytes --]

Hi Guys,

I have a question regarding openssl. The openssl.inc file under the poky package creates a -misc package which is not directly installed unless either put in RDPENEDS or RRECOMMENDS. This package (-misc) contains the openssl configuration file which is required while generating certificates on the target otherwise the command says:

WARNING: can't open config file: /usr/lib/ssl/openssl.cnf
Unable to load config info from /usr/lib/ssl/openssl.cnf

In an older version of the recipe attached here, the correct method is being (this is my understanding) to get that file in on the target while installing.

Any guidance here would be much appreciated.

BR,
Awais Belal

[-- Attachment #1.2: Type: text/html, Size: 1513 bytes --]

[-- Attachment #2: openssl.inc --]
[-- Type: application/octet-stream, Size: 3372 bytes --]

DESCRIPTION = "Secure Socket Layer (SSL) binary and related cryptographic tools."
HOMEPAGE = "http://www.openssl.org/"
LICENSE = "openssl"
SECTION = "libs/network"

SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz;name=src"
S = "${WORKDIR}/openssl-${PV}"

inherit siteinfo

INC_PR = "r14"

AR_append = " r"
CFLAG = "${@base_conditional('SITEINFO_ENDIANNESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)} \
	-DTERMIO ${FULL_OPTIMIZATION} -Wall"

# -02 does not work on mipsel: ssh hangs when it tries to read /dev/urandom
CFLAG_mtx-1 := "${@'${CFLAG}'.replace('-O2', '')}"
CFLAG_mtx-2 := "${@'${CFLAG}'.replace('-O2', '')}"

export DIRS = "crypto ssl apps"
export EX_LIBS = "-lgcc -ldl"
export AS = "${CC} -c"

PACKAGES =+ "libcrypto libssl ${PN}-misc openssl-conf"
FILES_libcrypto = "${libdir}/libcrypto.so.*"
FILES_libssl = "${libdir}/libssl.so.*"
FILES_${PN}-misc = "${libdir}/ssl/misc"

# Add the openssl.cnf file to the openssl-conf package.  Make the libcrypto
# package RRECOMMENDS on this package.  This will enable the configuration
# file to be installed for both the base openssl package and the libcrypto
# package since the base openssl package depends on the libcrypto package.
FILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
CONFFILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
RRECOMMENDS_libcrypto += "openssl-conf"

do_configure_prepend_darwin () {
	sed -i -e '/version-script=openssl\.ld/d' Configure
}

do_configure () {
	cd util
	perl perlpath.pl ${bindir}
	cd ..
	ln -sf apps/openssl.pod crypto/crypto.pod ssl/ssl.pod doc/

	os=${HOST_OS}
	if [ `echo $os | grep -q linux; echo $?` -eq 0 ]; then
		os=linux
	fi
	target="$os-${HOST_ARCH}"
	case $target in
	linux-arm)
		target=linux-elf-arm
		;;
	linux-armeb)
		target=linux-elf-armeb
		;;
	linux-sh3)
		target=debian-sh3
		;;
	linux-sh4)
		target=debian-sh4
		;;
	linux-i486)
		target=debian-i386-i486
		;;
	linux-i586 | linux-viac3)
		target=debian-i386-i586
		;;
	linux-i686)
		target=debian-i386-i686/cmov
		;;
	linux-mips)
		target=debian-mips
		;;
	linux-mipsel)
		target=debian-mipsel
		;;
	linux-powerpc)
		target=linux-ppc
		;;
	linux-powerpc64)
		target=linux-ppc64
		;;
	linux-supersparc)
		target=linux-sparcv8
		;;
	linux-sparc)
		target=linux-sparcv8
		;;
	darwin-i386)
		target=darwin-i386-cc
		;;
	esac
	# inject machine-specific flags
	sed -i -e "s|^\(\"$target\",\s*\"[^:]\+\):\([^:]\+\)|\1:${CFLAG}|g" Configure
        useprefix=${prefix}
        if [ "x$useprefix" = "x" ]; then
                useprefix=/
        fi        
	perl ./Configure ${EXTRA_OECONF} shared --prefix=$useprefix --openssldir=${libdir}/ssl $target

	eval "${@base_contains('DISTRO_FEATURES', 'largefile', '', 'sed -i -e "/_FILE_OFFSET_BITS/,/#endif/d" ${S}/crypto/bio/bss_file.c', d)}"
	eval "${@base_contains('DISTRO_FEATURES', 'ipv6', '', 'sed -i -e "/AF_INET6/,/break/d" ${S}/crypto/bio/bss_dgram.c', d)}"
}

do_compile () {
	oe_runmake
}

do_install () {
	oe_runmake INSTALL_PREFIX="${D}" install

	# On x86_64, move lib/* to lib64
	if [ "${libdir}" != "${prefix}/lib" ]
	then
		install -d ${D}${libdir} ${D}${libdir}/pkgconfig
		mv ${D}${prefix}/lib/lib* ${D}${libdir}
		mv ${D}${prefix}/lib/pkgconfig/*.pc ${D}${libdir}/pkgconfig
	fi

	oe_libinstall -so libcrypto ${D}${libdir}
	oe_libinstall -so libssl ${D}${libdir}

	install -d ${D}${includedir}
	cp -L -R include/openssl ${D}${includedir}
}

(No subject)

[Mike Looijmans]

This mail bounced so the v2 patch overtook it...

>> From: Mike Looijmans <mike.looijmans@topic.nl>
>>
>> Multicore embedded systems are getting more and more common.
>>
>> Remove "--disable-openmp" from the GCC configuration options and
>> always build libgomp. This only creates a "bigger" compiler but
>> has no effect on the compiled binaries that don't use openmp.
>>
>> Tested a clean build on mips32el and arm7a, no problems encountered.
>>
>> Autoconf will not detect OpenMP after this change, because it will
>> build and run a target binary on the build system. In order to use
>> OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
>> ---
>>  meta/recipes-devtools/gcc/gcc-4.7.inc              |    9 +++------
>>  .../recipes-devtools/gcc/gcc-configure-runtime.inc |    4 +---
>>  .../recipes-devtools/gcc/gcc-cross-canadian_4.7.bb |    2 +-
>>  3 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc
>> b/meta/recipes-devtools/gcc/gcc-4.7.inc
>> index 08a0103..a7aa4a4 100644
>> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
>> @@ -88,7 +88,6 @@ JAVA = ""
>>  EXTRA_OECONF_BASE = " --enable-lto \
>>                       --enable-libssp \
>>                       --disable-bootstrap \
>> -                     --disable-libgomp \
>>                       --disable-libmudflap \
>>                       --with-system-zlib \
>> --with-linker-hash-style=${LINKER_HASH_STYLE} \
>> @@ -99,7 +98,6 @@ EXTRA_OECONF_BASE = " --enable-lto \
>>                       --enable-cheaders=c_global "
>>
>>  EXTRA_OECONF_INITIAL = "--disable-libmudflap \
>> -                     --disable-libgomp \
>>                       --disable-libssp \
>>                       --disable-libquadmath \
>>                       --with-system-zlib \
>> @@ -108,7 +106,6 @@ EXTRA_OECONF_INITIAL = "--disable-libmudflap \
>>                       --enable-decimal-float=no"
>>
>>  EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
>> -                             --disable-libgomp \
>>                               --disable-libquadmath \
>>                               --with-system-zlib \
>>                               --disable-lto \
>
>
> I nearly took this however you still want this disabled in the
> INITIAL/INTERMEDIATE versions, you're just wasting compile time there sa
> nothing would use it.

I don't see the harm in allowing OpenMP usage in build tools (e.g. image
processing on the build machine), but if it gets the patch through
sooner, I'll happily remove it. I tend to run unit tests on my build
system, using OE's compiler version, so it's nice if both host and build
compilers accept the same options.


>
>> @@ -117,9 +114,9 @@ EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
>>
>>  EXTRA_OECONF_append_libc-uclibc = " --disable-decimal-float "
>>
>> -EXTRA_OECONF_PATHS = " \
>> - --with-gxx-include-dir=${STAGING_DIR_TARGET}${target_includedir}/c++ \
>> -                      --with-sysroot=${STAGING_DIR_TARGET} \
>> +EXTRA_OECONF_PATHS = " \
>> + --with-gxx-include-dir=${STAGING_DIR_TARGET}${target_includedir}/c++ \
>> +                      --with-sysroot=${STAGING_DIR_TARGET} \
>
>
> What changed here?

Excellent question, I haven't got the faintest clue why GIT added this.
I'll fix it.

>
>> --with-build-sysroot=${STAGING_DIR_TARGET}"
>>
>>  do_configure_prepend () {
>> diff --git a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> index d40383c..1c9155f 100644
>> --- a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> @@ -7,9 +7,7 @@ EXTRA_OECONF_PATHS = " \
>>      --with-sysroot=${STAGING_DIR_TARGET} \
>>      --with-build-sysroot=${STAGING_DIR_TARGET}"
>>
>> -RUNTIMETARGET = "libssp libstdc++-v3"
>> -RUNTIMETARGET_append_powerpc = " libgomp"
>> -RUNTIMETARGET_append_powerpc64 = " libgomp"
>> +RUNTIMETARGET = "libssp libstdc++-v3 libgomp"
>>  #  ?
>>  # libiberty
>>  # libmudflap
>> diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> index 53c4632..6c048c0 100644
>> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> @@ -13,7 +13,7 @@ SYSTEMLIBS = "${target_base_libdir}/"
>>  SYSTEMLIBS1 = "${target_libdir}/"
>>
>>  EXTRA_OECONF += "--disable-libunwind-exceptions --disable-libssp \
>> -             --disable-libgomp --disable-libmudflap \
>> +             --disable-libmudflap \
>
>
> Again, I'm wondering if you mean this here. The library would have been
> built as part of the target build? Does the library need gcc support as
> well as its presence?
>

Same motivation as above actually, I see no harm in allowing it. Again,
I'll remove it for quickness, I'm quite eager to see OpenMP support in OE.

I'll post a much smaller V2 patch.

Mike


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) - (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

(No subject)

[Richard Purdie]

On Mon, 2013-01-21 at 10:49 +0000, Mike Looijmans wrote:
> This mail bounced so the v2 patch overtook it...
> 
> >> From: Mike Looijmans <mike.looijmans@topic.nl>
> >>
> >> Multicore embedded systems are getting more and more common.
> >>
> >> Remove "--disable-openmp" from the GCC configuration options and
> >> always build libgomp. This only creates a "bigger" compiler but
> >> has no effect on the compiled binaries that don't use openmp.
> >>
> >> Tested a clean build on mips32el and arm7a, no problems encountered.
> >>
> >> Autoconf will not detect OpenMP after this change, because it will
> >> build and run a target binary on the build system. In order to use
> >> OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
> >> ---
> >>  meta/recipes-devtools/gcc/gcc-4.7.inc              |    9 +++------
> >>  .../recipes-devtools/gcc/gcc-configure-runtime.inc |    4 +---
> >>  .../recipes-devtools/gcc/gcc-cross-canadian_4.7.bb |    2 +-
> >>  3 files changed, 5 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> b/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> index 08a0103..a7aa4a4 100644
> >> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> @@ -88,7 +88,6 @@ JAVA = ""
> >>  EXTRA_OECONF_BASE = " --enable-lto \
> >>                       --enable-libssp \
> >>                       --disable-bootstrap \
> >> -                     --disable-libgomp \
> >>                       --disable-libmudflap \
> >>                       --with-system-zlib \
> >> --with-linker-hash-style=${LINKER_HASH_STYLE} \
> >> @@ -99,7 +98,6 @@ EXTRA_OECONF_BASE = " --enable-lto \
> >>                       --enable-cheaders=c_global "
> >>
> >>  EXTRA_OECONF_INITIAL = "--disable-libmudflap \
> >> -                     --disable-libgomp \
> >>                       --disable-libssp \
> >>                       --disable-libquadmath \
> >>                       --with-system-zlib \
> >> @@ -108,7 +106,6 @@ EXTRA_OECONF_INITIAL = "--disable-libmudflap \
> >>                       --enable-decimal-float=no"
> >>
> >>  EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
> >> -                             --disable-libgomp \
> >>                               --disable-libquadmath \
> >>                               --with-system-zlib \
> >>                               --disable-lto \
> >
> >
> > I nearly took this however you still want this disabled in the
> > INITIAL/INTERMEDIATE versions, you're just wasting compile time there sa
> > nothing would use it.
> 
> I don't see the harm in allowing OpenMP usage in build tools (e.g. image
> processing on the build machine), but if it gets the patch through
> sooner, I'll happily remove it. I tend to run unit tests on my build
> system, using OE's compiler version, so it's nice if both host and build
> compilers accept the same options.

The initial/intermediate compiles are only used to build libc and the
final "proper" cross compiler. Since none of these use or benefit from
libgomp, its simply wasting build time having this enabled there.

I'm ok with enabling things where there is a use for them but I also
perfer having an efficient build process where we can. This is why there
are various things disabled above for initial/intermediate.

> >> b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> index 53c4632..6c048c0 100644
> >> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> @@ -13,7 +13,7 @@ SYSTEMLIBS = "${target_base_libdir}/"
> >>  SYSTEMLIBS1 = "${target_libdir}/"
> >>
> >>  EXTRA_OECONF += "--disable-libunwind-exceptions --disable-libssp \
> >> -             --disable-libgomp --disable-libmudflap \
> >> +             --disable-libmudflap \
> >
> >
> > Again, I'm wondering if you mean this here. The library would have been
> > built as part of the target build? Does the library need gcc support as
> > well as its presence?
> >
> 
> Same motivation as above actually, I see no harm in allowing it. Again,
> I'll remove it for quickness, I'm quite eager to see OpenMP support in OE.

It leads to inconsistencies with other libraries and behaviour so I'm
happier with this being left disabled here, unless someone can point me
at a good reason why we should enable it.

> I'll post a much smaller V2 patch.

Thanks. This will likely go in after M3. I don't fancy changing the
compiler this close to the M3 build (feature freeze for M3 was
yesterday). I will queue it in master-next for now.

Cheers,

Richard

(No subject)

[Carrillodominguez Francisco Alberto-B35153]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]


Hello META-FSL Yocto Experts


I am interested in compiling Wayland framework in  yocto,

is this already supported?

Or is it scheduled?

Thanks in advance!


Francisco C.

[-- Attachment #2: Type: text/html, Size: 2322 bytes --]

(No subject)

[Otavio Salvador]

On Fri, Jan 18, 2013 at 9:13 PM, Carrillodominguez Francisco
Alberto-B35153 <B35153@freescale.com> wrote:
>
>
> Hello META-FSL Yocto Experts
>
>
>
>
>
> I am interested in compiling Wayland framework in  yocto,
>
>
>
> is this already supported?

In the works;

> Or is it scheduled?

We should be with basic infrastructure merged in next days, so we can
start working in the BSP specifics. The Wayland work is being done in
OpenEmbedded-Core mailing list.

(please, next time set a proper subject in your e-mail)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

(No subject)

[Eric Bénard]

Hi Franscisco C.,

Le Fri, 18 Jan 2013 23:13:37 +0000,
Carrillodominguez Francisco Alberto-B35153 <B35153@freescale.com> a
écrit :
> I am interested in compiling Wayland framework in  yocto,
> 
> is this already supported?
> 
> Or is it scheduled?
> 
patches were recently submitted to add it to OE-Core :
http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/31572

Eric

(no subject)

[Rushikesh Jadhav]

[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]

Hello List,

Please help me in diagnosing below error in /var/log/messages

HVM1[16586]:  txftrans.c:4498 -- TXF_HARD_ERROR (0xC01A002B) for RM:
fffff8800d099000

Im unable to find any google reference related to above C file or its
source code. http://lmgtfy.com/?q=txftrans.c

Thanks for reading and helping.

Regards,
Rushikesh

[-- Attachment #1.2: Type: text/html, Size: 484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

(no subject)

[mnccsm-b2MIaZL8fbqsTnJN9+BGXg]

STAATSLOTTERIJ INTERNATIONAL B.V.
CLAIM DEPARTMENT OFFICE,
Paleisstraat 5, 2514 JA 'S-Gravenhage,
Netherlands.
www.staatsloterij.nl

The STAATSLOTTERIJ INTERNATIONAL B.V is approved by the Netherlands 
Gaming Board and also licensed by the International Association of 
Gaming Regulators I.A.G international emails. Held on the 1st of 
January, 2013. All winnings must be claim not later than 20th of 
January, 2013, after this date, unclaimed funds will be returned to the 
Lotto. NL

Your email address won the lottery of our Beginning of the year 
programme for a total pay-out of €850,000.00 EURO no tickets were sold 
but all email addresses were assigned to different ticket numbers for 
representation and privacy.

To file for your claim, please contact your claim agent with the below 
details
**************************
Name: Mr. Marzeen Gluvart
Tel: +31- 633-640-721
E-mail: marzeengluvart-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org

**************************
In other to claim your €850,000.00 EURO prize winning, you will have to 
fill the form below and send it back for verification and then you will 
be directed how to get a ticket in your name.
NAME:……………………………….
AGE:………………………………….
SEX:………………………………….
PHONE:……………………………..
Occupation:………………………….
COUNTRY:………………………….

Please remember to quote your reference number and batch numbers:

Batch No: 181830/PQA/296
Qualification No:CEF/004/INT/052
Serial No: 027240879
Ticket No:  NL/SL-44-34-1507

Yours faithfully,
Mrs Eava Van Boer
Online coordinator
Sweepstakes International Program.

(no subject)

[艾祝]

[-- Attachment #1.1: Type: text/plain, Size: 19 bytes --]

azhu.666@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 63 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(No subject)

[Lukas Bulwahn]

I was trying to create a minimal core image with python-setuptools and noticed that the python-setuptools recipe does not work.
The reason is that during do_install, it creates shell scripts that refer to python-native instead of python.
The attached patch tries to solve this issue. Another minimal example thta shows this issue can be found at https://gist.github.com/4223250.

Lukas Bulwahn
BMW Car IT GmbH


From Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de> # This line is ignored.
From: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
Subject: 
In-Reply-To: 

(No subject)

[GOPIKRISHNAN S]

[-- Attachment #1.1: Type: text/plain, Size: 2929 bytes --]

I just did
$ rm -rf build<machine>
$ source ./fsl-setup-poky -m p2041rdb
$ bitbake fsl-image-minimal
$ bitbake vaminusers

Attached vaminusers.bb

Problem with useradd. First time
NOTE: package vaminusers-1.0-r0: task do_install: Started
ERROR: Function 'useradd_sysroot' failed (see
/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
for further information)
ERROR: Logfile of failure stored in:
/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
Log data follows:
| Running groupadd commands...
| Note: group vamin1 already exists, not re-creating it
| Note: group vamin already exists, not re-creating it
| Running useradd commands...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that
group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success, giving up
| ERROR: Function 'useradd_sysroot' failed (see
/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
for further information)
NOTE: package vaminusers-1.0-r0: task do_install: Failed
ERROR: Task 2
(/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/
vaminusers.bb, do_install) failed with exit code '1'
ERROR:
'/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/
vaminusers.bb' failed

[-- Attachment #1.2: Type: text/html, Size: 3169 bytes --]

[-- Attachment #2: vaminusers.bb --]
[-- Type: application/octet-stream, Size: 2514 bytes --]

SUMMARY = "Example recipe for using inherit useradd"
DESCRIPTION = "This recipe serves as an example for using features from useradd.bbclass"
SECTION = "examples"
PR = "r0"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
                    file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

SRC_URI = "file://file1 \
           file://file2 \
           file://file3 \
           file://file4"

S = "${WORKDIR}"

PACKAGES =+ "${PN}-vamin"

inherit useradd

# You must set USERADD_PACKAGES when you inherit useradd. This
# lists which output packages will include the user/group
# creation code.
USERADD_PACKAGES = "${PN} ${PN}-vamin"

# You must also set USERADD_PARAM and/or GROUPADD_PARAM when
# you inherit useradd.

# USERADD_PARAM specifies command line options to pass to the
# useradd command. Multiple users can be created by separating
# the commands with a semicolon. Here we'll create two users,
# vamin1 and user2:
USERADD_PARAM_${PN} = "-u 1200 -d /home/vamin1 -r -s /bin/bash vamin1"

# vamin will be managed in the useradd-example-vamin pacakge:
USERADD_PARAM_${PN}-vamin = "-u 1202 -d /home/vamin -r -s /bin/bash vamin"

# GROUPADD_PARAM works the same way, which you set to the options
# you'd normally pass to the groupadd command. This will create
# groups group1 and group2:
GROUPADD_PARAM_${PN} = "-g 880 vamin1"

# Likewise, we'll manage group3 in the useradd-example-vamin package:
GROUPADD_PARAM_${PN}-vamin = "-g 900 vamin"

do_install () {
	install -d -m 755 ${D}/usr/share/vamin1
	install -d -m 755 ${D}/usr/share/user2
	install -d -m 755 ${D}/usr/share/vamin

	install -p -m 644 file1 ${D}/usr/share/vamin1/
	install -p -m 644 file2 ${D}/usr/share/vamin1/

	install -p -m 644 file2 ${D}/usr/share/user2/
	install -p -m 644 file3 ${D}/usr/share/user2/

	install -p -m 644 file3 ${D}/usr/share/vamin/
	install -p -m 644 file4 ${D}/usr/share/vamin/

	# The new users and groups are created before the do_install
	# step, so you are now free to make use of them:
	chown -R vamin1 ${D}/usr/share/vamin1
	chown -R user2 ${D}/usr/share/user2
	chown -R vamin ${D}/usr/share/vamin

	chgrp -R group1 ${D}/usr/share/vamin1
	chgrp -R group2 ${D}/usr/share/user2
	chgrp -R group3 ${D}/usr/share/vamin
}

FILES_${PN} = "/usr/share/vamin1/* /usr/share/user2/*"
FILES_${PN}-vamin = "/usr/share/vamin/*"

# Prevents do_package failures with:
# debugsources.list: No such file or directory:
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"

(No subject)

[McClintock Matthew-B29882]

On Tue, Nov 27, 2012 at 2:45 AM, GOPIKRISHNAN S <gopikrishnans@pec.edu> wrote:
> I just did
> $ rm -rf build<machine>
> $ source ./fsl-setup-poky -m p2041rdb
> $ bitbake fsl-image-minimal
> $ bitbake vaminusers
>
> Attached vaminusers.bb
>
> Problem with useradd. First time
> NOTE: package vaminusers-1.0-r0: task do_install: Started
> ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> ERROR: Logfile of failure stored in:
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> Log data follows:
> | Running groupadd commands...
> | Note: group vamin1 already exists, not re-creating it
> | Note: group vamin already exists, not re-creating it
> | Running useradd commands...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | ERROR: tried running useradd command 10 times without success, giving up
> | ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> NOTE: package vaminusers-1.0-r0: task do_install: Failed
> ERROR: Task 2
> (/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb,
> do_install) failed with exit code '1'
> ERROR:
> '/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb'
> failed

What distro are you building on?

-M

(No subject)

[Luo Zhenhua-B19537]

[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]

When there is no -g option in USERADD_PARAM_*, the default group name is same as the  created user name, so USERADD_PARAM_* will create the group when add the new user. GROUPADD_PARAM_* is redundant. Remove GROUPADD_PARAM_* lines directly and try again.


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of GOPIKRISHNAN S
Sent: Tuesday, November 27, 2012 4:46 PM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] (no subject)

I just did
$ rm -rf build<machine>
$ source ./fsl-setup-poky -m p2041rdb
$ bitbake fsl-image-minimal
$ bitbake vaminusers

Attached vaminusers.bb<http://vaminusers.bb>

Problem with useradd. First time
NOTE: package vaminusers-1.0-r0: task do_install: Started
ERROR: Function 'useradd_sysroot' failed (see /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685 for further information)
ERROR: Logfile of failure stored in: /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
Log data follows:
| Running groupadd commands...
| Note: group vamin1 already exists, not re-creating it
| Note: group vamin already exists, not re-creating it
| Running useradd commands...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success, giving up
| ERROR: Function 'useradd_sysroot' failed (see /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685 for further information)
NOTE: package vaminusers-1.0-r0: task do_install: Failed
ERROR: Task 2 (/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb<http://vaminusers.bb>, do_install) failed with exit code '1'
ERROR: '/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb<http://vaminusers.bb>' failed


[-- Attachment #2: Type: text/html, Size: 7797 bytes --]

(No subject)

[GOPIKRISHNAN S]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

I am building fsl-image-core for Freescale P2041rdb. Now the useradd is
working without errors; But after building rootfs image, I couldn't find
the updates in /etc/users and group files

On Wed, Nov 28, 2012 at 12:52 PM, Luo Zhenhua-B19537
<B19537@freescale.com>wrote:

>  When there is no -g option in USERADD_PARAM_*, the default group name is
> same as the  created user name, so USERADD_PARAM_* will create the group
> when add the new user. GROUPADD_PARAM_* is redundant. Remove
> GROUPADD_PARAM_* lines directly and try again. ****
>
> ** **
>
> ** **
>
> Best Regards,****
>
> ** **
>
> Zhenhua****
>
> ** **
>
> *From:* meta-freescale-bounces@yoctoproject.org [mailto:
> meta-freescale-bounces@yoctoproject.org] *On Behalf Of *GOPIKRISHNAN S
> *Sent:* Tuesday, November 27, 2012 4:46 PM
> *To:* meta-freescale@yoctoproject.org
> *Subject:* [meta-freescale] (no subject)****
>
> ** **
>
> I just did
> $ rm -rf build<machine>
> $ source ./fsl-setup-poky -m p2041rdb
> $ bitbake fsl-image-minimal
> $ bitbake vaminusers
>
> Attached vaminusers.bb
>
> Problem with useradd. First time
> NOTE: package vaminusers-1.0-r0: task do_install: Started
> ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> ERROR: Logfile of failure stored in:
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> Log data follows:
> | Running groupadd commands...
> | Note: group vamin1 already exists, not re-creating it
> | Note: group vamin already exists, not re-creating it
> | Running useradd commands...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that
> group, use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | ERROR: tried running useradd command 10 times without success, giving up
> | ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> NOTE: package vaminusers-1.0-r0: task do_install: Failed
> ERROR: Task 2
> (/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/
> vaminusers.bb, do_install) failed with exit code '1'
> ERROR:
> '/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/
> vaminusers.bb' failed
>
> ****
>

[-- Attachment #2: Type: text/html, Size: 6286 bytes --]

(No subject)

[Luo Zhenhua-B19537]

[-- Attachment #1: Type: text/plain, Size: 4351 bytes --]

I guess you didn't add vaminusers into fsl-image-core, you can edit the fsl-image-core.bb to add this package into IMAGE_INSTALL variable and build fsl-image-core again.


Best Regards,

Zhenhua

From: GOPIKRISHNAN S [mailto:gopikrishnans@pec.edu]
Sent: Thursday, November 29, 2012 1:56 PM
To: Luo Zhenhua-B19537
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] (no subject)

I am building fsl-image-core for Freescale P2041rdb. Now the useradd is working without errors; But after building rootfs image, I couldn't find the updates in /etc/users and group files
On Wed, Nov 28, 2012 at 12:52 PM, Luo Zhenhua-B19537 <B19537@freescale.com<mailto:B19537@freescale.com>> wrote:
When there is no -g option in USERADD_PARAM_*, the default group name is same as the  created user name, so USERADD_PARAM_* will create the group when add the new user. GROUPADD_PARAM_* is redundant. Remove GROUPADD_PARAM_* lines directly and try again.


Best Regards,

Zhenhua

From: meta-freescale-bounces@yoctoproject.org<mailto:meta-freescale-bounces@yoctoproject.org> [mailto:meta-freescale-bounces@yoctoproject.org<mailto:meta-freescale-bounces@yoctoproject.org>] On Behalf Of GOPIKRISHNAN S
Sent: Tuesday, November 27, 2012 4:46 PM
To: meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>
Subject: [meta-freescale] (no subject)

I just did
$ rm -rf build<machine>
$ source ./fsl-setup-poky -m p2041rdb
$ bitbake fsl-image-minimal
$ bitbake vaminusers

Attached vaminusers.bb<http://vaminusers.bb>

Problem with useradd. First time
NOTE: package vaminusers-1.0-r0: task do_install: Started
ERROR: Function 'useradd_sysroot' failed (see /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685 for further information)
ERROR: Logfile of failure stored in: /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
Log data follows:
| Running groupadd commands...
| Note: group vamin1 already exists, not re-creating it
| Note: group vamin already exists, not re-creating it
| Running useradd commands...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| useradd: group vamin1 exists - if you want to add this user to that group, use -g.
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success, giving up
| ERROR: Function 'useradd_sysroot' failed (see /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685 for further information)
NOTE: package vaminusers-1.0-r0: task do_install: Failed
ERROR: Task 2 (/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb<http://vaminusers.bb>, do_install) failed with exit code '1'
ERROR: '/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb<http://vaminusers.bb>' failed


[-- Attachment #2: Type: text/html, Size: 13068 bytes --]

(No subject)

[McClintock Matthew-B29882]

See https://bugzilla.yoctoproject.org/show_bug.cgi?id=2779

-M

On Thu, Nov 29, 2012 at 1:17 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> I guess you didn’t add vaminusers into fsl-image-core, you can edit the
> fsl-image-core.bb to add this package into IMAGE_INSTALL variable and build
> fsl-image-core again.
>
>
>
>
>
> Best Regards,
>
>
>
> Zhenhua
>
>
>
> From: GOPIKRISHNAN S [mailto:gopikrishnans@pec.edu]
> Sent: Thursday, November 29, 2012 1:56 PM
> To: Luo Zhenhua-B19537
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] (no subject)
>
>
>
> I am building fsl-image-core for Freescale P2041rdb. Now the useradd is
> working without errors; But after building rootfs image, I couldn't find the
> updates in /etc/users and group files
>
> On Wed, Nov 28, 2012 at 12:52 PM, Luo Zhenhua-B19537 <B19537@freescale.com>
> wrote:
>
> When there is no -g option in USERADD_PARAM_*, the default group name is
> same as the  created user name, so USERADD_PARAM_* will create the group
> when add the new user. GROUPADD_PARAM_* is redundant. Remove
> GROUPADD_PARAM_* lines directly and try again.
>
>
>
>
>
> Best Regards,
>
>
>
> Zhenhua
>
>
>
> From: meta-freescale-bounces@yoctoproject.org
> [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of GOPIKRISHNAN S
> Sent: Tuesday, November 27, 2012 4:46 PM
> To: meta-freescale@yoctoproject.org
> Subject: [meta-freescale] (no subject)
>
>
>
> I just did
> $ rm -rf build<machine>
> $ source ./fsl-setup-poky -m p2041rdb
> $ bitbake fsl-image-minimal
> $ bitbake vaminusers
>
> Attached vaminusers.bb
>
> Problem with useradd. First time
> NOTE: package vaminusers-1.0-r0: task do_install: Started
> ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> ERROR: Logfile of failure stored in:
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> Log data follows:
> | Running groupadd commands...
> | Note: group vamin1 already exists, not re-creating it
> | Note: group vamin already exists, not re-creating it
> | Running useradd commands...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | useradd: group vamin1 exists - if you want to add this user to that group,
> use -g.
> | WARNING: useradd command did not succeed. Retrying...
> | ERROR: tried running useradd command 10 times without success, giving up
> | ERROR: Function 'useradd_sysroot' failed (see
> /media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/build_p2041rdb_release/tmp/work/ppce500mc-fsl-linux/vaminusers-1.0-r0/temp/log.do_install.19685
> for further information)
> NOTE: package vaminusers-1.0-r0: task do_install: Failed
> ERROR: Task 2
> (/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb,
> do_install) failed with exit code '1'
> ERROR:
> '/media/325GB_Drive/dev/QorIQ-SDK-V1.2-20120614-yocto/meta-testing/recipes/vaminusers/vaminusers.bb'
> failed
>
>
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

(no subject)

[Stefan Priebe]

From Stefan Priebe <s.priebe-2Lf/h1ldwEHR5kwTpVNS9A@public.gmane.org> # This line is ignored.
From: Stefan Priebe <s.priebe-2Lf/h1ldwEHR5kwTpVNS9A@public.gmane.org>
Cc: pve-devel-KmHT29P9Uc/4CZzEM2C48g@public.gmane.org
Cc: pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: QEMU/PATCH: rbd block driver: fix race between completition and cancel
In-Reply-To:


ve-devel-KmHT29P9Uc/4CZzEM2C48g@public.gmane.org
pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

(no subject)

[Tim Deegan]

Bcc: Tim Deegan <tjd-xen@phlegethon.org>
Subject: Re: [Xen-devel] Guest memory access hooking
Reply-To: 
In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>

Hi,

At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> I'm trying to do some research with malware, and I'm trying to get
> notifications on arbitrary guest page accesses (similar to what Ether
> does.) I've noticed the mem-event API and it seems like it might be close
> to what I need, but I can't find much documentation about how it works or
> how to use it.

Yes, the mem-event api, and in particular the HVMOP_set_mem_access
hypercall, looks like what you want.  As you say, there isn't much
documentation for it, except the xen-access.c client and the mailing
list archive. 

CC'ing Aravindh, who has worked on this code most recently and might be
able to help with specific questions.

> I know that that mem-event API works only with EPT, but is the code to
> change permissions modifying the guest page tables, or does it work via
> EPT? (Can the guest detect it?)

It works by EPT.  The guest can't detect it by looking at its pagetables
or page fault patterns, though it might be able to detect it by looking
at timings.

> I'm also interested monitoring arbitrary page access via the shadow page
> tables. I've been reading through the code, but if anyone has any insight
> or some kind of push in the right direction, I'd really appreciate it.

Your best bet is to modify _sh_propagate.  Look at how it handles
shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
shadow PTE is made read-only until the guest is actually doing a write,
then mark_dirty can be called.  You should be able to do the same thing
for other kinds of access.

Cheers,

Tim.

Re: (no subject)

[Aravindh Puthiyaparambil]

On Thu, Nov 15, 2012 at 4:08 AM, Tim Deegan <tim@xen.org> wrote:
>
> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.

Sure, I can help with the specifics of the API usage.

> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.

It might be useful to get mem-event working with shadow by following
Tim's suggestions to achieve what you are after.

Thanks,
Aravindh

Re: (no subject)

[Cutter 409]

[-- Attachment #1.1: Type: text/plain, Size: 3206 bytes --]

Hi,

I'm finally to a point where I can start looking at this more closely. I'm
trying to wrap my head around the shadow code to figure out the right
course of action.

I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
things to work via p2m somehow. I think I understand this part.

* HVMOP_set_mem_access is used to change the p2m_access_t for the target
page(s). This should already be implemented I think?
* During propagation, I'll check the p2m map to see if I should mask off
any permission bits.
* On a shadow paging fault, I'll check if the fault was caused by p2m
permissions, somehow integrating that with the code for read-only guest
page tables safely.

Questions:

* Just for background, am I correct in my understanding that the log_dirty
code is used to track which gfns have been written to by the guest, in
order to speed up migration?
* Are multiple shadow tables maintained per domain? Is there one per VCPU?
One shadow table per guest page table? Is it blown away every time the
guest changes CR3? I'm having some trouble tracking this down.
* How should I clear/update existing shadow entries after changing the
p2m_access_t? Can I clear the shadow tables somehow and force everything to
be repopulated? Is that insane?

Thanks!



On Thu, Nov 15, 2012 at 7:08 AM, Tim Deegan <tim@xen.org> wrote:

> Bcc: Tim Deegan <tjd-xen@phlegethon.org>
> Subject: Re: [Xen-devel] Guest memory access hooking
> Reply-To:
> In-Reply-To: <
> CAG4Ohu_p-vVF9ZS01PeMqHvscCrrO+UDawK-noaaP8k+MuqHrQ@mail.gmail.com>
>
> Hi,
>
> At 10:56 -0500 on 13 Nov (1352804161), Cutter 409 wrote:
> > I'm trying to do some research with malware, and I'm trying to get
> > notifications on arbitrary guest page accesses (similar to what Ether
> > does.) I've noticed the mem-event API and it seems like it might be close
> > to what I need, but I can't find much documentation about how it works or
> > how to use it.
>
> Yes, the mem-event api, and in particular the HVMOP_set_mem_access
> hypercall, looks like what you want.  As you say, there isn't much
> documentation for it, except the xen-access.c client and the mailing
> list archive.
>
> CC'ing Aravindh, who has worked on this code most recently and might be
> able to help with specific questions.
>
> > I know that that mem-event API works only with EPT, but is the code to
> > change permissions modifying the guest page tables, or does it work via
> > EPT? (Can the guest detect it?)
>
> It works by EPT.  The guest can't detect it by looking at its pagetables
> or page fault patterns, though it might be able to detect it by looking
> at timings.
>
> > I'm also interested monitoring arbitrary page access via the shadow page
> > tables. I've been reading through the code, but if anyone has any insight
> > or some kind of push in the right direction, I'd really appreciate it.
>
> Your best bet is to modify _sh_propagate.  Look at how it handles
> shadow_mode_log_dirty() -- any time a writeable mapping is shadowed, the
> shadow PTE is made read-only until the guest is actually doing a write,
> then mark_dirty can be called.  You should be able to do the same thing
> for other kinds of access.
>
> Cheers,
>
> Tim.
>

[-- Attachment #1.2: Type: text/html, Size: 4078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Tim Deegan]

Hi,

At 17:56 -0400 on 22 Apr (1366653364), Cutter 409 wrote:
> I'm finally to a point where I can start looking at this more closely. I'm
> trying to wrap my head around the shadow code to figure out the right
> course of action.
> 
> I'd want HVMOP_set_mem_access to work with both shadow and EPT, so I'd want
> things to work via p2m somehow. I think I understand this part.
> 
> * HVMOP_set_mem_access is used to change the p2m_access_t for the target
> page(s). This should already be implemented I think?

Yep.  The shadow code uses the same p2m implementataion as NPT, so that
should all be fine. 

> * During propagation, I'll check the p2m map to see if I should mask off
> any permission bits.

Yep.  You'll already be doing a p2m lookup to get the MFN, so you just
need to look at the p2ma as well. 

> * On a shadow paging fault, I'll check if the fault was caused by p2m
> permissions, somehow integrating that with the code for read-only guest
> page tables safely.

Yes.  The common case will be handled in _sh_propagate, which is where
the shadow PTE is constructed.  For the rest you'll need to look at the
places where the shadow fault handler calls the emulator and DTRT
(either before the call or in the callbacks that the emulator uses to
access guest memory).

> Questions:
> 
> * Just for background, am I correct in my understanding that the log_dirty
> code is used to track which gfns have been written to by the guest, in
> order to speed up migration?

That's right.  It's also used to track which parts of an emulated
framebuffer have been updated, to make VNC connections more efficient.

> * Are multiple shadow tables maintained per domain? Is there one per VCPU?
> One shadow table per guest page table? Is it blown away every time the
> guest changes CR3? I'm having some trouble tracking this down.

There's one set of shadows per domain, shared among all VCPUs.  A given
page of memory may have multiple shadows though, e.g. if it's seen both
as a top-level pagetables and a leaf pagetable. 

Shadows are kept around until:
 - it looks like the page is no longer a pagetable;
 - the guest explicitly tells us it's no longer a pagetable; or
 - we need the memory to shadow some other page. 

Mostly, a pages's shadow(s) are kept in sync with any changes the guest
makes to the page, by trapping and emulating all writes.  For
performance, we allow some l1 pagetables to be 'out of sync' ('oos' in
the code), letting the guest write to the page directly.  On guest CR3
writes (and other TLB-flush-related activity) we make sure any OOS
shadows are brought up to date. 

> * How should I clear/update existing shadow entries after changing the
> p2m_access_t? Can I clear the shadow tables somehow and force everything to
> be repopulated? Is that insane?

It depends how often you're changing the access permissions.
sh_remove_all_mappings() and sh_remove_write_access() will try to flush
mappings of a single MFN from the shadows, but they can be expensive
(e.g. involving a brute-force scan of all shadows) so if you're going to
do a lot of them it may be worth considering batching them up and
calling shadow_blow_tables() once instead.

Cheers,

Tim.

(No subject)

[Ilya Dmitrichenko]

[-- Attachment #1: Type: text/plain, Size: 9830 bytes --]

Hi,

I'm getting this on Ubuntu 10.04:

> bitbake core-image-minimal
                                                                [224/1821]
Pseudo is not present but is required, building this first before the main
build
Parsing recipes: 100%
|##############################################################################################################################################|
Time: 00:01:12
Parsing of 1262 .bb files complete (0 cached, 1262 parsed). 1605 targets,
64 skipped, 6 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121111"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"
meta-oe           = "master:ae2926ef202541014cde7c91a9ff75ed8b4eb390"
meta-ti           = "master:53dcf7977a86714cbd27f919a473dac8f6f16434"
meta-yocto-bsp    = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 56 tasks of which 0 didn't need to be rerun
and all succeeded.
Loading cache: 100%
|################################################################################################################################################|
ETA:  00:00:00
Loaded 1606 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121111"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"
meta-oe           = "master:ae2926ef202541014cde7c91a9ff75ed8b4eb390"
meta-ti           = "master:53dcf7977a86714cbd27f919a473dac8f6f16434"
meta-yocto-bsp    = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 63 tasks of which 42 didn't need to be rerun
and all succeeded.
Loading cache: 100%
|################################################################################################################################################|
ETA:  00:00:00
Loaded 1606 entries from dependency cache.

Build Configuration:

                    [173/1821]
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121111"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"
meta-oe           = "master:ae2926ef202541014cde7c91a9ff75ed8b4eb390"
meta-ti           = "master:53dcf7977a86714cbd27f919a473dac8f6f16434"
meta-yocto-bsp    = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: Unpack failure for URL: '
http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.5.0-0.tar.xz'.
Unpack command PATH="/home/ilya/oe/poky/sc
ripts/native-intercept:/home/ilya/oe/poky/scripts:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-linux:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin:/mnt/bu
ild/poky//tmp/sysroots/x86_64-linux/usr/sbin:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin:/mnt/build/poky//tmp/sysroots/x86_64-linux/sbin:/mnt/build/poky//tmp/sysroots/x86_64-
linux//bin:/home/ilya/oe/poky/scripts:/home/ilya/oe/poky/bitbake/bin/:/etc/rbenv/shims:/usr/local/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
xz -dc /home/ilya/oe/poky/build/downloads/kconfig-frontends-3.5.0-0.tar.xz
| tar x --no-same-owner -f - failed with return value 2
ERROR: Logfile of failure stored in:
/mnt/build/poky//tmp/work/x86_64-linux/kconfig-frontends-native-3.5.0-r1/temp/log.do_unpack.894
Log data follows:
| DEBUG: Executing python function do_unpack
| DEBUG: Executing python function base_do_unpack
| NOTE: Unpacking
/home/ilya/oe/poky/build/downloads/kconfig-frontends-3.5.0-0.tar.xz to
/mnt/build/poky/tmp/work/x86_64-linux/kconfig-frontends-native-3.5.0-r1/
| xz: error while loading shared libraries: liblzma.so.5: cannot open
shared object file: No such file or directory
| tar: This does not look like a tar archive
| tar: Exiting with failure status due to previous errors
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
| ERROR: Function failed: Unpack failure for URL: '
http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.5.0-0.tar.xz'.
Unpack command PATH="/home/ilya/oe/poky/
scripts/native-intercept:/home/ilya/oe/poky/scripts:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-linux:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin:/mnt/
build/poky//tmp/sysroots/x86_64-linux/usr/sbin:/mnt/build/poky//tmp/sysroots/x86_64-linux/usr/bin:/mnt/build/poky//tmp/sysroots/x86_64-linux/sbin:/mnt/build/poky//tmp/sysroots/x86_6
4-linux//bin:/home/ilya/oe/poky/scripts:/home/ilya/oe/poky/bitbake/bin/:/etc/rbenv/shims:/usr/local/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
" xz -dc
/home/ilya/oe/poky/build/downloads/kconfig-frontends-3.5.0-0.tar.xz | tar x
--no-same-owner -f - failed with return value 2
ERROR: Task 343
(virtual:native:/home/ilya/oe/poky/build/../meta/recipes-devtools/kconfig-frontends/
kconfig-frontends_3.5.bb, do_unpack) failed with exit code '1'
NOTE: Tasks Summary: Attempted 148 tasks of which 70 didn't need to be
rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:

virtual:native:/home/ilya/oe/poky/build/../meta/recipes-devtools/kconfig-frontends/
kconfig-frontends_3.5.bb, do_unpack
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

I managed to get past this by symlinking libzma.so.5 into /usr/local/lib/,
though then I got another error from nativesdk and trying to rebuild it
with `bitbake meta-toolchain` reproduced the error again:
bitbake meta-toolchain
Loading cache: 100%
|################################################################################################################################################|
ETA:  00:00:00
Loaded 1606 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121111"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"
meta-oe           = "master:ae2926ef202541014cde7c91a9ff75ed8b4eb390"
meta-ti           = "master:53dcf7977a86714cbd27f919a473dac8f6f16434"
meta-yocto-bsp    = "master:78983e939ab17f02f8911c8b0d0e326b419856b9"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_configure (see
/mnt/build/poky//tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-eglibc-initial-2.16-r17/temp/log.do_configure.28615
for further information)
ERROR: Logfile of failure stored in:
/mnt/build/poky//tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-eglibc-initial-2.16-r17/temp/log.do_configure.28615
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
'bit-64', 'x86_64-linux', 'common']
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pokysdk-linux-gnu
| checking for x86_64-pokysdk-linux-gcc... x86_64-pokysdk-linux-gcc
 --sysroot=/mnt/build/poky//tmp/sysroots/x86_64-nativesdk-pokysdk-linux
| checking for suffix of object files... configure: error: in
`/mnt/build/poky/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-eglibc-initial-2.16-r17/build-x86_64-pokysdk-linux':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details
| ERROR: Function failed: do_configure (see
/mnt/build/poky//tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-eglibc-initial-2.16-r17/temp/log.do_configure.28615
for further information)
ERROR: Task 1000
(virtual:nativesdk:/home/ilya/oe/poky/build/../meta/recipes-core/eglibc/
eglibc-initial_2.16.bb, do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 252 tasks of which 177 didn't need to be
rerun and 1 failed.
Waiting for 0 running tasks to finish:
Summary: 1 task failed:
  virtual:nativesdk:/home/ilya/oe/poky/build/../meta/recipes-core/eglibc/
eglibc-initial_2.16.bb, do_configure
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

not sure what to do here ... is it a possible breakage in the master branch
or host distro/version related?

I'm about to deploy the appliance image, will see if I get this same error
or what not ...

[-- Attachment #2: Type: text/html, Size: 12560 bytes --]

(no subject)

[a1tmblwd]

Make Inc0me like m0ney making machine
http://www.vastusukh.com/http-morenul-1.php?nipfriend=977


_____________________
"  I never went near the house, but struck throughthe woods and made 
for the swamp." (c) ally winsor
Fri, 12 Oct 2012 14:00:55

(no subject)

[ABN AMRO]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

 

Geachte klant,

De ABN-AMRO spendeert veel aandacht en zorg aan de
beveiliging en integriteit van al onze bankrekeningen. Graag vragen wij
u dan ook aandacht voor het volgende. Afgelopen jaar is de ABN AMRO,
samen met veel andere nederlandse banken, doelwit geworden van
grootschalig internetfraude. Daarom zijn wij afgelopen maanden een
grootschalig project gestart om dit te bestrijden. Alle online
bankrekeningen dienen te worden gekoppeld aan een nieuw ontwikkeld
beveiligingssysteem, waarmee verdachte bewegingen en ontwikkelingen op
uw online bankrekening sneller worden getraceerd en opgelost.

Er is
geconstateerd dat uw online ABN-AMRO rekening nog niet voorzien is van
het nieuwe beveiligingssysteem.Wij vragen u dan ook 5-10 minuten van uw
tijd om deze update compleet te maken, om zo de beveiliging te
voltooien.

Gebruikt u onderstaande link: Klik hier

Na de update zal er
door een van onze medewerkers nog contact met u worden opgenomen om het
gehele proces te voltooien. Wanneer het gehele proces gereed is zal u
weer als vanouds gebruik kunnen maken van het online bankieren via
ABN-AMRO. Wij willen u alvast bedanken voor uw
medewerking.

Hoogachtend,

Klantenservice

 ABN-AMRO ONLINE Copyright
2012, ABN AMRO NETHERLANDS. All rights reserved 

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

(no subject)

[ABN AMRO]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

 

Geachte klant,

De ABN-AMRO spendeert veel aandacht en zorg aan de
beveiliging en integriteit van al onze bankrekeningen. Graag vragen wij
u dan ook aandacht voor het volgende. Afgelopen jaar is de ABN AMRO,
samen met veel andere nederlandse banken, doelwit geworden van
grootschalig internetfraude. Daarom zijn wij afgelopen maanden een
grootschalig project gestart om dit te bestrijden. Alle online
bankrekeningen dienen te worden gekoppeld aan een nieuw ontwikkeld
beveiligingssysteem, waarmee verdachte bewegingen en ontwikkelingen op
uw online bankrekening sneller worden getraceerd en opgelost.

Er is
geconstateerd dat uw online ABN-AMRO rekening nog niet voorzien is van
het nieuwe beveiligingssysteem.Wij vragen u dan ook 5-10 minuten van uw
tijd om deze update compleet te maken, om zo de beveiliging te
voltooien.

Gebruikt u onderstaande link: Klik hier

Na de update zal er
door een van onze medewerkers nog contact met u worden opgenomen om het
gehele proces te voltooien. Wanneer het gehele proces gereed is zal u
weer als vanouds gebruik kunnen maken van het online bankieren via
ABN-AMRO. Wij willen u alvast bedanken voor uw
medewerking.

Hoogachtend,

Klantenservice

 ABN-AMRO ONLINE Copyright
2012, ABN AMRO NETHERLANDS. All rights reserved 

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

(no subject)

[Webmaster]

sss






--
powered by phpList, www.phplist.com --

[GIT PULL] sound fixes for 3.6-rc5

[Takashi Iwai]

Linus,

The following changes since commit 53e1719f3da0f095b8db1461bd12dd79f3246b84:

  ALSA: snd-als100: fix suspend/resume (2012-08-21 07:29:40 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.6

for you to fetch changes up to 2e4a263ca80a203ac6109f5932722a716c265395:

  ALSA: snd-usb: fix cross-interface streaming devices (2012-08-31 21:04:53 +0200)

----------------------------------------------------------------
Sound fixes for 3.6-rc5

There are nothing scaring, contains only small fixes for HD-audio and
USB-audio:
- EPSS regression fix and GPIO fix for HD-audio IDT codecs
- A series of USB-audio regression fixes that are found since 3.5 kernel

----------------------------------------------------------------
Daniel Mack (4):
      ALSA: snd-usb: Fix URB cancellation at stream start
      ALSA: snd-usb: restore delay information
      ALSA: snd-usb: fix calls to next_packet_size
      ALSA: snd-usb: fix cross-interface streaming devices

David Henningsson (1):
      ALSA: hda - Do not set GPIOs for speakers on IDT if there are no speakers

Pavel Roskin (1):
      ALSA: snd-usb: use list_for_each_safe for endpoint resources

Takashi Iwai (2):
      ALSA: hda - Avoid unnecessary parameter read for EPSS
      ALSA: hda - Don't trust codec EPSS bit for IDT 92HD83xx & co

 sound/pci/hda/hda_codec.c      | 10 +++++--
 sound/pci/hda/hda_codec.h      |  1 +
 sound/pci/hda/patch_sigmatel.c |  4 +++
 sound/usb/card.c               |  4 +--
 sound/usb/endpoint.c           | 24 +++++++---------
 sound/usb/endpoint.h           |  3 +-
 sound/usb/pcm.c                | 64 ++++++++++++++++++++++++++++++++++--------
 7 files changed, 79 insertions(+), 31 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index f560051..f25c24c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1209,6 +1209,9 @@ static void snd_hda_codec_free(struct hda_codec *codec)
 	kfree(codec);
 }
 
+static bool snd_hda_codec_get_supported_ps(struct hda_codec *codec,
+				hda_nid_t fg, unsigned int power_state);
+
 static void hda_set_power_state(struct hda_codec *codec, hda_nid_t fg,
 				unsigned int power_state);
 
@@ -1317,6 +1320,10 @@ int /*__devinit*/ snd_hda_codec_new(struct hda_bus *bus,
 					   AC_VERB_GET_SUBSYSTEM_ID, 0);
 	}
 
+	codec->epss = snd_hda_codec_get_supported_ps(codec,
+					codec->afg ? codec->afg : codec->mfg,
+					AC_PWRST_EPSS);
+
 	/* power-up all before initialization */
 	hda_set_power_state(codec,
 			    codec->afg ? codec->afg : codec->mfg,
@@ -3543,8 +3550,7 @@ static void hda_set_power_state(struct hda_codec *codec, hda_nid_t fg,
 	/* this delay seems necessary to avoid click noise at power-down */
 	if (power_state == AC_PWRST_D3) {
 		/* transition time less than 10ms for power down */
-		bool epss = snd_hda_codec_get_supported_ps(codec, fg, AC_PWRST_EPSS);
-		msleep(epss ? 10 : 100);
+		msleep(codec->epss ? 10 : 100);
 	}
 
 	/* repeat power states setting at most 10 times*/
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 7fbc1bc..e5a7e19 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -862,6 +862,7 @@ struct hda_codec {
 	unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */
 	unsigned int no_jack_detect:1;	/* Machine has no jack-detection */
 	unsigned int pcm_format_first:1; /* PCM format must be set first */
+	unsigned int epss:1;		/* supporting EPSS? */
 #ifdef CONFIG_SND_HDA_POWER_SAVE
 	unsigned int power_on :1;	/* current (global) power-state */
 	int power_transition;	/* power-state in transition */
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index ea5775a..6f806d3 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -4543,6 +4543,9 @@ static void stac92xx_line_out_detect(struct hda_codec *codec,
 	struct auto_pin_cfg *cfg = &spec->autocfg;
 	int i;
 
+	if (cfg->speaker_outs == 0)
+		return;
+
 	for (i = 0; i < cfg->line_outs; i++) {
 		if (presence)
 			break;
@@ -5531,6 +5534,7 @@ static int patch_stac92hd83xxx(struct hda_codec *codec)
 		snd_hda_codec_set_pincfg(codec, 0xf, 0x2181205e);
 	}
 
+	codec->epss = 0; /* longer delay needed for D3 */
 	codec->no_trigger_sense = 1;
 	codec->spec = spec;
 
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d5b5c33..4a469f0 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -553,7 +553,7 @@ static void snd_usb_audio_disconnect(struct usb_device *dev,
 				     struct snd_usb_audio *chip)
 {
 	struct snd_card *card;
-	struct list_head *p;
+	struct list_head *p, *n;
 
 	if (chip == (void *)-1L)
 		return;
@@ -570,7 +570,7 @@ static void snd_usb_audio_disconnect(struct usb_device *dev,
 			snd_usb_stream_disconnect(p);
 		}
 		/* release the endpoint resources */
-		list_for_each(p, &chip->ep_list) {
+		list_for_each_safe(p, n, &chip->ep_list) {
 			snd_usb_endpoint_free(p);
 		}
 		/* release the midi resources */
diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index c411812..d6e2bb4 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -141,7 +141,7 @@ int snd_usb_endpoint_implict_feedback_sink(struct snd_usb_endpoint *ep)
  *
  * For implicit feedback, next_packet_size() is unused.
  */
-static int next_packet_size(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
 {
 	unsigned long flags;
 	int ret;
@@ -177,15 +177,6 @@ static void retire_inbound_urb(struct snd_usb_endpoint *ep,
 		ep->retire_data_urb(ep->data_subs, urb);
 }
 
-static void prepare_outbound_urb_sizes(struct snd_usb_endpoint *ep,
-				       struct snd_urb_ctx *ctx)
-{
-	int i;
-
-	for (i = 0; i < ctx->packets; ++i)
-		ctx->packet_size[i] = next_packet_size(ep);
-}
-
 /*
  * Prepare a PLAYBACK urb for submission to the bus.
  */
@@ -370,7 +361,6 @@ static void snd_complete_urb(struct urb *urb)
 			goto exit_clear;
 		}
 
-		prepare_outbound_urb_sizes(ep, ctx);
 		prepare_outbound_urb(ep, ctx);
 	} else {
 		retire_inbound_urb(ep, ctx);
@@ -799,7 +789,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
 /**
  * snd_usb_endpoint_start: start an snd_usb_endpoint
  *
- * @ep: the endpoint to start
+ * @ep:		the endpoint to start
+ * @can_sleep:	flag indicating whether the operation is executed in
+ * 		non-atomic context
  *
  * A call to this function will increment the use count of the endpoint.
  * In case it is not already running, the URBs for this endpoint will be
@@ -809,7 +801,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
  *
  * Returns an error if the URB submission failed, 0 in all other cases.
  */
-int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
+int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
 {
 	int err;
 	unsigned int i;
@@ -821,6 +813,11 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
 	if (++ep->use_count != 1)
 		return 0;
 
+	/* just to be sure */
+	deactivate_urbs(ep, 0, can_sleep);
+	if (can_sleep)
+		wait_clear_urbs(ep);
+
 	ep->active_mask = 0;
 	ep->unlink_mask = 0;
 	ep->phase = 0;
@@ -850,7 +847,6 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
 			goto __error;
 
 		if (usb_pipeout(ep->pipe)) {
-			prepare_outbound_urb_sizes(ep, urb->context);
 			prepare_outbound_urb(ep, urb->context);
 		} else {
 			prepare_inbound_urb(ep, urb->context);
diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
index ee2723f..cbbbdf2 100644
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -13,7 +13,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
 				struct audioformat *fmt,
 				struct snd_usb_endpoint *sync_ep);
 
-int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep);
+int  snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
 void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
 			   int force, int can_sleep, int wait);
 int  snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
@@ -21,6 +21,7 @@ int  snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep);
 void snd_usb_endpoint_free(struct list_head *head);
 
 int snd_usb_endpoint_implict_feedback_sink(struct snd_usb_endpoint *ep);
+int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep);
 
 void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep,
 			     struct snd_usb_endpoint *sender,
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 62ec808..fd5e982 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -212,7 +212,7 @@ int snd_usb_init_pitch(struct snd_usb_audio *chip, int iface,
 	}
 }
 
-static int start_endpoints(struct snd_usb_substream *subs)
+static int start_endpoints(struct snd_usb_substream *subs, int can_sleep)
 {
 	int err;
 
@@ -225,7 +225,7 @@ static int start_endpoints(struct snd_usb_substream *subs)
 		snd_printdd(KERN_DEBUG "Starting data EP @%p\n", ep);
 
 		ep->data_subs = subs;
-		err = snd_usb_endpoint_start(ep);
+		err = snd_usb_endpoint_start(ep, can_sleep);
 		if (err < 0) {
 			clear_bit(SUBSTREAM_FLAG_DATA_EP_STARTED, &subs->flags);
 			return err;
@@ -236,10 +236,25 @@ static int start_endpoints(struct snd_usb_substream *subs)
 	    !test_and_set_bit(SUBSTREAM_FLAG_SYNC_EP_STARTED, &subs->flags)) {
 		struct snd_usb_endpoint *ep = subs->sync_endpoint;
 
+		if (subs->data_endpoint->iface != subs->sync_endpoint->iface ||
+		    subs->data_endpoint->alt_idx != subs->sync_endpoint->alt_idx) {
+			err = usb_set_interface(subs->dev,
+						subs->sync_endpoint->iface,
+						subs->sync_endpoint->alt_idx);
+			if (err < 0) {
+				snd_printk(KERN_ERR
+					   "%d:%d:%d: cannot set interface (%d)\n",
+					   subs->dev->devnum,
+					   subs->sync_endpoint->iface,
+					   subs->sync_endpoint->alt_idx, err);
+				return -EIO;
+			}
+		}
+
 		snd_printdd(KERN_DEBUG "Starting sync EP @%p\n", ep);
 
 		ep->sync_slave = subs->data_endpoint;
-		err = snd_usb_endpoint_start(ep);
+		err = snd_usb_endpoint_start(ep, can_sleep);
 		if (err < 0) {
 			clear_bit(SUBSTREAM_FLAG_SYNC_EP_STARTED, &subs->flags);
 			return err;
@@ -544,13 +559,10 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
 	subs->last_frame_number = 0;
 	runtime->delay = 0;
 
-	/* clear the pending deactivation on the target EPs */
-	deactivate_endpoints(subs);
-
 	/* for playback, submit the URBs now; otherwise, the first hwptr_done
 	 * updates for all URBs would happen at the same time when starting */
 	if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK)
-		return start_endpoints(subs);
+		return start_endpoints(subs, 1);
 
 	return 0;
 }
@@ -1032,6 +1044,7 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 				 struct urb *urb)
 {
 	struct snd_pcm_runtime *runtime = subs->pcm_substream->runtime;
+	struct snd_usb_endpoint *ep = subs->data_endpoint;
 	struct snd_urb_ctx *ctx = urb->context;
 	unsigned int counts, frames, bytes;
 	int i, stride, period_elapsed = 0;
@@ -1043,7 +1056,11 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 	urb->number_of_packets = 0;
 	spin_lock_irqsave(&subs->lock, flags);
 	for (i = 0; i < ctx->packets; i++) {
-		counts = ctx->packet_size[i];
+		if (ctx->packet_size[i])
+			counts = ctx->packet_size[i];
+		else
+			counts = snd_usb_endpoint_next_packet_size(ep);
+
 		/* set up descriptor */
 		urb->iso_frame_desc[i].offset = frames * stride;
 		urb->iso_frame_desc[i].length = counts * stride;
@@ -1094,7 +1111,16 @@ static void prepare_playback_urb(struct snd_usb_substream *subs,
 	subs->hwptr_done += bytes;
 	if (subs->hwptr_done >= runtime->buffer_size * stride)
 		subs->hwptr_done -= runtime->buffer_size * stride;
+
+	/* update delay with exact number of samples queued */
+	runtime->delay = subs->last_delay;
 	runtime->delay += frames;
+	subs->last_delay = runtime->delay;
+
+	/* realign last_frame_number */
+	subs->last_frame_number = usb_get_current_frame_number(subs->dev);
+	subs->last_frame_number &= 0xFF; /* keep 8 LSBs */
+
 	spin_unlock_irqrestore(&subs->lock, flags);
 	urb->transfer_buffer_length = bytes;
 	if (period_elapsed)
@@ -1112,12 +1138,26 @@ static void retire_playback_urb(struct snd_usb_substream *subs,
 	struct snd_pcm_runtime *runtime = subs->pcm_substream->runtime;
 	int stride = runtime->frame_bits >> 3;
 	int processed = urb->transfer_buffer_length / stride;
+	int est_delay;
 
 	spin_lock_irqsave(&subs->lock, flags);
-	if (processed > runtime->delay)
-		runtime->delay = 0;
+	est_delay = snd_usb_pcm_delay(subs, runtime->rate);
+	/* update delay with exact number of samples played */
+	if (processed > subs->last_delay)
+		subs->last_delay = 0;
 	else
-		runtime->delay -= processed;
+		subs->last_delay -= processed;
+	runtime->delay = subs->last_delay;
+
+	/*
+	 * Report when delay estimate is off by more than 2ms.
+	 * The error should be lower than 2ms since the estimate relies
+	 * on two reads of a counter updated every ms.
+	 */
+	if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
+		snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
+			est_delay, subs->last_delay);
+
 	spin_unlock_irqrestore(&subs->lock, flags);
 }
 
@@ -1175,7 +1215,7 @@ static int snd_usb_substream_capture_trigger(struct snd_pcm_substream *substream
 
 	switch (cmd) {
 	case SNDRV_PCM_TRIGGER_START:
-		err = start_endpoints(subs);
+		err = start_endpoints(subs, 0);
 		if (err < 0)
 			return err;
 

Re:

[Markus Trippelsdorf]

On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> ----------------------------------------------------------------
> Sound fixes for 3.6-rc5
> 
> There are nothing scaring, contains only small fixes for HD-audio and
> USB-audio:
> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> - A series of USB-audio regression fixes that are found since 3.5 kernel
> 
> ----------------------------------------------------------------
> Daniel Mack (4):
>       ALSA: snd-usb: Fix URB cancellation at stream start
>       ALSA: snd-usb: restore delay information
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
The commit fbcfbf5f above causes the following lines to be printed
whenever I start a new song:

delay: estimated 0, actual 352
delay: estimated 353, actual 705

(44.1 * 8 = 352.8)

This happens with an USB-DAC that identifies itself as "C-Media USB
Headphone Set".

-- 
Markus

Re: (no subject)

[Daniel Mack]

On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
>> ----------------------------------------------------------------
>> Sound fixes for 3.6-rc5
>>
>> There are nothing scaring, contains only small fixes for HD-audio and
>> USB-audio:
>> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
>> - A series of USB-audio regression fixes that are found since 3.5 kernel
>>
>> ----------------------------------------------------------------
>> Daniel Mack (4):
>>       ALSA: snd-usb: Fix URB cancellation at stream start
>>       ALSA: snd-usb: restore delay information
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> The commit fbcfbf5f above causes the following lines to be printed
> whenever I start a new song:

Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
patch (fbcfbf5f) brings back now.

> delay: estimated 0, actual 352
> delay: estimated 353, actual 705
> 
> (44.1 * 8 = 352.8)
> 
> This happens with an USB-DAC that identifies itself as "C-Media USB
> Headphone Set".

And you didn't you see these lines with 3.4?


Daniel

Re: (no subject)

[Takashi Iwai]

At Thu, 06 Sep 2012 08:33:30 +0200,
Daniel Mack wrote:
> 
> On 06.09.2012 08:02, Markus Trippelsdorf wrote:
> > On 2012.09.04 at 16:40 +0200, Takashi Iwai wrote:
> >> ----------------------------------------------------------------
> >> Sound fixes for 3.6-rc5
> >>
> >> There are nothing scaring, contains only small fixes for HD-audio and
> >> USB-audio:
> >> - EPSS regression fix and GPIO fix for HD-audio IDT codecs
> >> - A series of USB-audio regression fixes that are found since 3.5 kernel
> >>
> >> ----------------------------------------------------------------
> >> Daniel Mack (4):
> >>       ALSA: snd-usb: Fix URB cancellation at stream start
> >>       ALSA: snd-usb: restore delay information
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > The commit fbcfbf5f above causes the following lines to be printed
> > whenever I start a new song:
> 
> Copied Pierre-Louis Bossart - he wrote the code in 294c4fb8 which this
> patch (fbcfbf5f) brings back now.
> 
> > delay: estimated 0, actual 352
> > delay: estimated 353, actual 705
> > 
> > (44.1 * 8 = 352.8)
> > 
> > This happens with an USB-DAC that identifies itself as "C-Media USB
> > Headphone Set".
> 
> And you didn't you see these lines with 3.4?

Maybe the difference of start condition?

Markus, does the patch below fix anything?


Takashi

---
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index fd5e982..0ff9f1a 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -556,7 +556,7 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
 	subs->hwptr_done = 0;
 	subs->transfer_done = 0;
 	subs->last_delay = 0;
-	subs->last_frame_number = 0;
+	subs->last_frame_number = snd_usb_pcm_delay(subs, runtime->rate);
 	runtime->delay = 0;
 
 	/* for playback, submit the URBs now; otherwise, the first hwptr_done

(no subject)

[xuluqxulu]

5.53

(No subject)

[Javier Martinez Canillas]

The OpenEmbedded User Manual list the variables that should be used to
control the directories into which files are installed.

It says that is a poor practice to specify hardcoded paths instead of
using these variables, yet there are many recipes that don't use it.

This is second version of a big patch-set that does a cleanup and replace
the hardcoded paths used on these recipes with the build system variables.

I tried to be as careful as possible to do the proper replacement but
since I could introduce regressions I split the changes in 30 different
patches so it could be git bisectable in case of messing a recipe.

Also, the patches increment the recipes PR since the a distro config can
set the variables to a different value.

Changes since v1:

- Bump recipes PR as suggested by Otavio Salvador and Khem Raj
- Squash ${base_bindir} and ${sysconfdir} changes for xinetd and lsb
  recipes so the PR number gets incremented only once. 

The patch-set consist of the following patches:

[PATCH v2 01/28] xinetd: use ${sbindir} and ${sysconfdir} instead of
[PATCH v2 02/28] alsa-state: use ${sbindir} instead of /usr/sbin for
[PATCH v2 03/28] lsbsetup: use ${bindir} instead of /usr/bin for
[PATCH v2 04/28] sudo: use ${bindir} and ${sysconfdir} instead of
[PATCH v2 05/28] lsbtest: use ${bindir} instead of /usr/bin for
[PATCH v2 06/28] cronie: use variables instead of hardcoded paths
[PATCH v2 07/28] useradd-example: use ${datadir} instead of
[PATCH v2 08/28] ubootchart: use variables instead of hardcoded
[PATCH v2 09/28] xkeyboard-config: use ${datadir} instead of
[PATCH v2 10/28] systemtap: use ${datadir} instead of /usr/share for
[PATCH v2 11/28] lsb: use ${base_bindir} and ${sysconfdir} instead
[PATCH v2 12/28] mingetty: use ${base_sbindir} instead of /sbin for
[PATCH v2 13/28] external-sourcery: use ${prefix} and ${libdir}
[PATCH v2 14/28] rpm: use ${localstatedir} and ${libdir} instead of
[PATCH v2 15/28] at: use ${base_sbindir} instead of /sbin for
[PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and
[PATCH v2 17/28] linux-firware: use ${base_libdir} instead of /lib
[PATCH v2 18/28] openssh: use ${localstatedir} instead of /var for
[PATCH v2 19/28] libpam: use ${localstatedir} and ${sysconfdir}
[PATCH v2 20/28] x11-common: use ${sysconfdir} instead of /etc for
[PATCH v2 21/28] builder: use ${sysconfdir} instead of /etc for
[PATCH v2 22/28] xserver-nodm-init: use ${sysconfdir} instead of
[PATCH v2 23/28] lsbinitscripts: use ${sysconfdir} instead of /etc
[PATCH v2 24/28] usbinit: use ${sysconfdir} instead of /etc for
[PATCH v2 25/28] qemu-config: use ${sysconfdir} instead of /etc for
[PATCH v2 26/28] rsync: use ${sysconfdir} instead of /etc for
[PATCH v2 27/28] chkconfig: use ${sysconfdir} instead of /etc for
[PATCH v2 28/28] man: use ${sysconfdir} instead of /etc for

Best regards,
Javier

(No subject)

[Richard Purdie]

On Sun, 2012-08-05 at 21:48 +0200, Javier Martinez Canillas wrote:
> The OpenEmbedded User Manual list the variables that should be used to
> control the directories into which files are installed.
> 
> It says that is a poor practice to specify hardcoded paths instead of
> using these variables, yet there are many recipes that don't use it.
> 
> This is second version of a big patch-set that does a cleanup and replace
> the hardcoded paths used on these recipes with the build system variables.
> 
> I tried to be as careful as possible to do the proper replacement but
> since I could introduce regressions I split the changes in 30 different
> patches so it could be git bisectable in case of messing a recipe.
> 
> Also, the patches increment the recipes PR since the a distro config can
> set the variables to a different value.
> 
> Changes since v1:
> 
> - Bump recipes PR as suggested by Otavio Salvador and Khem Raj
> - Squash ${base_bindir} and ${sysconfdir} changes for xinetd and lsb
>   recipes so the PR number gets incremented only once. 
> 
> The patch-set consist of the following patches:
> 
> [PATCH v2 01/28] xinetd: use ${sbindir} and ${sysconfdir} instead of
> [PATCH v2 02/28] alsa-state: use ${sbindir} instead of /usr/sbin for
> [PATCH v2 03/28] lsbsetup: use ${bindir} instead of /usr/bin for
> [PATCH v2 04/28] sudo: use ${bindir} and ${sysconfdir} instead of
> [PATCH v2 05/28] lsbtest: use ${bindir} instead of /usr/bin for
> [PATCH v2 06/28] cronie: use variables instead of hardcoded paths
> [PATCH v2 07/28] useradd-example: use ${datadir} instead of
> [PATCH v2 08/28] ubootchart: use variables instead of hardcoded
> [PATCH v2 09/28] xkeyboard-config: use ${datadir} instead of
> [PATCH v2 10/28] systemtap: use ${datadir} instead of /usr/share for
> [PATCH v2 11/28] lsb: use ${base_bindir} and ${sysconfdir} instead
> [PATCH v2 12/28] mingetty: use ${base_sbindir} instead of /sbin for
> [PATCH v2 13/28] external-sourcery: use ${prefix} and ${libdir}
> [PATCH v2 14/28] rpm: use ${localstatedir} and ${libdir} instead of
> [PATCH v2 15/28] at: use ${base_sbindir} instead of /sbin for
> [PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and
> [PATCH v2 17/28] linux-firware: use ${base_libdir} instead of /lib
> [PATCH v2 18/28] openssh: use ${localstatedir} instead of /var for
> [PATCH v2 19/28] libpam: use ${localstatedir} and ${sysconfdir}
> [PATCH v2 20/28] x11-common: use ${sysconfdir} instead of /etc for
> [PATCH v2 21/28] builder: use ${sysconfdir} instead of /etc for
> [PATCH v2 22/28] xserver-nodm-init: use ${sysconfdir} instead of
> [PATCH v2 23/28] lsbinitscripts: use ${sysconfdir} instead of /etc
> [PATCH v2 24/28] usbinit: use ${sysconfdir} instead of /etc for
> [PATCH v2 25/28] qemu-config: use ${sysconfdir} instead of /etc for
> [PATCH v2 26/28] rsync: use ${sysconfdir} instead of /etc for
> [PATCH v2 27/28] chkconfig: use ${sysconfdir} instead of /etc for
> [PATCH v2 28/28] man: use ${sysconfdir} instead of /etc for

Thanks for these, I merged most of them apart from external-sourcery
which Chris commented on, the at recipe which I found a better fix for
which removed the lines in question and the rpm change which I want to
check something out related to it first.

Cheers,

Richard

(no subject)

[lmw]

What is the easiest way to determine the Dom Id of a unmodified Xen HVM guest from within a daemon process running in the guest?

(no subject)

[Olivier Galibert]

  Hi,

This is the second verion of the clipping/interpolation patches.

Main differences:
- I tried to take all of Paul's remarks into account
- I exploded the first patch in 4 independant ones
- I've added a patch to ensure that integers pass through unscathed

Patch 4/9 is (slightly) controversial.  There may be better ways to do
it, or at least more general ones.  But it's simple, it works, and it
allows to validate the other 8.  It's an easy one to revert if we
build an alternative.

Best,

  OG.
 
[PATCH 1/9] intel gen4-5: fix the vue view in the fs.
[PATCH 2/9] intel gen4-5: simplify the bfc copy in the sf.
[PATCH 3/9] intel gen4-5: fix GL_VERTEX_PROGRAM_TWO_SIDE selection.
[PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one
[PATCH 5/9] intel gen4-5: Compute the interpolation status for every
[PATCH 6/9] intel gen4-5: Correctly setup the parameters in the sf.
[PATCH 7/9] intel gen4-5: Correctly handle flat vs. non-flat in the
[PATCH 8/9] intel gen4-5: Make noperspective clipping work.
[PATCH 9/9] intel gen4-5: Don't touch flatshaded values when

(No subject)

[Ross Burton]

Two patches to follow up Andrei Gherzan's connman series.  The first applies
to master, the second only applies on his branch.

(no subject)

[张智]

[-- Attachment #1.1: Type: text/plain, Size: 168 bytes --]


Hi, list,
Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.
All the very best,Henry 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 844 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: (no subject)

[Tim Deegan]

At 04:16 +0000 on 14 Jul (1342239382), ???? wrote:
> 
> Hi, list,
> Where can I find the "tools/tests/mem-sharing/memshrtool.c" ?I didn't find it in the latest version of xen-4.1.2. Thanks.

You'll find it in the xen-unstable tree.  In general the memory-sharing
code in 4.1.x is not stable enough to use. 

Cheers,

Tim.

(No subject)

[Mikhail Boiko]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

From 86ad9569e30de537451fe0a4731ef57d92810d28 Mon Sep 17 00:00:00 2001
From: Mikhail Boiko <mikhailboiko85@gmail.com>
Date: Wed, 4 Jul 2012 00:03:17 +0300
Subject: [PATCH] Additional CMake include search path

Specify additional include search path for CMake via build-in
CMAKE_INCLUDE_PATH variable.
For example, to add freetype2 include dir you should add this line to you
receipe
OECMAKE_INCLUDE_PATH_append = "${STAGING_INCDIR}/freetype2"

Signed-off-by: Mikhail Boiko <mikhailboiko85@gmail.com>
---
 meta/classes/cmake.bbclass |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index eda45dd..2f90e36 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -65,6 +65,9 @@ set( CMAKE_MODULE_PATH ${STAGING_DATADIR}/cmake/Modules/ )
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})

+# additional cmake include search path
+set( CMAKE_INCLUDE_PATH ${OECMAKE_INCLUDE_PATH} )
+
 EOF
 }

-- 
1.7.9.5

[-- Attachment #2: Type: text/html, Size: 1490 bytes --]

(no subject)

[sindu sindhu]

[-- Attachment #1.1: Type: text/plain, Size: 112 bytes --]

http://www.billgoldberg.com/newsite/wp-content/themes/dilapidated/google.html?orqm=gsy.hsm&frf=ar.hkml&gwyj=ixpa

[-- Attachment #1.2: Type: text/html, Size: 398 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

(No subject)

[Andreas Müller]

after updating all my repos (angstrom+few extra layers) I get

  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-kernel/linux/linux-yocto_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/dhcp/dhcp_4.2.3-P2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-ti/recipes-bsp/formfactor/formfactor_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-multimedia/mplayer/mplayer2_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer2_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/update-rc.d/update-rc.d_0.7.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-bsp/x-load/x-load_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-gumstix/recipes-bsp/x-load/x-load_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-angstrom/recipes-extended/zypper/zypper_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.8.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-kde/recipes-misc-support/qt4-x11-free_4.8.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-bsp/alsa-state/alsa-state.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
  /home/Superandy/data/oe-core/sources/meta-ti/recipes-bsp/alsa-state/alsa-state.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-graphics/tslib/tslib_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/openssh/openssh_6.0p1.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/kexecboot/kexecboot-klibc_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-gnome/tasks/task-core-sdk-gmae.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk-intermediate_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/tasks/task-qte-toolchain-target.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/qt4/qt4-embedded_4.8.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/base-files/base-files_3.0.14.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/base-files/base-files_3.0.14.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/base-files/base-files_3.0.14.bbappend
  /home/Superandy/data/oe-core/sources/meta-kde/recipes-misc-support/qt4-native_4.8.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-ti/recipes-core/netbase/netbase_4.47.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/drm/libdrm_2.4.34.bbappend
  /home/Superandy/data/oe-core/sources/meta-gumstix/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.05.00.03.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-core/dropbear/dropbear_2012.55.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer-common.bbappend
  /home/Superandy/data/oe-core/sources/meta-freescale/recipes-bsp/u-boot/u-boot_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-core/tasks/task-core-tools-profile.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-htc/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-ti/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/cronie/cronie_1.4.8.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/initscripts/initscripts_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/initscripts/initscripts_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-core/initscripts/initscripts_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-gnome/gtk+/gtk-update-icon-cache-runonce.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-gumstix/recipes-kernel/linux/linux_3.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-gnome/tasks/task-core-standalone-gmae-sdk-target.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/tasks/task-base.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/kexecboot/kexecboot_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/systemd/systemd-machine-units_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/systemd/systemd-machine-units_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-gnome/recipes-gnome/gtk+/gtk+_2.24.8.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/connman/connman_0.79.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-support/lvm2/lvm2_2.02.85.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/mesa/mesa-dri_7.11.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk-initial_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-browser/recipes-support/nspr/nspr_4.8.9.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-graphics/xorg-lib/pixman_0.25.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-navigation/gpsd/gpsd_3.4.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-bsp/keymaps/keymaps_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-bsp/keymaps/keymaps_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/keymaps/keymaps_1.0.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-core/busybox/busybox_1.19.4.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-intermediate_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-intel/common/recipes-kernel/linux-firmware/linux-firmware_git.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-initial_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-gumstix/recipes-kernel/linux/linux-mainline_3.2.bbappend
  /home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/libgcc_4.6.bbappend
  /home/Superandy/data/oe-core/sources/meta-handheld/recipes-core/udev/udev_164.bbappend

Strange: many recipes are available. Anybody else with similar experience?

Andreas

(No subject)

[Henning Heinold]

Hi,

yes, that means the recpies are deleted in oe-core. For a quick workaround just delete the append files.
Another issue for now is the removing of the linux-tools.inc So you have to delete the include in all
the kernel recipes.

Bye Henning

(no subject)

[Muhammad Jamil]

Learn How to Make Money Online
http://3ftechnologies.com/http102dx-2.php?qohranknumber=245





__________________
  Why dont your juries hangmurderers?  Because theyre afraid the mans friends will shoot them inthe back, in the dark--and its just what they WOULD do. kaelah winfrith
Thu, 31 May 2012 19:00:33

(no subject)

[sabah halif]

-- 
Good day,my name is Mrs Sabah Halif  i have a proposal please contact 
me for details.

(No subject)

[Craig McQueen]

I am new to OE. I am trying to build OE from the git repository, for Freescale i.MX28, following the instructions here:

http://www.imxdev.org/wiki/index.php?title=All_Boards_OpenEmbedded

I am having a build failure trying to fetch elftosb-10.12.01.tar.gz. The command I run is:

 bitbake bootstrap-image

The error is pasted at the bottom of this message.

Is bootstrap-image still a valid build target?

What needs to be fixed to build elftosb?

I am trying to build from git 'master' branch, commit b50fde72d5789b3185f9a7c64924280bb063cfad. Building on Ubuntu 11.10.

Regards,
Craig McQueen


NOTE: Running task 1299 of 4060 (ID: 844, virtual:native:/home/craigm/openembedded/stuff/openembedded/recipes/freescale/elftosb_10.12.01.bb, do_fetch)
NOTE: package elftosb-native-10.12.01-r0: task do_fetch: Started
--2012-05-01 15:12:26--  http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
 Resolving foss.doredevelopment.dk... 62.95.78.42
 Connecting to foss.doredevelopment.dk|62.95.78.42|:80... failed: Connection timed out.
 Retrying.
 
 --2012-05-01 15:15:39--  (try: 2)  http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
 Connecting to foss.doredevelopment.dk|62.95.78.42|:80... failed: Connection timed out.
 Retrying.
 
 --2012-05-01 15:18:50--  (try: 3)  http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
 Connecting to foss.doredevelopment.dk|62.95.78.42|:80... failed: Connection timed out.
 Retrying.
 
 --2012-05-01 15:22:03--  (try: 4)  http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
 Connecting to foss.doredevelopment.dk|62.95.78.42|:80... failed: Connection timed out.
 Retrying.
 
 --2012-05-01 15:25:16--  (try: 5)  http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
 Connecting to foss.doredevelopment.dk|62.95.78.42|:80... failed: Connection timed out.
 Giving up.
 
 --2012-05-01 15:28:25--  http://mirrors.openembedded.org/elftosb-10.12.01.tar.gz
 Resolving mirrors.openembedded.org... 82.197.159.157
 Connecting to mirrors.openembedded.org|82.197.159.157|:80... failed: No route to host.
 --2012-05-01 15:28:28--  http://sources.openembedded.org/elftosb-10.12.01.tar.gz
 Resolving sources.openembedded.org... 140.211.169.152
 Connecting to sources.openembedded.org|140.211.169.152|:80... connected.
 HTTP request sent, awaiting response... 404 Not Found
 2012-05-01 15:28:29 ERROR 404: Not Found.
 
 --2012-05-01 15:28:29--  http://www.angstrom-distribution.org/unstable/sources/elftosb-10.12.01.tar.gz
 Resolving www.angstrom-distribution.org... 188.40.83.200
 Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected.
 HTTP request sent, awaiting response... 404 Not Found
 2012-05-01 15:28:31 ERROR 404: Not Found.
 
NOTE: package elftosb-native-10.12.01-r0: task Fetch failed: Unable to fetch URL http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz from any source.: Failed
ERROR: Function 'Fetch failed: Unable to fetch URL http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz from any source.' failed
ERROR: Task 844 (virtual:native:/home/craigm/openembedded/stuff/openembedded/recipes/freescale/elftosb_10.12.01.bb, do_fetch) failed with exit code '1'
ERROR: 'virtual:native:/home/craigm/openembedded/stuff/openembedded/recipes/freescale/elftosb_10.12.01.bb' failed
craigm@fw-linux:~/openembedded$

(No subject)

[Radoslav Kolev]

On Tue, May 1, 2012 at 10:57 AM, Craig McQueen
<craig.mcqueen@beamcommunications.com> wrote:
> I am new to OE. I am trying to build OE from the git repository, for Freescale i.MX28, following the instructions here:

If you're starting a new project may be it's better to base it on
oe-core. Have a look here:
http://groups.google.com/group/meta-fsl-arm

> I am having a build failure trying to fetch elftosb-10.12.01.tar.gz. The command I run is:

change the SRC_URI to this one in the elftosb recipe:

SRC_URI = "http://repository.timesys.com/buildsources/e/elftosb/elftosb-${PV}/elftosb-${PV}.tar.gz"

Regards,
Rado

(no subject)

[Lin Ming]

Hi all,

These 2 patches try to fix the "perf top" soft lockups under Xen
reported by Steven at: https://lkml.org/lkml/2012/2/9/506

I tested it with 3.4-rc2 and "perf top" works well now.

Steven,
Could you please help to test it too?

The soft lockup code path is:

__irq_work_queue
  arch_irq_work_raise
    apic->send_IPI_self(IRQ_WORK_VECTOR);
      apic_send_IPI_self
        __default_send_IPI_shortcut
          __xapic_wait_icr_idle

static inline void __xapic_wait_icr_idle(void)
{
        while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
                cpu_relax();
}

The lockup happens at above while looop.
                                                                
The cause is that Xen has not implemented the APIC IPI interface yet.
Xen has IPI interface: xen_send_IPI_one, but it's only used in
xen_smp_send_reschedule, xen_smp_send_call_function_ipi and
xen_smp_send_call_function_single_ipi, etc.

So we need to implement Xen's APIC IPI interface as Ben's patch does.
And implement Xen's IRQ_WORK_VECTOR handler.

Ben Guthro (1):
      xen: implement apic ipi interface

Lin Ming (1):
      xen: implement IRQ_WORK_VECTOR handler

 arch/x86/include/asm/xen/events.h |    1 +
 arch/x86/xen/enlighten.c          |    7 ++
 arch/x86/xen/smp.c                |  111 +++++++++++++++++++++++++++++++++++-
 arch/x86/xen/smp.h                |   12 ++++
 4 files changed, 127 insertions(+), 4 deletions(-)

Any comment is appreciated.
Lin Ming

(no subject)

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers.
>From EDID spec we can (might?) infer modes using GTF and CVT when monitor allows it trough range limited flag... obviously limiting by the range.
>From our code:
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
 * - detailed modes from extension blocks
 * - CVT 3-byte code modes
 * - standard timing codes
 * - established timing codes
 * - modes inferred from GTF or CVT range information
 *
 * We get this pretty much right.

Not actually so right... We were inferring just using GTF... not CVT or even GTF2.
This patch not just add some common cvt modes but also allows some modes been inferred when using gtf2 as well.

Cheers,
Rodrigo.

>From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
 allows range limited ones trough EDID.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/drm_edid.c       |   37 +++++++++++++-
 drivers/gpu/drm/drm_edid_modes.h |  101 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
 	return modes;
 }
 
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+			struct detailed_timing *timing)
+{
+	int i, modes = 0;
+	struct drm_display_mode *newmode;
+	struct drm_device *dev = connector->dev;
+
+	for (i = 0; i < drm_num_cvt_inferred_modes; i++) {
+		if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+			newmode = drm_mode_duplicate(dev, &drm_cvt_inferred_modes[i]);
+			if (newmode) {
+				drm_mode_probed_add(connector, newmode);
+				modes++;
+			}
+		}
+	}
+
+	return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
 	struct detailed_mode_closure *closure = c;
 	struct detailed_non_pixel *data = &timing->data.other_data;
-	int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
+	int timing_level = standard_timing_level(closure->edid);
 
-	if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
+	if (data->type == EDID_DETAIL_MONITOR_RANGE)
+	    switch (timing_level) {
+	    case LEVEL_DMT:
+		break;
+	    case LEVEL_GTF:
+	    case LEVEL_GTF2:
 		closure->modes += drm_gtf_modes_for_range(closure->connector,
 							  closure->edid,
 							  timing);
+		break;
+	    case LEVEL_CVT:
+		closure->modes += drm_cvt_modes_for_range(closure->connector,
+							  closure->edid,
+							  timing);
+		break;
+	    }
 }
 
 static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
 static const int drm_num_dmt_modes =
 	sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
 
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+	/* 640x480@60Hz */
+	{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 23750  640, 664,
+		   720, 800, 0, 480, 483, 487, 500, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 800x600@60Hz */
+	{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+		   912, 1024, 0, 600, 603, 607, 624, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 900x600@60Hz */
+	{ DRM_MODE("900x600", DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+		   1088, 1216, 0, 600, 603, 609, 624, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1024x576@60Hz */
+	{ DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+		   1160, 1296, 0, 576, 579, 584, 599, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1024x768@60Hz */
+	{ DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+		   1176, 1328, 0, 768, 771, 775, 798, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1152x864@60Hz */
+	{ DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 81750, 1152, 1216,
+		   1336, 1520, 0, 864, 867, 871, 897, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1280x720@60Hz */
+	{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74500, 1280, 1344,
+		   1472, 1664, 0, 720, 723, 728, 748, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1280x768@60Hz */
+	{ DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
+		   1472, 1664, 0, 768, 771, 781, 798, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1280x800@60Hz */
+	{ DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
+		   1480, 1680, 0, 800, 803, 809, 831, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1280x1024@60Hz */
+	{ DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 109000, 1280, 1368,
+		   1496, 1712, 0, 1024, 1027, 1034, 1063, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1360x768@60Hz */
+	{ DRM_MODE("1360x768", DRM_MODE_TYPE_DRIVER, 84750, 1360, 1432,
+		   1568, 1776, 0, 768, 771, 781, 798, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1366x768@60Hz */
+	{ DRM_MODE("1366x768", DRM_MODE_TYPE_DRIVER, 85250, 1368, 1440,
+		   1576, 1784, 0, 768, 771, 781, 798, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1440x900@60Hz */
+	{ DRM_MODE("1440x900", DRM_MODE_TYPE_DRIVER, 106500, 1440, 1528,
+		   1672, 1904, 0, 900, 903, 909, 934, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1400x1050@60Hz */
+	{ DRM_MODE("1400x1050", DRM_MODE_TYPE_DRIVER, 121750, 1400, 1488,
+		   1632, 1864, 0, 1050, 1053, 1057, 1089, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1600x900@60Hz */
+	{ DRM_MODE("1600x900", DRM_MODE_TYPE_DRIVER, 118250, 1600, 1696,
+		   1856, 2112, 0, 900, 903, 908, 934, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1600x1200@60Hz */
+	{ DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 161000, 1600, 1712,
+		   1880, 2160, 0, 1200, 1203, 1207, 1245, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1680x945@60Hz */
+	{ DRM_MODE("1680x945", DRM_MODE_TYPE_DRIVER, 130750, 1680, 1776,
+		   1952, 2224, 0, 945, 948, 953, 981, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1680x1050@60Hz */
+	{ DRM_MODE("1680x1050", DRM_MODE_TYPE_DRIVER, 146250, 1680, 1784,
+		   1960, 2240, 0, 1050, 1053, 1059, 1089, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1920x1080@60Hz */
+	{ DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 73000, 1920, 2048,
+		   2248, 2576, 0, 1080, 1083, 1088, 1120, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1920x1200@60Hz */
+	{ DRM_MODE("1920x1200", DRM_MODE_TYPE_DRIVER, 193250, 1920, 2056,
+		   2256, 2592, 0, 1200, 1203, 1209, 1245, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 1920x1440@60Hz */
+	{ DRM_MODE("1920x1440", DRM_MODE_TYPE_DRIVER, 233500, 1920, 2064,
+		   2264, 2608, 0, 1440, 1443, 1447, 1493, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 2048x1152@60Hz */
+	{ DRM_MODE("2048x1152", DRM_MODE_TYPE_DRIVER, 197000, 2048, 2184,
+		   2400, 2752, 0, 1152, 1155, 1160, 1195, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 2048x1536@60Hz */
+	{ DRM_MODE("2048x1536", DRM_MODE_TYPE_DRIVER, 272000, 2048, 2208,
+		   2424, 2800, 0, 1563, 1566, 1576, 1620, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+	/* 2560x1600@60Hz */
+	{ DRM_MODE("2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
+		   3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
+		   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+};
+static const int drm_num_cvt_inferred_modes =
+	sizeof(drm_cvt_inferred_modes) / sizeof(struct drm_display_mode);
+
 static const struct drm_display_mode edid_est_modes[] = {
 	{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 40000, 800, 840,
 		   968, 1056, 0, 600, 601, 605, 628, 0,
-- 
1.7.7.6

(no subject)

[niamathullah sharief]

Turn your pc into making money machine.
http://184.168.145.37/gerhfgtim.php?jqyrfreepage=201



__________________
"_Instead, therefore, of relying on the barometer,the ship is equipped with a telescope which maybe instantly set at an angle of 45 degrees, or vertically." (c) sammijo windgate
Mon, 9 Apr 2012 15:39:25

(no subject)

[Muhammad Jamil]

Make Income 0nline with revolutionary system
http://184.168.145.37/etdfgtim.php?pjtcamp=95

            Sun, 8 Apr 2012 3:25:59
______________
"Billy took his seat with the others around a golden oak table, with a microphone all his own." (c) jerald visszapattant

(no subject)

[Francisco Rocha]

Date: Thu, 5 Apr 2012 18:44:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] lastest xen unstable crash
Message-ID: <4F7DD9EE.3080404@citrix.com>
Content-Type: text/plain; charset="ISO-8859-1"

On 05/04/12 18:37, Francisco Rocha wrote:
> Hi everyone,
>
> I was trying to build a new machine but the system keeps rebooting.
> I used the lasted unstable version from xen-unstable.hg.
>
> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>
> The output to my serial console is attached.
>
> Cheers,
> Francisco

What is your Linux command line? does it include "console=hvc0"? 
Perhaps some early_printk settings are required.

Please include my email in your replies, thank you.

Yes, it includes hvc0. I used your tutorial to setup the SOL.

title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
root         (hd0,0)
kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
module       /initrd-2.6.31.6.img

Something like this, I am not at the machine anymore.

Francisco

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Re: (no subject)

[Wei Huang]

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in 
xstate_enable() function to be exact) related. You can try to disable 
xsave to to see if this helps.

-Wei

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 20:36
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 01:26 PM, Francisco Rocha wrote:
> Date: Thu, 5 Apr 2012 18:44:14 +0100
> From: Andrew Cooper<andrew.cooper3@citrix.com>
> To:<xen-devel@lists.xen.org>
> Subject: Re: [Xen-devel] lastest xen unstable crash
> Message-ID:<4F7DD9EE.3080404@citrix.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> On 05/04/12 18:37, Francisco Rocha wrote:
>> Hi everyone,
>>
>> I was trying to build a new machine but the system keeps rebooting.
>> I used the lasted unstable version from xen-unstable.hg.
>>
>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>
>> The output to my serial console is attached.
>>
>> Cheers,
>> Francisco
> What is your Linux command line? does it include "console=hvc0"?
> Perhaps some early_printk settings are required.
>
> Please include my email in your replies, thank you.
>
> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>
> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
> root         (hd0,0)
> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
> module       /initrd-2.6.31.6.img
>
> Something like this, I am not at the machine anymore.
>
> Francisco
>
It looks like xsave/xrstore instructions (xsetbv instruction in
xstate_enable() function to be exact) related. You can try to disable
xsave to to see if this helps.

-Wei

Sorry about the untitled message. 

Should I be the one disabling xsave or is that for Andrew to change something?
How can I do that?

Anyway, shouldn't Xen support it?

cheers,
Francisco

Re: (no subject)

[Wei Huang]

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which 
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz 
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Francisco Rocha
Sent: 05 April 2012 21:43
To: wei.huang2@amd.com
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: RE: [Xen-devel] (no subject)

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 05 April 2012 21:27
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On 04/05/2012 03:17 PM, Francisco Rocha wrote:
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 20:36
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>> To:<xen-devel@lists.xen.org>
>> Subject: Re: [Xen-devel] lastest xen unstable crash
>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>> Content-Type: text/plain; charset="ISO-8859-1"
>>
>> On 05/04/12 18:37, Francisco Rocha wrote:
>>> Hi everyone,
>>>
>>> I was trying to build a new machine but the system keeps rebooting.
>>> I used the lasted unstable version from xen-unstable.hg.
>>>
>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>
>>> The output to my serial console is attached.
>>>
>>> Cheers,
>>> Francisco
>> What is your Linux command line? does it include "console=hvc0"?
>> Perhaps some early_printk settings are required.
>>
>> Please include my email in your replies, thank you.
>>
>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>
>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>> root         (hd0,0)
>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>> module       /initrd-2.6.31.6.img
>>
>> Something like this, I am not at the machine anymore.
>>
>> Francisco
>>
> It looks like xsave/xrstore instructions (xsetbv instruction in
> xstate_enable() function to be exact) related. You can try to disable
> xsave to to see if this helps.
>
> -Wei
>
> Sorry about the untitled message.
>
> Should I be the one disabling xsave or is that for Andrew to change something?
> How can I do that?
Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
line of grub entry and boot again. Something like this:

kernel /boot/xen.gz blah blah xsave=0
module blah blah
blah

Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.

Thank you for the help.

Francisco

-Wei

>
> Anyway, shouldn't Xen support it?
>
> cheers,
> Francisco

The xsave=0 command line parameter solves the problem.

Thank you,
Francisco

Re: (no subject)

[Wei Huang]

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with 
xsave/xrstor.

-Wei

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Wei Huang [wei.huang2@amd.com]
Sent: 06 April 2012 15:51
To: Francisco Rocha
Cc: Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
xsave/xrstor.

-Wei

I didn't change the kernel, it's a fresh install.
I tried the latest for Fedora 16 and Xubuntu 11.10 both 
rebooted the machine.

Cheers,
Francisco

On 04/06/2012 09:53 AM, Francisco Rocha wrote:
> ________________________________________
> From: Francisco Rocha
> Sent: 05 April 2012 21:43
> To: wei.huang2@amd.com
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] (no subject)
>
> ________________________________________
> From: Wei Huang [wei.huang2@amd.com]
> Sent: 05 April 2012 21:27
> To: Francisco Rocha
> Cc: Andrew Cooper; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] (no subject)
>
> On 04/05/2012 03:17 PM, Francisco Rocha wrote:
>> ________________________________________
>> From: Wei Huang [wei.huang2@amd.com]
>> Sent: 05 April 2012 20:36
>> To: Francisco Rocha
>> Cc: Andrew Cooper; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] (no subject)
>>
>> On 04/05/2012 01:26 PM, Francisco Rocha wrote:
>>> Date: Thu, 5 Apr 2012 18:44:14 +0100
>>> From: Andrew Cooper<andrew.cooper3@citrix.com>
>>> To:<xen-devel@lists.xen.org>
>>> Subject: Re: [Xen-devel] lastest xen unstable crash
>>> Message-ID:<4F7DD9EE.3080404@citrix.com>
>>> Content-Type: text/plain; charset="ISO-8859-1"
>>>
>>> On 05/04/12 18:37, Francisco Rocha wrote:
>>>> Hi everyone,
>>>>
>>>> I was trying to build a new machine but the system keeps rebooting.
>>>> I used the lasted unstable version from xen-unstable.hg.
>>>>
>>>> I have tried with Fedora 16 (kernel 3.3.0-8) and Xubuntu 11.10 (3.0.0.17-generic).
>>>>
>>>> The output to my serial console is attached.
>>>>
>>>> Cheers,
>>>> Francisco
>>> What is your Linux command line? does it include "console=hvc0"?
>>> Perhaps some early_printk settings are required.
>>>
>>> Please include my email in your replies, thank you.
>>>
>>> Yes, it includes hvc0. I used your tutorial to setup the SOL.
>>>
>>> title        Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console
>>> root         (hd0,0)
>>> kernel       /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1
>>> module       /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset
>>> module       /initrd-2.6.31.6.img
>>>
>>> Something like this, I am not at the machine anymore.
>>>
>>> Francisco
>>>
>> It looks like xsave/xrstore instructions (xsetbv instruction in
>> xstate_enable() function to be exact) related. You can try to disable
>> xsave to to see if this helps.
>>
>> -Wei
>>
>> Sorry about the untitled message.
>>
>> Should I be the one disabling xsave or is that for Andrew to change something?
>> How can I do that?
> Xen-unstable supports xsave/xrstor. You are using kernel 3.x.x, which
> should support xsave/xrstor too. You can try to set xsave=0 in xen.gz
> line of grub entry and boot again. Something like this:
>
> kernel /boot/xen.gz blah blah xsave=0
> module blah blah
> blah
>
> Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
>
> Thank you for the help.
>
> Francisco
>
> -Wei
>
>> Anyway, shouldn't Xen support it?
>>
>> cheers,
>> Francisco
> The xsave=0 command line parameter solves the problem.
>
> Thank you,
> Francisco
>

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

Re: (no subject)

[Francisco Rocha]

________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: 06 April 2012 16:14
To: Wei Huang
Cc: Francisco Rocha; Andrew Cooper; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] (no subject)

On Fri, Apr 06, 2012 at 09:51:52AM -0500, Wei Huang wrote:
> Then I think your Dom0 (i.e. kernel 3.x.x) has some problems with
> xsave/xrstor.

Hm .

.. snip..
> >kernel /boot/xen.gz blah blah xsave=0
> >module blah blah
> >blah
> >
> >Oh, i see, it's some new functionality. I will try it tomorrow and then let you know how it goes.
> >
> >Thank you for the help.
> >
> >Francisco
> >
> >-Wei
> >
> >>Anyway, shouldn't Xen support it?
> >>
> >>cheers,
> >>Francisco
> >The xsave=0 command line parameter solves the problem.

Francisco,

What version of Xen do you have? Xen 4.1? What is the motherboard/CPU combination.

I downloaded the latest version from xen-unstable.hg yesterday.

My machine is a Toshiba laptop R840-12F. Here is some info:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
stepping	: 7
microcode	: 0x25
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5382.80
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

BIOS: TOSHIBA
Version: Version 3.60  
Release Date: 01/24/2012

(no subject)

[Muhammad Jamil]

Learn H0w T0 Earn M0ney 0nline N0w
http://residentialtreatmentcenter.net/coffegold.php?evynumber=91



            Thu, 5 Apr 2012 7:44:44
_________________________________
" You yell." (c) daelynn wulfgar

(no subject)

[Muhammad Jamil]

[-- Attachment #1.1: Type: text/plain, Size: 109 bytes --]

http://www.signsandsites.com/wp-content/themes/duotone/nav21.php
Muhammad Jamil
Sumintar
4/3/2012 11:25:11 AM

[-- Attachment #1.2: Type: text/html, Size: 366 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[Muhammad Jamil]

W0rking fr0m h0me Ieads t0 sh0cking m0ney resuIts!
http://jadehurtz.com/coffeemoney.php?apohgoto=64



            Tue, 3 Apr 2012 13:42:09
______________
"  So Tom took his goods out himself, and soughtemployers for Bert who did not know of this strain of poetry inhis nature" (c) britin wynton

(no subject)

[Ian Jackson]

Once again, I have not executed the code in this series!

These three are intended to be bugfixes to sort out
the deadlock problem that Roger Pau Monne reported:
 01/15 libxl: ao: allow immediate completion
 02/15 libxl: fix hang due to libxl__initiate_device_remove

These are other bugfixes:
 03/15 libxl: Fix eventloop_iteration over-locking
 04/15 libxl: Fix leak of ctx->lock
 05/15 libxl: abolish libxl_ctx_postfork
 06/15 tools: Correct PTHREAD options in config/StdGNU.mk
 07/15 libxl: Use PTHREAD_CFLAGS, LDFLAGS, LIBS
 08/15 libxl: Crash (more sensibly) on malloc failure

These are handy new bits for internal libxl users:
 09/15 libxl: Make libxl__zalloc et al tolerate a NULL gc
 10/15 libxl: Introduce some convenience macros
 11/15 libxl: Protect fds with CLOEXEC even with forking threads
 12/15 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 14/15 libxl: Provide libxl_string_list_length
 15/15 libxl: Introduce libxl__sendmsg_fds and libxl__recvmsg_fds

This is the new child-handling machinery:
 13/15 libxl: event API: new facilities for waiting for subprocesses

There are not any users for much of this code in this series.  I have
a half-written rework of libxl_bootloader.c to make it event-driven,
but it's not suitable for review at this stage.  It doesn't even
compile.

(No subject)

[Andrei Gherzan]

Add Upstream-Status in patch file.

(no subject)

[Ian Jackson]

>From Ian Jackson <ian.jackson@eu.citrix.com> # This line is ignored.
From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [RFC PATCH 0/6] libxl: New child process handling
In-Reply-To: 

This is the first draft of my new libxl API for child process
handling.

 1/6 libxl: Fix leak of ctx->lock
 2/6 libxl: abolish libxl_ctx_postfork
 3/6 tools: Correct PTHREAD options in config/StdGNU.mk
 4/6 libxl: Protect fds with CLOEXEC even with forking threads
 5/6 libxl: libxl_event.c:beforepoll_internal, REQUIRE_FDS
 6/6 libxl: event API: new facilities for waiting for subprocesses

Please comment.  I'm particularly keen on comments about:

 * The correctness of the pthread_atfork logic in 4/6.
 * The sufficiency for applications of the child handling API in 6/6.
 * The portability of the pthread command line option changes in 3/6.
 * Correctness :-).

If you want to apply it to make sense of, you'll need to know that
this series is on top of my recently-posted 3-patch libxl event fixup
series.

Thanks,
Ian.

(No subject)

[Hauser, Wolfgang (external)]

Hello,

is there a recipe for TrueCrypt available which is usable for OE
2011.03-maintenance based environment ?

Regards
Wolfgang Hauser

(no subject)

[Tarak Ranjan]

http://www.troywitt.com/galleries/themes/hybrid/inbex.html

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
-----
squirrelmail-users mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-users@lists.sourceforge.net
List archives: http://news.gmane.org/gmane.mail.squirrelmail.user
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users

(no subject)

[Mikulas Patocka]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 288 bytes --]

Hi

Here I'm sending two dm-bufio patches. The first one fixed 
dm_bufio_release_move function (the write callback could be called with a 
wrong block number). The next one adds a conditional resched (Alasdair 
agreed on it --- it should be later put into general Linux headers).

Mikulas

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1221 bytes --]

---
 drivers/md/dm-bufio.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Index: linux-3.1-rc3-fast/drivers/md/dm-bufio.c
===================================================================
--- linux-3.1-rc3-fast.orig/drivers/md/dm-bufio.c	2011-10-19 18:39:22.000000000 +0200
+++ linux-3.1-rc3-fast/drivers/md/dm-bufio.c	2011-10-19 18:47:43.000000000 +0200
@@ -1185,11 +1185,24 @@ retry:
 		__unlink_buffer(b);
 		__link_buffer(b, new_block, LIST_DIRTY);
 	} else {
+		sector_t old_block;
 		wait_on_bit_lock(&b->state, B_WRITING,
 				 do_io_schedule, TASK_UNINTERRUPTIBLE);
+		/*
+		 * Relink buffer to "new_block" so that write_callback
+		 * sees "new_block" as a block number.
+		 * After the write, link the buffer back to old_block.
+		 * All this must be done in bufio lock, so that block number
+		 * change isn't visible to other threads.
+		 */
+		old_block = b->block;
+		__unlink_buffer(b);
+		__link_buffer(b, new_block, b->list_mode);
 		submit_io(b, WRITE, new_block, write_endio);
 		wait_on_bit(&b->state, B_WRITING,
 			    do_io_schedule, TASK_UNINTERRUPTIBLE);
+		__unlink_buffer(b);
+		__link_buffer(b, old_block, b->list_mode);
 	}
 
 	dm_bufio_unlock(c);

[-- Attachment #3: Type: TEXT/PLAIN, Size: 2874 bytes --]

---
 drivers/md/dm-bufio.c |   26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

Index: linux-3.1-rc3-fast/drivers/md/dm-bufio.c
===================================================================
--- linux-3.1-rc3-fast.orig/drivers/md/dm-bufio.c	2011-10-19 18:49:14.000000000 +0200
+++ linux-3.1-rc3-fast/drivers/md/dm-bufio.c	2011-10-19 18:57:01.000000000 +0200
@@ -183,6 +183,16 @@ static void dm_bufio_unlock(struct dm_bu
 	mutex_unlock(&c->lock);
 }
 
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+#define dm_bufio_cond_resched()                	\
+do {						\
+	if (unlikely(need_resched()))		\
+		_cond_resched();		\
+} while (0)
+#else
+#define dm_bufio_cond_resched()                do { } while (0)
+#endif
+
 /*----------------------------------------------------------------*/
 
 /*
@@ -644,6 +654,7 @@ static struct dm_buffer *__get_unclaimed
 			__unlink_buffer(b);
 			return b;
 		}
+		dm_bufio_cond_resched();
 	}
 
 	list_for_each_entry_reverse(b, &c->lru[LIST_DIRTY], lru_list) {
@@ -654,6 +665,7 @@ static struct dm_buffer *__get_unclaimed
 			__unlink_buffer(b);
 			return b;
 		}
+		dm_bufio_cond_resched();
 	}
 
 	return NULL;
@@ -772,6 +784,7 @@ static void __write_dirty_buffers_async(
 			return;
 
 		__write_dirty_buffer(b);
+		dm_bufio_cond_resched();
 	}
 }
 
@@ -820,6 +833,7 @@ static void __check_watermark(struct dm_
 			return;
 
 		__free_buffer_wake(b);
+		dm_bufio_cond_resched();
 	}
 
 	if (c->n_buffers[LIST_DIRTY] > threshold_buffers)
@@ -835,9 +849,11 @@ static struct dm_buffer *__find(struct d
 	struct hlist_node *hn;
 
 	hlist_for_each_entry(b, hn, &c->cache_hash[DM_BUFIO_HASH(block)],
-			     hash_list)
+			     hash_list) {
+		dm_bufio_cond_resched();
 		if (b->block == block)
 			return b;
+	}
 
 	return NULL;
 }
@@ -1084,6 +1100,8 @@ again:
 		    !test_bit(B_WRITING, &b->state))
 			__relink_lru(b, LIST_CLEAN);
 
+		dm_bufio_cond_resched();
+
 		/*
 		 * If we dropped the lock, the list is no longer consistent,
 		 * so we must restart the search.
@@ -1310,11 +1328,13 @@ static void __scan(struct dm_bufio_clien
 	int l;
 	struct dm_buffer *b, *tmp;
 
-	for (l = 0; l < LIST_SIZE; l++)
+	for (l = 0; l < LIST_SIZE; l++) {
 		list_for_each_entry_safe_reverse(b, tmp, &c->lru[l], lru_list)
 			if (!__cleanup_old_buffer(b, sc->gfp_mask, 0) &&
 			    !--nr_to_scan)
 				return;
+		dm_bufio_cond_resched();
+	}
 }
 
 static int shrink(struct shrinker *shrinker, struct shrink_control *sc)
@@ -1531,9 +1551,11 @@ static void cleanup_old_buffers(void)
 				       struct dm_buffer, lru_list);
 			if (__cleanup_old_buffer(b, 0, max_age * HZ))
 				break;
+			dm_bufio_cond_resched();
 		}
 
 		dm_bufio_unlock(c);
+		dm_bufio_cond_resched();
 	}
 	mutex_unlock(&dm_bufio_clients_lock);
 }

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

(no subject)

[Paolo Bonzini]

Writing [PATCH] netback: disable features not supported by netfront ...
ntent-Transfer-Encoding: 7bit
Subject: [PATCH] netback: disable features not supported by netfront
X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
User-Agent: Mercurial-patchbomb/1.9.1
Date: Mon, 17 Oct 2011 09:37:42 +0200
From: pbonzini@redhat.com
To: pbonzini@redhat.com

# HG changeset patch
# User Paolo Bonzini <pbonzini@redhat.com>
# Date 1318837036 -7200
# Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
# Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
netback: disable features not supported by netfront

Netback works by first setting all possible features, and then
resetting some after connection, if the front-end didn't negotiate them.
Except that in the old 2.6.18 tree the "resetting" part was missing.
In the pvops tree, this should work correctly through the fix_features
mechanism.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
--- a/drivers/xen/netback/interface.c
+++ b/drivers/xen/netback/interface.c
@@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
 void netif_set_features(netif_t *netif)
 {
 	struct net_device *dev = netif->dev;
-	int features = dev->features;
+	int features;
 
+	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
 	if (netif->can_sg)
 		features |= NETIF_F_SG;
 	if (netif->gso)

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:

Something went wrong with your patchbomb..

anyhow, lets CC Ian here since he is the maintainer.

> 
> Writing [PATCH] netback: disable features not supported by netfront ...
> ntent-Transfer-Encoding: 7bit
> Subject: [PATCH] netback: disable features not supported by netfront
> X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> User-Agent: Mercurial-patchbomb/1.9.1
> Date: Mon, 17 Oct 2011 09:37:42 +0200
> From: pbonzini@redhat.com
> To: pbonzini@redhat.com
> 
> # HG changeset patch
> # User Paolo Bonzini <pbonzini@redhat.com>
> # Date 1318837036 -7200
> # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> netback: disable features not supported by netfront
> 
> Netback works by first setting all possible features, and then
> resetting some after connection, if the front-end didn't negotiate them.
> Except that in the old 2.6.18 tree the "resetting" part was missing.
> In the pvops tree, this should work correctly through the fix_features
> mechanism.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> --- a/drivers/xen/netback/interface.c
> +++ b/drivers/xen/netback/interface.c
> @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
>  void netif_set_features(netif_t *netif)
>  {
>  	struct net_device *dev = netif->dev;
> -	int features = dev->features;
> +	int features;
>  
> +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
>  	if (netif->can_sg)
>  		features |= NETIF_F_SG;
>  	if (netif->gso)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: (no subject)

[Ian Campbell]

On Mon, 2011-10-17 at 18:05 +0100, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
> 
> Something went wrong with your patchbomb..
> 
> anyhow, lets CC Ian here since he is the maintainer.

This is a 2.6.18-xen patch. I'm not especially interested in that tree
-- Jan looks after it though and picked up this patch from the resend.

Ian.

> 
> > 
> > Writing [PATCH] netback: disable features not supported by netfront ...
> > ntent-Transfer-Encoding: 7bit
> > Subject: [PATCH] netback: disable features not supported by netfront
> > X-Mercurial-Node: eb896361fc70b60b9a257d0c82e19633a11b9d41
> > Message-Id: <eb896361fc70b60b9a25.1318837062@yakj.usersys.redhat.com>
> > User-Agent: Mercurial-patchbomb/1.9.1
> > Date: Mon, 17 Oct 2011 09:37:42 +0200
> > From: pbonzini@redhat.com
> > To: pbonzini@redhat.com
> > 
> > # HG changeset patch
> > # User Paolo Bonzini <pbonzini@redhat.com>
> > # Date 1318837036 -7200
> > # Node ID eb896361fc70b60b9a257d0c82e19633a11b9d41
> > # Parent  3c900d6a5f6a51ff1547f21fef30ab8b92feccc9
> > netback: disable features not supported by netfront
> > 
> > Netback works by first setting all possible features, and then
> > resetting some after connection, if the front-end didn't negotiate them.
> > Except that in the old 2.6.18 tree the "resetting" part was missing.
> > In the pvops tree, this should work correctly through the fix_features
> > mechanism.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > 
> > diff --git a/drivers/xen/netback/interface.c b/drivers/xen/netback/interface.c
> > --- a/drivers/xen/netback/interface.c
> > +++ b/drivers/xen/netback/interface.c
> > @@ -98,8 +98,9 @@ static int netbk_change_mtu(struct net_d
> >  void netif_set_features(netif_t *netif)
> >  {
> >  	struct net_device *dev = netif->dev;
> > -	int features = dev->features;
> > +	int features;
> >  
> > +	features = dev->features & ~(NETIF_F_SG|NETIF_F_TSO|NETIF_F_IP_CSUM);
> >  	if (netif->can_sg)
> >  		features |= NETIF_F_SG;
> >  	if (netif->gso)
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

Re: (no subject)

[Paolo Bonzini]

On 10/17/2011 07:05 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 17, 2011 at 09:40:49AM +0200, Paolo Bonzini wrote:
>
> Something went wrong with your patchbomb..
>
> anyhow, lets CC Ian here since he is the maintainer.

Already resent, and acked by Jan. :)

Paolo

(no subject)

[Maxim Levitsky]

Hi,

This is my work in documenting EVO.
I did some RE to fill missing gaps.

Best regards,
	Maxim Levitsky

(no subject)

[Pratik shinde]

[-- Attachment #1.1: Type: text/plain, Size: 44 bytes --]

why coscheduling is not implemented in xen?

[-- Attachment #1.2: Type: text/html, Size: 48 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Andrew Cooper]

On 06/10/11 14:11, Pratik shinde wrote:
> why coscheduling is not implemented in xen?

http://wiki.xen.org/xenwiki/AskingXenDevelQuestions

After reading that wiki page, please explain why you think coscheduling
should be implemented on Xen.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

(No subject)

[Joel A Fernandes]

On Fri, Aug 26, 2011 at 10:26 PM, Fernandes, Joel A <joelagnel@ti.com> wrote:
> v2 Changes:
> Addressing Koen's feedback on patches
> * Added a PR to all recipes

I thought you meant the PR when you said "Which version", didn't know
you were talking about the LICENSE versions.

Anyway, Can we leave the PRs I put into patches 2/4 and 4/4 in?

Also, is it necessary to update LICENSE versions or can we leave it as
is, as I've seen many recipes in oe-core that have it without a
version number.

thanks,
Joel

> * Changed meta-ti in subject to meta-oe
>
> Patches in the series:
>
> [PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
> [PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
> [PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
> [PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic
>

(No subject)

[Koen Kooi]

Op 27 aug. 2011, om 06:38 heeft Joel A Fernandes het volgende geschreven:

> On Fri, Aug 26, 2011 at 10:26 PM, Fernandes, Joel A <joelagnel@ti.com> wrote:
>> v2 Changes:
>> Addressing Koen's feedback on patches
>> * Added a PR to all recipes
> 
> I thought you meant the PR when you said "Which version", didn't know
> you were talking about the LICENSE versions.
> 
> Anyway, Can we leave the PRs I put into patches 2/4 and 4/4 in?

No

> Also, is it necessary to update LICENSE versions

Working for a big corporation, do you really need to ask that?

> or can we leave it as
> is, as I've seen many recipes in oe-core that have it without a
> version number.

The fact that OE-core has 83 recipes with a wrong LICENSE doesn't give meta-oe the excuse to drop the ball.

(No subject)

[Joel A Fernandes]

v2 Changes:
Addressing Koen's feedback on patches
* Added a PR to all recipes
* Changed meta-ti in subject to meta-oe

Patches in the series:

[PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
[PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
[PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
[PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic

(No subject)

[Koen Kooi]

Op 27 aug. 2011, om 05:26 heeft Joel A Fernandes het volgende geschreven:

> v2 Changes:
> Addressing Koen's feedback on patches
> * Added a PR to all recipes
> * Changed meta-ti in subject to meta-oe
> 
> Patches in the series:
> 
> [PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
> [PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
> [PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
> [PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic


Same feedback as for Noors series:

1) drop PR = r*
2) RDEPENDS_${PN} is sorted with FILES_*, so don't put it next to DEPENDS

(no subject)

[Grant McWilliams]

http://succeedonpurpose.com/google.php

(No subject)

[Fan, WenhuaX]

[-- Attachment #1.1: Type: text/plain, Size: 5408 bytes --]

Hi, All
       This is the weekly test report for Yocto 1.1 20110624 build. There are six new bugs found in this testing. Both sato and sato-sdk for Qemux86 and Qemux84-64 were build successfully on autobuilder, and all mete-intel BSPs are validated too. Mkswap failed when installation on emenlow/blacksand/crownbay. X server failed to start up on Crownbay-emgd. Qemuppc lsb-sdk rootfs image and qemumips lsb-sdk image build failed on autobuilder in nightly build. And mmci-omap-hs failed when boot up with current build. Rpm/zypper install/remove consume disk space issue still exist in this build. No icons shown on X desktop with Qemux86-64 sato and sato-sdk. After upgrade the BIOS/firmware, standby issue on Blacksand not reappear. For bug fixing, autobuilder build issues about lsb/sato-sdk/toolchain images are fixed.
         You can access the wiki page @ https://wiki.pokylinux.org/wiki/Yocto_1.1_Weekly_Test_Report


Test Summary:
---------------------------------------


Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

GOOD

parport_pc probe fail of 00:0b

CrownBay-emgd

BLOCK

Format swap partition failed; X server failed to start up when live image from USB.

JasperForest

GOOD

I/OAT DMA engine init failed; No libXinerama.so for sudoku; login meets some error.

Blacksand

GOOD

Format swap partition failed.

eMenlow

GOOD

Format swap partition failed; S3 does not work.

Beagleboard

GOOD

mmci-omap-hs failed when boot up.

Routerstationpro

GOOD

Everything runs well.

Mpc8315e-rdb

GOOD

Everything runs well.

QEMU

qemux86

GOOD

No enough disk space

qemux86-64

GOOD

No enough disk space

qemuarm

GOOD

Missing 'perl' command; Not enough disk space.

qemuppc

Buggy

Missing 'perl' command; Not enough disk space; Unfs doesn't work.

qemumips

GOOD

Missing 'perl' command; Not enough disk space.

ADT

　

Buggy

Unfs does not work with qemuppc; CVS build failed with mips toolchain.


　

Critical bugs, more than 50% test cases are blocked

　

Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed

　

Normal, Major and Critical bugs, and more than 10% test cases failed




Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Sugarbay Sato-SDK

55

0

54

1 (bug 1187)

0

Jasperforest LSB-SDK

32

0

30

2 (bug 1188 1189)

0

n450 Sato-SDK

55

0

54

1 (bug 1099)

0

eMenlow Sato-SDK

55

0

52

3 (bug 310 631 1099)

0

Crownbay-Sato-SDK

55

0

36

0

19

Beagleboard

18

0

17

1 (bug 1201)

0

Routerstationpro

30

0

30

0

0

Mpc8315e-rdb

31

0

31

0

0

Qemux86-64 Sato

28

0

27

1 (bug 1172)

0

Qemux86-64 Sato-SDK

31

0

31

0

0

Qemux86 Sato

28

0

27

1 (bug 1172)

0

Qemux86 Sato-SDK

31

0

31

0

0

Qemumips Sato

28

0

26

2 (bug 1171, 1172)

0

Qemumips Sato-SDK

31

0

31

0

0

Qemuppc Sato

21

0

18

3 (bug 414, 1171, 1172)

0

Qemuppc Sato-SDK

27

0

26

1 (bug 414)

0

Qemuarm Sato

28

0

26

2 (bug 1171, 1172)

0

Qemuarm Sato-SDK

31

0

31

0

0

ADT

6

0

5

1 (bug 414)

0

Total

621

0

583

19

19




* You can check the detailed test result in attachment for each target.

** The failed/blocked case number is listed with failed cases’ bug number.



Commit Information
---------------------------------------

Tree/Branch: Poky/master

Poky Commit: a1f79a7896b6411669b3ccada6204d2695e80fc5

Meta Branch: master

Meta Commit: 50661bf038a34702f3aa139c3ea0d67fbb0ce5db




Issue Summary
---------------------------------------


Component

Bug Number

Target Milestone

System & Core OS

Installation & Boot

New! Bug 1205:[blacksand/emenlow/crownbay] Format swap partition failed when install

1.1 M2

New! Bug 1207:[Crownbay-emgd] X server failed to start up

1.1 M2

System Usage

Bug 1171: No enough disk space with qemu sato images

1.1 M2

Bug 1172: Perl not exist in sato image

1.1 M2

Bug 1174: [zypper/rpm] package install/removal costs lots of disk space

---

Others

New! Bug 1199: qemuppc lsb-sdk rootfs image build failed on autobuilder in nightly build 20110625-1

1.1

New! Bug 1200: qemumips lsb-sdk image build failed on autobuilder with nightly build 20110625-1.

---

New! Bug 1201: [beagleboard C4] mmci-omap-hs failed when boot up with 20110625 build

1.1

ADT

Bug 414: [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

1.1 M3

New! Bug 1195: [mips toolchain] cvs configure fail with no cvs_cv_func_printf_ptr set

1.1 M2



Verified Fixed Bug:
---------------------------------------



1.     Bug 1183<http://bugzilla.pokylinux.org/show_bug.cgi?id=1183> - sstate_task_postfunc fail for manifest-qemux86-qt4-x11-free.deploy-rpm


2.       Bug 1184<http://bugzilla.pokylinux.org/show_bug.cgi?id=1184> - ghostscript checksum fail on autobuilder



3.     Bug 1185<http://bugzilla.pokylinux.org/show_bug.cgi?id=1185> - gcc-cross-canadian do_configure fail on autobuilder for qemuarm/mips/ppc

[-- Attachment #1.2: Type: text/html, Size: 96199 bytes --]

[-- Attachment #2: weekly_detail_testreport-20110624.ods --]
[-- Type: application/oleobject, Size: 14929 bytes --]

(no subject)

[Attila Jecs]

[-- Attachment #1.1: Type: text/plain, Size: 2657 bytes --]

Hi!

well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
0xffffffff815cd65f()
Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
Jun 21 05:18:02 szerver kernel: Modules linked in:
Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
#8
Jun 21 05:18:02 szerver kernel: Call Trace:
Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
Jun 21 05:18:02 szerver kernel: ... version:                0
Jun 21 05:18:02 szerver kernel: ... bit width:              48
Jun 21 05:18:02 szerver kernel: ... generic registers:      4
Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
Jun 21 05:18:02 szerver kernel: devtmpfs: initialized

maybe it helps.
if u need more info, just tell me
-- 
Attila Jecs

[-- Attachment #1.2: Type: text/html, Size: 3237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Konrad Rzeszutek Wilk]

On Tue, Jun 21, 2011 at 05:39:46AM +0200, Attila Jecs wrote:
> Hi!
> 
> well, i got this when booting to gentoo/x64 xen/4.1 kernel/3.0rc3

Thank you.

That is a benign error. Does it continue booting?
> 
> Jun 21 05:18:02 szerver kernel: Initializing cgroup subsys perf_event
> Jun 21 05:18:02 szerver kernel: tseg: 00cfe00000
> Jun 21 05:18:02 szerver kernel: CPU: Physical Processor ID: 0
> Jun 21 05:18:02 szerver kernel: CPU: Processor Core ID: 0
> Jun 21 05:18:02 szerver kernel: ACPI: Core revision 20110413
> Jun 21 05:18:02 szerver kernel: cpu 0 spinlock event irq 273
> Jun 21 05:18:02 szerver kernel: Performance Events: AMD PMU driver.
> Jun 21 05:18:02 szerver kernel: ------------[ cut here ]------------
> Jun 21 05:18:02 szerver kernel: WARNING: at arch/x86/xen/enlighten.c:714
> 0xffffffff815cd65f()
> Jun 21 05:18:02 szerver kernel: Hardware name: GA-890FXA-UD5
> Jun 21 05:18:02 szerver kernel: Modules linked in:
> Jun 21 05:18:02 szerver kernel: Pid: 1, comm: swapper Not tainted 3.0.0-rc3
> #8
> Jun 21 05:18:02 szerver kernel: Call Trace:
> Jun 21 05:18:02 szerver kernel: [<ffffffff8104e3db>] ? 0xffffffff8104e3db
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd65f>] ? 0xffffffff815cd65f
> Jun 21 05:18:02 szerver kernel: [<ffffffff815cd1cd>] ? 0xffffffff815cd1cd
> Jun 21 05:18:02 szerver kernel: [<ffffffff8100214a>] ? 0xffffffff8100214a
> Jun 21 05:18:02 szerver kernel: [<ffffffff815c4c07>] ? 0xffffffff815c4c07
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d64>] ? 0xffffffff81463d64
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463176>] ? 0xffffffff81463176
> Jun 21 05:18:02 szerver kernel: [<ffffffff814628e1>] ? 0xffffffff814628e1
> Jun 21 05:18:02 szerver kernel: [<ffffffff81463d60>] ? 0xffffffff81463d60
> Jun 21 05:18:02 szerver kernel: ---[ end trace 4eaa2a86a8e2da22 ]---
> Jun 21 05:18:02 szerver kernel: ... version:                0
> Jun 21 05:18:02 szerver kernel: ... bit width:              48
> Jun 21 05:18:02 szerver kernel: ... generic registers:      4
> Jun 21 05:18:02 szerver kernel: ... value mask:             0000ffffffffffff
> Jun 21 05:18:02 szerver kernel: ... max period:             00007fffffffffff
> Jun 21 05:18:02 szerver kernel: ... fixed-purpose events:   0
> Jun 21 05:18:02 szerver kernel: ... event mask:             000000000000000f
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 1
> Jun 21 05:18:02 szerver kernel: cpu 1 spinlock event irq 279
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 2
> Jun 21 05:18:02 szerver kernel: cpu 2 spinlock event irq 285
> Jun 21 05:18:02 szerver kernel: installing Xen timer for CPU 3
> Jun 21 05:18:02 szerver kernel: cpu 3 spinlock event irq 291
> Jun 21 05:18:02 szerver kernel: Brought up 4 CPUs
> Jun 21 05:18:02 szerver kernel: devtmpfs: initialized
> 
> maybe it helps.
> if u need more info, just tell me
> -- 
> Attila Jecs

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

(No subject)

[Bruce Ashfield, Bruce Ashfield]

Tom/Darren/Saul,

Not sure who wants to proxy these into meta-intel for me, 
so I've copied you all. Now that the recipe renames for
linux-yocto in the main repos, meta-intel needs to be updated
as well.

Patch 2 is for meta-yocto with the same change.

These are the referenes that I found (hopefully I didn't 
miss any) and fixed to the new naming convention. 

Note: I can't push to meta-intel-contrib, so I'm just sending
this as a patch.

Cheers,

Bruce

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[@ 2011-06-04 9:31 UTC (permalink / raw)]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c-EMRzualFZlQ@public.gmane.org
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[@ 2011-06-04 9:30 UTC (permalink / raw)]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
04-06-20011
Your Mail-ID has been awarded 750,000.00 GBP From The Coca-Cola Online
Bonanza 2011. For claims send
Name:
Address:
Phone No:
Age: Sex:
Occupation:
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[Swastik Das]

[-- Attachment #1.1: Type: text/plain, Size: 62 bytes --]


http://newprojetinteriors.com/supersurprise.html 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 259 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c-EMRzualFZlQ@public.gmane.org
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c-EMRzualFZlQ@public.gmane.org
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

Re: (no subject)

[Dan Carpenter]

On 4/30/11, Naveen Singh <sningh@atheros.com> wrote:
> --- a/drivers/staging/ath6kl/os/linux/cfg80211.c
> +++ b/drivers/staging/ath6kl/os/linux/cfg80211.c
> @@ -1455,6 +1455,11 @@ ar6k_cfg80211_init(struct device *dev)
>      wdev->wiphy->cipher_suites = cipher_suites;
>      wdev->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
>
> +    /*Support the seprate keys for unicast and multicast packets
> +     *This flag is needed because because nl80211 checks for this
> +     *flag before calling cfg ops for setting the key.*/
> +    wdev->wiphy->flags |= WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS;
> +

No subject.  Comment style wrong.  Please read CodingStyle and resend.

regards,
dan carpenter

Re: (no subject)

[Dan Carpenter]

On 5/1/11, Dan Carpenter <error27@gmail.com> wrote:
> On 4/30/11, Naveen Singh <sningh@atheros.com> wrote:
>> --- a/drivers/staging/ath6kl/os/linux/cfg80211.c
>> +++ b/drivers/staging/ath6kl/os/linux/cfg80211.c
>> @@ -1455,6 +1455,11 @@ ar6k_cfg80211_init(struct device *dev)
>>      wdev->wiphy->cipher_suites = cipher_suites;
>>      wdev->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
>>
>> +    /*Support the seprate keys for unicast and multicast packets
>> +     *This flag is needed because because nl80211 checks for this
>> +     *flag before calling cfg ops for setting the key.*/
>> +    wdev->wiphy->flags |= WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS;
>> +
>
> No subject.  Comment style wrong.  Please read CodingStyle and resend.
>

Also your email address is wrong so my reply bounced.  (The 'n' and 's'
were transposed).

regards,
dan carpenter

[PATCH 0/2] safer reclocking take 2

[Martin Peres]

Hi everyone,

This new version of the previous patchset features some memory reclocking and voltage management improvements.

Memory: Reclock it after all the other engines so as we don't need to reclock it back again if pausing didn't work.
Voltage: Bump the voltage before reclocking or lower it after reclocking. It should increase the stability when downclocking.

If you didn't test the previous pathset, test this one. If the former worked for you, this one will too.

Martin

(no subject)

[Martin Peres]

Sorry, forgot to add nouveau_pms.h

[PATCH 0/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)

[Liping Ke]

From: Liping Ke <liping.ke@intel.com>

Add -t options in bitbake for configuring server type.

Signed-off-by: Liping Ke <liping.ke@intel.com>


Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: lke/server_type
  Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lke/server_type

Thanks,
    Liping Ke <liping.ke@intel.com>
---


Liping Ke (1):
  Make bitbake server type configurable (xmlrpc, none)

 bitbake/bin/bitbake |   22 +++++++++++++++++-----
 1 files changed, 17 insertions(+), 5 deletions(-)

(No subject)

[Liping Ke]

From: Liping Ke <liping.ke@intel.com>

Subject: [PATCH 1/1] Resend:[Image-Creator]Make bitbake server type configurable (xmlrpc, none)

Add -t options in bitbake for configuring server type.

Signed-off-by: Liping Ke <liping.ke@intel.com>
---
 bitbake/bin/bitbake |   22 +++++++++++++++++-----
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/bitbake/bin/bitbake b/bitbake/bin/bitbake
index 6d05289..2c45224 100755
--- a/bitbake/bin/bitbake
+++ b/bitbake/bin/bitbake
@@ -39,8 +39,6 @@ import bb.msg
 from bb import cooker
 from bb import ui
 from bb import server
-from bb.server import none
-#from bb.server import xmlrpc
 
 __version__ = "1.11.0"
 logger = logging.getLogger("BitBake")
@@ -71,7 +69,7 @@ def get_ui(config):
         return getattr(module, interface).main
     except AttributeError:
         sys.exit("FATAL: Invalid user interface '%s' specified.\n"
-                 "Valid interfaces: depexp, goggle, ncurses, knotty [default]." % interface)
+                 "Valid interfaces: depexp, goggle, ncurses, hob, knotty [default]." % interface)
 
 
 # Display bitbake/OE warnings via the BitBake.Warnings logger, ignoring others"""
@@ -161,6 +159,9 @@ Default BBFILES are the .bb files in the current directory.""")
     parser.add_option("-u", "--ui", help = "userinterface to use",
                action = "store", dest = "ui")
 
+    parser.add_option("-t", "--servertype", help = "choose which server to user, none or xmlrpc",
+               action = "store", dest = "servertype")
+
     parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not",
                action = "store_true", dest = "revisions_changed", default = False)
 
@@ -175,8 +176,19 @@ Default BBFILES are the .bb files in the current directory.""")
     loghandler = event.LogHandler()
     logger.addHandler(loghandler)
 
-    #server = bb.server.xmlrpc
-    server = bb.server.none
+    # Server type could be xmlrpc or none currently, if nothing is specified,
+    # default server would be none
+    if configuration.servertype:
+        server_type = configuration.servertype
+    else:
+        server_type = 'none'
+
+    try:
+        module = __import__("bb.server", fromlist = [server_type])
+        server = getattr(module, server_type)
+    except AttributeError:
+        sys.exit("FATAL: Invalid server type '%s' specified.\n"
+                 "Valid interfaces: xmlrpc [default]." % servertype)
 
     # Save a logfile for cooker into the current working directory. When the
     # server is daemonized this logfile will be truncated.
-- 
1.7.0.4

(no subject)

[Mr. Miaoqing Fang]

--
Get Back To Me Now
Greetings,
I'm Mr. Miaoqing Fang, A Chinese from China a top staff with CBD,
I write brief this letter to request your collaboration in a very
lucrative partnership, if in agreement, send me your
(Full Names & Tel Number) to my private email below:


I shall give you more comprehensive info upon your swift reply.
Regards,
Mr. Miaoqing Fang

forcewake v4 (now with spinlock)

[Ben Widawsky]

As the patches say, I don't think adding this spinlock will have too
much of a performance impact (I couldn't notice anything in my limited
testing), because the serializing locks are already held when acquiring
this lock. I suppose it now serializes access between stuct_mutex and
config.lock, but in most cases I don't think that's big.

Perhaps the ugliest change is spin_lock() in debugfs. But as I argue in
the comments, if you can't get the lock there, register reads are also
failing, and hung somewhere else.

Ben

(no subject)

[Ben Widawsky]

GIT: [Intel-gfx] [PATCH 1/3] drm/i915: proper use of forcewake
GIT: [Intel-gfx] [PATCH 2/3] drm/i915: refcounts for forcewake
GIT: [Intel-gfx] [PATCH 3/3] drm/i915: userspace interface to the forcewake refcount

(no subject)

[TONY KINGS]

-- 

Are you in need of getting a loan today.Contact us via mail

at:tonykings_loans@yahoo.com

(no subject)

[TONY KINGS]

-- 

Are you in need of getting a loan today.Contact us via mail

at:tonykings_loans@yahoo.com

(no subject)

[TONY KINGS]

-- 
Are you in need of getting a loan today.Contact us via mail
at:tonykings_loans@yahoo.com

(no subject)

[TONY KINGS]

-- 
Are you in need of getting a loan today.Contact us via mail
at:tonykings_loans@yahoo.com

forcewake junk, RFC, RFT(test)

[Ben Widawsky]

I am requesting 3 things:
1. code review/request for comments
2. testing on SNB
3. performance regression on < SNB

review
------
The first two patches have nothing to do with the user's ability to
interact with registers. Those patches are about enforcing correctness
within our driver for newer generation products. In other words, if
patch 3 doesn't make sense, don't automatically drop 1, and 2.

review patch 1/2
----------------
The first change is straight forward. It attempts to fold the forcewake stuff
into our standard register read and write functions. Some overhead is added as
a result, but I'd guess it is nothing compared to the UC read about to happen,
and so will not be noticeable.

The existing method for doing the forcewake_get and put requires some
synchronization. For the most part it is protected by struct_mutex and life is
good. Adding a WARN to the get()/put() function is there more as documentation
to future developers, and reminders to the current ones.

To provide an interface to allow user space to use forcewake, I've decided to
change the mechanism that get()/put() operate by introducing a reference count.
The reference count itself must be protected by struct mutex (since we need
synchronization between the initial condition and the destructor). Imagine for
instance: Thread A does a get() and is in the middle of waking the GT (ref has
already been incremented), thread B comes in, thinks the GT is awake,
and incorrectly goes about its business. This does allow users of the
interface to only have to hold struct_mutex while doing the get() and
not for every read and write.

review patch 3
--------------
User space interface is mostly what you'd expect, except the in the case
of trying to get lockless access. This code is a bit meh, but to
remind everyone, it is root only debug code.

testing
-------
The assertion that forcewake is currently properly protected for the
most part, may not be true. People interested should run these patches
on SNB systems with their favorite graphics applications and report the
warnings that occur, they will be in the kernel log, ie. dmesg.

performance
-----------
Looking mostly for regressions on older systems. There is a slight
overhead added to all register reads and writes, which I think shouldn't
be noticeable, but who knows.

Thanks, and let the flames begin!
Ben

forcewake junk, part2

[Ben Widawsky]

The request to test, and report the warnings is still desired.

These address all of Chris' comments from IRC (I think). I tried to put
the reasoning in the code comments, as well as commits; but I'll add it
here for completeness.

Simplify the acquisition of the forcewake lock by removing the forced
entry. The motivation behind it is that the kernel offers sufficient
tools to get relevant data before/during/after a hang, and adding a
complex mechanism for userspace is not such a great idea. If a need to
do this comes up, we can always add it back on a situational basis.

Similarly, on releasing of the debugfs file, no more forced entry mechanism.
This does leave a potential for release to hang, but AFAICS if release hangs,
the system is going to need a reboot before i915 becomes usable again because
module unload would also hang.

(no subject)

[Ben Widawsky]

GIT: [Intel-gfx] [PATCH 1/4] drm/i915: proper use of forcewake
GIT: [Intel-gfx] [PATCH 2/4] drm/i915: refcounts for forcewake
GIT: [Intel-gfx] [PATCH 3/4] drm/i915: userspace interface to the forcewake refcount
GIT: [Intel-gfx] [PATCH 4/4] drm/i915: optional fewer warning patch

(no subject)

[Jesse Barnes]

These are some prep patches I'd like to get feedback on.  I've only
compile tested them so far (the actual hw support code this is for was
tested before the split), so testing would be appreciated as well.

Thanks,
Jesse

(no subject)

[Novik, Alex]

[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]

Hi, all.
 How do I activate the battery management in pass-through mode?  XEN 4.1, platform Lenovo.
 Thanks in advance,
 Alex Novik.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Keshav Darak]

[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]

We have implemented hugepage support for guests in following manner

In
 our implementation we added a parameter hugepage_num which is specified
 in the config file of the DomU. It is the number of hugepages that the 
guest is guaranteed to receive whenever the kernel asks for hugepage by 
using its boot time parameter or reserving after booting (eg. Using echo
 XX > /proc/sys/vm/nr_hugepages). During creation of the domain we 
reserve MFN's for these hugepages and store them in the list. The 
listhead of this list is inside the domain structure with name 
"hugepage_list". When the domain is booting, at that time the memory 
seen by the kernel is allocated memory  less the amount required for hugepages. The function 
reserve_hugepage_range is called as a initcall. Before this function the
 xen_extra_mem_start points to this apparent end of the memory. In this 
function we reserve the PFN range for the hugepages which are going to 
be allocated by kernel by incrementing the xen_extra_mem_start. We 
maintain these PFNs as pages in "xen_hugepfn_list" in the kernel. 

Now before the kernel requests for hugepages, it makes a hypercall HYPERVISOR_memory_op  to get count of hugepages allocated to it and accordingly reserves the pfn range.
then whenever kernel requests for hugepages it again make hypercall HYPERVISOR_memory_op to get the preallocated hugepage and according makes the p2m mapping on both sides (xen as well as kernel side)

The approach can be better explained using the presentation attached.

--
Keshav Darak

 




      

[-- Attachment #1.2: Type: text/html, Size: 1742 bytes --]

[-- Attachment #2: xen_patch_210311_0227.patch --]
[-- Type: application/x-download, Size: 18234 bytes --]

[-- Attachment #3: jeremy-kernel.patch --]
[-- Type: application/x-download, Size: 6731 bytes --]

[-- Attachment #4: our_hugepage_approach.ppt --]
[-- Type: application/vnd.ms-powerpoint, Size: 327168 bytes --]

[-- Attachment #5: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(No subject)

[Denis 'GNUtoo' Carikli]

Hi,

Is it possible to move /etc/rcS.d/S98configure before S40networking, 
so usb0 comes up at first boot, or is there some problems that would 
be introduced from such move?

Here's my problem:
on the bug machine,with Angstrom, at first boot usb0 doesn't come up 
in a console-image.
It is very annoying because the only way to get control of the machine 
is trough ssh on usbnet.

At second boot it works fine.

If I move /etc/rcS.d/S98configure before S40networking it 
works fine at first boot.

I will send a patch that changes the order of S40networking  
and S98configure to S40configure and S41networking.

Denis.

(No subject)

[Denis 'GNUtoo' Carikli]

Sorry for the lack of Subject, 

I tried to send a first mail and had an error while sending it.

Then I pasted the content of the saved mail(git-send-email often errors
for me so I saved it as a precaution),forgetting to paste the Subject.

Denis.

(no subject)

[Javier Martin]

This series of patches provides support for audio in Visstrim_M10 boards.

This second version has some fixes in the aic32x4 codec driver as asked by
Mark Brown.

(no subject)

[Ken Ash]

 h

Sent from my iPhone

(no subject)

[Russell Cattelan]

[-- Attachment #1: Type: text/plain, Size: 10 bytes --]

subscribe

[-- Attachment #2: cattelan.vcf --]
[-- Type: text/x-vcard, Size: 181 bytes --]

begin:vcard
fn:Russell Cattelan
n:Cattelan;Russell
email;internet:cattelan-fTMmaJvPcXhBDgjK7y7TUQ@public.gmane.org
tel;cell:612 805 3144
x-mozilla-html:FALSE
version:2.1
end:vcard

[PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Zou Nan hai]

before reading ring register, set force wake bit to prevent GT core
power down to low power state. otherwise we may read stale value.

Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h         |   14 ++++++++++++++
 drivers/gpu/drm/i915/i915_reg.h         |    1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |    3 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   11 +++++++----
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90414ae..53c0239 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1325,4 +1325,18 @@ static inline void i915_write(struct drm_i915_private *dev_priv, u32 reg,
 
 #define PRIMARY_RINGBUFFER_SIZE         (128*1024)
 
+/* on SNB platform,
+   before reading ring registers forcewake bit 
+   must be set to prevent GT core from power down
+*/
+
+static inline u32 i915_safe_read(struct intel_ring_buffer *ring,
+		unsigned int offset)
+{
+	u32 ret;
+	drm_i915_private_t *dev_priv = ring->dev->dev_private;
+	if (IS_GEN6(ring->dev))	 I915_WRITE(FORCEWAKE, 1);
+	ret = I915_READ(offset);
+	return ret;
+}
 #endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 25ed911..4d994d2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3052,4 +3052,5 @@
 #define  EDP_LINK_TRAIN_800MV_0DB_SNB_B		(0x38<<22)
 #define  EDP_LINK_TRAIN_VOL_EMP_MASK_SNB	(0x3f<<22)
 
+#define  FORCEWAKE				0xA18C
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7c1f3ff..2820235 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -572,7 +572,6 @@ err:
 int intel_init_ring_buffer(struct drm_device *dev,
 			   struct intel_ring_buffer *ring)
 {
-	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_i915_gem_object *obj_priv;
 	struct drm_gem_object *obj;
 	int ret;
@@ -691,8 +690,6 @@ int intel_wait_ring_buffer(struct drm_device *dev,
 			   struct intel_ring_buffer *ring, int n)
 {
 	unsigned long end;
-	drm_i915_private_t *dev_priv = dev->dev_private;
-
 	trace_i915_ring_wait_begin (dev);
 	end = jiffies + 3 * HZ;
 	do {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3126c26..cde1cdd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -7,13 +7,16 @@ struct  intel_hw_status_page {
 	struct		drm_gem_object *obj;
 };
 
-#define I915_READ_TAIL(ring) I915_READ(RING_TAIL(ring->mmio_base))
+#define I915_READ_TAIL(ring) i915_safe_read(ring, RING_TAIL(ring->mmio_base))
 #define I915_WRITE_TAIL(ring, val) I915_WRITE(RING_TAIL(ring->mmio_base), val)
-#define I915_READ_START(ring) I915_READ(RING_START(ring->mmio_base))
+
+#define I915_READ_START(ring) i915_safe_read(ring, RING_START(ring->mmio_base))
 #define I915_WRITE_START(ring, val) I915_WRITE(RING_START(ring->mmio_base), val)
-#define I915_READ_HEAD(ring) I915_READ(RING_HEAD(ring->mmio_base))
+
+#define I915_READ_HEAD(ring)  i915_safe_read(ring, RING_HEAD(ring->mmio_base))
 #define I915_WRITE_HEAD(ring, val) I915_WRITE(RING_HEAD(ring->mmio_base), val)
-#define I915_READ_CTL(ring) I915_READ(RING_CTL(ring->mmio_base))
+
+#define I915_READ_CTL(ring) i915_safe_read(ring, RING_CTL(ring->mmio_base))
 #define I915_WRITE_CTL(ring, val) I915_WRITE(RING_CTL(ring->mmio_base), val)
 
 struct drm_i915_gem_execbuffer2;
-- 
1.7.1

Re: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Zou, Nanhai]

>>-----Original Message-----
>>From: Zou, Nanhai
>>Sent: 2010年11月9日 17:18
>>To: intel-gfx@lists.freedesktop.org; Chris Wilson
>>Cc: Zou, Nanhai
>>Subject: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring
>>register
>>
>>before reading ring register, set force wake bit to prevent GT core
>>power down to low power state. otherwise we may read stale value.
>>
>>Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
>>---
>> drivers/gpu/drm/i915/i915_drv.h         |   14 ++++++++++++++
>> drivers/gpu/drm/i915/i915_reg.h         |    1 +
>> drivers/gpu/drm/i915/intel_ringbuffer.c |    3 ---
>> drivers/gpu/drm/i915/intel_ringbuffer.h |   11 +++++++----
>> 4 files changed, 22 insertions(+), 7 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>b/drivers/gpu/drm/i915/i915_drv.h
>>index 90414ae..53c0239 100644
>>--- a/drivers/gpu/drm/i915/i915_drv.h
>>+++ b/drivers/gpu/drm/i915/i915_drv.h
>>@@ -1325,4 +1325,18 @@ static inline void i915_write(struct drm_i915_private
>>*dev_priv, u32 reg,
>>
>> #define PRIMARY_RINGBUFFER_SIZE         (128*1024)
>>
>>+/* on SNB platform,
>>+   before reading ring registers forcewake bit
>>+   must be set to prevent GT core from power down
>>+*/
>>+
>>+static inline u32 i915_safe_read(struct intel_ring_buffer *ring,
>>+		unsigned int offset)
>>+{
>>+	u32 ret;
>>+	drm_i915_private_t *dev_priv = ring->dev->dev_private;
>>+	if (IS_GEN6(ring->dev))	 I915_WRITE(FORCEWAKE, 1);
>>+	ret = I915_READ(offset);
>>+	return ret;
>>+}
>> #endif
>>diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>b/drivers/gpu/drm/i915/i915_reg.h
>>index 25ed911..4d994d2 100644
>>--- a/drivers/gpu/drm/i915/i915_reg.h
>>+++ b/drivers/gpu/drm/i915/i915_reg.h
>>@@ -3052,4 +3052,5 @@
>> #define  EDP_LINK_TRAIN_800MV_0DB_SNB_B		(0x38<<22)
>> #define  EDP_LINK_TRAIN_VOL_EMP_MASK_SNB	(0x3f<<22)
>>
>>+#define  FORCEWAKE				0xA18C
>> #endif /* _I915_REG_H_ */
>>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>>b/drivers/gpu/drm/i915/intel_ringbuffer.c
>>index 7c1f3ff..2820235 100644
>>--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>>@@ -572,7 +572,6 @@ err:
>> int intel_init_ring_buffer(struct drm_device *dev,
>> 			   struct intel_ring_buffer *ring)
>> {
>>-	struct drm_i915_private *dev_priv = dev->dev_private;
>> 	struct drm_i915_gem_object *obj_priv;
>> 	struct drm_gem_object *obj;
>> 	int ret;
>>@@ -691,8 +690,6 @@ int intel_wait_ring_buffer(struct drm_device *dev,
>> 			   struct intel_ring_buffer *ring, int n)
>> {
>> 	unsigned long end;
>>-	drm_i915_private_t *dev_priv = dev->dev_private;
>>-
>> 	trace_i915_ring_wait_begin (dev);
>> 	end = jiffies + 3 * HZ;
>> 	do {
>>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
>>b/drivers/gpu/drm/i915/intel_ringbuffer.h
>>index 3126c26..cde1cdd 100644
>>--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
>>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
>>@@ -7,13 +7,16 @@ struct  intel_hw_status_page {
>> 	struct		drm_gem_object *obj;
>> };
>>
>>-#define I915_READ_TAIL(ring) I915_READ(RING_TAIL(ring->mmio_base))
>>+#define I915_READ_TAIL(ring) i915_safe_read(ring,
>>RING_TAIL(ring->mmio_base))
>> #define I915_WRITE_TAIL(ring, val) I915_WRITE(RING_TAIL(ring->mmio_base),
>>val)
>>-#define I915_READ_START(ring) I915_READ(RING_START(ring->mmio_base))
>>+
>>+#define I915_READ_START(ring) i915_safe_read(ring,
>>RING_START(ring->mmio_base))
>> #define I915_WRITE_START(ring, val) I915_WRITE(RING_START(ring->mmio_base),
>>val)
>>-#define I915_READ_HEAD(ring) I915_READ(RING_HEAD(ring->mmio_base))
>>+
>>+#define I915_READ_HEAD(ring)  i915_safe_read(ring,
>>RING_HEAD(ring->mmio_base))
>> #define I915_WRITE_HEAD(ring, val) I915_WRITE(RING_HEAD(ring->mmio_base),
>>val)
>>-#define I915_READ_CTL(ring) I915_READ(RING_CTL(ring->mmio_base))
>>+
>>+#define I915_READ_CTL(ring) i915_safe_read(ring,
>>RING_CTL(ring->mmio_base))
>> #define I915_WRITE_CTL(ring, val) I915_WRITE(RING_CTL(ring->mmio_base),
>>val)
>>
>> struct drm_i915_gem_execbuffer2;
>>--
>>1.7.1

I have tested this patch with the read ring head from status page workaround patch reverted.
Seems it works on my SNB box.

Thanks
Zou Nanhai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Chris Wilson]

On Tue, 9 Nov 2010 17:17:07 +0800, "Zou, Nanhai" <nanhai.zou@intel.com> wrote:
 
> I have tested this patch with the read ring head from status page workaround patch reverted.
> Seems it works on my SNB box.

I needed to add a udelay(100) to i915_safe_read for my rev 8. Can you
check if there is a recommended delay for FORCEWAKE?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Zou, Nanhai]

>>-----Original Message-----
>>From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
>>Sent: 2010年11月9日 18:50
>>To: Zou, Nanhai; intel-gfx@lists.freedesktop.org; Zhao, Jian J
>>Subject: RE: [PATCH] drm/i915/ringbuffer: set force wake bit before reading
>>ring register
>>
>>On Tue, 9 Nov 2010 17:17:07 +0800, "Zou, Nanhai" <nanhai.zou@intel.com> wrote:
>>
>>> I have tested this patch with the read ring head from status page workaround
>>patch reverted.
>>> Seems it works on my SNB box.
>>
>>I needed to add a udelay(100) to i915_safe_read for my rev 8. Can you
>>check if there is a recommended delay for FORCEWAKE?
>>-Chris
>>
Dose a post read to FORCEWAKE help?

Thanks
Zou Nanhai

>>--
>>Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Chris Wilson]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Wed, 10 Nov 2010 08:36:20 +0800, "Zou, Nanhai" <nanhai.zou@intel.com> wrote:
> >>-----Original Message-----
> >>From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> >>Sent: 2010年11月9日 18:50
> >>To: Zou, Nanhai; intel-gfx@lists.freedesktop.org; Zhao, Jian J
> >>Subject: RE: [PATCH] drm/i915/ringbuffer: set force wake bit before reading
> >>ring register
> >>
> >>On Tue, 9 Nov 2010 17:17:07 +0800, "Zou, Nanhai" <nanhai.zou@intel.com> wrote:
> >>
> >>> I have tested this patch with the read ring head from status page workaround
> >>patch reverted.
> >>> Seems it works on my SNB box.
> >>
> >>I needed to add a udelay(100) to i915_safe_read for my rev 8. Can you
> >>check if there is a recommended delay for FORCEWAKE?
> >>-Chris
> >>
> Dose a post read to FORCEWAKE help?

No, tried a POSTING_READ(FORCEWAKE) first and it wasn't until I added the
udelay() between the READ(FORCEWAKE) and the READ(reg) that it returned
the correct results in a single call.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/ringbuffer: set force wake bit before reading ring register

[Jesse Barnes]

On Wed, 10 Nov 2010 07:54:12 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Wed, 10 Nov 2010 08:36:20 +0800, "Zou, Nanhai"
> <nanhai.zou@intel.com> wrote:
> > >>-----Original Message-----
> > >>From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> > >>Sent: 2010年11月9日 18:50
> > >>To: Zou, Nanhai; intel-gfx@lists.freedesktop.org; Zhao, Jian J
> > >>Subject: RE: [PATCH] drm/i915/ringbuffer: set force wake bit
> > >>before reading ring register
> > >>
> > >>On Tue, 9 Nov 2010 17:17:07 +0800, "Zou, Nanhai"
> > >><nanhai.zou@intel.com> wrote:
> > >>
> > >>> I have tested this patch with the read ring head from status
> > >>> page workaround
> > >>patch reverted.
> > >>> Seems it works on my SNB box.
> > >>
> > >>I needed to add a udelay(100) to i915_safe_read for my rev 8. Can
> > >>you check if there is a recommended delay for FORCEWAKE?
> > >>-Chris
> > >>
> > Dose a post read to FORCEWAKE help?
> 
> No, tried a POSTING_READ(FORCEWAKE) first and it wasn't until I added
> the udelay() between the READ(FORCEWAKE) and the READ(reg) that it
> returned the correct results in a single call.

I think these regs will be affected by the ucode on the GPU; we may
need specific delays after some operations.  Have you tried asking the
hw guys what the best practices are here?

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

(no subject)

[Thantry, Hariharan L]

Hi folks,

I am a bit new to graphics, but had a few questions that I was hoping that someone could answer for me. I hope this is the right forum to ask these questions.
My interest is in seeing whether I can use the Intel integrated graphics part for non-graphics (GPGPU) work, while driving the display through another discrete card.
I have an Ironlake system (core setup with base Debian (no X-related packages), a basic PCI-E graphics card (NVIDIA NV37GL) and a 2.6.36 kernel with the following relevant config entries. 


CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_TTM=m
CONFIG_DRM_R128=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y

I have libdrm & libva installed, and was hoping to use libdrm APIs to do some basic operations on the integrated graphics.

I can insmod the DRM & the DRM_KMS_HELPER module fine, but when trying to insert the I915 driver, I get a "no such device error", even though the module object exists.

lspci doesn't seem to return the Intel integrated graphics PCI device either.


00:00.0 Host bridge: Intel Corporation Auburndale/Havendale DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation Auburndale/Havendale PCI Express x16 Root Port (rev 02)
00:16.0 Communication controller: Intel Corporation Ibex Peak HECI Controller (rev 06)
00:16.2 IDE interface: Intel Corporation Ibex Peak PT IDER Controller (rev 06)
00:16.3 Serial controller: Intel Corporation Ibex Peak KT Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation Device 10f0 (rev 06)
00:1a.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation Ibex Peak High Definition Audio (rev 06)
00:1d.0 USB Controller: Intel Corporation Ibex Peak USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation Ibex Peak LPC Interface Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation Ibex Peak 6 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation Ibex Peak SMBus Controller (rev 06)
01:00.0 VGA compatible controller: nVidia Corporation NV37GL [Quadro PCI-E Series] (rev a2)
02:02.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)

First off, is there a way for the Intel integrated graphics to appear in the list of PCI devices when it's not being used for driving the display?
Secondly, can I simply use the libdrm APIs to directly perform operations on the Intel integrated part? Does there exist any documentation describing the DRM APIs?
Finally, can I use the DRM APIs for using the GPU "media pipe" (architecturally different from the 3D graphics pipe)?

Thanks,
Hari

(no subject)

[RODNEY BINGHAM]

[-- Attachment #1.1: Type: text/plain, Size: 362 bytes --]


I have noticed when I install Google earth, since nouveau got involved in Ubuntu, the embedded pictures have not opened.???? Two different machines both Nvidia. From what I have found on the Internet, there seems to be a few of us out there.   Please help... I am trying to be a loyal Ubuntoian. Both machines do have windows also... to use.  Rod
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 576 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

(no subject)

[Mike Viau]

I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/


http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score


I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?


Thanks.



-Mike Viau


 		 	   		  

Re: (no subject)

[Stefano Stabellini]

On Thu, 7 Oct 2010, Mike Viau wrote:
> 
> I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> 
> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> 
> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> 

We intend to publish debian and centos packages for the xen hypervisor
and tools, however the project is stalling a bit recently.
Hopefully those packages will be published in the next few weeks.

Re: (no subject)

[George Shuklin]

Please note this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711

This behavior confirmed in lenny and squeeze. Kernel is very unstable
(compare to centos/suse) and cause OOM killer without any rational
reason.


В Чтв, 07/10/2010 в 11:43 +0100, Stefano Stabellini пишет:
> On Thu, 7 Oct 2010, Mike Viau wrote:
> > 
> > I have search the archives for reference to Ian Campbell's Debian binaries found at: http://xenbits.xen.org/people/ianc/
> > 
> > http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!&idxname=xen-devel&max=20&result=normal&sort=score
> > 
> > I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way be added to Debian's apt sources file?
> > 
> 
> We intend to publish debian and centos packages for the xen hypervisor
> and tools, however the project is stalling a bit recently.
> Hopefully those packages will be published in the next few weeks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: (no subject)

[Ian Campbell]

On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> Please note this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> 
> This behavior confirmed in lenny and squeeze. Kernel is very unstable
> (compare to centos/suse) and cause OOM killer without any rational
> reason.

I wasn't aware that this issue was present on Squeeze as well as Lenny,
there is no mention of that in the bug.

The two kernels have practically nothing in common wrt the Xen port
(Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
are seeing something similar under Squeeze as well please file a
separate bug report.

(Note that only the OS in the specific VM which is exhibiting the
problem is relevant, so even if you are seeing the issue with a Lenny VM
hosted on a Squeeze dom0 that does not imply the bug is present in
Squeeze).

I'm afraid that at this point I do not have cycles to spend on the Lenny
issue. Unfortunately my best recommendation is not to balloon such
systems too aggressively or to use a more recent kernel (e.g. a backport
of the Squeeze kernel).

Ian.

-- 
Ian Campbell
Current Noise: Twisted Sister - Tear It Loose

Other restrictions may apply.

Re: (no subject)

[George Shuklin]

В Чтв, 07/10/2010 в 15:21 +0100, Ian Campbell пишет:
> On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> > Please note this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> > 
> > This behavior confirmed in lenny and squeeze. Kernel is very unstable
> > (compare to centos/suse) and cause OOM killer without any rational
> > reason.
> 
> I wasn't aware that this issue was present on Squeeze as well as Lenny,
> there is no mention of that in the bug.
> 
> The two kernels have practically nothing in common wrt the Xen port
> (Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
> are seeing something similar under Squeeze as well please file a
> separate bug report.

OK, I'll recheck bug in squeeze and report it separately.

Main problem for this bug is very high value of free memory when OOM
killer starts. In my tests it appear when about 300MiB was free. And it
kill not most 'badness' process, but runs repeatedly for few (or even
all) process. 

But, again, I'll recheck it in clean environment with reproducible
behavior and submit it.

Re: (no subject)

[Ian Campbell]

On Thu, 2010-10-07 at 03:46 +0100, Mike Viau wrote:
> I have search the archives for reference to Ian Campbell's Debian
> binaries found at: http://xenbits.xen.org/people/ianc/

> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%
> 2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!
> &idxname=xen-devel&max=20&result=normal&sort=score

They were posted on my personal website
http://www.hellion.org.uk/debian/test/
and referred to by
http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01912.html
but I moved them to xen.org and just left a pointer on my website, I
didn't bother to announce this.

> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or
> http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way
> be added to Debian's apt sources file?

I'm afraid the necessary meta data is not present to allow them to be
used as an apt source so they are download+dpkg only.

Originally they were intended to simply verify that the issues people
were seeing related to changesets which had been excluded from the
Debian kernel.

I haven't decided if these are something I necessarily want to maintain
for the lifetime of Squeeze. For the moment I build them for my own
personal use and so I publish them, since I might as well do so, but
they are not a formal xen.org service or anything like that.

For something provided by xen.org I think we would more likely want to
track the latest xen.git#xen/stable-2.6.x.y branch rather than the
Debian packages.

Ian.

(no subject)

[Mrs. Habiba Miller]

-- 
Good day to you,

my name is Mrs. Habiba Miller, I saw your e-mail in a quest book, so i
decided to contact bacuase i want to discuss a vary 
important transaction which i have to carry out before it get too late due
to my health condition. please write back.
My e-mail is : miller.mrshabiba@gmail.com 

Mrs. Habiba Miller

[PATCH 00/25] treewide-next: Use static const char arrays

[Joe Perches]

Using static const char foo[] = "bar" can save some
code and text space, so change the places where it's possible.

Also change the places that use
	char foo[] = "barX";
	...
	foo[3] = value + '0';
where X is typically changed
	char foo[sizeof("barX")];
	...
	sprintf(foo, "bar%c", value + '0');

Joe Perches (25):
  arch/mips: Use static const char arrays
  arch/powerpc: Use static const char arrays
  drivers/acpi: Use static const char arrays
  drivers/char: Use static const char arrays
  drivers/i2c: Use static const char arrays
  drivers/isdn: Use static const char arrays
  drivers/media: Use static const char arrays
  drivers/net/atl1c: Use static const char arrays
  drivers/net/atl1e: Use static const char arrays
  drivers/net/(intel): Use static const char arrays
  drivers/net/netxen: Use static const char arrays
  drivers/net/qlcnic: Use static const char arrays
  drivers/net/spider_net.c: Use static const char arrays
  drivers/net/vnxnet3: Use static const char arrays
  drivers/net/wireless/ipw2x00: Use static const char arrays
  drivers/s390/char: Use static const char arrays
  drivers/scsi: Use static const char arrays
  drivers/serial/suncore.c: Use static const char arrays
  drivers/staging: Use static const char arrays
  drivers/usb: Use static const char arrays
  drivers/video: Use static const char arrays
  net/dsa: Use static const char arrays
  net/sunrpc: Use static const char arrays
  sound: Use static const char arrays
  tools/perf/util: Use static const char arrays

 arch/mips/pnx8550/common/reset.c                   |    4 ++--
 arch/powerpc/boot/addnote.c                        |    4 ++--
 arch/powerpc/boot/cuboot-c2k.c                     |    4 ++--
 arch/powerpc/kernel/irq.c                          |    2 +-
 drivers/acpi/sleep.c                               |    4 ++--
 drivers/char/hvc_vio.c                             |    2 +-
 drivers/i2c/busses/i2c-stu300.c                    |    4 ++--
 drivers/isdn/hysdn/hycapi.c                        |    2 +-
 drivers/isdn/mISDN/dsp_cmx.c                       |    2 +-
 drivers/media/video/zoran/zoran_device.c           |    5 ++---
 drivers/net/atl1c/atl1c.h                          |    4 ++--
 drivers/net/atl1c/atl1c_main.c                     |    4 ++--
 drivers/net/atl1e/atl1e.h                          |    4 ++--
 drivers/net/atl1e/atl1e_main.c                     |    4 ++--
 drivers/net/e1000/e1000.h                          |    2 +-
 drivers/net/e1000/e1000_main.c                     |    4 ++--
 drivers/net/e1000e/e1000.h                         |    2 +-
 drivers/net/e1000e/netdev.c                        |    2 +-
 drivers/net/igb/igb.h                              |    4 ++--
 drivers/net/igb/igb_main.c                         |    4 ++--
 drivers/net/igbvf/igbvf.h                          |    2 +-
 drivers/net/igbvf/netdev.c                         |    2 +-
 drivers/net/ixgb/ixgb.h                            |    2 +-
 drivers/net/ixgb/ixgb_main.c                       |    2 +-
 drivers/net/ixgbe/ixgbe.h                          |    2 +-
 drivers/net/ixgbe/ixgbe_main.c                     |    4 ++--
 drivers/net/ixgbevf/ixgbevf.h                      |    2 +-
 drivers/net/ixgbevf/ixgbevf_main.c                 |    2 +-
 drivers/net/netxen/netxen_nic.h                    |    2 +-
 drivers/net/netxen/netxen_nic_main.c               |    2 +-
 drivers/net/qlcnic/qlcnic.h                        |    2 +-
 drivers/net/qlcnic/qlcnic_main.c                   |    2 +-
 drivers/net/spider_net.c                           |    2 +-
 drivers/net/vmxnet3/vmxnet3_drv.c                  |    2 +-
 drivers/net/vmxnet3/vmxnet3_int.h                  |    2 +-
 drivers/net/wireless/ipw2x00/ipw2100.c             |    2 +-
 drivers/net/wireless/ipw2x00/ipw2200.c             |    2 +-
 drivers/net/wireless/ipw2x00/libipw_module.c       |    2 +-
 drivers/s390/char/vmlogrdr.c                       |    4 ++--
 drivers/scsi/bnx2i/bnx2i_hwi.c                     |    6 +++---
 drivers/scsi/lpfc/lpfc_init.c                      |    2 +-
 drivers/scsi/megaraid/megaraid_mbox.c              |    6 +++---
 drivers/serial/suncore.c                           |    4 ++--
 drivers/staging/brcm80211/util/bcmutils.c          |    2 +-
 drivers/staging/comedi/drivers/comedi_bond.c       |    2 +-
 drivers/staging/cxt1e1/ossiRelease.c               |    2 +-
 drivers/staging/go7007/go7007-driver.c             |    2 +-
 drivers/staging/msm/mdp.c                          |    2 +-
 .../staging/rtl8192e/ieee80211/ieee80211_module.c  |    2 +-
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  |    2 +-
 drivers/staging/tidspbridge/rmgr/dbdcd.c           |    6 +++---
 drivers/usb/atm/ueagle-atm.c                       |   14 +++++---------
 drivers/usb/otg/langwell_otg.c                     |    2 +-
 drivers/video/sh_mipi_dsi.c                        |    4 ++--
 drivers/video/sis/sis_main.c                       |   10 +++++-----
 drivers/video/via/viafbdev.c                       |    2 +-
 net/dsa/dsa.c                                      |    2 +-
 net/dsa/dsa_priv.h                                 |    2 +-
 net/sunrpc/auth_gss/gss_krb5_mech.c                |    2 +-
 sound/core/misc.c                                  |    5 ++++-
 tools/perf/util/ui/setup.c                         |    3 ++-
 tools/perf/util/ui/util.c                          |    3 ++-
 62 files changed, 98 insertions(+), 98 deletions(-)

-- 
1.7.3.rc1

(no subject)

[David Howells]

Joe Perches <joe@perches.com> wrote:

> Using static const char foo[] = "bar" can save some
> code and text space, so change the places where it's possible.

That's reasonable.

> Also change the places that use
> 	char foo[] = "barX";
> 	...
> 	foo[3] = value + '0';
> where X is typically changed
> 	char foo[sizeof("barX")];
> 	...
> 	sprintf(foo, "bar%c", value + '0');

You haven't said what this gains.  I can see what it may cost, though
(depending on how gcc loads foo[]).

David

(no subject)

[David Howells]

Joe Perches <joe@perches.com> wrote:

> Using static const char foo[] = "bar" can save some
> code and text space, so change the places where it's possible.

That's reasonable.

> Also change the places that use
> 	char foo[] = "barX";
> 	...
> 	foo[3] = value + '0';
> where X is typically changed
> 	char foo[sizeof("barX")];
> 	...
> 	sprintf(foo, "bar%c", value + '0');

You haven't said what this gains.  I can see what it may cost, though
(depending on how gcc loads foo[]).

David

(no subject)

[asim khan]

Hi,
 Iam using alsa lib version 1.0.22..and Iam running an alsa capture
application.
 if Iam running this standalone application on my arm11 target ..it runs
fine
but when iam runnig this with my complete BD player integrated application
it gives an error
ALSA lib pcm.c:2175 snd_pcm_open_conf) symbol _snd_pcm_plug_open is not
defined inside [builtin]
cannot open audio device plughw:0,0 (No such device or address).

I googled Which explained the errors meant I didn't have the Alsa plugins
set via ALSA_PCM_PLUGINS in make.conf

I have enabled  --with-pcm-plugins  option in my configure script which will
select all pcm-plugins
#!/bin/sh
./configure CC=arm_v7_vfp_le-gcc --target=arm-linux --host=i386-linux
--build=$BUILD --enable-static  --enable-pcm --with-pcm-plugins
--disable-debug --disable-python --prefix=/mtd_rwarea

I have checked using pcm plugins the created library(.so,.a) size is
reduced...
                              but still Iam getting above same error *ALSA
lib pcm.c:2175 snd_pcm_open_conf) symbol _snd_pcm_plug_open is not defined
inside [builtin]*
**
Please let me know is there any other thing i can check to solve this
problem

---Thanks
Asim
*

*

(no subject)

[lode leroy]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]


I tried compiling grub from bzr on cygwin.

grub-mkimage failed with the following error:

~/grub/build/grub-core $ ../grub-mkimage -v -O i386-pc -d . -o core.img biosdisk part_msdos fat ntfs
../grub-mkimage: info: getting the size of ./biosdisk.mod.
../grub-mkimage: info: getting the size of ./part_msdos.mod.
../grub-mkimage: info: getting the size of ./fat.mod.
../grub-mkimage: info: getting the size of ./fshelp.mod.
../grub-mkimage: info: getting the size of ./ntfs.mod.
../grub-mkimage: info: the total module size is 0x6280.
../grub-mkimage: info: getting the size of ./kernel.img.
../grub-mkimage: info: reading ./kernel.img.
../grub-mkimage: info: getting the size of ./kernel.img.
../grub-mkimage: error: invalid ELF header.

I found that the problem can be solved by replacing the following line in the Makefile

strip -v -R .rel.dyn -R .reginfo -R .note -R .comment  -o kernel.img kernel.exec.exe

by

strip -Felf32-i386 -v -R .rel.dyn -R .reginfo -R .note -R .comment  -o kernel.img kernel.exec.exe

-- lode
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1319 bytes --]

Re: (no subject)

[BVK Chaitanya]

Are you sure your build was fine?  What is your bzr revision?  It
worked fine for me with below output:


bvk@dbook:~/Work/grub2/m/b/grub-core$ ../grub-mkimage -v -O i386-pc -d
. -o core.img biosdisk part_msdos fat ntfs
../grub-mkimage: info: getting the size of ./biosdisk.mod.
../grub-mkimage: info: getting the size of ./part_msdos.mod.
../grub-mkimage: info: getting the size of ./fat.mod.
../grub-mkimage: info: getting the size of ./fshelp.mod.
../grub-mkimage: info: getting the size of ./ntfs.mod.
../grub-mkimage: info: the total module size is 0x6378.
../grub-mkimage: info: getting the size of ./kernel.img.
../grub-mkimage: info: reading ./kernel.img.
../grub-mkimage: info: getting the size of ./kernel.img.
../grub-mkimage: info: locating the section .text at 0x0.
../grub-mkimage: info: locating the section .rodata at 0x546c.
../grub-mkimage: info: locating the section .data at 0x630c.
../grub-mkimage: info: locating the section .bss at 0x6888.
../grub-mkimage: info: getting the size of ./biosdisk.mod.
../grub-mkimage: info: reading ./biosdisk.mod.
../grub-mkimage: info: getting the size of ./biosdisk.mod.
../grub-mkimage: info: getting the size of ./part_msdos.mod.
../grub-mkimage: info: reading ./part_msdos.mod.
../grub-mkimage: info: getting the size of ./part_msdos.mod.
../grub-mkimage: info: getting the size of ./fat.mod.
../grub-mkimage: info: reading ./fat.mod.
../grub-mkimage: info: getting the size of ./fat.mod.
../grub-mkimage: info: getting the size of ./fshelp.mod.
../grub-mkimage: info: reading ./fshelp.mod.
../grub-mkimage: info: getting the size of ./fshelp.mod.
../grub-mkimage: info: getting the size of ./ntfs.mod.
../grub-mkimage: info: reading ./ntfs.mod.
../grub-mkimage: info: getting the size of ./ntfs.mod.
../grub-mkimage: info: kernel_img=0x9d13138, kernel_size=0x6888.
../grub-mkimage: info: the core size is 0x6c21.
../grub-mkimage: info: getting the size of ./diskboot.img.
../grub-mkimage: info: reading ./diskboot.img.
../grub-mkimage: info: getting the size of ./diskboot.img.
../grub-mkimage: info: writing 0x200 bytes.
../grub-mkimage: info: writing 0x6c21 bytes.
bvk@dbook:~/Work/grub2/m/b/grub-core$ echo $?
0
bvk@dbook:~/Work/grub2/m/b/grub-core$



-- 
bvk.chaitanya

Re: (no subject)

[BVK Chaitanya]

Sorry, I didn't notice you mentioned cygwin there, my bad   :(




-- 
bvk.chaitanya

Runtime power management during system resume

[Raj Kumar]

 
Hi Alan,
 
I have implemented the run time power management in my drivers. I have one
issue regarding System resume.
 
When the system sleep is triggered as it is mentioned that Power management
core will increment the power_usage counter during prepare and decrements when complete
is called.
 
Now I have few questions:
 
1) When the system resume is done, it does not increase the power_usage counter.
 right?
 
So Does then the driver need to update the power_usage counter with run time power management
core and again set it to active means RPM_ACTIVE?
 
2) Suppose device is active, means its power_usage counter is already one, Now during system
sleep, does the driver first suspend it with run time power management core and then continue
System suspend?
 
3) Because I have seen the code of power management core and I did not see the that during
system suspend, run time power management status is updated means RPM_SUSPENDED.
right?
 
What do you think?
 
Regards
Raj
 
  		 	   		  

Re: Runtime power management during system resume

[Alan Stern]

On Tue, 24 Aug 2010, Raj Kumar wrote:

> Hi Alan,
>  
> I have implemented the run time power management in my drivers. I have one
> issue regarding System resume.
>  
> When the system sleep is triggered as it is mentioned that Power management
> core will increment the power_usage counter during prepare and decrements when complete
> is called.
>  
> Now I have few questions:
>  
> 1) When the system resume is done, it does not increase the power_usage counter.
>  right?

That's right.

> So Does then the driver need to update the power_usage counter with run time power management
> core and again set it to active means RPM_ACTIVE?

Read section 6 of Documentation/power/runtime_pm.h.  It explains this.

> 2) Suppose device is active, means its power_usage counter is already one, Now during system
> sleep, does the driver first suspend it with run time power management core and then continue
> System suspend?

No.

> 3) Because I have seen the code of power management core and I did not see the that during
> system suspend, run time power management status is updated means RPM_SUSPENDED.
> right?

I don't understand your question.

Alan Stern

Re: Runtime power management during system resume

[Raj Kumar]

 
Hi,
 
My question is:
 
1) When the system suspends, it invokes pm_runtime_put_sync when complete
callback is called which will again trigger to put device idle
 
means in runtime power management core, the device status is set to RPM_SUSPENDED.
right?
 
2) As you also said that during system resume, it does not increment the power_usage
counter,
 
that is ok, driver will increase the power_usage counter...
 
But will driver also set the state to RPM_ACTIVE means pm_runtime_set_active
 
right?
 
 
3) During hibernation, if the driver is registered using platform_driver_register...
 
When the system hibernates, will power management core call suspend, resume?
 
right?
 
Regards,
Raj
 
 
 
 
 
 


----------------------------------------
> Date: Tue, 24 Aug 2010 10:30:25 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-kernel@vger.kernel.org
> Subject: Re: Runtime power management during system resume
>
> On Tue, 24 Aug 2010, Raj Kumar wrote:
>
>> Hi Alan,
>>
>> I have implemented the run time power management in my drivers. I have one
>> issue regarding System resume.
>>
>> When the system sleep is triggered as it is mentioned that Power management
>> core will increment the power_usage counter during prepare and decrements when complete
>> is called.
>>
>> Now I have few questions:
>>
>> 1) When the system resume is done, it does not increase the power_usage counter.
>> right?
>
> That's right.
>
>> So Does then the driver need to update the power_usage counter with run time power management
>> core and again set it to active means RPM_ACTIVE?
>
> Read section 6 of Documentation/power/runtime_pm.h. It explains this.
>
>> 2) Suppose device is active, means its power_usage counter is already one, Now during system
>> sleep, does the driver first suspend it with run time power management core and then continue
>> System suspend?
>
> No.
>
>> 3) Because I have seen the code of power management core and I did not see the that during
>> system suspend, run time power management status is updated means RPM_SUSPENDED.
>> right?
>
> I don't understand your question.
>
> Alan Stern
> 		 	   		  

Re: Runtime power management during system resume

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 2593 bytes --]



Hi Alan,

Thanks for quick replies. As you said

 


> >> 2) Suppose device is active, means its power_usage counter is already one, Now during system
> >> sleep, does the driver first suspend it with run time power management core and then continue
> >> System suspend?
> >
{ALAN}  No.

 

 

But since during system suspend power_usage counter is incremented by 1 But if the device is active

means its state is RPM_ACTIVE, its power_usage counter is 1 in run time power management core.

 

when the system suspend happens, it will also increment the power_usage_counter by 1 during dpm_prepare

 

Now   the power_usage_counter is 2.

 

So when dpm_complete is invoked, it will decrement the power_usage_counter by 1 during dpm_complete.

 

So now when the drivers gets system suspend, its power_usage counter is still 1.

 

So what in this scenario, does the device decrements the power_usage counter itself?

 

Thanks

Raj









>
>
>
> ----------------------------------------
> > Date: Tue, 24 Aug 2010 10:30:25 -0400
> > From: stern@rowland.harvard.edu
> > To: rajkumar278@hotmail.com
> > CC: linux-kernel@vger.kernel.org
> > Subject: Re: Runtime power management during system resume
> >
> > On Tue, 24 Aug 2010, Raj Kumar wrote:
> >
> >> Hi Alan,
> >>
> >> I have implemented the run time power management in my drivers. I have one
> >> issue regarding System resume.
> >>
> >> When the system sleep is triggered as it is mentioned that Power management
> >> core will increment the power_usage counter during prepare and decrements when complete
> >> is called.
> >>
> >> Now I have few questions:
> >>
> >> 1) When the system resume is done, it does not increase the power_usage counter.
> >> right?
> >
> > That's right.
> >
> >> So Does then the driver need to update the power_usage counter with run time power management
> >> core and again set it to active means RPM_ACTIVE?
> >
> > Read section 6 of Documentation/power/runtime_pm.h. It explains this.
> >
> >> 2) Suppose device is active, means its power_usage counter is already one, Now during system
> >> sleep, does the driver first suspend it with run time power management core and then continue
> >> System suspend?
> >
> > No.
> >
> >> 3) Because I have seen the code of power management core and I did not see the that during
> >> system suspend, run time power management status is updated means RPM_SUSPENDED.
> >> right?
> >
> > I don't understand your question.
> >
> > Alan Stern
> >
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 3384 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Runtime power management during system resume

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 3572 bytes --]


 

Hi Alan,

 

I have few more questions:

 

1) If the platform device driver is using platform_bus_type as its bus type, in that case is the parent of device is its bus?

 

2) Because I saw the code in platform_device_register, when any platform device is register, its parent is set to

platform bus?

right?

 

int platform_device_add(struct platform_device *pdev)
{

----------------------------------------

if (!pdev->dev.parent)
                pdev->dev.parent = &platform_bus;

------------------------------------------------------

}

 

So when the platform device wants to use parent other than platform bus, is it possible to set the parent

of platform device to any other device rather than platform_bus?

 

 

3) The 3rd question is regarding, in this function

 

int __pm_runtime_resume(struct device *dev, bool from_wq)
        __releases(&dev->power.lock) __acquires(&dev->power.lock)
{

 

-----------------------
        if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_resume) {
                spin_unlock_irq(&dev->power.lock);

                retval = dev->bus->pm->runtime_resume(dev);

                spin_lock_irq(&dev->power.lock);
                dev->power.runtime_error = retval;
        }

 

--------------------

 out:
        if (parent) {
                spin_unlock_irq(&dev->power.lock);

                pm_runtime_put(parent);

                spin_lock_irq(&dev->power.lock);
        }

}

 

When the device is resumed and its status is set to RPM_ACTIVE, Now the control comes to 

pm_runtime_put(parent) (suppose device is resumed correctly)

 

Now it decrements the power usage count and call idle for parent.

 

Why after resuming the device, It will try to schedule idle for its parent?

 

Since the device is resumed so its parent should be active.

 

Regards

Raj

 

 

 

 


 

 

 


 

 

> ----------------------------------------
> > Date: Tue, 24 Aug 2010 10:30:25 -0400
> > From: stern@rowland.harvard.edu
> > To: rajkumar278@hotmail.com
> > CC: linux-kernel@vger.kernel.org
> > Subject: Re: Runtime power management during system resume
> >
> > On Tue, 24 Aug 2010, Raj Kumar wrote:
> >
> >> Hi Alan,
> >>
> >> I have implemented the run time power management in my drivers. I have one
> >> issue regarding System resume.
> >>
> >> When the system sleep is triggered as it is mentioned that Power management
> >> core will increment the power_usage counter during prepare and decrements when complete
> >> is called.
> >>
> >> Now I have few questions:
> >>
> >> 1) When the system resume is done, it does not increase the power_usage counter.
> >> right?
> >
> > That's right.
> >
> >> So Does then the driver need to update the power_usage counter with run time power management
> >> core and again set it to active means RPM_ACTIVE?
> >
> > Read section 6 of Documentation/power/runtime_pm.h. It explains this.
> >
> >> 2) Suppose device is active, means its power_usage counter is already one, Now during system
> >> sleep, does the driver first suspend it with run time power management core and then continue
> >> System suspend?
> >
> > No.
> >
> >> 3) Because I have seen the code of power management core and I did not see the that during
> >> system suspend, run time power management status is updated means RPM_SUSPENDED.
> >> right?
> >
> > I don't understand your question.
> >
> > Alan Stern
> >

 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 5342 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]


Hi Alan,

 

I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.

e.g. If we have device driver (X device contains processor) that wants to scale its own processor based

upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)

then X device driver when detects waorkload,  Can this X device driver call policy governor APIS for scaling clock or

this X device driver can directly calls DVFS driver APIs directly?

I just want to know from our device driver how do call DVFS driver if DVFS driver is registered with cpu frequency subsystem?

 

 

 

Regards

Raj 

 
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1000 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(No subject)

[Soumya R]

(no subject)

[Tom H]

(no subject)

[Ang Way Chuang]

unsubscribe linux-media

(No subject)

[Soumya R]

Hi All,

      I need to include root file system in my uImage how can i
do that in OpenEmbedded.

Regards,
Soumya

(No subject)

[Khem Raj]

On Thu, Jul 1, 2010 at 3:19 AM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Hi All,
>
>      I need to include root file system in my uImage how can i
> do that in OpenEmbedded.

look into initramfs.
Dont you think adding subject to email makes sense.?

>
> Regards,
> Soumya
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

(No subject)

[Soumya R]

Thanks for the reply.. Yes ofcourse i forgot it will not repeat again sorry..

Regards,
Soumya
________________________________________
From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Khem Raj [raj.khem@gmail.com]
Sent: Friday, July 02, 2010 12:34 AM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] (no subject)

On Thu, Jul 1, 2010 at 3:19 AM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Hi All,
>
>      I need to include root file system in my uImage how can i
> do that in OpenEmbedded.

look into initramfs.
Dont you think adding subject to email makes sense.?

>
> Regards,
> Soumya
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.

[Justin P. Mattock]

First and foremost, I must
thank anybody taking the time to even
look at these(I know you people have better
things to be doing).

And secondly here is my try at trying
to fix some of the warning messages
spammed by gcc 4.6.0 when building the
kernel. Some of them I removed, and
some of them I just shut off.

Note: Removing the code does seem like a
good approach(if it's actually dead),
but if not then something needs
to be fixed.
As for shutting off the code to shutup gcc
does seem like a temporary fix, but would
rather have a warning message, than see it get
lost in the sands of time.

In any case Thanks for taking the time,
and hopefully we can get fixes for all of
this mess generated by gcc..

Justin P. Mattock

[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used

[Justin P. Mattock]

Temporary fix until something is resolved
to fix the below warning:
  CC [M]  drivers/ieee1394/sbp2.o
drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory':
drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used
 Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>

---
 drivers/ieee1394/sbp2.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c
index 4565cb5..fcf8bd5 100644
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu,
 
 	management_agent_addr = 0;
 	unit_characteristics = 0;
+	if (!unit_characteristics)
+		unit_characteristics = 0;
 	firmware_revision = SBP2_ROM_VALUE_MISSING;
 	model = ud->flags & UNIT_DIRECTORY_MODEL_ID ?
 				ud->model_id : SBP2_ROM_VALUE_MISSING;
-- 
1.7.1.rc1.21.gf3bd6

[PATCH] ieee1394: sbp2: remove unused code

[Stefan Richter]

which caused gcc 4.6 to warn about
    variable 'unit_characteristics' set but not used.

The underlying problem that was spotted here --- an incomplete
implementation --- is already 50% fixed in drivers/firewire/sbp2.c which
observes mgt_ORB_timeout but not yet ORB_size.

Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/ieee1394/sbp2.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Index: b/drivers/ieee1394/sbp2.c
===================================================================
--- a/drivers/ieee1394/sbp2.c
+++ b/drivers/ieee1394/sbp2.c
@@ -1350,12 +1350,11 @@ static void sbp2_parse_unit_directory(st
 	struct csr1212_keyval *kv;
 	struct csr1212_dentry *dentry;
 	u64 management_agent_addr;
-	u32 unit_characteristics, firmware_revision, model;
+	u32 firmware_revision, model;
 	unsigned workarounds;
 	int i;
 
 	management_agent_addr = 0;
-	unit_characteristics = 0;
 	firmware_revision = SBP2_ROM_VALUE_MISSING;
 	model = ud->flags & UNIT_DIRECTORY_MODEL_ID ?
 				ud->model_id : SBP2_ROM_VALUE_MISSING;
@@ -1372,17 +1371,15 @@ static void sbp2_parse_unit_directory(st
 				lu->lun = ORB_SET_LUN(kv->value.immediate);
 			break;
 
-		case SBP2_UNIT_CHARACTERISTICS_KEY:
-			/* FIXME: This is ignored so far.
-			 * See SBP-2 clause 7.4.8. */
-			unit_characteristics = kv->value.immediate;
-			break;
 
 		case SBP2_FIRMWARE_REVISION_KEY:
 			firmware_revision = kv->value.immediate;
 			break;
 
 		default:
+			/* FIXME: Check for SBP2_UNIT_CHARACTERISTICS_KEY
+			 * mgt_ORB_timeout and ORB_size, SBP-2 clause 7.4.8. */
+
 			/* FIXME: Check for SBP2_DEVICE_TYPE_AND_LUN_KEY.
 			 * Its "ordered" bit has consequences for command ORB
 			 * list handling. See SBP-2 clauses 4.6, 7.4.11, 10.2 */

-- 
Stefan Richter
-=====-==-=- -==- -===-
http://arcgraph.de/sr/

Re: [PATCH] ieee1394: sbp2: remove unused code

[Justin P. Mattock]

On 06/14/2010 02:44 PM, Stefan Richter wrote:
> which caused gcc 4.6 to warn about
>      variable 'unit_characteristics' set but not used.
>
> The underlying problem that was spotted here --- an incomplete
> implementation --- is already 50% fixed in drivers/firewire/sbp2.c which
> observes mgt_ORB_timeout but not yet ORB_size.
>
> Reported-by: Justin P. Mattock<justinmattock@gmail.com>
> Signed-off-by: Stefan Richter<stefanr@s5r6.in-berlin.de>
> ---
>   drivers/ieee1394/sbp2.c |   11 ++++-------
>   1 file changed, 4 insertions(+), 7 deletions(-)
>
> Index: b/drivers/ieee1394/sbp2.c
> ===================================================================
> --- a/drivers/ieee1394/sbp2.c
> +++ b/drivers/ieee1394/sbp2.c
> @@ -1350,12 +1350,11 @@ static void sbp2_parse_unit_directory(st
>   	struct csr1212_keyval *kv;
>   	struct csr1212_dentry *dentry;
>   	u64 management_agent_addr;
> -	u32 unit_characteristics, firmware_revision, model;
> +	u32 firmware_revision, model;
>   	unsigned workarounds;
>   	int i;
>
>   	management_agent_addr = 0;
> -	unit_characteristics = 0;
>   	firmware_revision = SBP2_ROM_VALUE_MISSING;
>   	model = ud->flags&  UNIT_DIRECTORY_MODEL_ID ?
>   				ud->model_id : SBP2_ROM_VALUE_MISSING;
> @@ -1372,17 +1371,15 @@ static void sbp2_parse_unit_directory(st
>   				lu->lun = ORB_SET_LUN(kv->value.immediate);
>   			break;
>
> -		case SBP2_UNIT_CHARACTERISTICS_KEY:
> -			/* FIXME: This is ignored so far.
> -			 * See SBP-2 clause 7.4.8. */
> -			unit_characteristics = kv->value.immediate;
> -			break;
>
>   		case SBP2_FIRMWARE_REVISION_KEY:
>   			firmware_revision = kv->value.immediate;
>   			break;
>
>   		default:
> +			/* FIXME: Check for SBP2_UNIT_CHARACTERISTICS_KEY
> +			 * mgt_ORB_timeout and ORB_size, SBP-2 clause 7.4.8. */
> +
>   			/* FIXME: Check for SBP2_DEVICE_TYPE_AND_LUN_KEY.
>   			 * Its "ordered" bit has consequences for command ORB
>   			 * list handling. See SBP-2 clauses 4.6, 7.4.11, 10.2 */
>


perfect!! compiled without any warning
with that one..
thanks for the reply and patch..

FWIW if you have time there's these guys as well
that I never looked at:

   CC [M]  drivers/firewire/core-transaction.o
drivers/firewire/core-transaction.c: In function 'fw_core_handle_response':
drivers/firewire/core-transaction.c:835:21: warning: variable 
'destination' set but not used
   CC [M]  drivers/firewire/ohci.o

   CC [M]  drivers/ieee1394/raw1394.o
drivers/ieee1394/raw1394.c: In function 'arm_write':
drivers/ieee1394/raw1394.c:1018:39: warning: variable 'length_conflict' 
set but not used
drivers/ieee1394/raw1394.c: In function 'arm_lock64':
drivers/ieee1394/raw1394.c:1373:11: warning: 'old' may be used 
uninitialized in this function
drivers/ieee1394/raw1394.c: In function 'arm_lock':
drivers/ieee1394/raw1394.c:1155:12: warning: 'old' may be used 
uninitialized in this function


  CC [M]  drivers/ieee1394/dv1394.o
drivers/ieee1394/dv1394.c: In function 'frame_prepare':
drivers/ieee1394/dv1394.c:613:15: warning: variable 'ts_off' set but not 
used
drivers/ieee1394/dv1394.c: In function 'ir_tasklet_func':
drivers/ieee1394/dv1394.c:2007:22: warning: variable 'packet_time' set 
but not used
drivers/ieee1394/dv1394.c: In function 'dv1394_host_reset':
drivers/ieee1394/dv1394.c:2323:18: warning: variable 'ohci' set but not used
   CC [M]  drivers/ieee1394/eth1394.o
drivers/ieee1394/eth1394.c: In function 'ether1394_iso':
drivers/ieee1394/eth1394.c:1261:23: warning: variable 'priv' set but not 
used
   LD      drivers/ieee802154/built-in.o


I can test and see!!

Justin P. Mattock

(no subject)

[Stefan Richter]

which caused gcc 4.6 to warn about
    variable 'destination' set but not used.

Reported-by: Justin P. Mattock <justinmattock@gmail.com>

Since the hardware ensures that we receive only response packets with
proper destination node ID (in a given bus generation), we have no use
for destination here in the core as well as in upper layers.

(This is different with request packets.  There we pass destination node
ID to upper layers because they may for example need to check whether
this was an unicast or broadcast request.)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/core-transaction.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: b/drivers/firewire/core-transaction.c
===================================================================
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -881,13 +881,12 @@ void fw_core_handle_response(struct fw_c
 	unsigned long flags;
 	u32 *data;
 	size_t data_length;
-	int tcode, tlabel, destination, source, rcode;
+	int tcode, tlabel, source, rcode;
 
-	tcode       = HEADER_GET_TCODE(p->header[0]);
-	tlabel      = HEADER_GET_TLABEL(p->header[0]);
-	destination = HEADER_GET_DESTINATION(p->header[0]);
-	source      = HEADER_GET_SOURCE(p->header[1]);
-	rcode       = HEADER_GET_RCODE(p->header[1]);
+	tcode	= HEADER_GET_TCODE(p->header[0]);
+	tlabel	= HEADER_GET_TLABEL(p->header[0]);
+	source	= HEADER_GET_SOURCE(p->header[1]);
+	rcode	= HEADER_GET_RCODE(p->header[1]);
 
 	spin_lock_irqsave(&card->lock, flags);
 	list_for_each_entry(t, &card->transaction_list, link) {

-- 
Stefan Richter
-=====-==-=- -==- -====
http://arcgraph.de/sr/

Re: (no subject)

[Stefan Richter]

On 15 Jun, Stefan Richter wrote:
> which caused gcc 4.6 to warn about
>     variable 'destination' set but not used.
...
>  drivers/firewire/core-transaction.c |   11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
...

Subject was meant to be [PATCH] firewire: core: remove unused variable.
-- 
Stefan Richter
-=====-==-=- -==- -====
http://arcgraph.de/sr/

(No subject)

["Andreas Müller"]

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

(No subject)

[Soumya R]

Hi All,
 
     I am using ubuntu 10.4 LTS and i am trying to build my own customized image
for mipsel.. When i run bitbake avn-image i get the following error.

cp: cannot stat `/home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native-2.6.4/05-enable-ctypes-cross-build.patch': No such file or directory
NOTE: Task failed: 
ERROR: TaskFailed event exception, aborting
ERROR: Build of /home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native_2.6.4.bb do_unpack failed
ERROR: Task 749 (/home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native_2.6.4.bb, do_unpack) failed
NOTE: Waiting for 3 active tasks to finish

  I am unable to tar Python-2.6.4.tar.bz2 by using the command 
tar -zxvf Python-2.6.4.tar.bz2
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Exiting with failure status due to previous errors
  
   so i downgraded the gzip but still the same error.. If anybody got the same error and resolved it please help me out.. I am stuck here:-(


Thanks in advance :-)

Regards,
Soumya



  

(No subject)

[Frans Meulenbroeks]

2010/6/10 Soumya R <Soumya.R@kpitcummins.com>:
> Hi All,

Hi,

I think it was already told to you that it is better to use a subject line.
More chance of getting a response.

>
>     I am using ubuntu 10.4 LTS and i am trying to build my own customized image
> for mipsel.. When i run bitbake avn-image i get the following error.
>
> cp: cannot stat `/home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native-2.6.4/05-enable-ctypes-cross-build.patch': No such file or directory
> NOTE: Task failed:
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native_2.6.4.bb do_unpack failed
> ERROR: Task 749 (/home/likewise-open/KPIT/soumyar/openembedded/recipes/python/python-native_2.6.4.bb, do_unpack) failed
> NOTE: Waiting for 3 active tasks to finish
>
>  I am unable to tar Python-2.6.4.tar.bz2 by using the command
> tar -zxvf Python-2.6.4.tar.bz2
> gzip: stdin: not in gzip format
> tar: Child returned status 1
> tar: Exiting with failure status due to previous errors
>
>   so i downgraded the gzip but still the same error.. If anybody got the same error and resolved it please help me out.. I am stuck here:-(

Read.
It tells the file is not in gzip format.
The file has .bz2 extension so it is probably a bzip2
tar -z decompresses with gzip, tar -j juses bunzip2

And if you have a decent tar you can just omit it and it will find out by itself

Frans.
>
>
> Thanks in advance :-)
>
> Regards,
> Soumya
>
>
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

(No subject)

[Soumya R]

Hi All,
      
     I get the following error when I run bitbake avn-image

NOTE: Handling BitBake files: \ (0172/0172) [100 %]
NOTE: Parsing finished. 163 cached, 7 parsed, 2 skipped, 0 masked.
NOTE: Resolving any missing task queue dependencies
ERROR: '['/home/likewise-open/KPIT/soumyar/openembedded/recipes/glibc/glibc_2.10.1.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'linux-libc-headers-dev' but it wasn't found in any PACKAGE or RPROVIDES variables
NOTE: Runtime target 'linux-libc-headers-dev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['linux-libc-headers-dev']
ERROR: Required build target 'avn-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['avn-image', 'opkg-native', 'gnu-config-native']

               How do I resolve this error?? Any suggestions is badly needed..

Thanks in advance

Regards,
Soumya

(No subject)

[Khem Raj]

On Tue, Jun 8, 2010 at 1:22 AM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Hi All,
>
>     I get the following error when I run bitbake avn-image
>
> NOTE: Handling BitBake files: \ (0172/0172) [100 %]
> NOTE: Parsing finished. 163 cached, 7 parsed, 2 skipped, 0 masked.
> NOTE: Resolving any missing task queue dependencies
> ERROR: '['/home/likewise-open/KPIT/soumyar/openembedded/recipes/glibc/glibc_2.10.1.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'linux-libc-headers-dev' but it wasn't found in any PACKAGE or RPROVIDES variables
> NOTE: Runtime target 'linux-libc-headers-dev' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['linux-libc-headers-dev']
> ERROR: Required build target 'avn-image' has no buildable providers.
> Missing or unbuildable dependency chain was: ['avn-image', 'opkg-native', 'gnu-config-native']
>
>               How do I resolve this error?? Any suggestions is badly needed..

post you local.conf somewhere. and take time to add some subject to the mail
many people have filters to send subjectless emails to /dev/null

>
> Thanks in advance
>
> Regards,
> Soumya
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

(No subject)

[Soumya R]

Hi All,

   I am running bibake micro-image i got the following error,

NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
ERROR: function do_package_update_index_ipk failed
ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
| + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
| + '[' '!' -z '' ']'
| + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
| 
| + for arch in '$ipkgarchs'
| + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
| Traceback (most recent call last):
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
|     pkg = ipkg.Package(filename)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
|     tarStream = ar.open("control.tar.gz")
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
|     f = self._scan(fname)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
|     size = int(descriptor[5])
| IndexError: list index out of range
NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
ERROR: TaskFailed event exception, aborting
ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
NOTE: Waiting for 1 active tasks to finish
NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
KPIT\soumyar@d-5289lnx:~/oe/build$ 

   Anybody can help me out to resolve this.Any suggestions are welcome:-)

Thanks in advance:-)

Regards,
Soumya

(No subject)

[Hodgson, Simon]

Let me guess, you're using Ubuntu 10.4 to build?

Edit the file:
home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py

Change the line:
size = int(descriptor[5])

To:
size = int(descriptor[3])

I'm afraid I can't explain why you need to do this, only that it works for me.

Simon

-----Original Message-----
From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
Sent: 02 June 2010 10:20
To: openembedded-devel@lists.openembedded.org
Cc: angstrom-distro-devel@linuxtogo.org
Subject: [oe] (no subject)

Hi All,

   I am running bibake micro-image i got the following error,

NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
ERROR: function do_package_update_index_ipk failed
ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
| + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
| + '[' '!' -z '' ']'
| + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
| 
| + for arch in '$ipkgarchs'
| + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
| Traceback (most recent call last):
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
|     pkg = ipkg.Package(filename)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
|     tarStream = ar.open("control.tar.gz")
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
|     f = self._scan(fname)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
|     size = int(descriptor[5])
| IndexError: list index out of range
NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
ERROR: TaskFailed event exception, aborting
ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
NOTE: Waiting for 1 active tasks to finish
NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
KPIT\soumyar@d-5289lnx:~/oe/build$ 

   Anybody can help me out to resolve this.Any suggestions are welcome:-)

Thanks in advance:-)

Regards,
Soumya


_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

(No subject)

[Soumya R]

Ya you are right i am using Ubuntu 10.4..
Thanks a lot for the reply it worked..

Thank you so much:-)

Regards,
Soumya
________________________________________
From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Hodgson, Simon [Simon.Hodgson@nortechonline.co.uk]
Sent: Wednesday, June 02, 2010 9:11 PM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] (no subject)

Let me guess, you're using Ubuntu 10.4 to build?

Edit the file:
home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py

Change the line:
size = int(descriptor[5])

To:
size = int(descriptor[3])

I'm afraid I can't explain why you need to do this, only that it works for me.

Simon

-----Original Message-----
From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
Sent: 02 June 2010 10:20
To: openembedded-devel@lists.openembedded.org
Cc: angstrom-distro-devel@linuxtogo.org
Subject: [oe] (no subject)

Hi All,

   I am running bibake micro-image i got the following error,

NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
ERROR: function do_package_update_index_ipk failed
ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
| + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
| + '[' '!' -z '' ']'
| + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
|
| + for arch in '$ipkgarchs'
| + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
| + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
| + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
| /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
|   import md5
| Traceback (most recent call last):
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
|     pkg = ipkg.Package(filename)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
|     tarStream = ar.open("control.tar.gz")
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
|     f = self._scan(fname)
|   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
|     size = int(descriptor[5])
| IndexError: list index out of range
NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
ERROR: TaskFailed event exception, aborting
ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
NOTE: Waiting for 1 active tasks to finish
NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
KPIT\soumyar@d-5289lnx:~/oe/build$

   Anybody can help me out to resolve this.Any suggestions are welcome:-)

Thanks in advance:-)

Regards,
Soumya


_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

(No subject)

[Khem Raj]

On Wed, Jun 2, 2010 at 7:37 PM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Ya you are right i am using Ubuntu 10.4..
> Thanks a lot for the reply it worked..
>
> Thank you so much:-)

are you using .dev ?. I don't see this issue here locally on ubuntu
10.04. whats your distro
and machine.it could be issue in ipkg-utils-native

Thx
-Khem

> home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py
>
> Change the line:
> size = int(descriptor[5])
>
> To:
> size = int(descriptor[3])
>
> I'm afraid I can't explain why you need to do this, only that it works for me.
>
> Simon
>
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
> Sent: 02 June 2010 10:20
> To: openembedded-devel@lists.openembedded.org
> Cc: angstrom-distro-devel@linuxtogo.org
> Subject: [oe] (no subject)
>
> Hi All,
>
>   I am running bibake micro-image i got the following error,
>
> NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
> NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
> ERROR: function do_package_update_index_ipk failed
> ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
> | + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
> | + '[' '!' -z '' ']'
> | + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> |
> | + for arch in '$ipkgarchs'
> | + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> | Traceback (most recent call last):
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
> |     pkg = ipkg.Package(filename)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
> |     tarStream = ar.open("control.tar.gz")
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
> |     f = self._scan(fname)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
> |     size = int(descriptor[5])
> | IndexError: list index out of range
> NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
> NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
> ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
> NOTE: Waiting for 1 active tasks to finish
> NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
> NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
> ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
> KPIT\soumyar@d-5289lnx:~/oe/build$
>
>   Anybody can help me out to resolve this.Any suggestions are welcome:-)
>
> Thanks in advance:-)
>
> Regards,
> Soumya
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

(No subject)

[Hodgson, Simon]

I'm using Angstrom, and at91sam9g20-ek, on two machines with new installs of Ubuntu 10.4 we see this problem, on another that was upgraded from 9.10 we don't see it.

-----Original Message-----
From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Khem Raj
Sent: 03 June 2010 06:11
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] (no subject)

On Wed, Jun 2, 2010 at 7:37 PM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Ya you are right i am using Ubuntu 10.4..
> Thanks a lot for the reply it worked..
>
> Thank you so much:-)

are you using .dev ?. I don't see this issue here locally on ubuntu
10.04. whats your distro
and machine.it could be issue in ipkg-utils-native

Thx
-Khem

> home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py
>
> Change the line:
> size = int(descriptor[5])
>
> To:
> size = int(descriptor[3])
>
> I'm afraid I can't explain why you need to do this, only that it works for me.
>
> Simon
>
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
> Sent: 02 June 2010 10:20
> To: openembedded-devel@lists.openembedded.org
> Cc: angstrom-distro-devel@linuxtogo.org
> Subject: [oe] (no subject)
>
> Hi All,
>
>   I am running bibake micro-image i got the following error,
>
> NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
> NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
> ERROR: function do_package_update_index_ipk failed
> ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
> | + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
> | + '[' '!' -z '' ']'
> | + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> |
> | + for arch in '$ipkgarchs'
> | + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> | Traceback (most recent call last):
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
> |     pkg = ipkg.Package(filename)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
> |     tarStream = ar.open("control.tar.gz")
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
> |     f = self._scan(fname)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
> |     size = int(descriptor[5])
> | IndexError: list index out of range
> NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
> NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
> ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
> NOTE: Waiting for 1 active tasks to finish
> NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
> NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
> ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
> KPIT\soumyar@d-5289lnx:~/oe/build$
>
>   Anybody can help me out to resolve this.Any suggestions are welcome:-)
>
> Thanks in advance:-)
>
> Regards,
> Soumya
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

(No subject)

[Nick Lee]

It turned out to be a likewise-open issue (for us at least) - if we log 
in as a normal user (i.e. not through likewise-open), the build works 
fine.  If we log in using likewise-open, the python file needs to be 
patched as described, but this then breaks the build for normal logins! 
  Our solution was to just not use likewise-open.

Nick

On 03/06/10 09:24, Hodgson, Simon wrote:
> I'm using Angstrom, and at91sam9g20-ek, on two machines with new installs of Ubuntu 10.4 we see this problem, on another that was upgraded from 9.10 we don't see it.
>
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Khem Raj
> Sent: 03 June 2010 06:11
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] (no subject)
>
> On Wed, Jun 2, 2010 at 7:37 PM, Soumya R<Soumya.R@kpitcummins.com>  wrote:
>> Ya you are right i am using Ubuntu 10.4..
>> Thanks a lot for the reply it worked..
>>
>> Thank you so much:-)
>
> are you using .dev ?. I don't see this issue here locally on ubuntu
> 10.04. whats your distro
> and machine.it could be issue in ipkg-utils-native
>
> Thx
> -Khem
>
>> home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py
>>
>> Change the line:
>> size = int(descriptor[5])
>>
>> To:
>> size = int(descriptor[3])
>>
>> I'm afraid I can't explain why you need to do this, only that it works for me.
>>
>> Simon
>>
>> -----Original Message-----
>> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
>> Sent: 02 June 2010 10:20
>> To: openembedded-devel@lists.openembedded.org
>> Cc: angstrom-distro-devel@linuxtogo.org
>> Subject: [oe] (no subject)
>>
>> Hi All,
>>
>>    I am running bibake micro-image i got the following error,
>>
>> NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
>> NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
>> ERROR: function do_package_update_index_ipk failed
>> ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
>> | + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
>> | + '[' '!' -z '' ']'
>> | + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
>> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
>> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
>> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
>> |   import md5
>> |
>> | + for arch in '$ipkgarchs'
>> | + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
>> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
>> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
>> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
>> |   import md5
>> | Traceback (most recent call last):
>> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in<module>
>> |     pkg = ipkg.Package(filename)
>> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
>> |     tarStream = ar.open("control.tar.gz")
>> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
>> |     f = self._scan(fname)
>> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
>> |     size = int(descriptor[5])
>> | IndexError: list index out of range
>> NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
>> ERROR: TaskFailed event exception, aborting
>> ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
>> NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
>> ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
>> NOTE: Waiting for 1 active tasks to finish
>> NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
>> NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
>> ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
>> KPIT\soumyar@d-5289lnx:~/oe/build$
>>
>>    Anybody can help me out to resolve this.Any suggestions are welcome:-)
>>
>> Thanks in advance:-)
>>
>> Regards,
>> Soumya
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

(No subject)

[Soumya R]

Hi,
    
MACHINE = "at91sam9263ek"
DISTRO = "angstrom-2008.1"
    
  I am new to this open embedded so you may seem may question is silly..
I need to know wat i need to deploy to my target and where the final image is stored..
Please help me out.. Thanks in advance :-)

Regards,
Soumya
________________________________________
From: openembedded-devel-bounces@lists.openembedded.org [openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Khem Raj [raj.khem@gmail.com]
Sent: Thursday, June 03, 2010 10:40 AM
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] (no subject)

On Wed, Jun 2, 2010 at 7:37 PM, Soumya R <Soumya.R@kpitcummins.com> wrote:
> Ya you are right i am using Ubuntu 10.4..
> Thanks a lot for the reply it worked..
>
> Thank you so much:-)

are you using .dev ?. I don't see this issue here locally on ubuntu
10.04. whats your distro
and machine.it could be issue in ipkg-utils-native

Thx
-Khem

> home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py
>
> Change the line:
> size = int(descriptor[5])
>
> To:
> size = int(descriptor[3])
>
> I'm afraid I can't explain why you need to do this, only that it works for me.
>
> Simon
>
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of Soumya R
> Sent: 02 June 2010 10:20
> To: openembedded-devel@lists.openembedded.org
> Cc: angstrom-distro-devel@linuxtogo.org
> Subject: [oe] (no subject)
>
> Hi All,
>
>   I am running bibake micro-image i got the following error,
>
> NOTE: Running task 965 of 970 (ID: 93, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_write)
> NOTE: Running task 966 of 970 (ID: 18, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk)
> ERROR: function do_package_update_index_ipk failed
> ERROR: log data follows (/home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831)
> | + ipkgarchs='all any noarch arm  armv4 armv4t armv5te at91sam9263ek'
> | + '[' '!' -z '' ']'
> | + mkdir -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> |
> | + for arch in '$ipkgarchs'
> | + '[' -e /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/ ']'
> | + touch /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages
> | + ipkg-make-index -r /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -p /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages -l /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/Packages.filelist -m /home/likewise-open/KPIT/soumyar/oe/build/tmp/deploy/glibc/ipk/all/
> | /home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py:39: DeprecationWarning: the md5 module is deprecated; use hashlib instead
> |   import md5
> | Traceback (most recent call last):
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg-make-index", line 114, in <module>
> |     pkg = ipkg.Package(filename)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/ipkg.py", line 161, in __init__
> |     tarStream = ar.open("control.tar.gz")
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 59, in open
> |     f = self._scan(fname)
> |   File "/home/likewise-open/KPIT/soumyar/oe/build/tmp/sysroots/i686-linux/usr/bin/arfile.py", line 79, in _scan
> |     size = int(descriptor[5])
> | IndexError: list index out of range
> NOTE: Task failed: /home/likewise-open/KPIT/soumyar/oe/build/tmp/work/at91sam9263ek-angstrom-linux-gnueabi/micro-image-1.0-r0/temp/log.do_package_update_index_ipk.24831
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb do_package_update_index_ipk failed
> NOTE: Running task 967 of 970 (ID: 95, /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage)
> ERROR: Task 18 (/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb, do_package_update_index_ipk) failed
> NOTE: Waiting for 1 active tasks to finish
> NOTE: 1: /home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/mtd/mtd-utils-native_1.3.1.bb, do_package_stage (24841)
> NOTE: Tasks Summary: Attempted 965 tasks of which 927 didn't need to be rerun and 1 failed.
> ERROR: '/home/likewise-open/KPIT/soumyar/oe/openembedded/recipes/images/micro-image.bb' failed
> KPIT\soumyar@d-5289lnx:~/oe/build$
>
>   Anybody can help me out to resolve this.Any suggestions are welcome:-)
>
> Thanks in advance:-)
>
> Regards,
> Soumya
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

(No subject)

[Nicolas Ferre]

Le 03/06/2010 14:13, Soumya R :
> Hi,
>     
> MACHINE = "at91sam9263ek"
> DISTRO = "angstrom-2008.1"
>     
>   I am new to this open embedded so you may seem may question is silly..
> I need to know wat i need to deploy to my target and where the final image is stored..
> Please help me out.. Thanks in advance :-)

I advice you to go on
http://www.linux4sam.org
and follow the documentation there. You will have an example of the
deployment of such a distribution.

In an OE build, here are the resulting images:
tmp/deploy/glibc/images/at91sam9263ek/

- Linux kernel (as a uImage suitable for u-boot):
  uImage-2.6.30-r1-at91sam9263ek.bin
- Angstrom rootfs:

Angstrom-x11-at91sam9-image-glibc-ipk-2009.X-stable-at91sam9263ek.rootfs.jffs2

For micro-image, you will find a different name but at the same location.

IPK packages are located here:
tmp/deploy/glibc/ipk/

Hope that it helps,
-- 
Nicolas Ferre

(no subject)

[carlopmart]

unsubscribe kvm

(no subject)

[bgamari.foss]

>From nobody Tue Apr 20 22:00:38 2010
From: Ben Gamari <bgamari.foss@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-kernel@vger.kernel.org, pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: [REGRESSION 2.6.34] Suspend fails in pm_test=processor on Dell
	laptop
In-Reply-To: <201004200533.13219.rjw@sisk.pl>
References: <4bcb1cf2.116bdc0a.2008.6f5a@mx.google.com>
	<201004200533.13219.rjw@sisk.pl>
Date: Tue, 20 Apr 2010 15:11:52 -0400
Message-ID: <87633mey6f.fsf@ben-laptop.i-did-not-set--mail-host-address--so-tickle-me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Tue, 20 Apr 2010 05:33:13 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Sunday 18 April 2010, Ben Gamari wrote:
[snip]
> > It seems that something in the 2.6.34 merge cycle has broken suspend to RAM on
> > my Dell Latitude D830. While suspend has been rock solid for several release
> > cycles, as of 2.6.34-rc4 it locks up on suspend. All of the pm_test options up
> > to processor work fine, precluding a driver issue.
> 
> Hmm, does the "processors" work?

Nope. Processors is the first failing phase.

I'm still working on getting a bisection, but it'll be a few more days
due to various school-related delays.

- Ben

(no subject)

[Jiang, Yunhong]

[-- Attachment #1: Type: text/plain, Size: 10984 bytes --]

Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;



[-- Attachment #2: mcinfo_reserve.patch --]
[-- Type: application/octet-stream, Size: 10822 bytes --]

# HG changeset patch
# User Yunhong Jiang <yunhong.jiang@intel.com>
# Date 1271415118 -28800
# Node ID 63632454170a30f4e0cbffa78be62b33e87605bb
# Parent  4e1d1e56e8b90f8594db6f812b5bd5f35f6e87be
Add a x86_mcinfo_reserve() function, to reserve space from mc_info.

With this method, we don't need to collect bank and globalinformation to a
local variable and do x86_mcinfo_add() to copy that information to mc_info.
This avoid copy and also we can be aware earlier if there is enough space
in the mc_info.

Also extract function that get global/bank information to seperated
function mca_init_bank/mca_init_global.

It's meaningless to get the current information in mce context, keep it here
but should be removed in future.

Also a flag added to mc_info, to indicate some information is lost due to OOM.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 16 18:51:58 2010 +0800
@@ -125,6 +125,88 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+static struct mcinfo_bank *mca_init_bank(enum mca_source who,
+                                         struct mc_info *mi, int bank)
+{
+	struct mcinfo_bank *mib;
+	uint64_t addr=0, misc = 0;
+
+	if (!mi)
+		return NULL;
+
+	mib = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_bank));
+	if (!mib)
+	{
+		mi->flags |= MCINFO_FLAGS_UNCOMPLETE;
+		return NULL;
+	}
+
+	memset(mib, 0, sizeof (struct mcinfo_bank));
+	mca_rdmsrl(MSR_IA32_MC0_STATUS + bank * 4, mib->mc_status);
+
+	mib->common.type = MC_TYPE_BANK;
+	mib->common.size = sizeof (struct mcinfo_bank);
+	mib->mc_bank = bank;
+
+	addr = misc = 0;
+	if (mib->mc_status & MCi_STATUS_MISCV)
+		mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * bank, mib->mc_misc);
+
+	if (mib->mc_status & MCi_STATUS_ADDRV)
+	{
+		mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * bank, mib->mc_addr);
+
+		if (mfn_valid(paddr_to_pfn(mib->mc_addr))) {
+			struct domain *d;
+
+			d = maddr_get_owner(mib->mc_addr);
+			if (d != NULL && (who == MCA_POLLER ||
+				  who == MCA_CMCI_HANDLER))
+				mib->mc_domid = d->domain_id;
+		}
+	}
+
+	if (who == MCA_CMCI_HANDLER) {
+		mca_rdmsrl(MSR_IA32_MC0_CTL2 + bank, mib->mc_ctrl2);
+		rdtscll(mib->mc_tsc);
+	}
+
+	return mib;
+}
+
+static int mca_init_global(uint32_t flags, struct mcinfo_global *mig)
+{
+	uint64_t status;
+	int cpu_nr;
+	struct vcpu *v = current;
+	struct domain *d;
+
+	/* Set global information */
+	memset(mig, 0, sizeof (struct mcinfo_global));
+	mig->common.type = MC_TYPE_GLOBAL;
+	mig->common.size = sizeof (struct mcinfo_global);
+	mca_rdmsrl(MSR_IA32_MCG_STATUS, status);
+	mig->mc_gstatus = status;
+	mig->mc_domid = mig->mc_vcpuid = -1;
+	mig->mc_flags = flags;
+	cpu_nr = smp_processor_id();
+	/* Retrieve detector information */
+	x86_mc_get_cpu_info(cpu_nr, &mig->mc_socketid,
+	  &mig->mc_coreid, &mig->mc_core_threadid,
+	  &mig->mc_apicid, NULL, NULL, NULL);
+
+	/* This is really meaningless */
+	if (v != NULL && ((d = v->domain) != NULL)) {
+		mig->mc_domid = d->domain_id;
+		mig->mc_vcpuid = v->vcpu_id;
+	} else {
+		mig->mc_domid = -1;
+		mig->mc_vcpuid = -1;
+	}
+
+	return 0;
+}
+
 /* Utility function to perform MCA bank telemetry readout and to push that
  * telemetry towards an interested dom0 for logging and diagnosis.
  * The caller - #MC handler or MCA poll function - must arrange that we
@@ -139,64 +221,38 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 mctelem_cookie_t mcheck_mca_logout(enum mca_source who, cpu_banks_t bankmask,
     struct mca_summary *sp, cpu_banks_t* clear_bank)
 {
-	struct vcpu *v = current;
-	struct domain *d;
-	uint64_t gstatus, status, addr, misc;
-	struct mcinfo_global mcg;	/* on stack */
-	struct mcinfo_common *mic;
-	struct mcinfo_global *mig;	/* on stack */
+	uint64_t gstatus, status;
+	struct mcinfo_global *mig = NULL;	/* on stack */
 	mctelem_cookie_t mctc = NULL;
-	uint32_t uc = 0, pcc = 0, recover, need_clear = 1 ;
+	uint32_t uc = 0, pcc = 0, recover, need_clear = 1, mc_flags = 0;
 	struct mc_info *mci = NULL;
 	mctelem_class_t which = MC_URGENT;	/* XXXgcc */
-	unsigned int cpu_nr;
 	int errcnt = 0;
 	int i;
 	enum mca_extinfo cbret = MCA_EXTINFO_IGNORED;
 
-	cpu_nr = smp_processor_id();
-	BUG_ON(cpu_nr != v->processor);
-
 	mca_rdmsrl(MSR_IA32_MCG_STATUS, gstatus);
-
-	memset(&mcg, 0, sizeof (mcg));
-	mcg.common.type = MC_TYPE_GLOBAL;
-	mcg.common.size = sizeof (mcg);
-	if (v != NULL && ((d = v->domain) != NULL)) {
-		mcg.mc_domid = d->domain_id;
-		mcg.mc_vcpuid = v->vcpu_id;
-	} else {
-		mcg.mc_domid = -1;
-		mcg.mc_vcpuid = -1;
-	}
-	mcg.mc_gstatus = gstatus;	/* MCG_STATUS */
-
 	switch (who) {
 	case MCA_MCE_HANDLER:
 	case MCA_MCE_SCAN:
-		mcg.mc_flags = MC_FLAG_MCE;
+		mc_flags = MC_FLAG_MCE;
 		which = MC_URGENT;
 		break;
 
 	case MCA_POLLER:
 	case MCA_RESET:
-		mcg.mc_flags = MC_FLAG_POLLED;
+		mc_flags = MC_FLAG_POLLED;
 		which = MC_NONURGENT;
 		break;
 
 	case MCA_CMCI_HANDLER:
-		mcg.mc_flags = MC_FLAG_CMCI;
+		mc_flags = MC_FLAG_CMCI;
 		which = MC_NONURGENT;
 		break;
 
 	default:
 		BUG();
 	}
-
-	/* Retrieve detector information */
-	x86_mc_get_cpu_info(cpu_nr, &mcg.mc_socketid,
-	    &mcg.mc_coreid, &mcg.mc_core_threadid,
-	    &mcg.mc_apicid, NULL, NULL, NULL);
 
 	/* If no mc_recovery_scan callback handler registered,
 	 * this error is not recoverable
@@ -204,7 +260,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 	recover = (mc_recoverable_scan)? 1: 0;
 
 	for (i = 0; i < 32 && i < nr_mce_banks; i++) {
-		struct mcinfo_bank mcb;		/* on stack */
+		struct mcinfo_bank *mib;		/* on stack */
 
 		/* Skip bank if corresponding bit in bankmask is clear */
 		if (!test_bit(i, bankmask))
@@ -227,17 +283,16 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		 * a poller;  this can fail (for example dom0 may not
 		 * yet have consumed past telemetry). */
 		if (errcnt == 0) {
-			if ((mctc = mctelem_reserve(which)) != NULL) {
+			if ( (mctc = mctelem_reserve(which)) != NULL ) {
 				mci = mctelem_dataptr(mctc);
 				mcinfo_clear(mci);
+				mig = (struct mcinfo_global*)x86_mcinfo_reserve
+				  (mci, sizeof(struct mcinfo_global));
+				/* mc_info should at least hold up the global information */
+				ASSERT(mig);
+				mca_init_global(mc_flags, mig);
 			}
 		}
-
-		memset(&mcb, 0, sizeof (mcb));
-		mcb.common.type = MC_TYPE_BANK;
-		mcb.common.size = sizeof (mcb);
-		mcb.mc_bank = i;
-		mcb.mc_status = status;
 
 		/* form a mask of which banks have logged uncorrected errors */
 		if ((status & MCi_STATUS_UC) != 0)
@@ -252,37 +307,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		  */
 			recover = mc_recoverable_scan(status);
 
-		addr = misc = 0;
-
-		if (status & MCi_STATUS_ADDRV) {
-			mca_rdmsrl(MSR_IA32_MC0_ADDR + 4 * i, addr);
-			if (mfn_valid(paddr_to_pfn(addr))) {
-				d = maddr_get_owner(addr);
-				if (d != NULL && (who == MCA_POLLER ||
-				    who == MCA_CMCI_HANDLER))
-					mcb.mc_domid = d->domain_id;
-			}
-		}
-
-		if (status & MCi_STATUS_MISCV)
-			mca_rdmsrl(MSR_IA32_MC0_MISC + 4 * i, misc);
-
-		mcb.mc_addr = addr;
-		mcb.mc_misc = misc;
-
-		if (who == MCA_CMCI_HANDLER) {
-			mca_rdmsrl(MSR_IA32_MC0_CTL2 + i, mcb.mc_ctrl2);
-			rdtscll(mcb.mc_tsc);
-		}
-
-		/* Increment the error count;  if this is the first bank
-		 * with a valid error then add the global info to the mcinfo. */
-		if (errcnt++ == 0 && mci != NULL)
-			x86_mcinfo_add(mci, &mcg);
-
-		/* Add the bank data */
-		if (mci != NULL)
-			x86_mcinfo_add(mci, &mcb);
+		mib = mca_init_bank(who, mci, i);
 
 		if (mc_callback_bank_extended && cbret != MCA_EXTINFO_GLOBAL) {
 			cbret = mc_callback_bank_extended(mci, i, status);
@@ -298,12 +323,8 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 		wmb();
 	}
 
-	if (mci != NULL && errcnt > 0) {
-		x86_mcinfo_lookup(mic, mci, MC_TYPE_GLOBAL);
-		mig = container_of(mic, struct mcinfo_global, common);
-		if (mic == NULL)
-			;
-		else if (pcc)
+	if (mig && errcnt > 0) {
+		if (pcc)
 			mig->mc_flags |= MC_FLAG_UNCORRECTABLE;
 		else if (uc)
 			mig->mc_flags |= MC_FLAG_RECOVERABLE;
@@ -758,13 +779,12 @@ static void mcinfo_clear(struct mc_info 
 	x86_mcinfo_nentries(mi) = 0;
 }
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+void *x86_mcinfo_reserve(struct mc_info *mi, int size)
 {
 	int i;
 	unsigned long end1, end2;
-	struct mcinfo_common *mic, *mic_base, *mic_index;
-
-	mic = (struct mcinfo_common *)mcinfo;
+	struct mcinfo_common *mic_base, *mic_index;
+
 	mic_index = mic_base = x86_mcinfo_first(mi);
 
 	/* go to first free entry */
@@ -774,16 +794,35 @@ int x86_mcinfo_add(struct mc_info *mi, v
 
 	/* check if there is enough size */
 	end1 = (unsigned long)((uint8_t *)mic_base + sizeof(struct mc_info));
-	end2 = (unsigned long)((uint8_t *)mic_index + mic->size);
+	end2 = (unsigned long)((uint8_t *)mic_index + size);
 
 	if (end1 < end2)
-		return x86_mcerr("mcinfo_add: no more sparc", -ENOSPC);
+	{
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+		return NULL;
+	}
 
 	/* there's enough space. add entry. */
-	memcpy(mic_index, mic, mic->size);
 	x86_mcinfo_nentries(mi)++;
 
-	return 0;
+    return mic_index;
+}
+
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo)
+{
+	struct mcinfo_common *mic, *buf;
+
+	mic = (struct mcinfo_common *)mcinfo;
+	buf = x86_mcinfo_reserve(mi, mic->size);
+
+	if ( !buf )
+		mce_printk(MCE_CRITICAL,
+			"mcinfo_add: No space left in mc_info\n");
+	else
+		memcpy(buf, mic, mic->size);
+
+	return buf;
 }
 
 /* Dump machine check information in a format,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Apr 16 18:51:58 2010 +0800
@@ -161,7 +161,8 @@ typedef enum mca_extinfo (*x86_mce_callb
     (struct mc_info *, uint16_t, uint64_t);
 extern void x86_mce_callback_register(x86_mce_callback_t);
 
-int x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_add(struct mc_info *mi, void *mcinfo);
+void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r 4e1d1e56e8b9 -r 63632454170a xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:00:23 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 16 18:51:58 2010 +0800
@@ -233,10 +233,11 @@ struct mcinfo_recovery
 #define MCINFO_HYPERCALLSIZE	1024
 #define MCINFO_MAXSIZE		768
 
+#define MCINFO_FLAGS_UNCOMPLETE 0x1
 struct mc_info {
     /* Number of mcinfo_* entries in mi_data */
     uint32_t mi_nentries;
-    uint32_t _pad0;
+    uint32_t flags;
     uint64_t mi_data[(MCINFO_MAXSIZE - 1) / 8];
 };
 typedef struct mc_info mc_info_t;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Sascha Hauer]

Hi,

Here are further fixes for the i.MX ssi driver. Mark, please let me know
whether I should combine 1/2 with the patch that actually broke fiq support.

Sascha

(No subject)

[majo huber]

Hi@all,

when compiling classpath I get the following error:

jm@pc-jm:~/localcvs/oe/stuff/openembedded$ bitbake classpath -c build
NOTE: Handling BitBake files: \ (8095/8095) [100 %]
NOTE: Parsing finished. 7448 cached, 317 parsed, 330 skipped, 0 masked.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 1335 of 1946 (ID: 284,
/home/jm/localcvs/oe/stuff/openembedded/recipes/antlr/antlr-native_2.7.7.bb,
do_compile)
ERROR: function do_compile failed
ERROR: log data follows
(/home/jm/oe/tmp/work/i686-linux/antlr-native-2.7.7-r0/temp/log.do_compile.20706)
| Exception in thread "main" java.lang.NoClassDefFoundError:
org/eclipse/jdt/internal/compiler/batch/Main
|    <<No stacktrace available>>
| Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.Main not found in
java.lang.ClassLoader$1{urls=[], parent=null}
|    at java.net.URLClassLoader.findClass(URLClassLoader.java:529)
|    at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
|    at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
|    at java.lang.ClassLoader.loadClass(ClassLoader.java:293)
NOTE: Task failed:
/home/jm/oe/tmp/work/i686-linux/antlr-native-2.7.7-r0/temp/log.do_compile.20706
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/jm/localcvs/oe/stuff/openembedded/recipes/antlr/antlr-native_2.7.7.bb
do_compile failed
ERROR: Task 284
(/home/jm/localcvs/oe/stuff/openembedded/recipes/antlr/antlr-native_2.7.7.bb,
do_compile) failed
NOTE: Tasks Summary: Attempted 1334 tasks of which 1334 didn't need to
be rerun and 1 failed.
ERROR: '/home/jm/localcvs/oe/stuff/openembedded/recipes/antlr/antlr-native_2.7.7.bb'
failed


Has anybody an idea how to resolve this issue?
I saw that the classpath has recently changed from 0.97 to 0.98
(according to git). And I'm pretty sure that I compiled this earlier
and had no problems. I'm no Java guy, so I don't really know where to
start. Is it possible that it has someting to do with the Host
platform (Ubuntu 9.10)?

Thanks in advance,
majo

(no subject)

["Alexander Jölly"]

hi,

i tried to install debian squeeze on an intel s3210 mainboard with an areca arc-1222 hardware raid-controller, but after install the system will not boot;
grub stops after:

GRUB loading..
Welcome to GRUB!

i have more of these servers, and upgrading from debian lenny to squeeze or a fresh install dont work on any of them;
what could be the problem here?
how can i troubleshoot this?

partitions:
/dev/sda1 /boot 100mb
/dev/sda2 /swap 8gb
/dev/sda3 /     300gb
/dev/sda4 /srv  4tb

thx,
alex
-- 
NEU: Mit GMX DSL über 1000,- ¿ sparen!
http://portal.gmx.net/de/go/dsl02

Re: (no subject)

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Alexander Jölly wrote:
> hi,
>
> i tried to install debian squeeze on an intel s3210 mainboard with an areca arc-1222 hardware raid-controller, but after install the system will not boot;
> grub stops after:
>
> GRUB loading..
> Welcome to GRUB!
>
>   
Do you have access to grub rescue prompt?
The best way to debug this is to add printfs in grub code. If you
installed grub correctly it's probably a firmware bug.
> i have more of these servers, and upgrading from debian lenny to squeeze or a fresh install dont work on any of them;
> what could be the problem here?
> how can i troubleshoot this?
>
> partitions:
> /dev/sda1 /boot 100mb
> /dev/sda2 /swap 8gb
> /dev/sda3 /     300gb
> /dev/sda4 /srv  4tb
>
> thx,
> alex
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

(No subject)

[saleh usman]

How I can solve this problem? any solution? guidance? tutorial?Plz help me in moving forword.RegardsSaleh >>>>BBFILES = "/oe/org.openembedded.dev/packages/*/*.bb  /oe/ossie_collection/packages/*/*.bb"
This seems wrong

>>>>NOTE: Handling BitBake files: \ (0014/0014) [100 %]
In fact you get just 14 items...

>>Dunno about ossie, but in openembedded we moved from 'packages' to 'recipes'.

>>Regards

>>Andrea
 >>>>I've built console-image without adding the following lines in local.conf

 file and it has been built successfully.Now when I've added these lines it is

giving  error.Attached is local.conf file.

>> >>ANGSTROM_EXTRA_INSTALL = " screen oprofile ossie-fm-from-file "

BBFILES = "/oe/org.openembedded.dev/packages/*/*.bb  /oe/ossie_collection/packages/*/*.bb"

BBFILE_COLLECTIONS = "upstream ossie"

BBFILE_PATTERN_upstream = "^/oe/org.openembedded.dev/packages"

BBFILE_PRIORITY_upstream = "5"

BBFILE_PATTERN_ossie = "^/oe/ossie/packages"

BBFILE_PRIORITY_ossie = "10"

Where oe is directory in which I've placed openembedded.

 Terminal window is showing following error.

[saleh <at> localhost ~]$ bitbake console-image

NOTE: Out of date cache found, rebuilding...

NOTE: Handling BitBake files: \ (0014/0014) [100 %]

NOTE: Parsing finished. 0 cached, 14 parsed, 0 skipped, 0 masked.

 ERROR: Nothing PROVIDES 'console-image' 		 	   		  
_________________________________________________________________
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010

(no subject)

[Ben Gamari]

Bcc: 
Subject: GPIO chip select support in omap2_mcspi driver

Hey,

Recently I have been looking to use a BeagleBoard to drive several
serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
BeagleBoard is severely limited by the number of SPI controllers it
exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
with one). This is insufficient for our application and thus I have been
investigating adding support to the mcspi driver for using GPIO lines as
chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.

To this end, I have a few questions about how this support was
implemented. First, it seems that the s3c24xx driver is built on the
spi_bitbang driver, despite interfacing with a dedicated hardware SPI
controller.  What is the reason for this? Was this done specifically for
the purpose of incorporating support for GPIO CS pins?

It seems like the rough idea is to add a cs_gpio field to the device
struct (omap2_mcspi) and add the appropriate code to the
omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
potential problem I can see with this is that omap2_mcspi_set_enable()
is called to enable the channel before the force_cs() is called (in
omap2_mcspi_work()). If I'm interpreting the documentation correctly,
the enable bit starts the clocks, meaning that the chip will begin
clocking out data before CS is brought high. I must be missing something
here, no?

For reference, I included a short list of relevant commits below, largely for
my own benefit. I would greatly appreciate any feedback you might have.

Thanks,
- Ben


pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

Re: (no subject)

[Ben Dooks]

Ben Gamari wrote:
> Bcc: 
> Subject: GPIO chip select support in omap2_mcspi driver
> 
> Hey,
> 
> Recently I have been looking to use a BeagleBoard to drive several
> serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
> BeagleBoard is severely limited by the number of SPI controllers it
> exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
> with one). This is insufficient for our application and thus I have been
> investigating adding support to the mcspi driver for using GPIO lines as
> chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
> 
> To this end, I have a few questions about how this support was
> implemented. First, it seems that the s3c24xx driver is built on the
> spi_bitbang driver, despite interfacing with a dedicated hardware SPI
> controller.  What is the reason for this? Was this done specifically for
> the purpose of incorporating support for GPIO CS pins?

The spi_bitbang driver also has a really useful spi queue and workqueue
built into it, which is what the s3c24xx spi driver actually bothers to
use.

> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
> 
> For reference, I included a short list of relevant commits below, largely for
> my own benefit. I would greatly appreciate any feedback you might have.
> 
> Thanks,
> - Ben
> 
> 
> pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
> bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

(no subject)

[Mr Mou Xinsheng]

-- 
Hello Friend,
I seek your assistance to receive funds on my behalf for mutual business
benefits,kindly reply via email:mrmouxinsheng01@gala.net, Mr Mou Xinsheng.

(no subject)

[Darrell]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: leadsman.jpg --]
[-- Type: image/jpeg, Size: 24442 bytes --]

[-- Attachment #3: Type: text/plain, Size: 191 bytes --]

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

[-- Attachment #4: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[Mikulas Patocka]

Hi

The current version of shared snapshots can be downloaded from 
http://people.redhat.com/mpatocka/patches/kernel/new-snapshots/devel

So if you want to review it, you can get it from there. (I'm not sending 
it to the mailing list because it's big)

Mikulas

(no subject)

[Mike Snitzer]

From: Mikulas Patocka <mpatocka@redhat.com>

Subject: [PATCH] dm snapshot: rework writing to snapshot origin

The previous code selected one exception as "primary_pe", linked all
other exceptions on it and used reference counting to wait until all
exceptions are reallocated. This didn't work with exceptions with
different chunk sizes:
https://bugzilla.redhat.com/show_bug.cgi?id=182659 

I removed all the complexity with exceptions linking and reference
counting.  Currently, bio is linked on one exception and when that
exception is reallocated, the bio is retried to possibly wait for
other exceptions.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
 drivers/md/dm-snap.c |  167 +++++++++++++++++----------------------------------
 1 file changed, 58 insertions(+), 109 deletions(-)

Index: linux-2.6/drivers/md/dm-snap.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-snap.c
+++ linux-2.6/drivers/md/dm-snap.c
@@ -153,28 +153,6 @@ struct dm_snap_pending_exception {
 	struct bio_list origin_bios;
 	struct bio_list snapshot_bios;
 
-	/*
-	 * Short-term queue of pending exceptions prior to submission.
-	 */
-	struct list_head list;
-
-	/*
-	 * The primary pending_exception is the one that holds
-	 * the ref_count and the list of origin_bios for a
-	 * group of pending_exceptions.  It is always last to get freed.
-	 * These fields get set up when writing to the origin.
-	 */
-	struct dm_snap_pending_exception *primary_pe;
-
-	/*
-	 * Number of pending_exceptions processing this chunk.
-	 * When this drops to zero we must complete the origin bios.
-	 * If incrementing or decrementing this, hold pe->snap->lock for
-	 * the sibling concerned and not pe->primary_pe->snap->lock unless
-	 * they are the same.
-	 */
-	atomic_t ref_count;
-
 	/* Pointer back to snapshot context */
 	struct dm_snapshot *snap;
 
@@ -961,6 +939,28 @@ static void flush_queued_bios(struct wor
 	flush_bios(queued_bios);
 }
 
+static int do_origin(struct dm_dev *origin, struct bio *bio);
+
+/*
+ * Flush a list of buffers.
+ */
+static void retry_origin_bios(struct dm_snapshot *s, struct bio *bio)
+{
+	struct bio *n;
+	int r;
+
+	while (bio) {
+		n = bio->bi_next;
+		bio->bi_next = NULL;
+		r = do_origin(s->origin, bio);
+		if (r == DM_MAPIO_REMAPPED)
+			generic_make_request(bio);
+		else
+			BUG_ON(r != DM_MAPIO_SUBMITTED);
+		bio = n;
+	}
+}
+
 /*
  * Error a list of buffers.
  */
@@ -994,39 +994,6 @@ static void __invalidate_snapshot(struct
 	dm_table_event(s->ti->table);
 }
 
-static void get_pending_exception(struct dm_snap_pending_exception *pe)
-{
-	atomic_inc(&pe->ref_count);
-}
-
-static struct bio *put_pending_exception(struct dm_snap_pending_exception *pe)
-{
-	struct dm_snap_pending_exception *primary_pe;
-	struct bio *origin_bios = NULL;
-
-	primary_pe = pe->primary_pe;
-
-	/*
-	 * If this pe is involved in a write to the origin and
-	 * it is the last sibling to complete then release
-	 * the bios for the original write to the origin.
-	 */
-	if (primary_pe &&
-	    atomic_dec_and_test(&primary_pe->ref_count)) {
-		origin_bios = bio_list_get(&primary_pe->origin_bios);
-		free_pending_exception(primary_pe);
-	}
-
-	/*
-	 * Free the pe if it's not linked to an origin write or if
-	 * it's not itself a primary pe.
-	 */
-	if (!primary_pe || primary_pe != pe)
-		free_pending_exception(pe);
-
-	return origin_bios;
-}
-
 static void pending_complete(struct dm_snap_pending_exception *pe, int success)
 {
 	struct dm_exception *e;
@@ -1075,7 +1042,8 @@ static void pending_complete(struct dm_s
  out:
 	dm_remove_exception(&pe->e);
 	snapshot_bios = bio_list_get(&pe->snapshot_bios);
-	origin_bios = put_pending_exception(pe);
+	origin_bios = bio_list_get(&pe->origin_bios);
+	free_pending_exception(pe);
 
 	up_write(&s->lock);
 
@@ -1085,7 +1053,7 @@ static void pending_complete(struct dm_s
 	else
 		flush_bios(snapshot_bios);
 
-	flush_bios(origin_bios);
+	retry_origin_bios(s, origin_bios);
 }
 
 static void commit_callback(void *context, int success)
@@ -1172,8 +1140,6 @@ __find_pending_exception(struct dm_snaps
 	pe->e.old_chunk = chunk;
 	bio_list_init(&pe->origin_bios);
 	bio_list_init(&pe->snapshot_bios);
-	pe->primary_pe = NULL;
-	atomic_set(&pe->ref_count, 0);
 	pe->started = 0;
 
 	if (s->store->type->prepare_exception(s->store, &pe->e)) {
@@ -1181,7 +1147,6 @@ __find_pending_exception(struct dm_snaps
 		return NULL;
 	}
 
-	get_pending_exception(pe);
 	dm_insert_exception(&s->pending, &pe->e);
 
 	return pe;
@@ -1441,14 +1406,21 @@ static int snapshot_iterate_devices(stru
 /*-----------------------------------------------------------------
  * Origin methods
  *---------------------------------------------------------------*/
-static int __origin_write(struct list_head *snapshots, struct bio *bio)
+
+/*
+ * Returns:
+ *	DM_MAPIO_REMAPPED: bio may be submitted to origin device
+ *	DM_MAPIO_SUBMITTED: bio was queued on queue on one of exceptions
+ */
+
+static int __origin_write(struct list_head *snapshots,
+			  sector_t sector, struct bio *bio)
 {
-	int r = DM_MAPIO_REMAPPED, first = 0;
+	int r = DM_MAPIO_REMAPPED;
 	struct dm_snapshot *snap;
 	struct dm_exception *e;
-	struct dm_snap_pending_exception *pe, *next_pe, *primary_pe = NULL;
+	struct dm_snap_pending_exception *pe, *pe_to_start = NULL;
 	chunk_t chunk;
-	LIST_HEAD(pe_queue);
 
 	/* Do all the snapshots on this origin */
 	list_for_each_entry (snap, snapshots, list) {
@@ -1460,22 +1432,19 @@ static int __origin_write(struct list_he
 			goto next_snapshot;
 
 		/* Nothing to do if writing beyond end of snapshot */
-		if (bio->bi_sector >= dm_table_get_size(snap->ti->table))
+		if (sector >= dm_table_get_size(snap->ti->table))
 			goto next_snapshot;
 
 		/*
 		 * Remember, different snapshots can have
 		 * different chunk sizes.
 		 */
-		chunk = sector_to_chunk(snap->store, bio->bi_sector);
+		chunk = sector_to_chunk(snap->store, sector);
 
 		/*
 		 * Check exception table to see if block
 		 * is already remapped in this snapshot
 		 * and trigger an exception if not.
-		 *
-		 * ref_count is initialised to 1 so pending_complete()
-		 * won't destroy the primary_pe while we're inside this loop.
 		 */
 		e = dm_lookup_exception(&snap->complete, chunk);
 		if (e)
@@ -1505,59 +1474,39 @@ static int __origin_write(struct list_he
 			}
 		}
 
-		if (!primary_pe) {
-			/*
-			 * Either every pe here has same
-			 * primary_pe or none has one yet.
-			 */
-			if (pe->primary_pe)
-				primary_pe = pe->primary_pe;
-			else {
-				primary_pe = pe;
-				first = 1;
-			}
-
-			bio_list_add(&primary_pe->origin_bios, bio);
-
-			r = DM_MAPIO_SUBMITTED;
-		}
+		r = DM_MAPIO_SUBMITTED;
 
-		if (!pe->primary_pe) {
-			pe->primary_pe = primary_pe;
-			get_pending_exception(primary_pe);
+		if (bio) {
+			bio_list_add(&pe->origin_bios, bio);
+			bio = NULL;
+
+			if (!pe->started) {
+				pe->started = 1;
+				pe_to_start = pe;
+			}
 		}
 
 		if (!pe->started) {
 			pe->started = 1;
-			list_add_tail(&pe->list, &pe_queue);
+			start_copy(pe);
 		}
 
  next_snapshot:
 		up_write(&snap->lock);
 	}
 
-	if (!primary_pe)
-		return r;
-
 	/*
-	 * If this is the first time we're processing this chunk and
-	 * ref_count is now 1 it means all the pending exceptions
-	 * got completed while we were in the loop above, so it falls to
-	 * us here to remove the primary_pe and submit any origin_bios.
+	 * pe_to_start is a small performance improvement:
+	 * To avoid calling __origin_write N times for N snapshots, we start
+	 * the snapshot where we queued the bio as the last one.
+	 *
+	 * If we start it as the last one, it finishes most likely as the last
+	 * one and exceptions in other snapshots will be already finished when
+	 * the bio will be retried.
 	 */
 
-	if (first && atomic_dec_and_test(&primary_pe->ref_count)) {
-		flush_bios(bio_list_get(&primary_pe->origin_bios));
-		free_pending_exception(primary_pe);
-		/* If we got here, pe_queue is necessarily empty. */
-		return r;
-	}
-
-	/*
-	 * Now that we have a complete pe list we can start the copying.
-	 */
-	list_for_each_entry_safe(pe, next_pe, &pe_queue, list)
-		start_copy(pe);
+	if (pe_to_start)
+		start_copy(pe_to_start);
 
 	return r;
 }
@@ -1573,7 +1522,7 @@ static int do_origin(struct dm_dev *orig
 	down_read(&_origins_lock);
 	o = __lookup_origin(origin->bdev);
 	if (o)
-		r = __origin_write(&o->snapshots, bio);
+		r = __origin_write(&o->snapshots, bio->bi_sector, bio);
 	up_read(&_origins_lock);
 
 	return r;

(no subject)

[Roger Cruz]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 370 bytes --]

(no subject)

[evgen]

subscribe kernel-janitors

(no subject)

[Noah Watkins]

Sage,

A few changes you might be interested in:

You can pull from:

      http://code.noahdesu.com/git/ceph-client-standalone.git/ for-sage

- Noah

--------------

Noah Watkins (3):
       ceph: add 'tags' to .gitignore
       ceph: replace list_entry with container_of
       ceph: remove redundant use of le32_to_cpu



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: (no subject)

[Sage Weil]

On Wed, 28 Oct 2009, Noah Watkins wrote:

> Sage,
> 
> A few changes you might be interested in:
> 
> You can pull from:
> 
>       http://code.noahdesu.com/git/ceph-client-standalone.git/ for-sage

Applied.

>        ceph: add 'tags' to .gitignore

This one belongs in ceph-client-standalone.git...

>        ceph: replace list_entry with container_of
>        ceph: remove redundant use of le32_to_cpu

but in the future, can you apply these to a ceph-client.git tree?  The 
-standalone repo is entirely slaved off the main repo with some bash 
scripts.

Thanks!
sage


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

Re: (no subject)

[Noah Watkins]

[-- Attachment #1.1: Type: text/plain, Size: 252 bytes --]

>
> but in the future, can you apply these to a ceph-client.git tree?  The
> -standalone repo is entirely slaved off the main repo with some bash
> scripts.

Yeh, no problem. Is there a script to yank the standalone module out of
the kernel tree?

-n


[-- Attachment #1.2: Type: text/html, Size: 1071 bytes --]

[-- Attachment #2: Type: text/plain, Size: 399 bytes --]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Ceph-devel mailing list
Ceph-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ceph-devel

Re: (no subject)

[Noah Watkins]

[-- Attachment #1.1: Type: text/plain, Size: 281 bytes --]

>
> This one belongs in ceph-client-standalone.git...
>
>>        ceph: replace list_entry with container_of
>>        ceph: remove redundant use of le32_to_cpu

All three patches were against ceph-client-standalone.git. You want  
them re-submitted against ceph-client.git ?

-n


[-- Attachment #1.2: Type: text/html, Size: 1229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 399 bytes --]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Ceph-devel mailing list
Ceph-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ceph-devel

Re: (no subject)

[Sage Weil]

On Wed, 28 Oct 2009, Noah Watkins wrote:

> > 
> > This one belongs in ceph-client-standalone.git...
> > 
> > >       ceph: replace list_entry with container_of
> > >       ceph: remove redundant use of le32_to_cpu
> 
> All three patches were against ceph-client-standalone.git. You want them
> re-submitted against ceph-client.git ?

No worries, I fixed these up and applied them.

The -standalone.git has a pull.sh and tries to mirror the git history for 
just commits affecting fs/ceph/.  A backport.sh maintains the backport 
branch.  There're not much use to anyone unless I forget to update 
-standalone.git and you want to pull the latest from the main repo.

sage

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

(no subject)

[Vikram Dhillon]

echo subscribe kernel-janitors | mail majordomo@vger.kernel.org

(no subject)

[Eads, Joshua Michael (S&T-Student)]

I have an HVM guest and I am trying to have a usermode program in Dom0 query the context (CPU registers, specifically) of the guest.  

I first tried using xc_domain_getcontext() in xenctrl.h but I haven't figured out what data structure ctxt_buf is that it returns.  Next, I have tried using xc_vcpu_getcontext() in xenctrl.h but so far it always returns -1 for failure.  For xc_vcpu_getcontext, I am passing in a vcpu number of 1 (I only have a single virtual CPU domU running) along with an unallocated vcpu_guest_context_t pointer.

Is this the right direction to pull guest registers, or is there another method I need to use to get the HVM guest context?

Thanks,
Josh

(no subject)

[Dave Wysochanski]

(no subject)

[debmail_5f63g]

subscribe kvm

(no subject)

[Delusion's Master]

Hi,

I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c:

[..]
copying file alsa-kernel/core/info.c
patching file info.c
copying file alsa-kernel/core/pcm.c
patching file pcm.c
Hunk #3 succeeded at 739 (offset 2 lines).
Hunk #5 succeeded at 954 (offset 2 lines).
Hunk #7 succeeded at 1045 (offset 2 lines).
copying file alsa-kernel/core/pcm_native.c
patching file pcm_native.c
Hunk #4 succeeded at 1544 (offset -25 lines).
Hunk #5 succeeded at 2827 (offset 12 lines).
Hunk #6 succeeded at 2878 (offset 10 lines).
Hunk #7 FAILED at 2906.
Hunk #8 FAILED at 2922.
Hunk #9 succeeded at 2915 (offset -23 lines).
Hunk #10 succeeded at 3036 (offset 10 lines).
Hunk #11 succeeded at 3027 (offset -23 lines).
Hunk #12 succeeded at 3074 (offset 10 lines).
Hunk #13 succeeded at 3098 (offset -23 lines).
Hunk #14 succeeded at 3143 (offset 10 lines).
Hunk #15 succeeded at 3124 (offset -23 lines).
Hunk #16 succeeded at 3214 (offset 10 lines).
Hunk #17 succeeded at 3208 (offset -23 lines).
Hunk #18 succeeded at 3271 (offset 10 lines).
Hunk #19 succeeded at 3304 (offset -23 lines).
Hunk #20 succeeded at 3386 (offset 10 lines).
Hunk #21 succeeded at 3411 (offset -23 lines).
Hunk #22 succeeded at 3456 (offset 10 lines).
Hunk #23 succeeded at 3450 (offset -23 lines).
Hunk #24 succeeded at 3525 (offset 10 lines).
Hunk #25 succeeded at 3644 (offset -23 lines).
2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej
make[2]: *** [pcm_native.c] Error 1


It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates.

I searched for this error and the only relevant report I could find is this one:

http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html

a report from last April.

What could the problem be?
Thanks
 		 	   		  
_________________________________________________________________
Windows Live™: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009

(no subject)

[David Howells]

Hi,

I've come across an interesting problem with grub and grub2 booting with only a
serial console: they won't finish booting if they don't have anything plugged
into the serial port.  The moment a serial cable is inserted, they throw up a
menu and continues booting.

The board boots fine with the extlinux variant of syslinux with nothing
attached to the serial port.

I have a Soekris net5501 board, which I'm trying to set up to be a DSL firewall
router box.  There is no video hardware, and there won't normally be anything
plugged into the serial port.

David

Re: (no subject)

[Robert Millan]

On Mon, Sep 21, 2009 at 02:39:05PM +0100, David Howells wrote:
> Hi,
> 
> I've come across an interesting problem with grub and grub2 booting with only a
> serial console: they won't finish booting if they don't have anything plugged
> into the serial port.  The moment a serial cable is inserted, they throw up a
> menu and continues booting.

Could have something to do with a BIOS bug.  What happens if you convert
grub_checkkey() and grub_getkey() (in kern/term.c) into dummy stubs?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: (no subject)

[David Howells]

Robert Millan <rmh@aybabtu.com> wrote:

> Could have something to do with a BIOS bug.  What happens if you convert
> grub_checkkey() and grub_getkey() (in kern/term.c) into dummy stubs?

It doesn't seem to help.  Grub still waits until the PC is plugged in before
displaying its menu.

David

(no subject)

[Hyundai]

-- 
Congrats... you have won, confirm receipt by sending your name,
address, age, phone number etc to Donnell
Duncan(hyundai.claims00@sify.com),Tel:+44 70457 09552

(no subject)

[Hyundai]

-- 
Congrats... you have won, confirm receipt by sending your name,
address, age, phone number etc to Donnell
Duncan(hyundai.claims00@sify.com),Tel:+44 70457 09552

(no subject)

[the uknl]

A lump sum of (£1,000,000.00GBP) has been credited to your E-mail, contact
Mr.kyle evan.(kyle_evan1@9.cn) Provide your
Name,Country,Address,Tel,Occupation.

(no subject)

[MRS SANDRA WHITE]

I am Mrs Sandra White, I am currently sending you this mail from my sick
bed in the hospital,I would want you to contact my lawyer;Email
(Martins009@9.cn)

(no subject)

[MRS SANDRA WHITE]

I am Mrs Sandra White, I am currently sending you this mail from my sick
bed in the hospital,I would want you to contact my lawyer;Email
(Martins009@9.cn)

(no subject)

[INFO]

A lump sum of (£1,000,000.00 GBP) has been credited to your E-mail
id,contact markrobinson@9.cn with your Name: Address: Age: Sex:
Occupation:Tel: Country

(no subject)

[Wy]

I have a business deal of $6.8million for you,if interested please contact
me with your required info to email:wynewilliams@9.cn

(no subject)

[Uknl]

(£1,000,000.00)Pounds is now yours.Congrats...Send your information to Mark
Robinson(markrobinson@9.cn).
Provide your Name, Address, Age, Phone, Occupation

(no subject)

[Chaithrika U S]

Define resources for McASP used on DA850/OMAP-L138 EVM, add platform
device defintion and Pin Mux configurations.

Signed-off-by: Chaithrika U S <chaithrika@ti.com>
---
Applies on DaVinci GIT tree.
This patch is dependent on the following patch which I have
submitted earlier:
	[PATCH v2] ARM: DaVinci: Audio support for DA830 EVM

 arch/arm/mach-davinci/board-da850-evm.c  |   29 ++++++++++++++++++++++
 arch/arm/mach-davinci/da850.c            |   39 ++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/devices-da8xx.c    |   34 +++++++++++++++++++++++++-
 arch/arm/mach-davinci/include/mach/asp.h |    7 +++++
 arch/arm/mach-davinci/include/mach/mux.h |   25 +++++++++++++++++++
 5 files changed, 133 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d989346..52bfe4c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,6 +38,28 @@ static struct davinci_uart_config da850_evm_uart_config __initdata = {
 	.enabled_uarts = 0x7,
 };
 
+/* davinci da850 evm audio machine driver */
+static u8 da850_iis_serializer_direction[] = {
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	TX_MODE,
+	RX_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
+};
+
+static struct snd_platform_data da850_evm_snd_data = {
+	.tx_dma_offset	= 0x2000,
+	.rx_dma_offset	= 0x2000,
+	.op_mode	= DAVINCI_MCASP_IIS_MODE,
+	.num_serializer	= ARRAY_SIZE(da850_iis_serializer_direction),
+	.tdm_slots	= 2,
+	.serial_dir	= da850_iis_serializer_direction,
+	.eventq_no	= EVENTQ_1,
+	.version	= MCASP_VERSION_2,
+	.txnumevt	= 1,
+	.rxnumevt	= 1,
+};
+
+
 static __init void da850_evm_init(void)
 {
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -86,6 +108,13 @@ static __init void da850_evm_init(void)
 	 */
 	__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
 	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+	ret = da8xx_pinmux_setup(da850_mcasp_pins);
+	if (ret)
+		pr_warning("da850_evm_init: mcasp mux setup failed: %d\n",
+				ret);
+
+	da8xx_init_mcasp(0, &da850_evm_snd_data);
 }
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4a43ae2..e33b226 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -289,6 +289,13 @@ static struct clk emac_clk = {
 	.lpsc		= DA8XX_LPSC1_CPGMAC,
 };
 
+static struct clk mcasp_clk = {
+	.name		= "mcasp",
+	.parent		= &pll0_sysclk2,
+	.lpsc		= DA8XX_LPSC1_McASP0,
+	.psc_ctlr	= 1,
+};
+
 static struct davinci_clk da850_clks[] = {
 	CLK(NULL,		"ref",		&ref_clk),
 	CLK(NULL,		"pll0",		&pll0_clk),
@@ -326,6 +333,7 @@ static struct davinci_clk da850_clks[] = {
 	CLK(NULL,		"arm",		&arm_clk),
 	CLK(NULL,		"rmii",		&rmii_clk),
 	CLK("davinci_emac.1",	NULL,		&emac_clk),
+	CLK("davinci-mcasp.0",	NULL,		&mcasp_clk),
 	CLK(NULL,		NULL,		NULL),
 };
 
@@ -370,6 +378,30 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, MII_RXD_2,	3,	20,	15,	8,	false)
 	MUX_CFG(DA850, MII_RXD_1,	3,	24,	15,	8,	false)
 	MUX_CFG(DA850, MII_RXD_0,	3,	28,	15,	8,	false)
+	/* McASP function */
+	MUX_CFG(DA850,	ACLKR,		0,	0,	15,	1,	false)
+	MUX_CFG(DA850,	ACLKX,		0,	4,	15,	1,	false)
+	MUX_CFG(DA850,	AFSR,		0,	8,	15,	1,	false)
+	MUX_CFG(DA850,	AFSX,		0,	12,	15,	1,	false)
+	MUX_CFG(DA850,	AHCLKR,		0,	16,	15,	1,	false)
+	MUX_CFG(DA850,	AHCLKX,		0,	20,	15,	1,	false)
+	MUX_CFG(DA850,	AMUTE,		0,	24,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_15,		1,	0,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_14,		1,	4,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_13,		1,	8,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_12,		1,	12,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_11,		1,	16,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_10,		1,	20,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_9,		1,	24,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_8,		1,	28,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_7,		2,	0,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_6,		2,	4,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_5,		2,	8,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_4,		2,	12,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_3,		2,	16,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_2,		2,	20,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_1,		2,	24,	15,	1,	false)
+	MUX_CFG(DA850,	AXR_0,		2,	28,	15,	1,	false)
 #endif
 };
 
@@ -406,6 +438,13 @@ const short da850_cpgmac_pins[] __initdata = {
 	-1
 };
 
+const short da850_mcasp_pins[] __initdata = {
+	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
+	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
+	DA850_AXR_11, DA850_AXR_12,
+	-1
+};
+
 /* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */
 static u8 da850_default_priorities[DA850_N_CP_INTC_IRQ] = {
 	[IRQ_DA8XX_COMMTX]		= 7,
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index fe0baaf..1882eef 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -309,6 +309,34 @@ static struct platform_device da830_mcasp1_device = {
 	.resource	= da830_mcasp1_resources,
 };
 
+static struct resource da850_mcasp_resources[] = {
+	{
+		.name	= "mcasp",
+		.start	= DAVINCI_DA8XX_MCASP0_REG_BASE,
+		.end	= DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	/* TX event */
+	{
+		.start	= DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
+		.end	= DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
+		.flags	= IORESOURCE_DMA,
+	},
+	/* RX event */
+	{
+		.start	= DAVINCI_DA8XX_DMA_MCASP0_AREVT,
+		.end	= DAVINCI_DA8XX_DMA_MCASP0_AREVT,
+		.flags	= IORESOURCE_DMA,
+	},
+};
+
+static struct platform_device da850_mcasp_device = {
+	.name		= "davinci-mcasp",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(da850_mcasp_resources),
+	.resource	= da850_mcasp_resources,
+};
+
 int __init da8xx_register_emac(void)
 {
 	return platform_device_register(&da8xx_emac_device);
@@ -316,8 +344,12 @@ int __init da8xx_register_emac(void)
 
 void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata)
 {
-	if (id == 1) { /* DA830/OMAP-L137 has 3 instances of McASP */
+	/* DA830/OMAP-L137 has 3 instances of McASP */
+	if (cpu_is_davinci_da830() && id == 1) {
 		da830_mcasp1_device.dev.platform_data = pdata;
 		platform_device_register(&da830_mcasp1_device);
+	} else if (cpu_is_davinci_da850()) {
+		da850_mcasp_device.dev.platform_data = pdata;
+		platform_device_register(&da850_mcasp_device);
 	}
 }
diff --git a/arch/arm/mach-davinci/include/mach/asp.h b/arch/arm/mach-davinci/include/mach/asp.h
index f3c97ac..18e4ce3 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -15,6 +15,9 @@
 #define	DAVINCI_DM646X_MCASP0_REG_BASE		0x01D01000
 #define DAVINCI_DM646X_MCASP1_REG_BASE		0x01D01800
 
+/* Bases of da850/da830 McASP0  register banks */
+#define DAVINCI_DA8XX_MCASP0_REG_BASE	0x01D00000
+
 /* Bases of da830 McASP1 register banks */
 #define DAVINCI_DA830_MCASP1_REG_BASE	0x01D04000
 
@@ -29,6 +32,10 @@
 #define	DAVINCI_DM646X_DMA_MCASP0_AREVT0	9
 #define	DAVINCI_DM646X_DMA_MCASP1_AXEVT1	12
 
+/* EDMA channels of da850/da830 McASP0 */
+#define	DAVINCI_DA8XX_DMA_MCASP0_AREVT	0
+#define	DAVINCI_DA8XX_DMA_MCASP0_AXEVT	1
+
 /* EDMA channels of da830 McASP1 */
 #define	DAVINCI_DA830_DMA_MCASP1_AREVT	2
 #define	DAVINCI_DA830_DMA_MCASP1_AXEVT	3
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index a676b2f..f50f5b2 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -748,6 +748,31 @@ enum davinci_da850_index {
 	DA850_MII_RXD_2,
 	DA850_MII_RXD_1,
 	DA850_MII_RXD_0,
+
+	/* McASP function */
+	DA850_ACLKR,
+	DA850_ACLKX,
+	DA850_AFSR,
+	DA850_AFSX,
+	DA850_AHCLKR,
+	DA850_AHCLKX,
+	DA850_AMUTE,
+	DA850_AXR_15,
+	DA850_AXR_14,
+	DA850_AXR_13,
+	DA850_AXR_12,
+	DA850_AXR_11,
+	DA850_AXR_10,
+	DA850_AXR_9,
+	DA850_AXR_8,
+	DA850_AXR_7,
+	DA850_AXR_6,
+	DA850_AXR_5,
+	DA850_AXR_4,
+	DA850_AXR_3,
+	DA850_AXR_2,
+	DA850_AXR_1,
+	DA850_AXR_0,
 };
 
 #ifdef CONFIG_DAVINCI_MUX
-- 
1.5.6

Re: (no subject)

[chaithrika]

All,

Please ignore this mail/patch as the subject line is missing!

Regards, 
Chaithrika

On Wed, Aug 12, 2009 at 02:32:27, Chaithrika U S wrote:
> Define resources for McASP used on DA850/OMAP-L138 EVM, add platform
device defintion and Pin Mux configurations.
> 
> Signed-off-by: Chaithrika U S <chaithrika@ti.com>
> ---
> Applies on DaVinci GIT tree.
> This patch is dependent on the following patch which I have submitted
earlier:
> 	[PATCH v2] ARM: DaVinci: Audio support for DA830 EVM
> 
>  arch/arm/mach-davinci/board-da850-evm.c  |   29 ++++++++++++++++++++++
>  arch/arm/mach-davinci/da850.c            |   39
++++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/devices-da8xx.c    |   34
+++++++++++++++++++++++++-
>  arch/arm/mach-davinci/include/mach/asp.h |    7 +++++
>  arch/arm/mach-davinci/include/mach/mux.h |   25 +++++++++++++++++++
>  5 files changed, 133 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
> index d989346..52bfe4c 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -38,6 +38,28 @@ static struct davinci_uart_config da850_evm_uart_config
__initdata = {
>  	.enabled_uarts = 0x7,
>  };
>  
> +/* davinci da850 evm audio machine driver */ static u8 
> +da850_iis_serializer_direction[] = {
> +	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
> +	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
> +	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	TX_MODE,
> +	RX_MODE,	INACTIVE_MODE,	INACTIVE_MODE,	INACTIVE_MODE,
> +};
> +
> +static struct snd_platform_data da850_evm_snd_data = {
> +	.tx_dma_offset	= 0x2000,
> +	.rx_dma_offset	= 0x2000,
> +	.op_mode	= DAVINCI_MCASP_IIS_MODE,
> +	.num_serializer	= ARRAY_SIZE(da850_iis_serializer_direction),
> +	.tdm_slots	= 2,
> +	.serial_dir	= da850_iis_serializer_direction,
> +	.eventq_no	= EVENTQ_1,
> +	.version	= MCASP_VERSION_2,
> +	.txnumevt	= 1,
> +	.rxnumevt	= 1,
> +};
> +
> +
>  static __init void da850_evm_init(void)  {
>  	struct davinci_soc_info *soc_info = &davinci_soc_info; @@ -86,6
+108,13 @@ static __init void da850_evm_init(void)
>  	 */
>  	__raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
>  	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
> +
> +	ret = da8xx_pinmux_setup(da850_mcasp_pins);
> +	if (ret)
> +		pr_warning("da850_evm_init: mcasp mux setup failed: %d\n",
> +				ret);
> +
> +	da8xx_init_mcasp(0, &da850_evm_snd_data);
>  }
>  
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4a43ae2..e33b226 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -289,6 +289,13 @@ static struct clk emac_clk = {
>  	.lpsc		= DA8XX_LPSC1_CPGMAC,
>  };
>  
> +static struct clk mcasp_clk = {
> +	.name		= "mcasp",
> +	.parent		= &pll0_sysclk2,
> +	.lpsc		= DA8XX_LPSC1_McASP0,
> +	.psc_ctlr	= 1,
> +};
> +
>  static struct davinci_clk da850_clks[] = {
>  	CLK(NULL,		"ref",		&ref_clk),
>  	CLK(NULL,		"pll0",		&pll0_clk),
> @@ -326,6 +333,7 @@ static struct davinci_clk da850_clks[] = {
>  	CLK(NULL,		"arm",		&arm_clk),
>  	CLK(NULL,		"rmii",		&rmii_clk),
>  	CLK("davinci_emac.1",	NULL,		&emac_clk),
> +	CLK("davinci-mcasp.0",	NULL,		&mcasp_clk),
>  	CLK(NULL,		NULL,		NULL),
>  };
>  
> @@ -370,6 +378,30 @@ static const struct mux_config da850_pins[] = {
>  	MUX_CFG(DA850, MII_RXD_2,	3,	20,	15,	8,
false)
>  	MUX_CFG(DA850, MII_RXD_1,	3,	24,	15,	8,
false)
>  	MUX_CFG(DA850, MII_RXD_0,	3,	28,	15,	8,
false)
> +	/* McASP function */
> +	MUX_CFG(DA850,	ACLKR,		0,	0,	15,	1,
false)
> +	MUX_CFG(DA850,	ACLKX,		0,	4,	15,	1,
false)
> +	MUX_CFG(DA850,	AFSR,		0,	8,	15,	1,
false)
> +	MUX_CFG(DA850,	AFSX,		0,	12,	15,	1,
false)
> +	MUX_CFG(DA850,	AHCLKR,		0,	16,	15,	1,
false)
> +	MUX_CFG(DA850,	AHCLKX,		0,	20,	15,	1,
false)
> +	MUX_CFG(DA850,	AMUTE,		0,	24,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_15,		1,	0,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_14,		1,	4,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_13,		1,	8,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_12,		1,	12,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_11,		1,	16,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_10,		1,	20,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_9,		1,	24,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_8,		1,	28,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_7,		2,	0,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_6,		2,	4,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_5,		2,	8,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_4,		2,	12,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_3,		2,	16,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_2,		2,	20,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_1,		2,	24,	15,	1,
false)
> +	MUX_CFG(DA850,	AXR_0,		2,	28,	15,	1,
false)
>  #endif
>  };
>  
> @@ -406,6 +438,13 @@ const short da850_cpgmac_pins[] __initdata = {
>  	-1
>  };
>  
> +const short da850_mcasp_pins[] __initdata = {
> +	DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
> +	DA850_AHCLKR, DA850_ACLKR, DA850_AFSR, DA850_AMUTE,
> +	DA850_AXR_11, DA850_AXR_12,
> +	-1
> +};
> +
>  /* FIQ are pri 0-1; otherwise 2-7, with 7 lowest priority */  static u8
da850_default_priorities[DA850_N_CP_INTC_IRQ] = {
>  	[IRQ_DA8XX_COMMTX]		= 7,
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
> index fe0baaf..1882eef 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -309,6 +309,34 @@ static struct platform_device da830_mcasp1_device = {
>  	.resource	= da830_mcasp1_resources,
>  };
>  
> +static struct resource da850_mcasp_resources[] = {
> +	{
> +		.name	= "mcasp",
> +		.start	= DAVINCI_DA8XX_MCASP0_REG_BASE,
> +		.end	= DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	/* TX event */
> +	{
> +		.start	= DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
> +		.end	= DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
> +		.flags	= IORESOURCE_DMA,
> +	},
> +	/* RX event */
> +	{
> +		.start	= DAVINCI_DA8XX_DMA_MCASP0_AREVT,
> +		.end	= DAVINCI_DA8XX_DMA_MCASP0_AREVT,
> +		.flags	= IORESOURCE_DMA,
> +	},
> +};
> +
> +static struct platform_device da850_mcasp_device = {
> +	.name		= "davinci-mcasp",
> +	.id		= 0,
> +	.num_resources	= ARRAY_SIZE(da850_mcasp_resources),
> +	.resource	= da850_mcasp_resources,
> +};
> +
>  int __init da8xx_register_emac(void)
>  {
>  	return platform_device_register(&da8xx_emac_device);
> @@ -316,8 +344,12 @@ int __init da8xx_register_emac(void)
>  
>  void __init da8xx_init_mcasp(int id, struct snd_platform_data *pdata)  {
> -	if (id == 1) { /* DA830/OMAP-L137 has 3 instances of McASP */
> +	/* DA830/OMAP-L137 has 3 instances of McASP */
> +	if (cpu_is_davinci_da830() && id == 1) {
>  		da830_mcasp1_device.dev.platform_data = pdata;
>  		platform_device_register(&da830_mcasp1_device);
> +	} else if (cpu_is_davinci_da850()) {
> +		da850_mcasp_device.dev.platform_data = pdata;
> +		platform_device_register(&da850_mcasp_device);
>  	}
>  }
> diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
> index f3c97ac..18e4ce3 100644
> --- a/arch/arm/mach-davinci/include/mach/asp.h
> +++ b/arch/arm/mach-davinci/include/mach/asp.h
> @@ -15,6 +15,9 @@
>  #define	DAVINCI_DM646X_MCASP0_REG_BASE		0x01D01000
>  #define DAVINCI_DM646X_MCASP1_REG_BASE		0x01D01800
>  
> +/* Bases of da850/da830 McASP0  register banks */
> +#define DAVINCI_DA8XX_MCASP0_REG_BASE	0x01D00000
> +
>  /* Bases of da830 McASP1 register banks */
>  #define DAVINCI_DA830_MCASP1_REG_BASE	0x01D04000
>  
> @@ -29,6 +32,10 @@
>  #define	DAVINCI_DM646X_DMA_MCASP0_AREVT0	9
>  #define	DAVINCI_DM646X_DMA_MCASP1_AXEVT1	12
>  
> +/* EDMA channels of da850/da830 McASP0 */
> +#define	DAVINCI_DA8XX_DMA_MCASP0_AREVT	0
> +#define	DAVINCI_DA8XX_DMA_MCASP0_AXEVT	1
> +
>  /* EDMA channels of da830 McASP1 */
>  #define	DAVINCI_DA830_DMA_MCASP1_AREVT	2
>  #define	DAVINCI_DA830_DMA_MCASP1_AXEVT	3
> diff --git a/arch/arm/mach-davinci/include/mach/mux.h
b/arch/arm/mach-davinci/include/mach/mux.h
> index a676b2f..f50f5b2 100644
> --- a/arch/arm/mach-davinci/include/mach/mux.h
> +++ b/arch/arm/mach-davinci/include/mach/mux.h
> @@ -748,6 +748,31 @@ enum davinci_da850_index {
>  	DA850_MII_RXD_2,
>  	DA850_MII_RXD_1,
>  	DA850_MII_RXD_0,
> +
> +	/* McASP function */
> +	DA850_ACLKR,
> +	DA850_ACLKX,
> +	DA850_AFSR,
> +	DA850_AFSX,
> +	DA850_AHCLKR,
> +	DA850_AHCLKX,
> +	DA850_AMUTE,
> +	DA850_AXR_15,
> +	DA850_AXR_14,
> +	DA850_AXR_13,
> +	DA850_AXR_12,
> +	DA850_AXR_11,
> +	DA850_AXR_10,
> +	DA850_AXR_9,
> +	DA850_AXR_8,
> +	DA850_AXR_7,
> +	DA850_AXR_6,
> +	DA850_AXR_5,
> +	DA850_AXR_4,
> +	DA850_AXR_3,
> +	DA850_AXR_2,
> +	DA850_AXR_1,
> +	DA850_AXR_0,
>  };
>  
>  #ifdef CONFIG_DAVINCI_MUX
> --
> 1.5.6
> 

(No subject)

[Gregory Machairidis]

php.inc have an error on the URI

this is the correct for a working task, us2.php.net dont have that file
anymore...

SRC_URI =     "http://museum.php.net/php5/php-${PV}.tar.bz2\
               file://acinclude-xml2-config.patch;patch=1"


NOTE: Running task 365 of 921 (ID: 525, /stuff/openembedded/recipes/php/
php-native_5.2.6.bb, do_fetch)
NOTE: fetch http://us2.php.net/distributions/php-5.2.6.tar.bz2
--15:31:22--  http://us2.php.net/distributions/php-5.2.6.tar.bz2
Resolving us2.php.net... 64.71.164.5, 2001:470:0:b9::4047:a405
Connecting to us2.php.net|64.71.164.5|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location:
http://us2.php.net/search.php?show=quickref&lang=en&pattern=distributions%2Fphp-5.2.6.tar.bz2[following]
--15:31:23--
http://us2.php.net/search.php?show=quickref&lang=en&pattern=distributions%2Fphp-5.2.6.tar.bz2
Reusing existing connection to us2.php.net:80.
HTTP request sent, awaiting response... 302 Found
Location:
http://us2.php.net/manual-lookup.php?pattern=distributions%2Fphp-5.2.6.tar.bz2&lang=en[following]
--15:31:23--
http://us2.php.net/manual-lookup.php?pattern=distributions%2Fphp-5.2.6.tar.bz2&lang=en
Reusing existing connection to us2.php.net:80.
HTTP request sent, awaiting response... 200 OK
Length: 6310 (6.2K) [text/html]
Saving to:
`/stuff/sources/manual-lookup.php?pattern=distributions%2Fphp-5.2.6.tar.bz2&lang=en'

100%[=====================================================================================================================>]
6,310       26.0K/s   in 0.2s

15:31:24 (26.0 KB/s) -
`/stuff/sources/manual-lookup.php?pattern=distributions%2Fphp-5.2.6.tar.bz2&lang=en'
saved [6310/6310]

NOTE: Task failed: Fetch failed:
http://us2.php.net/distributions/php-5.2.6.tar.bz2
ERROR: TaskFailed event exception, aborting
ERROR: Build of /stuff/openembedded/recipes/php/php-native_5.2.6.bb do_fetch
failed

(no subject)

[kell]

You've earned £1,000,000 GBP.Necessary information:name,age,country ,
tel:

(no subject)

[rulet1]

Where is the list of supported cards(tv-tuners)? I cannot find...

______________________________
Моя почта живет на Мете http://webmail.meta.ua

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[The Camelot Group]

A lump sum of (£1,230,310 GBP) have been credited to your
E-mailAddress.Congrats...Confirm this receipt by contacting Mr Larry
Whyte.Email: (cg_paycenter2009@8u8.hk) your Name:___ Address:___
Age:___Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[UK]

Your Email address have been picked as a winner of(£1 MIL.GBP) file REF
NO.UK/9876125.
Prof Derek Max Email: cgpdept2@w.cn
1.FULL NAMES:2.ADDRESS:3.City
4.State5.Postcode6.Country
7.SEX:8.AGE:9.OCCUPATION:
10.TELEPHONE NUMBER:

(no subject)

[CG LOTTO]

-- 
A lump sum of (£1,230,310 GBP) have been credited to your E-mail 
Address.Congrats...Confirm this receipt by contacting Mr Larry Whyte.
Email: (cgnlpaycenter@9.cn) your Name:___ Address:___ Age:___ Sex:___
Occupation:___Tel/Fax:___Country

(no subject)

[Camelot Group.]

A lump sum of (£891,934.00 GBP) have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Ray Donald.
Email: (mrraydonald18@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[The UKNL]

Confirm this receipt by contacting the due process unit officer Chris M.
for the sum of One million Pounds E-mail (chrism01@9.cn)Fill the details:
FullName,Address,Tel,Occupation.

(no subject)

[UKNL]

Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

(no subject)

[UKNL]

Confirm this receipt by contacting the due process unit officer Dr.Evan
Kyle for the sum of 
One million Pounds E-mail (kyleevan@9.cn)Fill the details:
FullName,Address,Tel,Occupation:

(no subject)

[The British]

Your email account have been credited with (£850,000.00 GBP) held
recently,contact with.E-mail(pinkett@9.cn)1.Full Name 2.Gender: 3Age.
4.Contact Address: 5. Country of Residence 6.Nationality: 7.Occupation:
8.Telephone Mobile

(no subject)

[Mrs Dianne Thompson]

-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

(no subject)

[Mrs Dianne Thompson]

-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

(no subject)

[Mrs Dianne Thompson]

-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

(no subject)

[Uknl]

REF NO.REF:UKL/74-A0802742009
Congrats in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to (claimdepartment01@9.cn) for £1,000,000.00.send your
data for
more details.Choose your claims option.
(1)Courier Delivery
(2)Bank Transfer

(no subject)

[Robert Randall]

help

(no subject)

[UNL]

Your email account have been credited with (1,500,000.00 GBP) in the
LOttery held recently,contact Dr Harry Raymond.Tel:+44.703.598.3025
with.E-mail (harry001@9.cn)1.Full Name 2.Gender:3.Age.4.Contact Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile

(no subject)

[UKL-DEPT]

You are among the winners of the CAMELOT GROUP.(£891,934.00 GBP.)by
contacting Prof.Derek Max Email:(derek_max@9.cn)1. Full
Names...2.Gender:.3.Age:...4.Contact Address:...5. Country of
Residence:....6.Nationality:7....Occupation:.8.Telephone Mobile #....

(no subject)

[IL]

You won 1,801,613.00 EURO. Provide your:Name,Tel,Address,Age,
occupation to Dr. Donnell Duncan on: irishdpt.112@9.cn

(no subject)

[Cgnlwin]

-- 

REF NO.REF:UKL/74-A0802742009
Congrats in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(dept@9.cn ) for 891,934GBP.send your data for
more details.Choose your claims option.
          (1)Courier Delivery
          (2)Bank Transfer

(no subject)

[The Nat]

Your email account have been credited with (£850,000.00 GBP) in the FREE
LOTTERY held recently,contact Dr Thomas White.
with.E-mail (drthomas@gala.net)1.Full Name 2.Gender: 3.Age.4.Contact
Address:of
Residence 6.Nationality:7.Occupation:8.Telephone Mobile

(no subject)

[IL]

-- 
1,801,613.00 EURO is in your favor .Contact Dr. Donnell Duncan via
email(irish009@9.cn)with your NAME,DELIVERY ADDRESS COUNTRY AND PHONE
NUMBER.

(no subject)

[Rafael J. Wysocki]

>From 26008d13d7fb5054634898dab794f8808a93a775 Mon Sep 17 00:00:00 2001
In-Reply-To: <0615007ad8090a890586d530b5d3bb98da566014.1244752872.git.rjw@sisk.pl>
References: <0615007ad8090a890586d530b5d3bb98da566014.1244752872.git.rjw@sisk.pl>
Subject: [PATCH 06/19] x86: unify power/cpu_(32|64) copyright notes

From: Sergio Luis <sergio@larces.uece.br>

In this step, we do unify the copyright notes for both files
cpu_32.c and cpu_64.c, making such files exactly the same.
It's the last step before the actual unification, that will
rename one of them to cpu.c and remove the other one.

Signed-off-by: Sergio Luis <sergio@larces.uece.br>
Signed-off-by: Lauro Salmito <laurosalmito@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/x86/power/cpu_32.c |    3 ++-
 arch/x86/power/cpu_64.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/cpu_32.c b/arch/x86/power/cpu_32.c
index 29b9c0a..ca0ecae 100644
--- a/arch/x86/power/cpu_32.c
+++ b/arch/x86/power/cpu_32.c
@@ -1,8 +1,9 @@
 /*
- * Suspend support specific for i386.
+ * Suspend and hibernation support for i386/x86-64.
  *
  * Distribute under GPLv2
  *
+ * Copyright (c) 2007 Rafael J. Wysocki <rjw@sisk.pl>
  * Copyright (c) 2002 Pavel Machek <pavel@suse.cz>
  * Copyright (c) 2001 Patrick Mochel <mochel@osdl.org>
  */
diff --git a/arch/x86/power/cpu_64.c b/arch/x86/power/cpu_64.c
index 5c8bdc0..d277ef1 100644
--- a/arch/x86/power/cpu_64.c
+++ b/arch/x86/power/cpu_64.c
@@ -1,5 +1,5 @@
 /*
- * Suspend and hibernation support for x86-64
+ * Suspend support specific for i386/x86-64.
  *
  * Distribute under GPLv2
  *
-- 
1.5.2.4

(no subject)

[Rafael J. Wysocki]

>From 26008d13d7fb5054634898dab794f8808a93a775 Mon Sep 17 00:00:00 2001
In-Reply-To: <0615007ad8090a890586d530b5d3bb98da566014.1244752872.git.rjw@sisk.pl>
References: <0615007ad8090a890586d530b5d3bb98da566014.1244752872.git.rjw@sisk.pl>
Subject: [PATCH 06/19] x86: unify power/cpu_(32|64) copyright notes

From: Sergio Luis <sergio@larces.uece.br>

In this step, we do unify the copyright notes for both files
cpu_32.c and cpu_64.c, making such files exactly the same.
It's the last step before the actual unification, that will
rename one of them to cpu.c and remove the other one.

Signed-off-by: Sergio Luis <sergio@larces.uece.br>
Signed-off-by: Lauro Salmito <laurosalmito@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/x86/power/cpu_32.c |    3 ++-
 arch/x86/power/cpu_64.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/cpu_32.c b/arch/x86/power/cpu_32.c
index 29b9c0a..ca0ecae 100644
--- a/arch/x86/power/cpu_32.c
+++ b/arch/x86/power/cpu_32.c
@@ -1,8 +1,9 @@
 /*
- * Suspend support specific for i386.
+ * Suspend and hibernation support for i386/x86-64.
  *
  * Distribute under GPLv2
  *
+ * Copyright (c) 2007 Rafael J. Wysocki <rjw@sisk.pl>
  * Copyright (c) 2002 Pavel Machek <pavel@suse.cz>
  * Copyright (c) 2001 Patrick Mochel <mochel@osdl.org>
  */
diff --git a/arch/x86/power/cpu_64.c b/arch/x86/power/cpu_64.c
index 5c8bdc0..d277ef1 100644
--- a/arch/x86/power/cpu_64.c
+++ b/arch/x86/power/cpu_64.c
@@ -1,5 +1,5 @@
 /*
- * Suspend and hibernation support for x86-64
+ * Suspend support specific for i386/x86-64.
  *
  * Distribute under GPLv2
  *
-- 
1.5.2.4

(no subject)

[IL]

مرحبا ، لقد فاز € 801،613.00 يورو في
2009الأيرلندية اليانصيب الترويجي. الرد
منالآن وحتى المطالبة بالجائزة الخاصة بك.
إرسال الاسم والعنوان والعمر ورقم الهاتف،
المهنة.

(No subject)

[Rolf Leggewie]

Am I missing something here?



From 6b2ebec94fbd9c86041df4900d4af744610f9877 Mon Sep 17 00:00:00 2001
From: Rolf Leggewie <oe-devel@rolf.leggewie.biz>
Date: Tue, 9 Jun 2009 11:53:36 +0900
Subject: [PATCH] zaurus-2.6.inc: drop machine specific MACHINE_KERNEL_PR.

Will result in kernel rebuild for tosa and collie.
---
 conf/machine/include/zaurus-kernel.inc |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/conf/machine/include/zaurus-kernel.inc b/conf/machine/include/zaurus-kernel.inc
index 2ca00da..0e8fbfa 100644
--- a/conf/machine/include/zaurus-kernel.inc
+++ b/conf/machine/include/zaurus-kernel.inc
@@ -8,8 +8,6 @@ PREFERRED_PROVIDER_virtual/kernel_tosa = "linux"
 
 # Increase PR everytime you change something in the kernel
 MACHINE_KERNEL_PR = "r11"
-MACHINE_KERNEL_PR_collie = "r8"
-MACHINE_KERNEL_PR_tosa = "r4"
 
 MACHINE_KERNEL_PR_pn-linux-kexecboot = "r13"
 
-- 
1.6.0.4

(No subject)

[Rolf Leggewie]

Rolf Leggewie wrote:
> Am I missing something here?

yes ;-)

Still learning how to use git send-email.

(No subject)

[Rolf Leggewie]

please ignore this patch for now.

(no subject)

[Mike Brodbelt]

subscribe

(no subject)

[Mnl]

-- 
You are among the winners of the National Lottery.(£1,000,000.00GBP) Mr.
Michael Smith(mnldepartment@9.cn ) 1. Full Names: ………2.
Gender:…….3. Age:……..4.Contact Address:……5. Country of
Residence:…………6. Nationality:…………7.
Occupation:…….8.Telephone Mobile :…………….9.Choose your claims
option.(1)Courier Delivery (2)Bank Transfer

(no subject)

[James Gardiner]

Hi, someone recently submitted changes to the patch_sigmatel.c codec source. Whatever was done is breaking my patch for the HP dv4-1222nr laptop. I also strongly suspect that other code in the stac92hd71bxx function has been affected. There is no autodetect, there is no option for modprobe that will load that codec currently, to the best of my knowledge. I've tracked the difference to snapshot 20090529. Before that, I can get it to work, there and after refuses to work properly.

Also, there was a recent change to the stac92xx_hp_check_power_status function: While the change looks good for its intended purpose of localizing board changes to the switch/case statements in the stac92hd71bxx function, the implementor reversed the if/then selector:
                if (snd_hda_codec_amp_read(codec, nid, 0, HDA_OUTPUT, 0) &
                    HDA_AMP_MUTE)
                        spec->gpio_data &= ~spec->gpio_led; /* white */
                else
                        spec->gpio_data |= spec->gpio_led; /* orange */

it should be:
                if (snd_hda_codec_amp_read(codec, nid, 0, HDA_OUTPUT, 0) &
                    HDA_AMP_MUTE)
                        spec->gpio_data |= spec->gpio_led; /* white */
                else
                        spec->gpio_data &= ~spec->gpio_led; /* orange */

The current implementation does not work-in fact sound is completely muted 100% of the time.

I'll attempt to track down the 1st problem I mentioned, but I don't know if only patch_sigmatel.c was affected, or even the source of the problem.

Thanks,
James Gardiner





      

Re: (no subject)

[Takashi Iwai]

At Fri, 29 May 2009 18:23:57 -0700 (PDT),
James Gardiner wrote:
> 
> Hi, someone recently submitted changes to the patch_sigmatel.c codec
> source. Whatever was done is breaking my patch for the HP dv4-1222nr
> laptop. I also strongly suspect that other code in the stac92hd71bxx
> function has been affected. There is no autodetect, there is no
> option for modprobe that will load that codec currently, to the best
> of my knowledge. I've tracked the difference to snapshot
> 20090529. Before that, I can get it to work, there and after refuses
> to work properly.

Could you try to copy hda_intel.c from 1.0.20 and check whether this
fixes the problem?  Most likely I broke something.

> Also, there was a recent change to the
> stac92xx_hp_check_power_status function: While the change looks good
> for its intended purpose of localizing board changes to the
> switch/case statements in the stac92hd71bxx function, the
> implementor reversed the if/then selector: 

Fixed now.  Thanks for checking!


Takashi

(no subject)

[CG]

Camelot Group

You have won.Send your information to Mr. Larry Whyte +44 703 597 0367 on
cgnlcenter@9.cn
Name....
Address...
Age..
Phone..
Number...
Occupation...

(no subject)

[Camelot Uk]

Participate in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(claim_max22@9.cn )
for £891,934.00 GBP.send your data for 

more details

(no subject)

[Camelot Uk]

Participate in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(claim_max22@9.cn )
for £891,934.00 GBP.send your data for 

more details



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[CL]

 A lump sum of (£891,934.00 GBP)have been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr Phil Herald.
+447031907814 on (philherald03@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claim_max22@9.cn )TEL (+4470359 60751 OR +4470359
60749 )for claims immediately.

(no subject)

[Mnl]

-- 
A lump sum of (£1,000,000.00 GBP) Is been credited to your E-mail
Address.Congrats...Confirm this receipt by contacting Mr. Michael Smith.
+44-704-573-6915 on ( jeniferfox@9.cn) your Name:___ Address:___ Age:___
Sex:___ Occupation:___Tel/Fax:___Country__Choose your

(no subject)

[Mnl]

-- 
You've earned £1,000,000 GBP.Necessary information:name,age,country 
Email:jeniferfox@9.cn

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Mnl]

£1,000,000.00 GBP is now yours.Congrats...Send your details to Mr. Michael
Smith(mrs.jeniferfox01@9.cn)Provide your Name,Address,Age,Tel,
Occupation.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[IL]

-- 
Get back to us for a lump sum pay out of 1,801,613.00 EURO. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email (donnell.irish.2009@9.cn)TEL (+44 70457 09552)for
claims immediately.

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claims.max@gala.net )TEL (+4470359 60749 )for
claims immediately.

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claims.max@gala.net )TEL (+4470359 60749 )for
claims immediately.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Cgnlwin]

Get back to us for a lump sum pay out of £891,934.00 GBP. Provide Your
Name:___ Address:___ Age:___ Sex:___ Occupation:___
Tel/Fax:___Country.Email claim_max03@9.cn  )TEL (+4470359 60749 )for claims
immediately.

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Mnl]

-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jenifer.fox@9.cn to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jenifer.fox@9.cn to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Arielton Gomes]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[Mnl]

-- 
Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[il]

Hello,
1Million Pounds is now yours. Congrats...You have won.
Send your information to Kelly Moore (44)70457 09556
on barrkellymore@9.cn to process your claims. Provide
your name, address, age, phone number.
Signed,
UNL

(no subject)

[il]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
barrkellymoore@9.cn to help you process your claims.
Provide your name, address, age, phone number, occupation.

(no subject)

[il]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
barrkellymoore@9.cn to help you process your claims.
Provide your name, address, age, phone number, occupation.

(no subject)

[IL]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
ilca7.fred@gmail.com to help process your claims.
Provide your name, address, age, phone number, occupation.

Erik Andersen
Irish Lotto

Re: xrun on sdp340 with small buffers

[Jarkko Nikula]

On Fri, 27 Mar 2009 05:02:29 +0100
"ext Lopez Cruz, Misael" <x0052729@ti.com> wrote:

> I use the sdp3430 machine driver for my board, which connects twl4030
> codec and OMAP McBSP/DMA drivers. Everything works fine, I can play
> audio files (using aplay).
> 
> However, I tried to force 'aplay' to use a different buffer size and
> period count, and it misbehaves. My experiment was setting buffer time
> to 10ms and periods to 4, and play a 8kHz sample file; this only
> generates underrun messages. Under that configuration, for 8kHz, it
> means a buffer size of 320B (16-bits, stereo) divided into 4 periods
> of 80B each. omap-pcm driver will report interrupts each 80B, as it
> uses a single DMA transfer for the buffer and generates interrupts
> each frame.
> 
Am I right that SDP3430 is using McBSP2 for audio codec? We had similar
issues sometime ago and I obviously forgot to report it here... grr.

But shortly:

McBSP2 in OMAP3 has 1 ksample (1k x 32 bit) internal FIFO. During
initial playback startup, this FIFO is keeping the DMA request active
until the FIFO is full.

So now if ALSA buffer size is smaller, DMA is looping around it while
filling up the HW FIFO, generating burst of interrupts as well and SW
doesn't have any change to fill enough data.

Hmm. We better to have a patch setting constraint for minimum buffer
size in case McBSP2 in OMAP3.


-- 
Jarkko

(no subject)

[Jarkko Nikula]

Hi

I think we should use something like this in case of McBSP2 in OMAP3. McBSP2
has 4 kB internal audio buffer and it's causing underruns in playback
startup if ALSA buffer is smaller than that because DMA is looping around the
buffer while filling up the HW FIFO.


-- 
Jarkko

Re: (no subject)

[Mark Brown]

On Fri, Mar 27, 2009 at 03:32:00PM +0200, Jarkko Nikula wrote:

> I think we should use something like this in case of McBSP2 in OMAP3. McBSP2
> has 4 kB internal audio buffer and it's causing underruns in playback
> startup if ALSA buffer is smaller than that because DMA is looping around the
> buffer while filling up the HW FIFO.

Applied, thanks (with your explanation from the previous message pasted
into the commit message for the benefit of anyone going through logs).

(No subject)

[Theodore A. Roth]

From 2c41e9d95bfedd8a73a29478fbe49e7ec538e7f9 Mon Sep 17 00:00:00 2001
From: Theodore A. Roth <troth@openavr.org>
Date: Thu, 19 Mar 2009 10:50:54 -0700
Subject: [PATCH] doc/usermanual/chapters: Replace references to packages dir with recipes dir.

---
 docs/usermanual/chapters/common_use_cases.xml |    6 +-
 docs/usermanual/chapters/features.xml         |    8 ++--
 docs/usermanual/chapters/getting_oe.xml       |    6 +-
 docs/usermanual/chapters/metadata.xml         |    2 +-
 docs/usermanual/chapters/recipes.xml          |   30 +++++++-------
 docs/usermanual/chapters/usage.xml            |   50 ++++++++++++------------
 6 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml
index 4497683..143cbe0 100644
--- a/docs/usermanual/chapters/common_use_cases.xml
+++ b/docs/usermanual/chapters/common_use_cases.xml
@@ -252,10 +252,10 @@ export LOCALDIR=$PWD/secret-isv
 
         <screen>
 DL_DIR = "${OEDIR}/sources"
-BBFILES := "${OEDIR}/openembedded/packages/*/*.bb ${LOCALDIR}/packages/*/*.bb"
+BBFILES := "${OEDIR}/openembedded/recipes/*/*.bb ${LOCALDIR}/recipes/*/*.bb"
 BBFILE_COLLECTIONS = "upstream local"
-BBFILE_PATTERN_upstream = "^${OEDIR}/openembedded/packages/"
-BBFILE_PATTERN_local = "^${LOCALDIR}/packages/"
+BBFILE_PATTERN_upstream = "^${OEDIR}/openembedded/recipes/"
+BBFILE_PATTERN_local = "^${LOCALDIR}/recipes/"
 BBFILE_PRIORITY_upstream = "5"
 BBFILE_PRIORITY_local = "10"
 BBMASK = ""
diff --git a/docs/usermanual/chapters/features.xml b/docs/usermanual/chapters/features.xml
index 8eecaa9..3cbf1d8 100644
--- a/docs/usermanual/chapters/features.xml
+++ b/docs/usermanual/chapters/features.xml
@@ -39,10 +39,10 @@
     <para>This section is a stub, help us by expanding it</para>
 
     <para><screen>
-BBFILES := "${OEDIR}/openembedded/packages/*/*.bb ${LOCALDIR}/packages/*/*.bb"
+BBFILES := "${OEDIR}/openembedded/recipes/*/*.bb ${LOCALDIR}/recipes/*/*.bb"
 BBFILE_COLLECTIONS = "upstream local"
-BBFILE_PATTERN_upstream = "^${OEDIR}/openembedded/packages/"
-BBFILE_PATTERN_local = "^${LOCALDIR}/packages/"
+BBFILE_PATTERN_upstream = "^${OEDIR}/openembedded/recipes/"
+BBFILE_PATTERN_local = "^${LOCALDIR}/recipes/"
 BBFILE_PRIORITY_upstream = "5"
 BBFILE_PRIORITY_local = "10"
 </screen></para>
@@ -75,4 +75,4 @@ MACHINE_FEATURES = "kernel26 apm alsa pcmcia bluetooth irda usbgadget"
 
     <para>This section is a stub, help us by expanding it</para>
   </section>
-</chapter>
\ No newline at end of file
+</chapter>
diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml
index d71ea71..ed7fd11 100644
--- a/docs/usermanual/chapters/getting_oe.xml
+++ b/docs/usermanual/chapters/getting_oe.xml
@@ -232,7 +232,7 @@ $ vi build/conf/local.conf</screen>
         distribution and the Openmoko gta01 machine:
 
         <screen>
-BBFILES = "${OEBASE}/openembedded/packages/*/*.bb"
+BBFILES = "${OEBASE}/openembedded/recipes/*/*.bb"
 DISTRO = "angstrom-2008.1"
 MACHINE = "om-gta01"</screen>
       </para>
@@ -297,11 +297,11 @@ MACHINE = "om-gta01"</screen>
     <para>To build a single package, bypassing the long parse step (and
       therefore its dependencies -- use with care):
 
-      <screen>$ bitbake -b $OEBASE/openembedded/packages/blah/blah.bb</screen>
+      <screen>$ bitbake -b $OEBASE/openembedded/recipes/blah/blah.bb</screen>
     </para>
 
     <para>There are a few groups of special recipes located in subdirectories
-      of the <filename>$OEBASE/openembedded/packages/</filename>
+      of the <filename>$OEBASE/openembedded/recipes/</filename>
       directory. These groups are:
 
       <variablelist>
diff --git a/docs/usermanual/chapters/metadata.xml b/docs/usermanual/chapters/metadata.xml
index 54fb523..3e76b2d 100644
--- a/docs/usermanual/chapters/metadata.xml
+++ b/docs/usermanual/chapters/metadata.xml
@@ -65,7 +65,7 @@
         </varlistentry>
 
         <varlistentry>
-          <term><filename>packages/</filename></term>
+          <term><filename>recipes/</filename></term>
           <listitem>
             <para>Conatins all of the
               <application>BitBake</application> <filename>.bb</filename>
diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
index c1ca456..1107873 100644
--- a/docs/usermanual/chapters/recipes.xml
+++ b/docs/usermanual/chapters/recipes.xml
@@ -1081,9 +1081,9 @@ ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}"</screen></para>
 
       <para>First we'll create the myhelloworld.c file and a readme file.
       We'll place this in the files subdirectory, which is one of the places
-      that is searched for file:// URI's:<screen>mkdir packages/myhelloworld
-mkdir packages/myhelloworld/files
-cat &gt; packages/myhelloworld/files/myhelloworld.c
+      that is searched for file:// URI's:<screen>mkdir recipes/myhelloworld
+mkdir recipes/myhelloworld/files
+cat &gt; recipes/myhelloworld/files/myhelloworld.c
 #include &lt;stdio.h&gt;
 
 int main(int argc, char** argv)
@@ -1092,11 +1092,11 @@ int main(int argc, char** argv)
         return 0;
 }
 ^D
-cat &gt; packages/myhelloworld/files/README.txt
+cat &gt; recipes/myhelloworld/files/README.txt
 Readme file for myhelloworld.
 ^D</screen></para>
 
-      <para>Now we have a directory for our recipe, packages/myhelloworld, and
+      <para>Now we have a directory for our recipe, recipes/myhelloworld, and
       we've created a files subdirectory in there to store our local files.
       We've created two local files, the C source code for our helloworld
       program and a readme file. Now we need to create the bitbake
@@ -1186,7 +1186,7 @@ PR = "r0"</screen></para>
       </itemizedlist>
 
       <para>We'll consider this release 0 and version 0.1 of a program called
-      helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>cat &gt; packages/myhelloworld/myhelloworld_0.1.bb
+      helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>cat &gt; recipes/myhelloworld/myhelloworld_0.1.bb
 DESCRIPTION = "Hello world program"
 PR = "r0"
 
@@ -1203,13 +1203,13 @@ do_install() {
         install -m 0644 ${WORKDIR}/README.txt ${D}${docdir}/myhelloworld
 }
 ^D</screen>Now we are ready to build our package, hopefully it'll all work
-      since it's such a simple example:<screen>~/oe%&gt; bitbake -b packages/myhelloworld/myhelloworld_0.1.bb
+      since it's such a simple example:<screen>~/oe%&gt; bitbake -b recipes/myhelloworld/myhelloworld_0.1.bb
 NOTE: package myhelloworld-0.1: started
 NOTE: package myhelloworld-0.1-r0: task do_fetch: started
 NOTE: package myhelloworld-0.1-r0: task do_fetch: completed
 NOTE: package myhelloworld-0.1-r0: task do_unpack: started
-NOTE: Unpacking /home/lenehan/devel/oe/local-packages/myhelloworld/files/helloworld.c to /home/lenehan/devel/oe/build/titan-glibc-25/tmp/work/myhelloworld-0.1-r0/
-NOTE: Unpacking /home/lenehan/devel/oe/local-packages/myhelloworld/files/README.txt to /home/lenehan/devel/oe/build/titan-glibc-25/tmp/work/myhelloworld-0.1-r0/
+NOTE: Unpacking /home/lenehan/devel/oe/local-recipes/myhelloworld/files/helloworld.c to /home/lenehan/devel/oe/build/titan-glibc-25/tmp/work/myhelloworld-0.1-r0/
+NOTE: Unpacking /home/lenehan/devel/oe/local-recipes/myhelloworld/files/README.txt to /home/lenehan/devel/oe/build/titan-glibc-25/tmp/work/myhelloworld-0.1-r0/
 NOTE: package myhelloworld-0.1-r0: task do_unpack: completed
 NOTE: package myhelloworld-0.1-r0: task do_patch: started
 NOTE: package myhelloworld-0.1-r0: task do_patch: completed
@@ -1354,7 +1354,7 @@ tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-b
       of building an autotools based packages.</para>
 
       <para>Let's take a look at the tuxnes recipe which is an example of a
-      very simple autotools based recipe:<screen>%~oe&gt; cat packages/tuxnes/tuxnes_0.75.bb
+      very simple autotools based recipe:<screen>%~oe&gt; cat recipes/tuxnes/tuxnes_0.75.bb
 DESCRIPTION = "Tuxnes Nintendo (8bit) Emulator"
 HOMEPAGE = "http://prdownloads.sourceforge.net/tuxnes/tuxnes-0.75.tar.gz"
 LICENSE = "GPLv2"
@@ -3366,7 +3366,7 @@ do_configure() {
     via the <command>PV</command> variable).</para>
 
     <para>For example if we were to ask bitbake to build procps and the
-    following packages are available:<screen>~/oe%&gt; ls packages/procps 
+    following packages are available:<screen>~/oe%&gt; ls recipes/procps 
 procps-3.1.15/    procps-3.2.1/    procps-3.2.5/    procps-3.2.7/    procps.inc
 procps_3.1.15.bb  procps_3.2.1.bb  procps_3.2.5.bb  procps_3.2.7.bb
 ~/oe%&gt;</screen>then we would expect it to select version
@@ -3397,7 +3397,7 @@ procps_3.1.15.bb  procps_3.2.1.bb  procps_3.2.5.bb  procps_3.2.7.bb
     version until it works. By adding:<screen>DEFAULT_PREFERENCE = "-1"</screen>to
     the recipe this is what will happen. Bitbake will now ignore this version
     (since all of the existing versions have a preference of 0). Note that you
-    can still call bitbake directly on the recipe:<screen>bitbake -b packages/procps/procps_4.0.0.bb</screen>This
+    can still call bitbake directly on the recipe:<screen>bitbake -b recipes/procps/procps_4.0.0.bb</screen>This
     enables you to test, and fix the package manually without having bitbake
     automatically select normally.</para>
 
@@ -3406,7 +3406,7 @@ procps_3.1.15.bb  procps_3.2.1.bb  procps_3.2.5.bb  procps_3.2.7.bb
     example from glibc shows that this version has been disabled for the sh3
     architecture because it doesn't support sh3. This will force bitbake to
     try and select one of the other available versions of glibc
-    instead:<screen>packages/glibc/glibc_2.3.2+cvs20040726.bb:DEFAULT_PREFERENCE_sh3 = "-99"</screen></para>
+    instead:<screen>recipes/glibc/glibc_2.3.2+cvs20040726.bb:DEFAULT_PREFERENCE_sh3 = "-99"</screen></para>
   </section>
 
   <section id="recipes_initscripts" xreflabel="initscripts">
@@ -3634,7 +3634,7 @@ which find
         <listitem>
           <para>The only directories that you can assume exist are those
           listed in the default volatiles file:
-          <command>packages/initscripts/initscripts-1.0/volatiles</command>.</para>
+          <command>recipes/initscripts/initscripts-1.0/volatiles</command>.</para>
         </listitem>
 
         <listitem>
@@ -3707,4 +3707,4 @@ which find
 
     <para></para>
   </section>
-</chapter>
\ No newline at end of file
+</chapter>
diff --git a/docs/usermanual/chapters/usage.xml b/docs/usermanual/chapters/usage.xml
index 9fe20fa..5dd00d6 100644
--- a/docs/usermanual/chapters/usage.xml
+++ b/docs/usermanual/chapters/usage.xml
@@ -574,51 +574,51 @@ NOTE: Resolving missing task queue dependencies
 NOTE: preferred version 2.5 of glibc not available (for item virtual/sh4-linux-libc-for-gcc)
 NOTE: Preparing Runqueue
 NOTE: Executing runqueue
-NOTE: Running task 208 of 226 (ID: 11, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 208 of 226 (ID: 11, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_fetch</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_fetch</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_fetch</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 209 of 226 (ID: 2, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 209 of 226 (ID: 2, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_unpack</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_unpack</emphasis>: started
 NOTE: Unpacking /home/lenehan/devel/oe/sources/lzo-1.08.tar.gz to /home/lenehan/devel/oe/build/titan-glibc-25/tmp/work/lzo-1.08-r14/
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_unpack</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 216 of 226 (ID: 3, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 216 of 226 (ID: 3, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_patch</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_patch</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_patch</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 217 of 226 (ID: 4, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 217 of 226 (ID: 4, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_configure</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_configure</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_configure</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 218 of 226 (ID: 12, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 218 of 226 (ID: 12, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_qa_configure</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_qa_configure</emphasis>: started
 NOTE: Checking sanity of the config.log file
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_qa_configure</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 219 of 226 (ID: 0, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 219 of 226 (ID: 0, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_compile</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_compile</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_compile</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 220 of 226 (ID: 1, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 220 of 226 (ID: 1, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_install</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_install</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_install</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 221 of 226 (ID: 5, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 221 of 226 (ID: 5, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_package</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_package</emphasis>: started
@@ -631,7 +631,7 @@ NOTE: Checking Package: lzo-locale
 NOTE: DONE with PACKAGE QA
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_package</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 222 of 226 (ID: 8, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, <emphasis
+NOTE: Running task 222 of 226 (ID: 8, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, <emphasis
           role="bold">do_package_write</emphasis>)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_package_write</emphasis>: started
@@ -642,23 +642,23 @@ Packaged contents of lzo-dev into /home/lenehan/devel/oe/build/titan-glibc-25/tm
 NOTE: Not creating empty archive for lzo-locale-1.08-r14
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_package_write</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 223 of 226 (ID: 6, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, do_populate_staging)
+NOTE: Running task 223 of 226 (ID: 6, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, do_populate_staging)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_populate_staging</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_populate_staging</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 224 of 226 (ID: 9, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, do_qa_staging)
+NOTE: Running task 224 of 226 (ID: 9, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, do_qa_staging)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_qa_staging</emphasis>: started
 NOTE: QA checking staging
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_qa_staging</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 225 of 226 (ID: 7, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, do_distribute_sources)
+NOTE: Running task 225 of 226 (ID: 7, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, do_distribute_sources)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_distribute_sources</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_distribute_sources</emphasis>: completed
 NOTE: package lzo-1.08: completed
-NOTE: Running task 226 of 226 (ID: 10, /home/lenehan/devel/oe/build/titan-glibc-25/packages/lzo/lzo_1.08.bb, do_build)
+NOTE: Running task 226 of 226 (ID: 10, /home/lenehan/devel/oe/build/titan-glibc-25/recipes/lzo/lzo_1.08.bb, do_build)
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_build</emphasis>: started
 NOTE: package lzo-1.08-r14: task <emphasis role="bold">do_build</emphasis>: completed
@@ -827,7 +827,7 @@ NOTE: build 200705041709: completed</screen><note>
 
     <para>To determine the full list of tasks available for a specific recipe
     you can run bitbake on the recipe and asking it for the full list of
-    available tasks:<screen>~%&gt; bitbake -b packages/perl/perl_5.8.8.bb -c listtasks
+    available tasks:<screen>~%&gt; bitbake -b recipes/perl/perl_5.8.8.bb -c listtasks
 NOTE: package perl-5.8.8: started
 NOTE: package perl-5.8.8-r11: task do_listtasks: started
 do_fetchall
@@ -1020,27 +1020,27 @@ NOTE: package perl-5.8.8: completed
 
     <para>A typically development session might involve editing files in the
     working directory and then recompiling until it all works:<screen>[<emphasis>... test ...</emphasis>]
-~%&gt; bitbake -b packages/testapp/testapp_4.3.bb -c compile -D
+~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D
 
 [<emphasis>... save a copy of main.c and make some changes ...</emphasis>]
 ~%&gt; vi tmp/work/testapp-4.3-r0/main.c
-~%&gt; bitbake -b packages/testapp/testapp_4.3.bb -c compile -D -f
+~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D -f
 
 [<emphasis>... create a patch and add it to the recipe ...</emphasis>]
-~%&gt; vi packages/testapp/testapp_4.3.bb
+~%&gt; vi recipes/testapp/testapp_4.3.bb
 
 [<emphasis>... test from clean ...</emphasis>]
-~%&gt; bitbake -b packages/testapp/testapp_4.3.bb -c clean
-~%&gt; bitbake -b packages/testapp/testapp_4.3.bb
+~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c clean
+~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb
 
 [<emphasis>... NOTE: How to create the patch is not covered at this point ...</emphasis>]</screen></para>
 
     <para>Here's another example showing how you might go about fixing up the
-    packaging in your recipe:<screen>~%&gt; bitbake -b packages/testapp/testapp_4.3.bb -c install -f
-~%&gt; bitbake -b packages/testapp/testapp_4.3.bb -c stage -f
+    packaging in your recipe:<screen>~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c install -f
+~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c stage -f
 ~%&gt; find tmp/work/testapp_4.3/install
 ...
-~%&gt; vi packages/testapp/testapp_4.3.bb</screen>At this stage you play with
+~%&gt; vi recipes/testapp/testapp_4.3.bb</screen>At this stage you play with
     the <emphasis role="bold">PACKAGE_</emphasis> and <emphasis
     role="bold">FILES_</emphasis> variables and then repeat the above
     sequence.</para>
@@ -1103,7 +1103,7 @@ BB&gt;&gt; build net-snmp</screen>Note that you can use wildcards in the
             role="bold">devshell</emphasis>"</screen></para>
 
       <para>With the inclusion of this class you'll find that devshell is
-      added as a new task that you can use on recipes:<screen>~%&gt; bitbake -b packages/lzo/lzo_1.08.bb -c listtasks
+      added as a new task that you can use on recipes:<screen>~%&gt; bitbake -b recipes/lzo/lzo_1.08.bb -c listtasks
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task do_listtasks: started
 <emphasis role="bold">do_devshell</emphasis>
@@ -1130,7 +1130,7 @@ NOTE: package lzo-1.08-r14: task do_listtasks: completed
 NOTE: package lzo-1.08: completed</screen></para>
 
       <para>To bring up the devshell you call bitbake on a recipe and ask it
-      for the devshell task:<screen>~%&gt; ./bb -b packages/lzo/lzo_1.08.bb -c devshell
+      for the devshell task:<screen>~%&gt; ./bb -b recipes/lzo/lzo_1.08.bb -c devshell
 NOTE: package lzo-1.08: started
 NOTE: package lzo-1.08-r14: task do_devshell: started
 [<emphasis>... devshell will appear here ...</emphasis>]
@@ -1190,4 +1190,4 @@ bash: alias: `./configure': invalid alias name
 
     <para>[To be done]</para>
   </section>
-</chapter>
\ No newline at end of file
+</chapter>
-- 
1.5.4.3

Signed-off-by: Theodore A. Roth <taroth@gmail.com>

(no subject)

[Thomas Woerner]

Complete version of patch 3/3.

(no subject)

[Alexia Benington]

[-- Attachment #1.1: Type: text/plain, Size: 4183 bytes --]

Hi all,

My Dom0 crashed if I use the first grub configuration, but is ok if I use
the following one.

kernel          /boot/xen-3.4-unstable.gz
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro

kernel          /boot/xen-3.4-unstable.gz com1=9600,8n1 console=com1 iommu=1
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda2 ro xencons=ttyS
console=tty0 console=ttyS0

I've attached the full boot trace. Below is a snippet of the crash region.
Does anyone have any idea what's going on?

Thanks and have a nice day.


- Alexia

================================================
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6
iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP:
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>]
:usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task
ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed

[-- Attachment #1.2: Type: text/html, Size: 5276 bytes --]

[-- Attachment #2: boottrace.txt --]
[-- Type: text/plain, Size: 16160 bytes --]

 \ \/ /___ _ __   |___ /| || |     _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \    |_ \| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | |  ___) |__   _|__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_| |____(_) |_|     \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
                                                                         
(XEN) Xen version 3.4-unstable (xxx@xxx.xxx.xxx) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) Thu Jan 22 12:06:54 EST 2009
(XEN) Latest ChangeSet: Thu Jan 22 11:07:32 2009 +0000 19067:a92ed09b4032
(XEN) Command line: com1=9600,8n1 console=com1 iommu=1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e800 (usable)
(XEN)  000000000009e800 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bfae1000 (usable)
(XEN)  00000000bfae1000 - 00000000bfb24000 (ACPI NVS)
(XEN)  00000000bfb24000 - 00000000bfd42000 (reserved)
(XEN)  00000000bfd42000 - 00000000bfd43000 (ACPI NVS)
(XEN)  00000000bfd43000 - 00000000bfd48000 (reserved)
(XEN)  00000000bfd48000 - 00000000bfd50000 (ACPI data)
(XEN)  00000000bfd50000 - 00000000bfd6b000 (ACPI NVS)
(XEN)  00000000bfd6b000 - 00000000bfd8a000 (reserved)
(XEN)  00000000bfd8a000 - 00000000bfd90000 (ACPI NVS)
(XEN)  00000000bfd90000 - 00000000bff00000 (usable)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000013c000000 (usable)
(XEN) System RAM: 4027MB (4124604kB)
(XEN) ACPI: RSDP 000F03C0, 0024 (r2  INTEL)
(XEN) ACPI: XSDT BFD4EE18, 005C (r1 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: FACP BFD4DD98, 00F4 (r4  INTEL    A M I  6222004 MSFT    10013)
(XEN) ACPI: DSDT BFD48018, 4EFD (r1 INTEL  DQ45CB         43 INTL 20051117)
(XEN) ACPI: FACS BFD56F40, 0040
(XEN) ACPI: APIC BFD4DF18, 006C (r2 INTEL  DQ45CB         43 MSFT    10013)
(XEN) ACPI: MCFG BFD58E18, 003C (r1 INTEL  DQ45CB         43 MSFT       97)
(XEN) ACPI: ASF! BFD57D18, 00A0 (r32 INTEL  DQ45CB         43 TFSM    F4240)
(XEN) ACPI: SPCR BFD58D18, 0050 (r1 INTEL  DQ45CB         43 AMI.        3)
(XEN) ACPI: TCPA BFD58C98, 0032 (r2 INTEL  DQ45CB         43 MSFT  1000013)
(XEN) ACPI: DMAR BFD42F18, 00D8 (r1 INTEL  DQ45CB         43 INTL        1)
(XEN) Domain heap initialised
(XEN) Processor #0 7:7 APIC version 20
(XEN) Processor #1 7:7 APIC version 20
(XEN) Processor #2 7:7 APIC version 20
(XEN) Processor #3 7:7 APIC version 20
(XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Intel VT-d has been enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2499.770 MHz processor.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: VMX enabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 1/1 eip 8c000
(XEN) CPU1: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 2/2 eip 8c000
(XEN) CPU2: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Booting processor 3/3 eip 8c000
(XEN) CPU3: Intel(R) Core(TM)2 Quad  CPU   Q9300  @ 2.50GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Brought up 4 CPUs
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) mtrr: your CPUs had inconsistent fixed MTRR settings
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0xffffffff80200000 -> 0xffffffff805bf88c
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000134000000->0000000136000000 (970253 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff805bf88c
(XEN)  Init. ramdisk: ffffffff805c0000->ffffffff80956400
(XEN)  Phys-Mach map: ffffffff80957000->ffffffff810ce068
(XEN)  Start info:    ffffffff810cf000->ffffffff810cf4b4
(XEN)  Page tables:   ffffffff810d0000->ffffffff810dd000
(XEN)  Boot stack:    ffffffff810dd000->ffffffff810de000
(XEN)  TOTAL:         ffffffff80000000->ffffffff81400000
(XEN)  ENTRY ADDRESS: ffffffff80200000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 108kB init memory.
kernel direct mapping tables up to ef60d000 @ 10e0000-1861000
Bootdata ok (command line is root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0)
Linux version 2.6.18.8-xen (root@amber) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Jan 22 12:02:23 EST 2009
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000ef60d000 (usable)
DMI 2.4 present.
No mptable found.
  >>> ERROR: Invalid checksum
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Setting APIC routing to xen
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at c0000000 (gap: bff00000:3ee1c000)
Built 1 zonelists.  Total pages: 967088
Kernel command line: root=/dev/sda2 ro xencons=ttyS console=tty0 console=ttyS0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Xen reported: 2499.770 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Software IO TLB enabled: 
 Aperture:     64 megabytes
 Kernel range: ffff880005a7a000 - ffff880009a7a000
 Address size: 27 bits
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Memory: 3764092k/3921972k available (2027k kernel code, 149244k reserved, 887k data, 180k init)
Calibrating delay using timer specific routine.. 5000.60 BogoMIPS (lpj=25003009)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20060707
SMP alternatives: switching to SMP code
Initializing CPU#1
Initializing CPU#2
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Brought up 4 CPUs
Initializing CPU#3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 3
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 3072K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 2
migration_cost=9
checking if image is initramfs... it is
Freeing initrd memory: 3673k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
(XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4
(XEN) ioapic_guest_write: old_entry=000009f1, new_entry=000109f1
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
pnp: PnP ACPI: found 10 devices
xen_mem: Initialising balloon driver.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:02: ioport range 0xa20-0xa3f has been reserved
pnp: 00:02: ioport range 0xa00-0xa1f has been reserved
pnp: 00:02: ioport range 0xb78-0xb7f has been reserved
pnp: 00:02: ioport range 0xf78-0xf7f has been reserved
pnp: 00:09: ioport range 0x400-0x47f could not be reserved
pnp: 00:09: ioport range 0x1180-0x119f has been reserved
pnp: 00:09: ioport range 0x500-0x57f has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: c0000000-d00fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: d0100000-d01fffff
  PREFETCH window: disabled.
GSI 16 sharing vector 0xA8 and IRQ 16
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IA-32 Microcode Update Driver: v1.14a-xen <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1232672414.325:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Xen virtual console successfully installed as ttyS0
Event-channel device installed.
netfront: Initialising virtual ethernet driver.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 180k freed
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [     IST] [20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 0 initialization completed
ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 1 initialization completed
ACPI: CPU2 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 2 initialization completed
ACPI: CPU3 (power states: C1[C1] C2[C2] C3[C3])
(XEN) xen_pminfo: @acpi_cpufreq_cpu_init,HARDWARE addr space
(XEN) CPU 3 initialization completed
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
ACPI Exception (acpi_processor-0721): AE_NOT_FOUND, Processor Device is not present [20060707]
ACPI: CPU-1 (power states: C1[C1] C2[C2] C3[C3])
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e0e0
(XEN) [VT-D]iommu.c:721: iommu_page_fault: iommu->reg = ffff828bfff55000
(XEN) [VT-D]iommu.c:693: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:675: iommu_fault:DMA Read: 0:1a.0 addr bf7ed000 REASON 6 iommu->reg = ffff828bfff55000
(XEN) print_vtd_entries: iommu = ffff8300bfef10f0 bdf = 0:1a:0 gmfn = bf7ed
(XEN)     root_entry = ffff83013bdea000
(XEN)     root_entry[0] = 1374a0001
(XEN)     context = ffff8301374a0000
(XEN)     context[d0] = 101_13bde6001
(XEN)     l3 = ffff83013bde6000
(XEN)     l3_index = 2
(XEN)     l3[2] = 137a83003
(XEN)     l2 = ffff830137a83000
(XEN)     l2_index = 1fb
(XEN)     l2[1fb] = 137887003
(XEN)     l1 = ffff830137887000
(XEN)     l1_index = 1ed
(XEN)     l1[1ed] = 0
(XEN)     l1[1ed] not present
uhci_hcd 0000:00:1a.0: host system error, PCI problems?
uhci_hcd 0000:00:1a.0: host controller halted, very bad!
uhci_hcd 0000:00:1a.0: HC died; cleaning up
usb usb1: configuration #1 chosen from 1 choice
usb usb1: can't set config #1, error -108
uhci_hcd 0000:00:1a.0: HC died; cleaning up
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP: 
 [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
PGD ef053067 PUD ef051067 PMD 0 
Oops: 0000 [1] SMP 
CPU 3 
Modules linked in: uhci_hcd usbcore thermal processor fan
Pid: 496, comm: insmod Not tainted 2.6.18.8-xen #1
RIP: e030:[<ffffffff88019be9>]  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
RSP: e02b:ffff8800eeb6fc50  EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff8800eed03c00 RCX: ffffffffff578000
RDX: ffffffffff578000 RSI: 0000000000000001 RDI: ffff8800ef03e000
RBP: 0000000000000000 R08: 000000000000000e R09: 0000000000000001
R10: ffff8800ef052570 R11: ffffffff80300885 R12: ffff8800eecb01c8
R13: 0000000000000000 R14: ffff8800ef03e000 R15: ffff8800eecb0070
FS:  00002ad0ef6c66d0(0000) GS:ffffffff804d9180(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 496, threadinfo ffff8800eeb6e000, task ffff8800eec867a0)
Stack:  ffffffff8801a39b 0000000000000012 ffff8800ef03e000 ffff8800eed03c00
 ffffffff8801ad3c 0000001000000004 ffff8800eecb00e0 ffff8800eed03c00
 ffff8800eecb0000 0000000000000004 ffffffff8803d4a0 0000000000000000
Call Trace:
 [<ffffffff8801a39b>] :usbcore:usb_hc_died+0x5f/0x72
 [<ffffffff8801ad3c>] :usbcore:usb_add_hcd+0x4eb/0x562
 [<ffffffff880230cf>] :usbcore:usb_hcd_pci_probe+0x1e6/0x28f
 [<ffffffff802f4f5e>] pci_device_probe+0x4c/0x75
 [<ffffffff8034f250>] pci_bus_probe_wrapper+0x86/0x92
 [<ffffffff802f4e48>] pci_match_device+0x13/0xbd
 [<ffffffff8803d000>] :uhci_hcd:uhci_start+0x21e/0x3c0
 [<ffffffff802f4f06>] pci_bus_match+0x14/0x20
 [<ffffffff80346048>] driver_probe_device+0x52/0xa8
 [<ffffffff80346177>] __driver_attach+0x6d/0xaa
 [<ffffffff8034610a>] __driver_attach+0x0/0xaa
 [<ffffffff80345a49>] bus_for_each_dev+0x43/0x6e
 [<ffffffff803456a7>] bus_add_driver+0x7e/0x130
 [<ffffffff802f50f9>] __pci_register_driver+0x57/0x7d
 [<ffffffff8804305c>] :uhci_hcd:uhci_hcd_init+0x5c/0x97
 [<ffffffff8024b1f5>] sys_init_module+0x16cc/0x1883
 [<ffffffff8020a518>] system_call+0x68/0x6d
 [<ffffffff8020a4b0>] system_call+0x0/0x6d


Code: 48 8b 40 18 48 8b b8 f0 01 00 00 e9 52 db ff ff 41 56 41 55 
RIP  [<ffffffff88019be9>] :usbcore:usb_kick_khubd+0x7/0x17
 RSP <ffff8800eeb6fc50>
CR2: 0000000000000018
 Killed


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Sanjay Rao]

subscribe netdev

(no subject)

[engage]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[engage]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[Paul L]

Hi, I'm a new user of NILFS2, and I'm using it for both my root and
home partition. Since none of the boot loaders support NILFS2, I had
to use a small ext2 partition to boot, and use initrd scripts to load
the nilfs2 kernel module.

So far everything seems to work fine. But I notice that only one
clearnerd is running, and that's for my home partition. This is
probably because the initrd I use didn't have the nifs_cleanerd binary
in it, so mounting the root partition will not start it. I wonder if
it's safe to start it later manually? Something like "nilfs_cleanerd
/" in the rc.local script?

BTW, thanks for the exellent work, the performance is great on my SSD
netbook, much better than ext2 and reiserfs.

-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: (no subject)

[Ryusuke Konishi]

Hi,

On Mon, 8 Dec 2008 16:03:06 -0500, "Paul L" wrote:
> Hi, I'm a new user of NILFS2, and I'm using it for both my root and
> home partition. Since none of the boot loaders support NILFS2, I had
> to use a small ext2 partition to boot, and use initrd scripts to load
> the nilfs2 kernel module.
>
> So far everything seems to work fine. But I notice that only one
> clearnerd is running, and that's for my home partition. This is
> probably because the initrd I use didn't have the nifs_cleanerd binary
> in it, so mounting the root partition will not start it. I wonder if
> it's safe to start it later manually? Something like "nilfs_cleanerd
> /" in the rc.local script?

Thanks for reporting.

You can manually start nilfs_cleanerd, or you can do it through mount
program.

For example, if your boot partition is initially mounted read-only,
you can change it to writable mount by a re-mount option:

 # mount -t nilfs2 -o rw,remount /dev/xxx /mount-dir

This remount operation involves invocation of nilfs_cleanerd.

> BTW, thanks for the exellent work, the performance is great on my SSD
> netbook, much better than ext2 and reiserfs.

Interesting.

Could you tell me what brand of SSD is used in the netbook?


Regards,
Ryusuke Konishi

Re: (no subject)

[Paul L]

On 12/9/08, Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> wrote:
> You can manually start nilfs_cleanerd, or you can do it through mount
> program.
>
> For example, if your boot partition is initially mounted read-only,
> you can change it to writable mount by a re-mount option:
>
>  # mount -t nilfs2 -o rw,remount /dev/xxx /mount-dir
>
> This remount operation involves invocation of nilfs_cleanerd.

Strangely, the init scripts already did a remount of the root
partition (with remount option), but cleanerd is not invoked. I had to
do it for a second time in rc.local, then it becomes ok.

>> BTW, thanks for the exellent work, the performance is great on my SSD
>> netbook, much better than ext2 and reiserfs.
>
> Interesting.
>
> Could you tell me what brand of SSD is used in the netbook?

It's Intel SSD (SSDPAM0008G1EA), a very slow SSD with only 5-6 MB/s
write speed. My netbook is Acer Aspire One model AOA110.

-- 
Regards,
Paul Liu

Yale Haskell Group
http://www.haskell.org/yale

Re: (no subject)

[Ryusuke Konishi]

Hi Paul,
On Tue, 9 Dec 2008 11:16:33 -0500, "Paul L" wrote:
> Strangely, the init scripts already did a remount of the root
> partition (with remount option), but cleanerd is not invoked. I had to
> do it for a second time in rc.local, then it becomes ok.

I heard that the nilfs_cleanerd depends on /usr/lib/libnilfs.so.*.
Could you confirm whether these dynamic libraries are installed in the
initrd?

> > Interesting.
> >
> > Could you tell me what brand of SSD is used in the netbook?
> 
> It's Intel SSD (SSDPAM0008G1EA), a very slow SSD with only 5-6 MB/s
> write speed. My netbook is Acer Aspire One model AOA110.

Informative. Thanks.

I recognize that nilfs2 performance fairly depends on devices, and it
still has much things to do well at various devices.
The nature of nilfs2 which sequentially uses the disk partition almost
entirely (like a ring buffer), well suited to your device.

Anyhow, thanks for letting us know.

Regards,
Ryusuke

(no subject)

[Nitin Mahajan]

unsubscribe



      Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com. 
http://mail.promotions.yahoo.com/newdomains/aa/

(no subject)

[Nitin Mahajan]

unsubscribe alsa-devel


      New Email names for you! 
Get the Email name you've always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/

(no subject)

[Bowen, Clair]

[-- Attachment #1.1: Type: text/plain, Size: 126 bytes --]

Does anybody know if Storport is supported on XEN?  I only see references to SCSIPORT (i.e xenscsi.sys).

Regards,

CJ


[-- Attachment #1.2: Type: text/html, Size: 4277 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: (no subject)

[James Harper]

> 
> Does anybody know if Storport is supported on XEN?  I only see
references
> to SCSIPORT (i.e xenscsi.sys).
> 

If you are referring to the gplpv drivers, then I have only developed
with scsiport at the moment. Storport is only supported under 2003 and
later and I didn't want to maintain two versions of the same code. I'm
not yet convinced that storport will give any noticeable advantage over
scsiport for what we are doing.

xenvbd (scsi emulation of block device) and xenscsi (pvscsi scsi
passthrough) are both scsiport drivers, but xenscsi doesn't work at the
moment as it only worked with a slightly modified version of the 3.2
version of pvscsi. It will be incompatible with the 3.3 version. I will
update it once I get 3.3 installed on my dev box (waiting for some
Debian packages).

Thanks

James

(no subject)

[Oluf Svendson]

subscribe netdev

(no subject)

[Oluf Svendson]

subscribe netdev

(no subject)

[Bryan Wu]

Re: (no subject)

[Mark Brown]

On Tue, Nov 18, 2008 at 04:18:14PM +0800, Bryan Wu wrote:

...nothing.  :)

All patches look OK, a couple of comments to follow.

(no subject)

[Bryan Wu]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(no subject)

[Fernando Moro]

Dear member of the alsa time,
 
I am not sure if this is the email addres in which it is possible to talk about a problem with the Alsa plugins, but it is the unique address that I have found.
 
I am writing to tell you about the compatibility of the alsa plugins. There are lots of users (like me) who have the Lexicon lambda soundcard and the lexicon alpha soundcard, but alsa plugins only support the Lexicon Omega!, and it is impossible to connect our soundcards to the computer. I think that it is a problem for the Ubuntu Studio, Musix or Studio64 users, who use this devices to record and play midi songs, and I think that linux can be better than windows making audio. I would be grateful if alsa team could help us with this problem somehow. I look forward to your response. Thank you for your attention. Your faithfully, Fernando.
Sorry for my bad English, I am Spanish.
_________________________________________________________________
Los más de lo más, Especial Rankings
http://events.es.msn.com/dinero/listas/default.aspx

(no subject)

[Yang, Libin]

Hi Takashi,

This patch is to support detecting new AMD HD Audio devices with HDA PCI
class code. Would you please review it? Thanks a lot!
--------------------------------------------------------------------

Signed-off-by: Libin Yang <libin.yang@amd.com>

--- alsa-driver-1.0.18.orig/alsa-kernel/pci/hda/hda_intel.c
2008-10-29 20:41:35.000000000 +0800
+++ alsa-driver-1.0.18/alsa-kernel/pci/hda/hda_intel.c	2008-11-11
18:33:14.000000000 +0800
@@ -291,6 +291,7 @@
 /* Define VIA HD Audio Device ID*/
 #define VIA_HDAC_DEVICE_ID		0x3288
 
+#define PCI_CLASS_MULTIMEDIA_HDA	0x040300
 
 /*
  */
@@ -410,6 +411,7 @@
 	AZX_DRIVER_ULI,
 	AZX_DRIVER_NVIDIA,
 	AZX_DRIVER_TERA,
+	AZX_DRIVER_AMD_AUTO,
 	AZX_NUM_DRIVERS, /* keep this as last entry */
 };
 
@@ -423,6 +425,7 @@
 	[AZX_DRIVER_ULI] = "HDA ULI M5461",
 	[AZX_DRIVER_NVIDIA] = "HDA NVidia",
 	[AZX_DRIVER_TERA] = "HDA Teradici", 
+	[AZX_DRIVER_AMD_AUTO] = "HDA AMD",
 };
 
 /*
@@ -1198,6 +1201,7 @@
 static unsigned int azx_default_codecs[AZX_NUM_DRIVERS] __devinitdata =
{
 	[AZX_DRIVER_ICH] = 3,
 	[AZX_DRIVER_ATI] = 3,
+	[AZX_DRIVER_AMD_AUTO] = 3,
 };
 
 static int __devinit azx_codec_create(struct azx *chip, const char
*model,
@@ -2146,6 +2150,7 @@
 			chip->playback_streams = ULI_NUM_PLAYBACK;
 			chip->capture_streams = ULI_NUM_CAPTURE;
 			break;
+		case AZX_DRIVER_AMD_AUTO:
 		case AZX_DRIVER_ATIHDMI:
 			chip->playback_streams = ATIHDMI_NUM_PLAYBACK;
 			chip->capture_streams = ATIHDMI_NUM_CAPTURE;
@@ -2373,6 +2378,9 @@
 	{ PCI_DEVICE(0x10de, 0x0bd7), .driver_data = AZX_DRIVER_NVIDIA
},
 	/* Teradici */
 	{ PCI_DEVICE(0x6549, 0x1200), .driver_data = AZX_DRIVER_TERA },
+	/* AMD Generic, PCI class code and Vendor ID for HD Audio */
+	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+	  PCI_CLASS_MULTIMEDIA_HDA, 0xffffff, AZX_DRIVER_AMD_AUTO },
 	{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);

Thanks & Regards,
Libin

Re: (no subject)

[Takashi Iwai]

At Tue, 11 Nov 2008 10:43:12 +0800,
Yang, Libin wrote:
> 
> Hi Takashi,
> 
> This patch is to support detecting new AMD HD Audio devices with HDA PCI
> class code. Would you please review it? Thanks a lot!

Thanks for the patch!  Some quick review comments below...


> --- alsa-driver-1.0.18.orig/alsa-kernel/pci/hda/hda_intel.c
> 2008-10-29 20:41:35.000000000 +0800
> +++ alsa-driver-1.0.18/alsa-kernel/pci/hda/hda_intel.c	2008-11-11
> 18:33:14.000000000 +0800
> @@ -291,6 +291,7 @@
>  /* Define VIA HD Audio Device ID*/
>  #define VIA_HDAC_DEVICE_ID		0x3288
>  
> +#define PCI_CLASS_MULTIMEDIA_HDA	0x040300

Put this into include/linux/pci_ids.h as a common definition.
And, IMO, it'd be better to name it *_HD_AUDIO than *_HDA.

>  
>  /*
>   */
> @@ -410,6 +411,7 @@
>  	AZX_DRIVER_ULI,
>  	AZX_DRIVER_NVIDIA,
>  	AZX_DRIVER_TERA,
> +	AZX_DRIVER_AMD_AUTO,

We can create a more generic entry, say, AZX_DRIVER_GENERIC.


> @@ -423,6 +425,7 @@
>  	[AZX_DRIVER_ULI] = "HDA ULI M5461",
>  	[AZX_DRIVER_NVIDIA] = "HDA NVidia",
>  	[AZX_DRIVER_TERA] = "HDA Teradici", 
> +	[AZX_DRIVER_AMD_AUTO] = "HDA AMD",

And, make it [AZX_DRIVER_GENERIC] = "HD-Audio Generic" or so.


>  static unsigned int azx_default_codecs[AZX_NUM_DRIVERS] __devinitdata =
> {
>  	[AZX_DRIVER_ICH] = 3,
>  	[AZX_DRIVER_ATI] = 3,
> +	[AZX_DRIVER_AMD_AUTO] = 3,

I thought you'll have up to 4 codecs?


>  static int __devinit azx_codec_create(struct azx *chip, const char
> *model,
> @@ -2146,6 +2150,7 @@
>  			chip->playback_streams = ULI_NUM_PLAYBACK;
>  			chip->capture_streams = ULI_NUM_CAPTURE;
>  			break;
> +		case AZX_DRIVER_AMD_AUTO:

AZX_DRIVER_GENERIC can go to "default".

>  		case AZX_DRIVER_ATIHDMI:
>  			chip->playback_streams = ATIHDMI_NUM_PLAYBACK;
>  			chip->capture_streams = ATIHDMI_NUM_CAPTURE;
> @@ -2373,6 +2378,9 @@
>  	{ PCI_DEVICE(0x10de, 0x0bd7), .driver_data = AZX_DRIVER_NVIDIA
> },
>  	/* Teradici */
>  	{ PCI_DEVICE(0x6549, 0x1200), .driver_data = AZX_DRIVER_TERA },
> +	/* AMD Generic, PCI class code and Vendor ID for HD Audio */
> +	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> +	  PCI_CLASS_MULTIMEDIA_HDA, 0xffffff, AZX_DRIVER_AMD_AUTO },

Use PCI_DEVICE() macro and C99 style initialization, such as,

	{ PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_ANY_ID),
	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO,
	  .class_mask = 0xffffff,
	  .driver_data = AZX_DRIVER_GENERIC },

thanks,

Takashi

(no subject)

[Can Le]

Hello friends,



I am new to the list, I am needing help to modify webcam driver, 
to compile and install into SuSE 10 for V4l and kernel 2.6.



Anyonne please give a few links or help lines to do it.



 I could write and compile program in C++, and upload image in Perl to run apache2 in exe file from CGI with audio. 



http://www.lecan.net



Thank you



Cle1214







--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[Philippe CARRIERE]

Le mardi 14 octobre 2008 à 13:29 +0200, Karsten Wiese a écrit :
Am Dienstag, 14. Oktober 2008 schrieb Philippe Carriere:
> > Might this patch (the original one, without features yet implemented in
> > 2.6.26, and an extremely slight modification to fit it) I use on Fedora
> > kernel (the patch also applies as it stands to vanilla) save works and
> > time ?
> 
> maybe.
> I guess the patch would have to fit what will become 2.6.28.
> 
> 
> regards,
> Karsten
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Thus I can try to follow the next evolution of the kernel and send you new version of the patch, when required; would it be fruitful for you ?
During that time, I will try to implement a module modification (presently, I propose a whole kernel which is not the right solution), but I have some things to learn about the method.

A last question: you commented some lines in us122l.c which are concerned with the possible support of US-144 (which apparently has a very similar hardware): do you think support of US-144 would be possible - to be tested of course - with the same driver or do you think it would require more work ?

Regards

Phil

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

(no subject)

[Philippe CARRIERE]

Hi,

following is a report of some tests of alsa.1.0.18rc3 in view of support of Tascam US-122L, which might be of interest for you. As a preliminary information, note that I patched my own Fedora kernel and alsa-plugins with Karsten Wiese'patches a few month ago and use regularly Tascam US-122L under Linux which works very fine; I also provide (experimental) packages for Fedora 9 from june 2008 on my web page.

Test 1: succeeded

    - replacement of my own  alsa-plugins-usb_stream-1.0.16-4.us122lv05.fc9 by alsa-plugins-usbstream-1.0.18-1.rc3.fc10 on Fedora 9 (using my own patched kernel 2.6.26 including the snd-usb-us122l module). Everything works.

Test 2: succeeded

    - replacement of previous alsa-1.0.16 by alsa.1.0.18-1.rc3 (Fedora packages; thus alsa-driver-1.0.18rc3 not included). Everything works, including Tascam US-122L when using my patched kernel (which includes the snd-usb-us122l module).

Test 3: failed

    - installation of alsa-driver-1.0.18rc3 (succeeded) on Fedora 9 (as weel, I tested with new Fedora 10 beta which includes kernel 2.6.27.rc3); plug in the US-122L leads to error messages from snd-usb-us122l:

# cat /var/log/messages
...
Oct 11 09:21:51 pollux kernel: usb 2-6: new high speed USB device using ehci_hcd and address 3
Oct 11 09:21:51 pollux kernel: usb 2-6: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 9
Oct 11 09:21:51 pollux kernel: usb 2-6: configuration #1 chosen from 1 choice
Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device found, idVendor=0644, idProduct=800e
Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 11 09:21:51 pollux kernel: usb 2-6: Product: US-122L
Oct 11 09:21:51 pollux kernel: usb 2-6: Manufacturer: TASCAM
Oct 11 09:21:51 pollux kernel: usb 2-6: SerialNumber: no serial number
Oct 11 09:21:51 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/usb_stream.c:618: 0
Oct 11 09:21:55 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/us122l.c:329: us122l_start error -14 
Oct 11 09:21:55 pollux kernel: snd-usb-us122l: probe of 2-6:1.1 failed with error -5

Oct 11 09:21:55 pollux kernel: usbcore: registered new interface driver snd-usb-us122l

and

# cat /proc/asound/cards
0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfebfc000 irq 21

US-122L finally not being recognized.

Test 4: succeded

    - same than test 3 for Fedora 9, but using a patched ehci-hcd module (the patch adding some features from the original one by Karsten Wiese not - yet ? - included in kernel 2.6.26). Everything works including of course the US-122L.

Question:

Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to  work for providing a kind of kmod ?

Regards

Phil.
-- 
Philippe Carriere <philippe-f.carriere@wanadoo.fr>

Re: (no subject)

[Takashi Iwai]

At Mon, 13 Oct 2008 12:51:11 +0200 (CEST),
Philippe CARRIERE wrote:
> 
> Hi,
> 
> following is a report of some tests of alsa.1.0.18rc3 in view of support of Tascam US-122L, which might be of interest for you. As a preliminary information, note that I patched my own Fedora kernel and alsa-plugins with Karsten Wiese'patches a few month ago and use regularly Tascam US-122L under Linux which works very fine; I also provide (experimental) packages for Fedora 9 from june 2008 on my web page.
> 
> Test 1: succeeded
> 
>     - replacement of my own  alsa-plugins-usb_stream-1.0.16-4.us122lv05.fc9 by alsa-plugins-usbstream-1.0.18-1.rc3.fc10 on Fedora 9 (using my own patched kernel 2.6.26 including the snd-usb-us122l module). Everything works.
> 
> Test 2: succeeded
> 
>     - replacement of previous alsa-1.0.16 by alsa.1.0.18-1.rc3 (Fedora packages; thus alsa-driver-1.0.18rc3 not included). Everything works, including Tascam US-122L when using my patched kernel (which includes the snd-usb-us122l module).
> 
> Test 3: failed
> 
>     - installation of alsa-driver-1.0.18rc3 (succeeded) on Fedora 9 (as weel, I tested with new Fedora 10 beta which includes kernel 2.6.27.rc3); plug in the US-122L leads to error messages from snd-usb-us122l:
> 
> # cat /var/log/messages
> ...
> Oct 11 09:21:51 pollux kernel: usb 2-6: new high speed USB device using ehci_hcd and address 3
> Oct 11 09:21:51 pollux kernel: usb 2-6: config 1 interface 1 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 9
> Oct 11 09:21:51 pollux kernel: usb 2-6: configuration #1 chosen from 1 choice
> Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device found, idVendor=0644, idProduct=800e
> Oct 11 09:21:51 pollux kernel: usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Oct 11 09:21:51 pollux kernel: usb 2-6: Product: US-122L
> Oct 11 09:21:51 pollux kernel: usb 2-6: Manufacturer: TASCAM
> Oct 11 09:21:51 pollux kernel: usb 2-6: SerialNumber: no serial number
> Oct 11 09:21:51 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/usb_stream.c:618: 0
> Oct 11 09:21:55 pollux kernel: ALSA /home/Test/alsa-driver-1.0.18rc3/usb/usx2y/../../alsa-kernel/usb/usx2y/us122l.c:329: us122l_start error -14 
> Oct 11 09:21:55 pollux kernel: snd-usb-us122l: probe of 2-6:1.1 failed with error -5
> 
> Oct 11 09:21:55 pollux kernel: usbcore: registered new interface driver snd-usb-us122l
> 
> and
> 
> # cat /proc/asound/cards
> 0 [Intel          ]: HDA-Intel - HDA Intel
>                       HDA Intel at 0xfebfc000 irq 21
> 
> US-122L finally not being recognized.
> 
> Test 4: succeded
> 
>     - same than test 3 for Fedora 9, but using a patched ehci-hcd module (the patch adding some features from the original one by Karsten Wiese not - yet ? - included in kernel 2.6.26). Everything works including of course the US-122L.
> 
> Question:
> 
> Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to  work for providing a kind of kmod ?

Hm, I thought Karsten mentioned that patch will go to the upstream usb
tree, but it seems not done yet.

Karsten, what is the current status of your ehci patch?


thanks,

Takashi

Re: (no subject)

[Karsten Wiese]

Am Montag, 13. Oktober 2008 schrieb Takashi Iwai:

> > Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to  work for providing a kind of kmod ?
> 
> Hm, I thought Karsten mentioned that patch will go to the upstream usb
> tree, but it seems not done yet.
> 
> Karsten, what is the current status of your ehci patch?

has to be adjusted to fit head and submitted to usb-devel again.
will get back to it once my current main-project allows me to.
that might well be 09. sorry.

thanks,
Karsten

Re: (no subject)

[Philippe Carriere]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Might this patch (the original one, without features yet implemented in
2.6.26, and an extremely slight modification to fit it) I use on Fedora
kernel (the patch also applies as it stands to vanilla) save works and
time ?

Regards,

Phil.
Le mardi 14 octobre 2008 à 11:54 +0200, Karsten Wiese a écrit :

> Am Montag, 13. Oktober 2008 schrieb Takashi Iwai:
> 
> > > Thus, a patched ehci-hcd module is required. Is the patch scheduled to appear in kernel 2.6.27 or would it be useful to  work for providing a kind of kmod ?
> > 
> > Hm, I thought Karsten mentioned that patch will go to the upstream usb
> > tree, but it seems not done yet.
> > 
> > Karsten, what is the current status of your ehci patch?
> 
> has to be adjusted to fit head and submitted to usb-devel again.
> will get back to it once my current main-project allows me to.
> that might well be 09. sorry.
> 
> thanks,
> Karsten
> 

[-- Attachment #2: ehci-hcd_2.6.26.patch --]
[-- Type: text/x-patch, Size: 5767 bytes --]

diff -uNrp /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci.h vanilla-2.6.26/drivers/usb/host/ehci.h
--- /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci.h	2008-07-13 23:51:29.000000000 +0200
+++ vanilla-2.6.26/drivers/usb/host/ehci.h	2008-09-21 16:43:06.000000000 +0200
@@ -86,6 +86,9 @@ struct ehci_hcd {			/* one per controlle
 	union ehci_shadow	*pshadow;	/* mirror hw periodic table */
 	int			next_uframe;	/* scan periodic, start here */
 	unsigned		periodic_sched;	/* periodic activity count */
+	struct list_head	cached_itd_list; /* list of itds completed
+			while frame hadn't yet elapsed */
+	unsigned		hw_frame;
 
 	/* per root hub port */
 	unsigned long		reset_done [EHCI_MAX_ROOT_PORTS];
@@ -205,6 +208,9 @@ timer_action (struct ehci_hcd *ehci, enu
 	}
 }
 
+static void free_cached_itd_list(struct ehci_hcd *ehci);
+
+
 /*-------------------------------------------------------------------------*/
 
 /* EHCI register interface, corresponds to EHCI Revision 0.95 specification */
diff -uNrp /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-hcd.c vanilla-2.6.26/drivers/usb/host/ehci-hcd.c
--- /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-hcd.c	2008-07-13 23:51:29.000000000 +0200
+++ vanilla-2.6.26/drivers/usb/host/ehci-hcd.c	2008-09-21 16:23:32.000000000 +0200
@@ -479,6 +479,7 @@ static int ehci_init(struct usb_hcd *hcd
 	 * periodic_size can shrink by USBCMD update if hcc_params allows.
 	 */
 	ehci->periodic_size = DEFAULT_I_TDPS;
+	INIT_LIST_HEAD(&ehci->cached_itd_list);
 	if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
 		return retval;
 
@@ -491,6 +492,7 @@ static int ehci_init(struct usb_hcd *hcd
 
 	ehci->reclaim = NULL;
 	ehci->next_uframe = -1;
+	ehci->hw_frame = -1;
 
 	/*
 	 * dedicate a qh for the async ring head, since we couldn't unlink
diff -uNrp /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-mem.c vanilla-2.6.26/drivers/usb/host/ehci-mem.c
--- /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-mem.c	2008-07-13 23:51:29.000000000 +0200
+++ vanilla-2.6.26/drivers/usb/host/ehci-mem.c	2008-09-21 16:25:16.000000000 +0200
@@ -128,6 +128,7 @@ static inline void qh_put (struct ehci_q
 
 static void ehci_mem_cleanup (struct ehci_hcd *ehci)
 {
+	free_cached_itd_list(ehci);
 	if (ehci->async)
 		qh_put (ehci->async);
 	ehci->async = NULL;
diff -uNrp /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-sched.c vanilla-2.6.26/drivers/usb/host/ehci-sched.c
--- /home/Test/rpmbuild/BUILD/kernel-2.6.26/vanilla-2.6.26/drivers/usb/host/ehci-sched.c	2008-07-13 23:51:29.000000000 +0200
+++ vanilla-2.6.26/drivers/usb/host/ehci-sched.c	2008-09-21 16:40:38.000000000 +0200
@@ -1003,7 +1003,8 @@ iso_stream_put(struct ehci_hcd *ehci, st
 
 		is_in = (stream->bEndpointAddress & USB_DIR_IN) ? 0x10 : 0;
 		stream->bEndpointAddress &= 0x0f;
-		stream->ep->hcpriv = NULL;
+		if (stream->ep)
+			stream->ep->hcpriv = NULL;
 
 		if (stream->rescheduled) {
 			ehci_info (ehci, "ep%d%s-iso rescheduled "
@@ -1654,13 +1655,25 @@ itd_complete (
 			(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
 	}
 	iso_stream_put (ehci, stream);
-	/* OK to recycle this ITD now that its completion callback ran. */
 done:
 	usb_put_urb(urb);
 	itd->urb = NULL;
-	itd->stream = NULL;
-	list_move(&itd->itd_list, &stream->free_list);
-	iso_stream_put(ehci, stream);
+	if (ehci->hw_frame != itd->frame || itd->index[7] != -1) {
+		/* OK to recycle this ITD now. */
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	} else {
+		/* HW might still start transactions based on this ITD.
+		   If its content changed that is. Move it to a safe place. */
+		list_move(&itd->itd_list, &ehci->cached_itd_list);
+		if (stream->refcount == 2) {
+			/* If iso_stream_put() would be called here, stream
+			   would be freed. Prevent stream's reusage instead. */
+			stream->ep->hcpriv = NULL;
+			stream->ep = NULL;
+		}
+	}
 
 	return retval;
 }
@@ -2104,10 +2117,24 @@ done:
 
 /*-------------------------------------------------------------------------*/
 
+static void free_cached_itd_list(struct ehci_hcd *ehci)
+{
+	struct ehci_itd *itd, *n;
+
+	list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
+		struct ehci_iso_stream	*stream = itd->stream;
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	}
+}
+
+/*-------------------------------------------------------------------------*/
+
 static void
 scan_periodic (struct ehci_hcd *ehci)
 {
-	unsigned	now_uframe, frame, clock, clock_frame, mod;
+	unsigned	frame, hw_frame, clock, clock_frame, now_uframe, mod;
 	unsigned	modified;
 
 	mod = ehci->periodic_size << 3;
@@ -2118,10 +2145,17 @@ scan_periodic (struct ehci_hcd *ehci)
 	 * Touches as few pages as possible:  cache-friendly.
 	 */
 	now_uframe = ehci->next_uframe;
-	if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state))
+	if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state)) {
 		clock = ehci_readl(ehci, &ehci->regs->frame_index);
-	else
+		hw_frame = (clock >> 3) % ehci->periodic_size;
+	} else {
 		clock = now_uframe + mod - 1;
+		hw_frame = -1;
+	}
+	if (ehci->hw_frame != hw_frame) {
+		free_cached_itd_list(ehci);
+		ehci->hw_frame = hw_frame;
+	}
 	clock %= mod;
 	clock_frame = clock >> 3;
 
@@ -2281,6 +2315,11 @@ restart:
 			/* rescan the rest of this frame, then ... */
 			clock = now;
 			clock_frame = clock >> 3;
+			hw_frame = (clock >> 3);
+			if (ehci->hw_frame != hw_frame) {
+				free_cached_itd_list(ehci);
+				ehci->hw_frame = hw_frame;
+			}
 		} else {
 			now_uframe++;
 			now_uframe %= mod;

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: (no subject)

[Karsten Wiese]

Am Dienstag, 14. Oktober 2008 schrieb Philippe Carriere:
> Might this patch (the original one, without features yet implemented in
> 2.6.26, and an extremely slight modification to fit it) I use on Fedora
> kernel (the patch also applies as it stands to vanilla) save works and
> time ?

maybe.
I guess the patch would have to fit what will become 2.6.28.


regards,
Karsten

Re: (no subject)

[Karsten Wiese]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

Am Dienstag, 14. Oktober 2008 schrieb Philippe Carriere:
> Might this patch (the original one, without features yet implemented in
> 2.6.26, and an extremely slight modification to fit it) I use on Fedora
> kernel (the patch also applies as it stands to vanilla) save works and
> time ?

I resent the patch to linux-usb@vger.kernel.org today.
Maybe it helps, if you post a "tested-by:" there.

Regards,
Karsten


[-- Attachment #2: Karsten Wiese <fzu@wemgehoertderstaat.de>: [RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is active --]
[-- Type: message/rfc822, Size: 6854 bytes --]

From: Karsten Wiese <fzu@wemgehoertderstaat.de>
To: David Brownell <david-b@pacbell.net>
Cc: linux-usb@vger.kernel.org
Subject: [RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is active
Date: Mon, 26 Jan 2009 14:32:51 +0100
Message-ID: <200901261432.51974.fzu@wemgehoertderstaat.de>

Hi,

this is a refresh to let patch fit ontop 2.6.29-rc2.
Changes from previous version:
- use variable clock_frame instead of hw_frame
- Patch Description exactified
snd_usb_us122l (in kernel since .28) needs it, if device is attached to
ehci.

thanks,
Karsten



----------------------------------------------------------------------
From: Karsten Wiese <fzu@wemgehoertderstaat.de>
Date: Wed, 13 Feb 2008 22:22:09 +0100
Subject: [PATCH] USB: Prevent EHCI ITDs reusage while frame is active

ITDs can be detached from urbs, before the frame elapses. Now those ITDs are
immediately recycled.
If the ITD is reused before the frame elapses, the ITD becomes invalid
regarding the not yet elapsed frame.
Patch takes care of those ITDs by moving them into a new ehci member list
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>

---
 drivers/usb/host/ehci-hcd.c   |    2 +
 drivers/usb/host/ehci-mem.c   |    1 +
 drivers/usb/host/ehci-sched.c |   54 ++++++++++++++++++++++++++++++++++------
 drivers/usb/host/ehci.h       |    5 ++++
 4 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4725d15..e551bb3 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -485,6 +485,7 @@ static int ehci_init(struct usb_hcd *hcd)
 	 * periodic_size can shrink by USBCMD update if hcc_params allows.
 	 */
 	ehci->periodic_size = DEFAULT_I_TDPS;
+	INIT_LIST_HEAD(&ehci->cached_itd_list);
 	if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
 		return retval;
 
@@ -497,6 +498,7 @@ static int ehci_init(struct usb_hcd *hcd)
 
 	ehci->reclaim = NULL;
 	ehci->next_uframe = -1;
+	ehci->clock_frame = -1;
 
 	/*
 	 * dedicate a qh for the async ring head, since we couldn't unlink
diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 0431397..10d5291 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -128,6 +128,7 @@ static inline void qh_put (struct ehci_qh *qh)
 
 static void ehci_mem_cleanup (struct ehci_hcd *ehci)
 {
+	free_cached_itd_list(ehci);
 	if (ehci->async)
 		qh_put (ehci->async);
 	ehci->async = NULL;
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index a081ee6..c1f7d5f 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1004,7 +1004,8 @@ iso_stream_put(struct ehci_hcd *ehci, struct ehci_iso_stream *stream)
 
 		is_in = (stream->bEndpointAddress & USB_DIR_IN) ? 0x10 : 0;
 		stream->bEndpointAddress &= 0x0f;
-		stream->ep->hcpriv = NULL;
+		if (stream->ep)
+			stream->ep->hcpriv = NULL;
 
 		if (stream->rescheduled) {
 			ehci_info (ehci, "ep%d%s-iso rescheduled "
@@ -1653,14 +1654,26 @@ itd_complete (
 			(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
 	}
 	iso_stream_put (ehci, stream);
-	/* OK to recycle this ITD now that its completion callback ran. */
+
 done:
 	usb_put_urb(urb);
 	itd->urb = NULL;
-	itd->stream = NULL;
-	list_move(&itd->itd_list, &stream->free_list);
-	iso_stream_put(ehci, stream);
-
+	if (ehci->clock_frame != itd->frame || itd->index[7] != -1) {
+		/* OK to recycle this ITD now. */
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	} else {
+		/* HW might still start transactions based on this ITD.
+		   If its content changed that is. Move it to a safe place. */
+		list_move(&itd->itd_list, &ehci->cached_itd_list);
+		if (stream->refcount == 2) {
+			/* If iso_stream_put() would be called here, stream
+			   would be freed. Prevent stream's reusage instead. */
+			stream->ep->hcpriv = NULL;
+			stream->ep = NULL;
+		}
+	}
 	return retval;
 }
 
@@ -2101,6 +2114,20 @@ done:
 
 /*-------------------------------------------------------------------------*/
 
+static void free_cached_itd_list(struct ehci_hcd *ehci)
+{
+	struct ehci_itd *itd, *n;
+
+	list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
+		struct ehci_iso_stream	*stream = itd->stream;
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	}
+}
+
+/*-------------------------------------------------------------------------*/
+
 static void
 scan_periodic (struct ehci_hcd *ehci)
 {
@@ -2115,10 +2142,17 @@ scan_periodic (struct ehci_hcd *ehci)
 	 * Touches as few pages as possible:  cache-friendly.
 	 */
 	now_uframe = ehci->next_uframe;
-	if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state))
+	if (HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
 		clock = ehci_readl(ehci, &ehci->regs->frame_index);
-	else
+		clock_frame = (clock >> 3) % ehci->periodic_size;
+	} else  {
 		clock = now_uframe + mod - 1;
+		clock_frame = -1;
+	}
+	if (ehci->clock_frame != clock_frame) {
+		free_cached_itd_list(ehci);
+		ehci->clock_frame = clock_frame;
+	}
 	clock %= mod;
 	clock_frame = clock >> 3;
 
@@ -2277,6 +2311,10 @@ restart:
 			/* rescan the rest of this frame, then ... */
 			clock = now;
 			clock_frame = clock >> 3;
+			if (ehci->clock_frame != clock_frame) {
+				free_cached_itd_list(ehci);
+				ehci->clock_frame = clock_frame;
+			}
 		} else {
 			now_uframe++;
 			now_uframe %= mod;
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index fb7054c..5262fb7 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -86,6 +86,9 @@ struct ehci_hcd {			/* one per controller */
 	union ehci_shadow	*pshadow;	/* mirror hw periodic table */
 	int			next_uframe;	/* scan periodic, start here */
 	unsigned		periodic_sched;	/* periodic activity count */
+	struct list_head	cached_itd_list; /* list of itds completed
+						    while frame hadn't yet elapsed */
+	unsigned		clock_frame;
 
 	/* per root hub port */
 	unsigned long		reset_done [EHCI_MAX_ROOT_PORTS];
@@ -220,6 +223,8 @@ timer_action (struct ehci_hcd *ehci, enum ehci_timer_action action)
 	}
 }
 
+static void free_cached_itd_list(struct ehci_hcd *ehci);
+
 /*-------------------------------------------------------------------------*/
 
 #include <linux/usb/ehci_def.h>
-- 
1.6.0.6


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: (no subject)

[Philippe Carriere]

[-- Attachment #1: Type: text/plain, Size: 8455 bytes --]

Hi Karsten,

I successfully tested your new version of the patch and sent a
"tested:by" to linux-usb@vger.kernel.org today (see attached).
Hope it will speed up the process.

Regards,

Phil.

Le mardi 27 janvier 2009 à 01:16 +0100, Karsten Wiese a écrit :
> Am Dienstag, 14. Oktober 2008 schrieb Philippe Carriere:
> > Might this patch (the original one, without features yet implemented in
> > 2.6.26, and an extremely slight modification to fit it) I use on Fedora
> > kernel (the patch also applies as it stands to vanilla) save works and
> > time ?
> 
> I resent the patch to linux-usb@vger.kernel.org today.
> Maybe it helps, if you post a "tested-by:" there.
> 
> Regards,
> Karsten
> 
> pièce jointe message de courriel (forwarded message), "Karsten Wiese
> <fzu@wemgehoertderstaat.de>: [RESEND][PATCH] USB: Prevent EHCI ITDs
> reusage while frame is active"
> > -------- Message transféré --------
> > De: Karsten Wiese <fzu@wemgehoertderstaat.de>
> > À: David Brownell <david-b@pacbell.net>
> > Cc: linux-usb@vger.kernel.org
> > Sujet: [RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is
> > active
> > Date: Mon, 26 Jan 2009 14:32:51 +0100
> > 
> > pièce jointe document texte brut (forwarded message)
> > Hi,
> > 
> > this is a refresh to let patch fit ontop 2.6.29-rc2.
> > Changes from previous version:
> > - use variable clock_frame instead of hw_frame
> > - Patch Description exactified
> > snd_usb_us122l (in kernel since .28) needs it, if device is attached to
> > ehci.
> > 
> > thanks,
> > Karsten
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > From: Karsten Wiese <fzu@wemgehoertderstaat.de>
> > Date: Wed, 13 Feb 2008 22:22:09 +0100
> > Subject: [PATCH] USB: Prevent EHCI ITDs reusage while frame is active
> > 
> > ITDs can be detached from urbs, before the frame elapses. Now those ITDs are
> > immediately recycled.
> > If the ITD is reused before the frame elapses, the ITD becomes invalid
> > regarding the not yet elapsed frame.
> > Patch takes care of those ITDs by moving them into a new ehci member list
> > cached_itd_list. ITDs resting in cached_itd_list are moved back into their
> > stream's free_list once scan_periodic() detects that the active frame has
> > elapsed.
> > 
> > Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
> > 
> > ---
> >  drivers/usb/host/ehci-hcd.c   |    2 +
> >  drivers/usb/host/ehci-mem.c   |    1 +
> >  drivers/usb/host/ehci-sched.c |   54 ++++++++++++++++++++++++++++++++++------
> >  drivers/usb/host/ehci.h       |    5 ++++
> >  4 files changed, 54 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> > index 4725d15..e551bb3 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -485,6 +485,7 @@ static int ehci_init(struct usb_hcd *hcd)
> >  	 * periodic_size can shrink by USBCMD update if hcc_params allows.
> >  	 */
> >  	ehci->periodic_size = DEFAULT_I_TDPS;
> > +	INIT_LIST_HEAD(&ehci->cached_itd_list);
> >  	if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
> >  		return retval;
> >  
> > @@ -497,6 +498,7 @@ static int ehci_init(struct usb_hcd *hcd)
> >  
> >  	ehci->reclaim = NULL;
> >  	ehci->next_uframe = -1;
> > +	ehci->clock_frame = -1;
> >  
> >  	/*
> >  	 * dedicate a qh for the async ring head, since we couldn't unlink
> > diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
> > index 0431397..10d5291 100644
> > --- a/drivers/usb/host/ehci-mem.c
> > +++ b/drivers/usb/host/ehci-mem.c
> > @@ -128,6 +128,7 @@ static inline void qh_put (struct ehci_qh *qh)
> >  
> >  static void ehci_mem_cleanup (struct ehci_hcd *ehci)
> >  {
> > +	free_cached_itd_list(ehci);
> >  	if (ehci->async)
> >  		qh_put (ehci->async);
> >  	ehci->async = NULL;
> > diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> > index a081ee6..c1f7d5f 100644
> > --- a/drivers/usb/host/ehci-sched.c
> > +++ b/drivers/usb/host/ehci-sched.c
> > @@ -1004,7 +1004,8 @@ iso_stream_put(struct ehci_hcd *ehci, struct ehci_iso_stream *stream)
> >  
> >  		is_in = (stream->bEndpointAddress & USB_DIR_IN) ? 0x10 : 0;
> >  		stream->bEndpointAddress &= 0x0f;
> > -		stream->ep->hcpriv = NULL;
> > +		if (stream->ep)
> > +			stream->ep->hcpriv = NULL;
> >  
> >  		if (stream->rescheduled) {
> >  			ehci_info (ehci, "ep%d%s-iso rescheduled "
> > @@ -1653,14 +1654,26 @@ itd_complete (
> >  			(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
> >  	}
> >  	iso_stream_put (ehci, stream);
> > -	/* OK to recycle this ITD now that its completion callback ran. */
> > +
> >  done:
> >  	usb_put_urb(urb);
> >  	itd->urb = NULL;
> > -	itd->stream = NULL;
> > -	list_move(&itd->itd_list, &stream->free_list);
> > -	iso_stream_put(ehci, stream);
> > -
> > +	if (ehci->clock_frame != itd->frame || itd->index[7] != -1) {
> > +		/* OK to recycle this ITD now. */
> > +		itd->stream = NULL;
> > +		list_move(&itd->itd_list, &stream->free_list);
> > +		iso_stream_put(ehci, stream);
> > +	} else {
> > +		/* HW might still start transactions based on this ITD.
> > +		   If its content changed that is. Move it to a safe place. */
> > +		list_move(&itd->itd_list, &ehci->cached_itd_list);
> > +		if (stream->refcount == 2) {
> > +			/* If iso_stream_put() would be called here, stream
> > +			   would be freed. Prevent stream's reusage instead. */
> > +			stream->ep->hcpriv = NULL;
> > +			stream->ep = NULL;
> > +		}
> > +	}
> >  	return retval;
> >  }
> >  
> > @@ -2101,6 +2114,20 @@ done:
> >  
> >  /*-------------------------------------------------------------------------*/
> >  
> > +static void free_cached_itd_list(struct ehci_hcd *ehci)
> > +{
> > +	struct ehci_itd *itd, *n;
> > +
> > +	list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
> > +		struct ehci_iso_stream	*stream = itd->stream;
> > +		itd->stream = NULL;
> > +		list_move(&itd->itd_list, &stream->free_list);
> > +		iso_stream_put(ehci, stream);
> > +	}
> > +}
> > +
> > +/*-------------------------------------------------------------------------*/
> > +
> >  static void
> >  scan_periodic (struct ehci_hcd *ehci)
> >  {
> > @@ -2115,10 +2142,17 @@ scan_periodic (struct ehci_hcd *ehci)
> >  	 * Touches as few pages as possible:  cache-friendly.
> >  	 */
> >  	now_uframe = ehci->next_uframe;
> > -	if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state))
> > +	if (HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
> >  		clock = ehci_readl(ehci, &ehci->regs->frame_index);
> > -	else
> > +		clock_frame = (clock >> 3) % ehci->periodic_size;
> > +	} else  {
> >  		clock = now_uframe + mod - 1;
> > +		clock_frame = -1;
> > +	}
> > +	if (ehci->clock_frame != clock_frame) {
> > +		free_cached_itd_list(ehci);
> > +		ehci->clock_frame = clock_frame;
> > +	}
> >  	clock %= mod;
> >  	clock_frame = clock >> 3;
> >  
> > @@ -2277,6 +2311,10 @@ restart:
> >  			/* rescan the rest of this frame, then ... */
> >  			clock = now;
> >  			clock_frame = clock >> 3;
> > +			if (ehci->clock_frame != clock_frame) {
> > +				free_cached_itd_list(ehci);
> > +				ehci->clock_frame = clock_frame;
> > +			}
> >  		} else {
> >  			now_uframe++;
> >  			now_uframe %= mod;
> > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> > index fb7054c..5262fb7 100644
> > --- a/drivers/usb/host/ehci.h
> > +++ b/drivers/usb/host/ehci.h
> > @@ -86,6 +86,9 @@ struct ehci_hcd {			/* one per controller */
> >  	union ehci_shadow	*pshadow;	/* mirror hw periodic table */
> >  	int			next_uframe;	/* scan periodic, start here */
> >  	unsigned		periodic_sched;	/* periodic activity count */
> > +	struct list_head	cached_itd_list; /* list of itds completed
> > +						    while frame hadn't yet elapsed */
> > +	unsigned		clock_frame;
> >  
> >  	/* per root hub port */
> >  	unsigned long		reset_done [EHCI_MAX_ROOT_PORTS];
> > @@ -220,6 +223,8 @@ timer_action (struct ehci_hcd *ehci, enum ehci_timer_action action)
> >  	}
> >  }
> >  
> > +static void free_cached_itd_list(struct ehci_hcd *ehci);
> > +
> >  /*-------------------------------------------------------------------------*/
> >  
> >  #include <linux/usb/ehci_def.h>

-- 
Philippe Carriere <philippe-f.carriere@wanadoo.fr>

[-- Attachment #2: tested_by:_Philippe_Carriere.txt --]
[-- Type: text/plain, Size: 11199 bytes --]

>From philippe-f.carriere@wanadoo.fr Thu Jan 29 09:30:07 2009
Subject: [RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is
 active: tested by: Philippe Carriere.
From: Philippe Carriere <philippe-f.carriere@wanadoo.fr>
To: linux-usb@vger.kernel.org
Content-Type: multipart/mixed; boundary="=-VmmaepDIq/JbLd+TeS0C"
Message-Id: <1233217786.3257.20.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.3 (2.24.3-1.fc10) 
Date: Thu, 29 Jan 2009 09:30:07 +0100
X-Evolution-Format: text/plain
X-Evolution-Account: 1197104178.3652.20@pollux.mecaflu.ec-lyon.fr
X-Evolution-Transport:
 smtp://philippe-f.carriere;auth=PLAIN@smtp.wanadoo.fr/;use_ssl=never
X-Evolution-Fcc: mbox:/home/philippe/.evolution/mail/local#Sent


--=-VmmaepDIq/JbLd+TeS0C
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

 Hi,

I successfully tested the refreshed patch of Karsten using Fedora
rawhide packages. Following are  some informations on the test:

original kernel: 2.6.29-0.53.rc2.git1.fc11.x86_64
patched kernel: Linux 2.6.29-0.53.rc2.git1.ehcius122l.fc11.x86_64 #1 SMP
Wed Jan 28 22:48:01 CET 2009 x86_64 x86_64 x86_64 GNU/Linux
alsa: alsa-lib-1.0.19-1.fc11, alsa-plugins-usbstream-1.0.18
jack: jack-audio-connection-kit-0.116.1-3.fc11
qjackctl: qjackctl-0.3.3-1.fc10
audacious: audacious-1.5.1-5.fc11

after plugin the Tascam US-122L:

[root@pollux Test]# tail /var/log/messages
Jan 29 08:05:53 pollux kernel: usb 2-6: new high speed USB device using
ehci_hcd and address 4
Jan 29 08:05:53 pollux kernel: usb 2-6: config 1 interface 1 altsetting
1 bulk endpoint 0x83 has invalid maxpacket 9
Jan 29 08:05:53 pollux kernel: usb 2-6: New USB device found,
idVendor=0644, idProduct=800e
Jan 29 08:05:53 pollux kernel: usb 2-6: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Jan 29 08:05:53 pollux kernel: usb 2-6: Product: US-122L
Jan 29 08:05:53 pollux kernel: usb 2-6: Manufacturer: TASCAM
Jan 29 08:05:53 pollux kernel: usb 2-6: SerialNumber: no serial number
Jan 29 08:05:53 pollux kernel: usb 2-6: configuration #1 chosen from 1
choice
Jan 29 08:06:08 pollux kernel: ALSA sound/usb/usx2y/usb_stream.c:457:
underrun, status=4294967278
Jan 29 08:06:08 pollux kernel: ALSA sound/usb/usx2y/usb_stream.c:457:
underrun, status=4294967278

[root@pollux Test]# cat /proc/asound/cards
0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfebfc000 irq 21
1 [US122L         ]: USB US-122L - TASCAM US-122L
                      TASCAM US-122L (644:800e if 0 at 002/004)


and jack messages were

08:50:00.226 /usr/bin/jackd -R -P89 -dalsa -dusb_stream:1 -r48000 -p512
-n2
jackd 0.116.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
08:50:00.251 JACK was started with PID=6417.
loading driver ..
apparent rate = 48000
creating alsa driver ... usb_stream:1|usb_stream:1|512|2|48000|0|0|
nomon|swmeter|-|32bit
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL usb_stream:1
control open "usb_stream:1" (No such file or directory)
configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2
periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback
08:50:02.397 Server configuration saved to "/home/Test/.jackdrc".
08:50:02.398 Statistics reset.
08:50:02.547 Client activated.
08:50:02.550 JACK connection change.
08:50:02.558 JACK connection graph change.

Tested by .mp3 file playback using audacious (with plugin jack).

Additional notes: the previous version of the patch is routinely used by
myself, at least some Fedora users using my packages at
http://pagesperso-orange.fr/La-page-Web-of-Phil/Tascam_US-122L/Telechargement_us122l.html , and under Debian and Ubuntu (Federico Briata web site at http://wiki.briata.org/doku.php?id=testing_us122l_under_linux ) under 2.6.26 and 2.6.27 kernel.

Hope it will be soon integrated to 2.6.29 devel.

Regards

Phil.


--=-VmmaepDIq/JbLd+TeS0C
Content-Disposition: attachment; filename="forwarded_message"
Content-Type: message/rfc822; name="forwarded_message"

From: Karsten Wiese <fzu@wemgehoertderstaat.de>
To: David Brownell <david-b@pacbell.net>
Subject: [RESEND][PATCH] USB: Prevent EHCI ITDs reusage while frame is
 active
Date: Mon, 26 Jan 2009 14:32:51 +0100
User-Agent: KMail/1.9.9
Cc: linux-usb@vger.kernel.org
References: <200802132238.51929.fzu@wemgehoertderstaat.de>
	 <200803171405.02530.fzu@wemgehoertderstaat.de>
	 <200805201315.08008.fzu@wemgehoertderstaat.de>
In-Reply-To: <200805201315.08008.fzu@wemgehoertderstaat.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <200901261432.51974.fzu@wemgehoertderstaat.de>
Content-Transfer-Encoding: 8bit

Hi,

this is a refresh to let patch fit ontop 2.6.29-rc2.
Changes from previous version:
- use variable clock_frame instead of hw_frame
- Patch Description exactified
snd_usb_us122l (in kernel since .28) needs it, if device is attached to
ehci.

thanks,
Karsten



----------------------------------------------------------------------
From: Karsten Wiese <fzu@wemgehoertderstaat.de>
Date: Wed, 13 Feb 2008 22:22:09 +0100
Subject: [PATCH] USB: Prevent EHCI ITDs reusage while frame is active

ITDs can be detached from urbs, before the frame elapses. Now those ITDs are
immediately recycled.
If the ITD is reused before the frame elapses, the ITD becomes invalid
regarding the not yet elapsed frame.
Patch takes care of those ITDs by moving them into a new ehci member list
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>

---
 drivers/usb/host/ehci-hcd.c   |    2 +
 drivers/usb/host/ehci-mem.c   |    1 +
 drivers/usb/host/ehci-sched.c |   54 ++++++++++++++++++++++++++++++++++------
 drivers/usb/host/ehci.h       |    5 ++++
 4 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4725d15..e551bb3 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -485,6 +485,7 @@ static int ehci_init(struct usb_hcd *hcd)
 	 * periodic_size can shrink by USBCMD update if hcc_params allows.
 	 */
 	ehci->periodic_size = DEFAULT_I_TDPS;
+	INIT_LIST_HEAD(&ehci->cached_itd_list);
 	if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
 		return retval;
 
@@ -497,6 +498,7 @@ static int ehci_init(struct usb_hcd *hcd)
 
 	ehci->reclaim = NULL;
 	ehci->next_uframe = -1;
+	ehci->clock_frame = -1;
 
 	/*
 	 * dedicate a qh for the async ring head, since we couldn't unlink
diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 0431397..10d5291 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -128,6 +128,7 @@ static inline void qh_put (struct ehci_qh *qh)
 
 static void ehci_mem_cleanup (struct ehci_hcd *ehci)
 {
+	free_cached_itd_list(ehci);
 	if (ehci->async)
 		qh_put (ehci->async);
 	ehci->async = NULL;
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index a081ee6..c1f7d5f 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1004,7 +1004,8 @@ iso_stream_put(struct ehci_hcd *ehci, struct ehci_iso_stream *stream)
 
 		is_in = (stream->bEndpointAddress & USB_DIR_IN) ? 0x10 : 0;
 		stream->bEndpointAddress &= 0x0f;
-		stream->ep->hcpriv = NULL;
+		if (stream->ep)
+			stream->ep->hcpriv = NULL;
 
 		if (stream->rescheduled) {
 			ehci_info (ehci, "ep%d%s-iso rescheduled "
@@ -1653,14 +1654,26 @@ itd_complete (
 			(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
 	}
 	iso_stream_put (ehci, stream);
-	/* OK to recycle this ITD now that its completion callback ran. */
+
 done:
 	usb_put_urb(urb);
 	itd->urb = NULL;
-	itd->stream = NULL;
-	list_move(&itd->itd_list, &stream->free_list);
-	iso_stream_put(ehci, stream);
-
+	if (ehci->clock_frame != itd->frame || itd->index[7] != -1) {
+		/* OK to recycle this ITD now. */
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	} else {
+		/* HW might still start transactions based on this ITD.
+		   If its content changed that is. Move it to a safe place. */
+		list_move(&itd->itd_list, &ehci->cached_itd_list);
+		if (stream->refcount == 2) {
+			/* If iso_stream_put() would be called here, stream
+			   would be freed. Prevent stream's reusage instead. */
+			stream->ep->hcpriv = NULL;
+			stream->ep = NULL;
+		}
+	}
 	return retval;
 }
 
@@ -2101,6 +2114,20 @@ done:
 
 /*-------------------------------------------------------------------------*/
 
+static void free_cached_itd_list(struct ehci_hcd *ehci)
+{
+	struct ehci_itd *itd, *n;
+
+	list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
+		struct ehci_iso_stream	*stream = itd->stream;
+		itd->stream = NULL;
+		list_move(&itd->itd_list, &stream->free_list);
+		iso_stream_put(ehci, stream);
+	}
+}
+
+/*-------------------------------------------------------------------------*/
+
 static void
 scan_periodic (struct ehci_hcd *ehci)
 {
@@ -2115,10 +2142,17 @@ scan_periodic (struct ehci_hcd *ehci)
 	 * Touches as few pages as possible:  cache-friendly.
 	 */
 	now_uframe = ehci->next_uframe;
-	if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state))
+	if (HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
 		clock = ehci_readl(ehci, &ehci->regs->frame_index);
-	else
+		clock_frame = (clock >> 3) % ehci->periodic_size;
+	} else  {
 		clock = now_uframe + mod - 1;
+		clock_frame = -1;
+	}
+	if (ehci->clock_frame != clock_frame) {
+		free_cached_itd_list(ehci);
+		ehci->clock_frame = clock_frame;
+	}
 	clock %= mod;
 	clock_frame = clock >> 3;
 
@@ -2277,6 +2311,10 @@ restart:
 			/* rescan the rest of this frame, then ... */
 			clock = now;
 			clock_frame = clock >> 3;
+			if (ehci->clock_frame != clock_frame) {
+				free_cached_itd_list(ehci);
+				ehci->clock_frame = clock_frame;
+			}
 		} else {
 			now_uframe++;
 			now_uframe %= mod;
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index fb7054c..5262fb7 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -86,6 +86,9 @@ struct ehci_hcd {			/* one per controller */
 	union ehci_shadow	*pshadow;	/* mirror hw periodic table */
 	int			next_uframe;	/* scan periodic, start here */
 	unsigned		periodic_sched;	/* periodic activity count */
+	struct list_head	cached_itd_list; /* list of itds completed
+						    while frame hadn't yet elapsed */
+	unsigned		clock_frame;
 
 	/* per root hub port */
 	unsigned long		reset_done [EHCI_MAX_ROOT_PORTS];
@@ -220,6 +223,8 @@ timer_action (struct ehci_hcd *ehci, enum ehci_timer_action action)
 	}
 }
 
+static void free_cached_itd_list(struct ehci_hcd *ehci);
+
 /*-------------------------------------------------------------------------*/
 
 #include <linux/usb/ehci_def.h>
-- 
1.6.0.6


--=-VmmaepDIq/JbLd+TeS0C--

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

(no subject)

[Swapna Shingre]

[-- Attachment #1.1: Type: text/plain, Size: 167 bytes --]

hi all,
  can anyone tell me what exactly the iret hypercall does?
and, is there any way to disable the fast system call handlers and use
normal system call handling?

[-- Attachment #1.2: Type: text/html, Size: 204 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[Peter Leckie]

mod xfs-linux-melb:xfs-kern:32215a TAKE message
================================================
Subject: TAKE 986789 - 

Clean up dquot pincount code.

This is a code cleanup and optimization that removes a per mount point
spinlock from the quota code and cleans up the code.

The patch changes the pincount from being an int protected by a spinlock
to an atomic_t allowing the pincount to be manipulated without holding
the spinlock.

This cleanup also protects against random wakup's of both the aild and
xfssyncd by reevaluating the pincount after been woken. Two latter patches
will address the Spurious wakeups.

Signed-off-by: Peter Leckie <pleckie@sgi.com>

Date:  Fri Sep 26 14:42:30 AEST 2008
Workarea:  chook.melbourne.sgi.com:/build/pleckie/2.6.x-xfs
Inspected by:  
donaldd
lachlan
hch@lst.de
david@fromorbit.com
Author:  pleckie

The following file(s) were checked into:
  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb


Modid:  xfs-linux-melb:xfs-kern:32215a
fs/xfs/xfsidbg.c - 1.367 - changed
fs/xfs/quota/xfs_dquot_item.c - 1.24 - changed
fs/xfs/quota/xfs_dquot.h - 1.14 - changed
fs/xfs/quota/xfs_dquot.c - 1.39 - changed
fs/xfs/quota/xfs_qm.h - 1.21 - changed
fs/xfs/quota/xfs_qm.c - 1.75 - changed
	- Clean up dquot pincount code.

(no subject)

[James Song]

I test stubdom in xen-3.3.1, when I start it,  just see the message bellow using "xm li" . It seems stubdom haven't start. 

Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   964     2     r-----     34.8
hvmachine                                    1  1024     1     ------      0.0

   the two config files : 
#hvmachine
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =  256
name = "hvmachine"
vcpus=2
vif = [ 'type=ioemu, bridge=eth0' ]
device_model = '/usr/lib/xen/bin/stubdom-dm'
boot="cd"
sdl=0
opengl=0
vnc=1
vnclisten="172.30.206.1"
stdvga=0
-------------------------------------------------------------------------


#hvmachine-dm
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
vif = [ 'ip=172.30.206.1', 'bridge=eth0,mac=00:16:3e:21:a2:94' ]
disk = [ 'file:/home/images/opensuse11-2/disk0,hda,w' ]



what's wrong I make?


best regards,
-- James

(no subject)

[Greg]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[Fabian Ischia]

subscribe netdev

(no subject)

[Franco Fichtner]

subscribe

(no subject)

[lisandro1]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[toto eucup]

      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(no subject)

[Ben Dooks]

The following changes since commit c9272c4f9fbe2087beb3392f526dc5b19efaa56b:
  Linus Torvalds (1):
        Merge branch 'hotfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6

are available in the git repository at:

  git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-linus

Ben Dooks (4):
      i2c: S3C2410: Pass the I2C bus number via drivers platform data
      i2c: i2c_gpio: keep probe resident for hotplugged devices.
      i2c: S3C24XX I2C frequency scaling support.
      i2c: Documentation: upgrading clients HOWTO

Michael Hennerich (1):
      i2c: Blackfin I2C Driver: Functional power management support

 Documentation/i2c/upgrading-clients |  281 +++++++++++++++++++++++++++++++++++
 drivers/i2c/busses/i2c-bfin-twi.c   |   35 +++--
 drivers/i2c/busses/i2c-gpio.c       |    9 +-
 drivers/i2c/busses/i2c-s3c2410.c    |  129 ++++++++++++++--
 include/asm-arm/plat-s3c/iic.h      |    1 +
 5 files changed, 426 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/i2c/upgrading-clients

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

(no subject)

[Kevin Phair]

subscribe

(no subject)

[Jesper Krogh]

subscribe linux-scsi

(no subject)

[Dragos Ilie]

subscribe netdev

(no subject)

[林先生]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]


         尊敬的公司（领导/财务）负责人：

             您好！

             我司深圳市广航实业有限公司，是一家生产、销售、

         贸易与一体的一般纳税人企业，享有税收优惠政策，长

         期与国内各省市多家企业合作。凭着雄厚的经营（在报

         税、做帐方面积累有丰富的经验）实力、良好信誉、平

         等互利、诚信服务的宗旨。可为贵公司代开海关缴款书、

         增值税发票点数为7%，商品销售、建筑安装、运输、

         广告、其它服务等普通国税发票点数为2%（税率优惠）

         ，可提供交易手续，保证票源绝对正规，可在电脑网络

         查询，欢迎来电洽谈，真诚希望与您合作！

             祝贵公司生意兴隆！财源广进！

                         联 系 人：林先生       

                         联系电话：13622595316




[-- Attachment #1.2: Type: text/html, Size: 2289 bytes --]

[-- Attachment #2: ad0.gif --]
[-- Type: application/octet-stream, Size: 6180 bytes --]

[-- Attachment #3: Type: text/plain, Size: 230 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[林先生]

[-- Attachment #1.1: Type: text/plain, Size: 761 bytes --]


         尊敬的公司（领导/财务）负责人：

             您好！

             我司深圳市广航实业有限公司，是一家生产、销售、

         贸易与一体的一般纳税人企业，享有税收优惠政策，长

         期与国内各省市多家企业合作。凭着雄厚的经营（在报

         税、做帐方面积累有丰富的经验）实力、良好信誉、平

         等互利、诚信服务的宗旨。可为贵公司代开海关缴款书、

         增值税发票点数为7%，商品销售、建筑安装、运输、

         广告、其它服务等普通国税发票点数为2%（税率优惠）

         ，可提供交易手续，保证票源绝对正规，可在电脑网络

         查询，欢迎来电洽谈，真诚希望与您合作！

             祝贵公司生意兴隆！财源广进！

                         联 系 人：林先生       

                         联系电话：13622595316




[-- Attachment #1.2: Type: text/html, Size: 2289 bytes --]

[-- Attachment #2: ad1.gif --]
[-- Type: application/octet-stream, Size: 4901 bytes --]

[-- Attachment #3: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Jim Carter]

Our two webservers serve UserDirs that are automounted (NFS) from other
hosts.  Every few days we discover a catatonic webserver (Apache2) with
$ServerLimit child processes (150 of them), and many but not all home
directories cannot be accessed manually (ls -d ~$user, which hangs).
This started immediately after we upgraded the server host from SuSE
10.1 to SuSE 10.3; autofs version changed from 4.1.4 to 5.0.2.

A test program reproduces the problem.  First it identifies all
filesystems that can be NFS/auto mounted.  Then it goes through
/proc/mounts and for each one that is not currently mounted, it forks a
process which enumerates the mountpoint directory, causing automounting.
This is repeated every 2 secs, so when automount unmounts a directory
the test program promptly makes it get mounted again.  With our about
250 exported filesystems and default (5 min.) timeout, the test does
about 1 unmount-mount pair per second on average.  Simultaneous 
mounting and unmounting is a distinct possibility.

The program will run for 15 minutes to 1 hour with no failures, but then
directory-reading processes will start to hang.  My impression is that
about half of them hang.  (Like the webserver, the program gives up when
too many subprocesses are hung.)  If I kill and restart autofs, the test
program can be run again with similar behavior, i.e. runs for a while
with no failures, then starts hanging.  I do *not* see hanging mount
commands; they either succeed or fail and promptly exit.  The hung
directory-reading processes do not respond to SIGTERM but can be killed
with SIGKILL.

If I revert autofs back to 4.1.4 the test program can run for over 4
hours with no hangs (but with occasional, tolerable issues from the
obsolete version).  This is with module autofs4.ko from kernel
2.6.22.17, not compiling and reverting to an older module.  We have
reverted autofs on the webservers to avoid being lynched by our faculty.

I was hoping to include debug output from autofs, but when I set
DEFAULT_LOGGING=debug and started the test program it totally locked up
the machine and I haven't been able to get on it since (because I'm
working from home).  Update: a co-worker rebooted it for me and I was
able to clear the debug switch and recover the syslog output (attached).
But evidently the test program also seized up; I don't see a lot of
actual mounting going on.  Anyway I've included it, for what it's worth.

I was hoping to include useful strace output, and I have 80 Mbytes of
turgid information (on a different machine), but I have a feeling that
it's going to be more useful to include the test program and let 
someone overload their own testbed system.  Here's my impression of the
traces:  

Due to the structure of my map files, the autofs main process spawns a
thread for each host, and that thread spawns another thread that forks
and execve's /bin/mount or /bin/umount, which forks and execve's
/sbin/mount.nfs or /sbin/umount.nfs.  I followed ten of these threads
and each one exited seemingly normally.  I followed one (a mounter) in
line-by-line detail and everything was entirely plausible without any
apparent errors.  Others which were followed less meticulously also
seemed error-free.  During one segment of 10 Mbytes of tracing, lasting
62 elapsed secs, during the period when lots of client threads were
hanging, there were 88 execve(..., "/sbin/mount.nfs"...) and 226
execve("/sbin/umount.nfs").  Each time a filesystem was unmounted the
test script should have accessed it within 2 seconds, but evidently
about 2/3 of the access events did not result in spawning
/sbin/umount.nfs followed by letting the client's readdir finish.

I'm not able to identify where the main thread is getting notified of
which filesystem to automount.  It only seems to wait on a futex that
either times out or returns EAGAIN, call time(), and clone subthreads.
(Shared memory?)  Thus I can't tell whether the main thread was notified
but lost the information, or whether the kernel module failed to notify
userspace.

/bin/mount used to have notorious problems locking /etc/mtab.  But I
compare /etc/mtab with /proc/mounts before forking the directory access
process, and it was the same on several thousand comparisons with only
two unequal comparisons; in both cases the filesystem about to be
accessed (remounted) was in mtab and not /proc/mounts, and at most 8
seconds later it was in both and the content had been read.  2 minutes
after the second such event, and 38 minutes into the test run, client
processes started to hang.

Here are the particulars of our autofs setup.

Distro:		OpenSuSE 10.3
Kernel:		2.6.22.17 (kernel-default-2.6.22.17-0.1)
Autofs:		5.0.2-30.2 (recompiled with the DNS timeout mitigation 
		patch that Ian Kent made for us) (and identical behavior 
		without the patch)
Mount program:	util-linux-2.12r+2.13rc2+git20070725-24.2 (/bin/mount)
NFS:		nfs-client-1.1.0-8 (/sbin/mount.nfs)

=-- auto.master --- (comments omitted in all conf files)
/net            /etc/auto.net		<== giving trouble
/home           yp:auto.home

=-- auto.net ---
*       -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=&    file:/etc/auto.net.generic

=-- auto.net.generic ---
*       ${SERVER}:/&

(The effect is that when you refer to /net/$HOST/$DIR it starts a 
thread for $HOST which then mounts the exported filesystem(s).)

=-- nsswitch.conf --
passwd:         compat nis
shadow:         compat nis
group:          compat nis

hosts:          files dns
networks:       files dns

netgroup:       nis
aliases:        files nis

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
publickey:      files

bootparams:     files
automount:      files

=-- /etc/sysconfig/autofs --- (comments deleted)
AUTOFS_OPTIONS=""
NISMASTERMAP="auto.master"		<== map exists but not actually used
UNDERSCORETODOT="yes"			<== we have no underscores
LOCAL_OPTIONS=""
APPEND_OPTIONS="yes"
DEFAULT_MASTER_MAP_NAME="auto.master"
DEFAULT_TIMEOUT=600
DEFAULT_BROWSE_MODE="yes"
DEFAULT_LOGGING="none"			<== NOT changed to "debug"
	I tried with "debug" and the machine was totally overloaded, 
	could not get any session response.  

DEFAULT_MAP_OBJECT_CLASS="nisMap"	<== pro forma; we have no LDAP
DEFAULT_ENTRY_OBJECT_CLASS="nisObject"
DEFAULT_MAP_ATTRIBUTE="nisMapName"
DEFAULT_ENTRY_ATTRIBUTE="cn"
DEFAULT_VALUE_ATTRIBUTE="nisMapEntry"
DEFAULT_AUTH_CONF_FILE="etc/autofs_ldap_auth.conf"

=------- Test Program ---------
#!/usr/bin/perl -w
# Automount is giving us trouble.  This script beats on the automounter.
# Algorithm:
#   1.	Guess a set of candidate filesystems that could be automounted.
#   2.	Read /proc/mounts and find out which are not currently mounted.
#   3.	For each non-mounted filesys, fork a process that enumerates the
#	mountpoint directory, causing automounting and/or hanging.
#   3a.	On the first pass only, if a mount fails suppress that filesystem
#	silently -- our guess was wrong of which filesystems actually exist.
#   4.	Sleep 2 secs and repeat from step 2.  Eventually filesystems will
#	be auto-unmounted and this program will cause them to be remounted.

use Hostgroup;				# A local package giving sets of hosts.
	# If it would be useful to the test person to have this package,
	# rather than rewriting getfilesys() according to local conventions
	# for naming exported filesystems, I can send it over.
use POSIX qw(:sys_wait_h strftime);
use Time::HiRes qw(time sleep);
use strict;

# Adjustable parameters
# Minimum sleep time between automount actions (in secs)
our $dt = 0.2;
# Sleep time (secs) between repeats of the whole algorithm
our $dpass = 2;
# If the mounting process runs longer than this it is considered to be hung.
our $dmax = 25;
# If a filesystem can't be mounted (failed, not hung), how long for retrying
our $dfail = 900;


$| = 1;			# Line buffered standard output

# Message output
#   $mtpt	The mount point
#   $msg	Text of message
#   Returns:	nothing
our ($now, @now);		# Cached value of time()
sub message {
    my($mtpt, $msg) = @_;
    printf("%s %-20s %s\n", strftime("%H:%M:%S", @now), $mtpt, $msg);
}

# Get candidate filesystems.  This depends heavily on local conventions
# and on the Hostgroup.pm package, locally written.  
#   \%fsys	Ref. to hash to be stuffed.  Key = mount point, e.g.
#		/net/julia/h1; value = {host, mtpt}.  Filesystems are not
#		guaranteed to exist.
#   Returns:	Nothing.
# Interpretation of $fsys->{$mtpt}{state}
#   0		Uninitialized
#   1		Checking process was started
#   2		Success: mount point has some content
#   3		Failed: mount point has no directory entries
#   4		Hung: Checking process ran over 25 secs
#   5		Suppress: Mount point failed and should not be tried again.
sub getfilesys {
    my($fsys) = @_;
		# Let's try not to have 1500 candidates most of which
		# don't exist.  Adjust parameters per hostgroup.
    &getf1($fsys, 'server', [qw(h m s)], [1..4]);
    &getf1($fsys, 'nfsx-server', [qw(h)], [1]);
    &getf1($fsys, 'nfsx-server', [qw(m)], [1..2]);
}

# Expands potential filesystems within reasonable limits.
# At Mathnet an exported filesystem is named /${pfx}${digit}, e.g.
# /h1 or /m2.  
#   \%fsys	Ref. to hash to be stuffed.
#   $hgrp	Hostgroup expression giving hosts to be tried ('down' 
#		not needed)
#   \@pfx	Prefixes for names of exported filesystems
#   \@nbrs	Suffix numbers for the filesystems.
sub getf1 {
    my($fsys, $hgrp, $pfx, $nbrs) = @_;
    foreach my $host (&GetHostgroup("$hgrp-down-rogue")) {
	foreach my $ltr (@$pfx) {
	    foreach my $nbr (@$nbrs) {
		my $mtpt = "/net/$host/$ltr$nbr";
		$fsys->{$mtpt} = {
		    host => $host,
		    mtpt => $mtpt,
		    state => 0,		# 0 -> uninitialized
		    oldstate => 0,	# 0 -> uninitialized
		};
	    }
	}
    }
}

# Checks if a filesystem can be mounted.  This subroutine just spawns 
# the checking process.
#   $mtpt	Mount point being checked.
#   \%fsys	Hash of per mount point data.
#   Returns:	PID of subprocess.  It will return 0 on success, 1 on failure,
#		or it could hang forever; this is the symptom we are seeing.
our %pid2mtpt;
sub spawncheck {
    my($mtpt, $fsys) = @_;
    my $val = $fsys->{$mtpt};
    $val->{whenchecked} = $now;
    $val->{oldstate} = $val->{state};
    $val->{state} = 1;			# 1 = process running
    my $pid = fork();
    if (!$pid) {
		# In child process...
	my @content = glob("$mtpt/*");
	my $rc = @content ? 0 : 1;
	exit $rc;
    }
		# In parent process...
    $val->{pid} = $pid;
    $pid2mtpt{$pid} = $mtpt;		# Translation from PID to mount point
    $pid;
}

# Common processing for the result.  Args:
#   \%fsys	Ref. to mount point hash.
#   $pid	PID of checking process.
#   $rc		Return code of process: 0 = success, positive = failed,
#		negative = hung.
#   \@list	List of finished mount points
#   Returns:	Mount point that the process was checking.
sub fileresult {
    my($fsys, $pid, $rc, $list) = @_;
    my $mtpt = $pid2mtpt{$pid};
    if (defined($mtpt)) {
	my $val = $fsys->{$mtpt};
	if (defined($val)) {
	    $val->{state} = ($rc == 0) ? 2 : ($rc > 0) ? 3 : 4;
	    push(@$list, $mtpt);
	} else {
	    &message($mtpt, "not in fsys (fileresult)");
	}
    } else {
	&message($pid, "not in pid2mtpt (fileresult)");
    }
    delete $pid2mtpt{$pid} if $rc >= 0;
}

# Reaps any exited processes, then returns.  Also checks for hung processes.
# If a process is judged hung and later finishes, this is self-healing.
#   \%fsys	Hash of per mount point data.
#   Returns:	List of finished mount points (could be empty).  
sub spawnreap {
    my($fsys) = @_;
    my @finished;
    my($pid, $mtpt);
    REAP: {
	$pid = waitpid(-1, WNOHANG);
	last if $pid <= 0;
	&fileresult($fsys, $pid, $?, \@finished);
	redo;
    }
		# Check for hung processes.  It takes 10 secs to recognize
		# that the NFS server is down.
    my $timeout = $now - $dmax;			# Allow 25 secs 
    foreach $pid (keys %pid2mtpt) {
	$mtpt = $pid2mtpt{$pid};
	my $val = $fsys->{$mtpt};
	if (!defined($val)) {
	    delete $fsys->{$mtpt};
	    delete $pid2mtpt{$pid};
	    next;
	}
	next if defined($val) && ($val->{state} >= 4 || 
	    $val->{whenchecked} >= $timeout);
	&fileresult($fsys, $pid, -1, \@finished);
    }
    @finished;
}

# Checks if /etc/mtab agrees with /proc/mounts.  Only NFS mounts are 
# looked at.  Args:
#   $curse	Recursion depth, starting with 0.
#   $msg	Error message passed in from earlier recursion.
#   Returns:	Discrepancies as text string, or "" if no discreps
sub checkmtab {
    my($curse, $msg) = @_;
    $msg = "" unless defined($msg);
    return $msg if (++$curse > 5);
    my(%mounted, $i);
		# Identify which mtab we're reading today.
    my @stat1 = stat("/etc/mtab") or 
	return &checkmtab($curse, "can't stat /etc/mtab: $!");
		# Read /etc/mtab and save a list of what's mounted.
    open(MTAB, "/etc/mtab") or 
	return &checkmtab($curse, "can't read /etc/mtab: $!");
    while (<MTAB>) {
	my @line = split;
	$mounted{$line[1]} ++ if $line[2] eq 'nfs';
    }
    close(MTAB);
		# Read /proc/mounts and save a list of what's mounted.
    open(MTAB, "/proc/mounts") or 
	return &checkmtab($curse, "can't read /proc/mounts: $!");
    while (<MTAB>) {
	my @line = split;
	$mounted{$line[1]} += 16 if $line[2] eq 'nfs';
    }
    close(MTAB);
		# Detect if mtab was altered since first read.  (Can't do much
		# about /proc/mounts changing; stat() doesn't even give the
		# length.)  Recurse if mtab changed in inode, size or mtime.
    my @stat2 = stat("/etc/mtab") or 
	return &checkmtab($curse, "can't stat /etc/mtab: $!");
    foreach $i ((1, 7, 9)) {
	return &checkmtab($curse, $msg) if $stat1[$i] != $stat2[$i];
    }
		# We successfully read both files.  Detect discrepancies.
    $msg = "";
    my $nbad = 0;
    my($mtpt, $in);
    my @hdr = ("mtab: ", "<=> mounts: ");
    foreach $i (0..1) {
	$msg .= $hdr[$i];
	while (($mtpt, $in) = each %mounted) {
	    if ($in != 17 && ($in >= 16 || 0) == $i) {
		$msg .= "$mtpt ";
		$nbad++;
	    }
	}
    }
    return $nbad ? $msg : "";
}

# Digests and reports the results for finished mount points.
# Arg: list of mount points (could be empty).  First arg is ref. to
# mountpoint index.
our @digestxl = qw(uninitialized running success failed hung suppressed);
sub digest {
    my ($fsys) = shift;
    foreach my $mtpt (@_) {
	my $val = $fsys->{$mtpt};
	next unless defined($val);
	if ($val->{state} == 2) {
	    # Success, ignore silently.
	} elsif ($val->{oldstate} <= 0 ) {
		# Failed during initialization, do not report, suppress
		# permanently.
	    delete $fsys->{$mtpt};
	} else {
		# Failed during operation, so complain.
	    &message($mtpt, $digestxl[${$val}{state}]);
	}
    }
}

# Initialize the set of filesystems.
our %filesys;
$now = time();
@now = localtime($now);
our $passes = 0;
our $checked = 9999999;
&getfilesys(\%filesys);
open(MOUNTS, "/proc/mounts") or die "Can't read /proc/mounts: $!\n";
POUND: {
    $passes++;
    my $npids = scalar(keys %pid2mtpt);
    if ($npids >= 100) {
	message("--", "$npids hung processes, exiting");
	last;
    }
    if ($checked > 50) {
	&message("--", "Pass $passes starting, $npids processes running");
	$checked = 0;
    }
		# Turn off the "mounted" flag on all filesystems.
    my($mtpt, $val);
    my $n = 0;
    while (($mtpt, $val) = each %filesys) {
	$val->{mounted} = 0;
	$n++;
    }
    &message('--', "$n filesystems known") if $passes == 3;
		# Turn on the "mounted" flag if it is mounted.
    seek(MOUNTS, 0, 0);
    $n = 0;
    while (<MOUNTS>) {
	my @mt = split;
	next unless exists($filesys{$mt[1]});
	$filesys{$mt[1]}{mounted} = 1;
	$n++;
    }
    &message('--', "$n filesystems mounted") if $passes == 3;
		# For each filesystem that is not mounted, mount it.
    $now = time();
    @now = localtime($now);
    my $failtime = $now - $dfail;	# Re-check failed filesys every 15 mins
    $n = 0;
    foreach $mtpt (keys %filesys) {
	$val = $filesys{$mtpt};		# Could be deleted behind our backs.
	next if !defined($val) || $val->{mounted} || 
	    ($val->{state} == 3 && $val->{whenchecked} >= $failtime) ||
	    $val->{state} >= 4;
	my $msg = &checkmtab(0, "");
	&message($mtpt, $msg) if $msg ne '';	# Validate /etc/mtab
	&spawncheck($mtpt, \%filesys);
	sleep $dt;
	$now = time();
	@now = localtime($now);
	my @finished = &spawnreap(\%filesys);
	&digest(\%filesys, @finished);
	$checked++;
	$n++;
    }
    sleep $dpass;
    redo;
}

=------------- Output from DEFAULT_LOGGING=debug -------
Apr 21 17:13:50 serval automount[20419]: Starting automounter version 5.0.2, master map auto.master
Apr 21 17:13:50 serval automount[20419]: using kernel protocol version 5.00
Apr 21 17:13:50 serval automount[20419]: lookup_nss_read_master: reading master files auto.master
Apr 21 17:13:50 serval automount[20419]: parse_init: parse(sun): init gathered global options: (null)
Apr 21 17:13:50 serval automount[20419]: mount_init: mount(bind): bind_works = 1
Apr 21 17:13:50 serval automount[20419]: lookup_read_master: lookup(file): read entry /net
Apr 21 17:13:50 serval automount[20419]: lookup_read_master: lookup(file): read entry /home
Apr 21 17:13:50 serval automount[20419]: master_do_mount: mounting /net
Apr 21 17:13:50 serval automount[20419]: lookup_nss_read_map: reading map file /etc/auto.net
Apr 21 17:13:50 serval automount[20419]: parse_init: parse(sun): init gathered global options: (null)
Apr 21 17:13:50 serval automount[20419]: mount_init: mount(bind): bind_works = 1
Apr 21 17:13:50 serval automount[20419]: >> umount: /net/naseberry/m1: not mounted
Apr 21 17:13:51 serval automount[20419]: >> umount: /net/zuma/h1: not mounted
Apr 21 17:13:51 serval automount[20419]: >> umount: /net/pong/m2: not mounted
Apr 21 17:13:51 serval automount[20419]: >> umount: /net/lodi/m1: not mounted
(140 of these, all different filesystems that actually exist, probably 
leftover state from previously running the test program)
Apr 21 17:13:51 serval automount[20419]: mounted indirect mount on /net with timeout 600, freq 150 seconds
Apr 21 17:13:51 serval automount[20419]: ghosting enabled
Apr 21 17:13:51 serval automount[20419]: master_do_mount: mounting /home
Apr 21 17:13:51 serval automount[20419]: lookup_nss_read_map: reading map yp auto.home
Apr 21 17:13:51 serval automount[20419]: lookup_init: lookup(yp): ctxt->mapname=auto.home
Apr 21 17:13:51 serval automount[20419]: parse_init: parse(sun): init gathered global options: (null)
Apr 21 17:13:51 serval automount[20419]: mounted indirect mount on /home with timeout 600, freq 150 seconds
Apr 21 17:13:51 serval automount[20419]: ghosting enabled
Apr 21 17:13:57 serval automount[20419]: handle_packet: type = 3
Apr 21 17:13:57 serval automount[20419]: handle_packet_missing_indirect: token 2268, name serval, request pid 15617
Apr 21 17:13:57 serval automount[20419]: handle_packet: type = 3
Apr 21 17:13:57 serval automount[20419]: handle_packet_missing_indirect: token 2269, name julia, request pid 20846
Apr 21 17:13:57 serval automount[20419]: attempting to mount entry /net/serval
Apr 21 17:13:57 serval automount[20419]: attempting to mount entry /net/julia
Apr 21 17:13:57 serval automount[20419]: lookup_mount: lookup(file): looking up serval
Apr 21 17:13:57 serval automount[20419]: lookup_mount: lookup(file): serval -> -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=&	file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): expanded entry: -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=serval	file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): gathered options: rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=serval
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): dequote("file:/etc/auto.net.generic") -> file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): core of entry: options=rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=serval, loc=file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: sun_mount: parse(sun): mounting root /net, mountpoint serval, what file:/etc/auto.net.generic, fstype autofs, options rsize=8192,wsize=8192,retry=1,soft,-DSERVER=serval
Apr 21 17:13:57 serval automount[20419]: do_mount: file:/etc/auto.net.generic /net/serval type autofs options rsize=8192,wsize=8192,retry=1,soft,-DSERVER=serval using module autofs
Apr 21 17:13:57 serval automount[20419]: mount_mount: mount(autofs): fullpath=/net/serval what=file:/etc/auto.net.generic options=rsize=8192,wsize=8192,retry=1,soft,-DSERVER=serval
Apr 21 17:13:57 serval automount[20419]: lookup_mount: lookup(file): looking up julia
Apr 21 17:13:57 serval automount[20419]: lookup_mount: lookup(file): julia -> -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=&	file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): expanded entry: -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=julia	file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): gathered options: rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=julia
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): dequote("file:/etc/auto.net.generic") -> file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: parse_mount: parse(sun): core of entry: options=rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=julia, loc=file:/etc/auto.net.generic
Apr 21 17:13:57 serval automount[20419]: sun_mount: parse(sun): mounting root /net, mountpoint julia, what file:/etc/auto.net.generic, fstype autofs, options rsize=8192,wsize=8192,retry=1,soft,-DSERVER=julia
Apr 21 17:13:57 serval automount[20419]: do_mount: file:/etc/auto.net.generic /net/julia type autofs options rsize=8192,wsize=8192,retry=1,soft,-DSERVER=julia using module autofs
Apr 21 17:13:57 serval automount[20419]: mount_mount: mount(autofs): fullpath=/net/julia what=file:/etc/auto.net.generic options=rsize=8192,wsize=8192,retry=1,soft,-DSERVER=julia
Apr 21 17:17:28 serval syslog-ng[2743]: STATS: dropped 0
Apr 21 17:17:55 serval automount[20419]: st_expire: state 1 path /home
Apr 21 17:17:55 serval automount[20419]: expire_proc: exp_proc = 3071929232 path /home
Apr 21 17:17:55 serval automount[20419]: expire_cleanup: got thid 3071929232 path /home stat 0
Apr 21 17:17:55 serval automount[20419]: expire_cleanup: sigchld: exp 3071929232 finished, switching from 2 to 1
Apr 21 17:17:55 serval automount[20419]: st_ready: st_ready(): state = 2 path /home
Apr 21 17:18:29 serval automount[20419]: st_expire: state 1 path /net
Apr 21 17:18:29 serval automount[20419]: expire_proc: exp_proc = 3071929232 path /net
Apr 21 17:18:29 serval automount[20419]: mount still busy /net
Apr 21 17:18:29 serval automount[20419]: expire_cleanup: got thid 3071929232 path /net stat 0
Apr 21 17:18:29 serval automount[20419]: expire_cleanup: sigchld: exp 3071929232 finished, switching from 2 to 1
Apr 21 17:18:29 serval automount[20419]: st_ready: st_ready(): state = 2 path /net
Apr 21 17:18:32 serval sshd[20852]: Accepted publickey for root from 128.97.4.254 port 52557 ssh2
Apr 21 17:19:35 serval sshd[20866]: Accepted publickey for root from 128.97.4.254 port 48299 ssh2
(I'm trying to kill the test program; ssh accepted the command line
but shell execution hung probably due to a need to automount in 
/root/.profile)
Apr 21 17:20:25 serval automount[20419]: st_expire: state 1 path /home
Apr 21 17:20:25 serval automount[20419]: expire_proc: exp_proc = 3071929232 path /home
Apr 21 17:20:25 serval automount[20419]: expire_cleanup: got thid 3071929232 path /home stat 0
Apr 21 17:20:25 serval automount[20419]: expire_cleanup: sigchld: exp 3071929232 finished, switching from 2 to 1
Apr 21 17:20:25 serval automount[20419]: st_ready: st_ready(): state = 2 path /home
Apr 21 17:20:59 serval automount[20419]: st_expire: state 1 path /net
Apr 21 17:20:59 serval automount[20419]: expire_proc: exp_proc = 3071929232 path /net
Apr 21 17:20:59 serval automount[20419]: mount still busy /net
Apr 21 17:20:59 serval automount[20419]: expire_cleanup: got thid 3071929232 path /net stat 0
Apr 21 17:20:59 serval automount[20419]: expire_cleanup: sigchld: exp 3071929232 finished, switching from 2 to 1
Apr 21 17:20:59 serval automount[20419]: st_ready: st_ready(): state = 2 path /net
(The above continues all night and through the next day)



James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: (no subject)

[Jeff Moyer]

jimc@math.ucla.edu (Jim Carter) writes:

> Our two webservers serve UserDirs that are automounted (NFS) from other
> hosts.  Every few days we discover a catatonic webserver (Apache2) with
> $ServerLimit child processes (150 of them), and many but not all home
> directories cannot be accessed manually (ls -d ~$user, which hangs).
> This started immediately after we upgraded the server host from SuSE
> 10.1 to SuSE 10.3; autofs version changed from 4.1.4 to 5.0.2.

That's a big jump!

> I was hoping to include debug output from autofs, but when I set
> DEFAULT_LOGGING=debug and started the test program it totally locked up
> the machine and I haven't been able to get on it since (because I'm
> working from home).  Update: a co-worker rebooted it for me and I was
> able to clear the debug switch and recover the syslog output (attached).
> But evidently the test program also seized up; I don't see a lot of
> actual mounting going on.  Anyway I've included it, for what it's worth.

That's strange.  Given the number of mounts you're talking about,
though, it may just be that you overcommitted the boxes memory.  It will
be hard to say without further digging.

> I was hoping to include useful strace output, and I have 80 Mbytes of
> turgid information (on a different machine), but I have a feeling that
> it's going to be more useful to include the test program and let 
> someone overload their own testbed system.  Here's my impression of the
> traces:  

Or, you could just give us a backtrace of the automount process when
things go pear-shaped.  See below.

> /bin/mount used to have notorious problems locking /etc/mtab.  But I
> compare /etc/mtab with /proc/mounts before forking the directory access
> process, and it was the same on several thousand comparisons with only
> two unequal comparisons; in both cases the filesystem about to be
> accessed (remounted) was in mtab and not /proc/mounts, and at most 8
> seconds later it was in both and the content had been read.  2 minutes
> after the second such event, and 38 minutes into the test run, client
> processes started to hang.

This is less of a problem these days, due to the fact that we've fixed
the bugs we've found in util-linux and the fact that we don't use mtab
anymore.  ;)

>
> Here are the particulars of our autofs setup.
>
> Distro:		OpenSuSE 10.3
> Kernel:		2.6.22.17 (kernel-default-2.6.22.17-0.1)
> Autofs:		5.0.2-30.2 (recompiled with the DNS timeout mitigation 
> 		patch that Ian Kent made for us) (and identical behavior 
> 		without the patch)
> Mount program:	util-linux-2.12r+2.13rc2+git20070725-24.2 (/bin/mount)
> NFS:		nfs-client-1.1.0-8 (/sbin/mount.nfs)
>
> =-- auto.master --- (comments omitted in all conf files)
> /net            /etc/auto.net		<== giving trouble
> /home           yp:auto.home
>
> =-- auto.net ---
> *       -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=&    file:/etc/auto.net.generic

A ha!  Submounts!  We're currently chasing a couple of issues in this
area.

> =------------- Output from DEFAULT_LOGGING=debug -------
[snip]

Jim, I'm not sure I see anything out of the ordinary in this snippet of
the debug log.  Can you search your logs for a message that contains,
"ask umount returned busy"?  If you see that, then we're looking at the
same problem.  If you don't, well, we'll have to get more information
from you.

For starters, can you install the autofs debuginfo package and attach to
the running automounter (when in a bad state) and get the output from:

gdb> thr a a bt

?  That would be a great help.

-Jeff

Re: (no subject)

[Ian Kent]

On Wed, 2008-04-23 at 16:04 -0400, Jeff Moyer wrote:
> jimc@math.ucla.edu (Jim Carter) writes:
> 
> > Our two webservers serve UserDirs that are automounted (NFS) from other
> > hosts.  Every few days we discover a catatonic webserver (Apache2) with
> > $ServerLimit child processes (150 of them), and many but not all home
> > directories cannot be accessed manually (ls -d ~$user, which hangs).
> > This started immediately after we upgraded the server host from SuSE
> > 10.1 to SuSE 10.3; autofs version changed from 4.1.4 to 5.0.2.
> 
> That's a big jump!
> 
> > I was hoping to include debug output from autofs, but when I set
> > DEFAULT_LOGGING=debug and started the test program it totally locked up
> > the machine and I haven't been able to get on it since (because I'm
> > working from home).  Update: a co-worker rebooted it for me and I was
> > able to clear the debug switch and recover the syslog output (attached).
> > But evidently the test program also seized up; I don't see a lot of
> > actual mounting going on.  Anyway I've included it, for what it's worth.
> 
> That's strange.  Given the number of mounts you're talking about,
> though, it may just be that you overcommitted the boxes memory.  It will
> be hard to say without further digging.
> 
> > I was hoping to include useful strace output, and I have 80 Mbytes of
> > turgid information (on a different machine), but I have a feeling that
> > it's going to be more useful to include the test program and let 
> > someone overload their own testbed system.  Here's my impression of the
> > traces:  
> 
> Or, you could just give us a backtrace of the automount process when
> things go pear-shaped.  See below.
> 
> > /bin/mount used to have notorious problems locking /etc/mtab.  But I
> > compare /etc/mtab with /proc/mounts before forking the directory access
> > process, and it was the same on several thousand comparisons with only
> > two unequal comparisons; in both cases the filesystem about to be
> > accessed (remounted) was in mtab and not /proc/mounts, and at most 8
> > seconds later it was in both and the content had been read.  2 minutes
> > after the second such event, and 38 minutes into the test run, client
> > processes started to hang.
> 
> This is less of a problem these days, due to the fact that we've fixed
> the bugs we've found in util-linux and the fact that we don't use mtab
> anymore.  ;)

v5 still does, but much less so than previously.

> 
> >
> > Here are the particulars of our autofs setup.
> >
> > Distro:		OpenSuSE 10.3
> > Kernel:		2.6.22.17 (kernel-default-2.6.22.17-0.1)
> > Autofs:		5.0.2-30.2 (recompiled with the DNS timeout mitigation 
> > 		patch that Ian Kent made for us) (and identical behavior 
> > 		without the patch)
> > Mount program:	util-linux-2.12r+2.13rc2+git20070725-24.2 (/bin/mount)
> > NFS:		nfs-client-1.1.0-8 (/sbin/mount.nfs)
> >
> > =-- auto.master --- (comments omitted in all conf files)
> > /net            /etc/auto.net		<== giving trouble
> > /home           yp:auto.home
> >
> > =-- auto.net ---
> > *       -rsize=8192,wsize=8192,retry=1,soft,fstype=autofs,-DSERVER=&    file:/etc/auto.net.generic
> 
> A ha!  Submounts!  We're currently chasing a couple of issues in this
> area.
> 
> > =------------- Output from DEFAULT_LOGGING=debug -------
> [snip]
> 
> Jim, I'm not sure I see anything out of the ordinary in this snippet of
> the debug log.  Can you search your logs for a message that contains,
> "ask umount returned busy"?  If you see that, then we're looking at the
> same problem.  If you don't, well, we'll have to get more information
> from you.

Also, we don't know what patches have been included in the SuSE release.
Any chance of providing a source rpm?

> 
> For starters, can you install the autofs debuginfo package and attach to
> the running automounter (when in a bad state) and get the output from:
> 
> gdb> thr a a bt
> 
> ?  That would be a great help.

I don't know if SuSE provide debuginfo packages but the thread trace is
useless without debug info.

The backtrace is the most effective way to identify a few known
problems. It's really important.

Ian

(no subject)

[George Shammas]

subscribe

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

各位老总：您们好！
                
    诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
    我公司可以长期提供：出口报关单，核销单，等等一系列手续；代理：出口

报关，商检，境内外运输......等等；还可以代办：出口欧盟许可证，欧盟产地证；

并且还有（广州国际贸易交易会）的摊位可以转让；价格特别优惠；有意者请来邮件

或来电联系。谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
   此致：
                                                         

                                                                敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                             敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                             敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                             敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                                  敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                                  敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                                  敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]




         各位老总：您们好！
                
             诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
         鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
    
             我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
         核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

         以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

         位可以转让；有意者请来邮件或来电联系；谢谢合作！
　
                              电话：0755-81153047。
　
                              传真：0755-81172940。
　
                              手机：15817477278。
　
                              联系人：钟文辉。
　
             

                 此致：
                                                                         

                                                                  敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]




             各位老总：您们好！
                
                 诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
             鼠不尽的幸福！鼠不尽的美满生活！愿：您们阖家欢乐！幸福安康！
    
                 我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
            核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

            以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

            位可以转让；有意者请来邮件或来电联系。
　
                                          电话：0755-81153047。
　
                                          传真：0755-81172940。
　
                                          手机：15817477278。
　
                                          联系人：钟文辉。
　
                        此致：
                                                                       

                                                                         敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]




             各位老总：您们好！
                
                 诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
　
             鼠不尽的幸福！鼠不尽的美满生活！愿：您们阖家欢乐！幸福安康！
    
                 我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
            核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

            以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

            位可以转让；有意者请来邮件或来电联系。
　
                                          电话：0755-81153047。
　
                                          传真：0755-81172940。
　
                                          手机：15817477278。
　
                                          联系人：钟文辉。
　
                        此致：
                                                                       

                                                                         敬礼！


[-- Attachment #2: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[PATCH] x86: remove superfluous initialisation in boot code.

[Alexander van Heukelum]

x86: remove superfluous initialisation in boot code.

In arch/x86/boot/compressed/misc.c, the variable vidmem is
the only variable that ends up in de data segment. It's also
superfluous, because the first thing the code does is:

	if (RM_SCREEN_INFO.orig_video_mode == 7) {
		vidmem = (char *) 0xb0000;
		vidport = 0x3b4;
	} else {
		vidmem = (char *) 0xb8000;
		vidport = 0x3d4;
	}

This patch removes the initialisation.

---

Tested on qemu (i386 and x86_64). The boot messages still
appear as usual:

Decompressing Linux... Parsing ELF... done.
Booting the kernel.

Greetings,
	Alexander

 arch/x86/boot/compressed/misc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 9470a05..dad4e69 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -223,7 +223,7 @@ static memptr free_mem_end_ptr;
 #define HEAP_SIZE             0x4000
 #endif
 
-static char *vidmem = (char *)0xb8000;
+static char *vidmem;
 static int vidport;
 static int lines, cols;
 

Re: [PATCH] x86: remove superfluous initialisation in boot code.

[Ingo Molnar]

* Alexander van Heukelum <heukelum@mailshack.com> wrote:

> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -223,7 +223,7 @@ static memptr free_mem_end_ptr;
>  #define HEAP_SIZE             0x4000
>  #endif
>  
> -static char *vidmem = (char *)0xb8000;
> +static char *vidmem;
>  static int vidport;

thanks, applied. (Btw., you forgot your signoff line - not a big deal 
for a small fix like this but it's best to always include it for patches 
you'd like to see go upstream.)

	Ingo

Re: [PATCH] x86: remove superfluous initialisation in boot code.

[Alexander van Heukelum]

On Mon, 7 Apr 2008 09:46:14 +0200, "Ingo Molnar" <mingo@elte.hu> said:
> 
> * Alexander van Heukelum <heukelum@mailshack.com> wrote:
> 
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -223,7 +223,7 @@ static memptr free_mem_end_ptr;
> >  #define HEAP_SIZE             0x4000
> >  #endif
> >  
> > -static char *vidmem = (char *)0xb8000;
> > +static char *vidmem;
> >  static int vidport;
> 
> thanks, applied. (Btw., you forgot your signoff line - not a big deal 
> for a small fix like this but it's best to always include it for patches 
> you'd like to see go upstream.)

Hmm... I knew I had forgotten something. So I did another round of tests
to see if it was working correctly :-/.

If you like, you can add:
Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>

Greetings,
    Alexander

> 	Ingo
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - And now for something completely different…

(no subject)

[zhenwenxu]

unsubscribe linux-kernel

(no subject)

[Clint Moore]

(no subject)

[badguy development]

[-- Attachment #1.1: Type: text/plain, Size: 2185 bytes --]


Hello,

I am developing a driver for the LTC1760 dual battery charger.

 I have an interrupt occur and I get notification of that.

however I cannot seem to clear the interrupt from inside the ISR and thus I am ruined.



I have learned from the research and looking around I have done, that I cannot call just any code in an ISR.

the code I want to call will read the AlertResponse register of my LTC1760 chip and that will clear the interrupt.



but I get angry kernel response when I do, below is a brief dump of what I get:

BUG: scheduling while atomic: swapper/0x00010002/0
bad: scheduling from the idle thread!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1]
Modules linked in: i2c_battery swcamera(PF) clcdc(PF) pvr(PF) gecko_devices
CPU: 0
PC is at dequeue_task+0xc/0xa8
LR is at deactivate_task+0x38/0x44
pc : [<c009b070>]    lr : [<c009b218>]    Tainted: PF
sp : c0331c6c  ip : c0331c80  fp : c0331c7c
r10: 00000000  r9 : 00989642  r8 : b0e7aa00
r7 : c0335f98  r6 : c0331cd8  r5 : 00000001  r4 : c0335f98
r3 : 00000080  r2 : 00000000  r1 : 00000000  r0 : c0335f98
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: C5387F
Table: 868E8000  DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc0330250)

All the example code I can find regarding ISR, have access to register offsets and can simply clear the interrupt that way.
I am new to this and am having a hard time finding direction with regards to how to handle linux interrupts.

I need to send a request command out i2c to this device to clear this interrupt.
I am not 100% sure about this, but it is what the data sheet has led me to believe.

I would appreciate any help on this, and perhaps even a reference to what material I should look at to find this answer.

Thanks ahead of time.

       -Christian Hunt

_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207

[-- Attachment #1.2: Type: text/html, Size: 2576 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

(no subject)

[郝舜]

Hi:
      I'm confused by a problem when i modify a test application "alsa-lib-1.0.13/test/control.c".
      I wanna use the structure "snd_ctl_elem_value_t",but when i write like this:
             snd_ctl_elem_value_t aaa;
      there will be an error:
             storage size of 'aaa' isn't known
     while 
             snd_ctl_elem_value_t *aaa;
     makes no errors. But i can't change it directly such as:
             aaa->id=test_id ; //test_id is defined before
     cause it will bring an error:
             dereferencing pointer to incomplete type
     I think i should use the function like "snd_ctl_elem_info_set_id",but i just want to know why,i don't think it disobeys the C syntax.Is there something different in the ALSA making procedure?or Makefile?



haoshun
2008-04-03

Re: (no subject)

[Clemens Ladisch]

郝舜 wrote:
> I'm confused by a problem when i modify a test application "alsa-lib-1.0.13/test/control.c".
> I wanna use the structure "snd_ctl_elem_value_t",but when i write like this:
>        snd_ctl_elem_value_t aaa;
> there will be an error:
> ...
> I think i should use the function like "snd_ctl_elem_info_set_id",

Yes.

> but i just want to know why,i don't think it disobeys the C syntax.

These structures are only defined internally in alsa-lib and are not
exported.  It was made this way to make the library binary compatible
with future versions where the layout of these structures may change.


HTH
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

                 


               各位老总：您们好！
                
                   诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！ 
　
               鼠不尽的幸福！鼠不尽的美满生活！愿：您们阖家欢乐！幸福安康！
    
                   我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
               核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

               以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

               位可以转让；有意者请来邮件或来电联系。
　
                                             电话：0755-81153047。
　
                                             传真：0755-81172940。
　
                                             手机：15817477278。
　
                                             联系人：钟文辉。
　
                         此致：
                                                                 

                                                                          敬礼！
　


[-- Attachment #2: Type: text/plain, Size: 278 bytes --]

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

                 


               各位老总：您们好！
                
                   诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！ 
　
               鼠不尽的幸福！鼠不尽的美满生活！愿：您们阖家欢乐！幸福安康！
    
                   我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
               核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

               以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

               位可以转让；有意者请来邮件或来电联系。
　
                                             电话：0755-81153047。
　
                                             传真：0755-81172940。
　
                                             手机：15817477278。
　
                                             联系人：钟文辉。
　
                         此致：
                                                                 

                                                                          敬礼！
　


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[钟文辉]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

                 


               各位老总：您们好！
                
                   诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！ 
　
               鼠不尽的幸福！鼠不尽的美满生活！愿：您们阖家欢乐！幸福安康！
    
                   我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
　
               核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可

               以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊

               位可以转让；有意者请来邮件或来电联系。
　
                                             电话：0755-81153047。
　
                                             传真：0755-81172940。
　
                                             手机：15817477278。
　
                                             联系人：钟文辉。
　
                         此致：
                                                                 

                                                                          敬礼！
　


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Sandipan Bhattacharjee]

Dear All,

I have a very simple doubt. Can anyone please help me with it? I 
want to connect a Linux PC and a Windows PC by USB. Now since, 
both are working in host mode, I need a USB-bridge cable.I am not 
able to find any such cable which has the driver for Linux also. 
Can any one please help me out with a solution??
Thanks in advance.

Cheers
Sandipan.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

(No subject)

[Lele]

Re: Ответы для Linux Format

[Serge A. Suchkov]

В сообщении от Thursday 21 February 2008 12:33:26 Andrei Borovsky написал(а):
> > Хмм... а можно урезать эту информацию до минимума ?
> > Это ведь всего лишь хобби и я не склонен его афишировать настолько
>
> публично :)
>
> >Тем более мой вклад в GSPCA весьма скромен на общем фоне.
>
> Как скажете. В принципе, все это, конечно, необязательно. Даже фотографию
> поместить не хотите? :)

Нет, спасибо :)


>
>
> С уважением,
> Андрей Боровский.



-- 
Regards,
Serge A. Suchkov
--
A baby is an alimentary canal with a loud voice at one end and no
responsibility at the other.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: (no subject)

[Serge A. Suchkov]

oops ... sorry 
bad replay ;)
-- 
Regards,
Serge A. Suchkov
--
There is a natural hootchy-kootchy to a goldfish.
		-- Walt Disney

(no subject)

[veerasena reddy]

Hi,

I have a requirement where i need to execute a user process even when the kernel is utilizing 100% of CPU time.

Actual scenario is as below:
I have a device on my board. this device keeps generating regular (for every 2secs) messages for a user process. the user process has to poll on the device for any message is there to read and get the message from the device. once the user process reads the message it will be removed in device and uses for further/subsequent messages.

I have a test case where i need to send so much traffic through my board such that the kernel will be utilizing 100% CPU time to process this data. At this time (when CPU is 100% utilized) the user space process is not getting scheduled even after a long duration (say 10 minutes to 45 minutes). Mean time the message buffer in the device is filled up and the device halts (aka controlled crash; the device firmware has been designed like this) as there is no more memory on the device.
To avoid this scenario of device's message queue getting filled up because of the user space process not reading them, could you please anyone suggest some technique for getting my user space process scheduled even when there is very heavy traffic as described above.

In simple, i can put my requirement like this:
    Is there any way i can get a user space process get scheduled in the above condition (kernel occupying 100% of CPU due to heavy traffic)

Thanks in Advance.

Regards,
Veerasena.


      Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

RE: (no subject)

[Ramgopal Kota]

Hi,

You can set a real-time priority to the user-process.

Ramgopal Kota 
-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of veerasena reddy
Sent: Friday, February 01, 2008 11:45 PM
To: linux-kernel.org; linux-mips
Subject: (no subject)

Hi,

I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.

Actual scenario is as below:
I have a device on my board. this device keeps generating regular (for
every 2secs) messages for a user process. the user process has to poll
on the device for any message is there to read and get the message from
the device. once the user process reads the message it will be removed
in device and uses for further/subsequent messages.

I have a test case where i need to send so much traffic through my board
such that the kernel will be utilizing 100% CPU time to process this
data. At this time (when CPU is 100% utilized) the user space process is
not getting scheduled even after a long duration (say 10 minutes to 45
minutes). Mean time the message buffer in the device is filled up and
the device halts (aka controlled crash; the device firmware has been
designed like this) as there is no more memory on the device.
To avoid this scenario of device's message queue getting filled up
because of the user space process not reading them, could you please
anyone suggest some technique for getting my user space process
scheduled even when there is very heavy traffic as described above.

In simple, i can put my requirement like this:
    Is there any way i can get a user space process get scheduled in the
above condition (kernel occupying 100% of CPU due to heavy traffic)

Thanks in Advance.

Regards,
Veerasena.


      Now you can chat without downloading messenger. Go to
http://in.messenger.yahoo.com/webmessengerpromo.php

(no subject)

[Thiemo Seufer]

Hello All,

This patch moves the micro-assembler in a separate implementation, as
it is useful for further run-time optimizations. The only change in
behaviour is cutting down printk noise at kernel startup time.

Checkpatch complains about macro parameters which aren't protected by
parentheses. I believe this is a flaw in checkpatch, the paste operator
used in those macros won't work with parenthesised parameters.

Tested on:
- Qemu 32-bit little endian
- BCM1480 64-bit big endian


Thiemo


---
Split the micro-assembler from tlbex.c.

Signed-off-by:  Thiemo Seufer <ths@networkno.de>


diff --git a/arch/mips/mm/Makefile b/arch/mips/mm/Makefile
index 32fd5db..c6f832e 100644
--- a/arch/mips/mm/Makefile
+++ b/arch/mips/mm/Makefile
@@ -3,7 +3,8 @@
 #
 
 obj-y				+= cache.o dma-default.o extable.o fault.o \
-				   init.o pgtable.o tlbex.o tlbex-fault.o
+				   init.o pgtable.o tlbex.o tlbex-fault.o \
+				   uasm.o
 
 obj-$(CONFIG_32BIT)		+= ioremap.o pgtable-32.o
 obj-$(CONFIG_64BIT)		+= pgtable-64.o
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index a61246d..48a2589 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -5,7 +5,7 @@
  *
  * Synthesize TLB refill handlers at runtime.
  *
- * Copyright (C) 2004,2005,2006 by Thiemo Seufer
+ * Copyright (C) 2004,2005,2006,2008  Thiemo Seufer
  * Copyright (C) 2005  Maciej W. Rozycki
  * Copyright (C) 2006  Ralf Baechle (ralf@linux-mips.org)
  *
@@ -19,8 +19,6 @@
  * (Condolences to Napoleon XIV)
  */
 
-#include <stdarg.h>
-
 #include <linux/mm.h>
 #include <linux/kernel.h>
 #include <linux/types.h>
@@ -30,11 +28,11 @@
 #include <asm/pgtable.h>
 #include <asm/cacheflush.h>
 #include <asm/mmu_context.h>
-#include <asm/inst.h>
-#include <asm/elf.h>
 #include <asm/smp.h>
 #include <asm/war.h>
 
+#include "uasm.h"
+
 static inline int r45k_bvahwbug(void)
 {
 	/* XXX: We should probe for the presence of this bug, but we don't. */
@@ -72,371 +70,9 @@ static __init int __attribute__((unused)) m4kc_tlbp_war(void)
 	       (PRID_COMP_MIPS | PRID_IMP_4KC);
 }
 
-/*
- * A little micro-assembler, intended for TLB refill handler
- * synthesizing. It is intentionally kept simple, does only support
- * a subset of instructions, and does not try to hide pipeline effects
- * like branch delay slots.
- */
-
-enum fields
-{
-	RS = 0x001,
-	RT = 0x002,
-	RD = 0x004,
-	RE = 0x008,
-	SIMM = 0x010,
-	UIMM = 0x020,
-	BIMM = 0x040,
-	JIMM = 0x080,
-	FUNC = 0x100,
-	SET = 0x200
-};
-
-#define OP_MASK		0x3f
-#define OP_SH		26
-#define RS_MASK		0x1f
-#define RS_SH		21
-#define RT_MASK		0x1f
-#define RT_SH		16
-#define RD_MASK		0x1f
-#define RD_SH		11
-#define RE_MASK		0x1f
-#define RE_SH		6
-#define IMM_MASK	0xffff
-#define IMM_SH		0
-#define JIMM_MASK	0x3ffffff
-#define JIMM_SH		0
-#define FUNC_MASK	0x3f
-#define FUNC_SH		0
-#define SET_MASK	0x7
-#define SET_SH		0
-
-enum opcode {
-	insn_invalid,
-	insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
-	insn_beql, insn_bgez, insn_bgezl, insn_bltz, insn_bltzl,
-	insn_bne, insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0,
-	insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32,
-	insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld,
-	insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0,
-	insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll,
-	insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi,
-	insn_tlbwr, insn_xor, insn_xori
-};
-
-struct insn {
-	enum opcode opcode;
-	u32 match;
-	enum fields fields;
-};
-
-/* This macro sets the non-variable bits of an instruction. */
-#define M(a, b, c, d, e, f)					\
-	((a) << OP_SH						\
-	 | (b) << RS_SH						\
-	 | (c) << RT_SH						\
-	 | (d) << RD_SH						\
-	 | (e) << RE_SH						\
-	 | (f) << FUNC_SH)
-
-static __initdata struct insn insn_table[] = {
-	{ insn_addiu, M(addiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
-	{ insn_addu, M(spec_op, 0, 0, 0, 0, addu_op), RS | RT | RD },
-	{ insn_and, M(spec_op, 0, 0, 0, 0, and_op), RS | RT | RD },
-	{ insn_andi, M(andi_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
-	{ insn_beq, M(beq_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
-	{ insn_beql, M(beql_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
-	{ insn_bgez, M(bcond_op, 0, bgez_op, 0, 0, 0), RS | BIMM },
-	{ insn_bgezl, M(bcond_op, 0, bgezl_op, 0, 0, 0), RS | BIMM },
-	{ insn_bltz, M(bcond_op, 0, bltz_op, 0, 0, 0), RS | BIMM },
-	{ insn_bltzl, M(bcond_op, 0, bltzl_op, 0, 0, 0), RS | BIMM },
-	{ insn_bne, M(bne_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
-	{ insn_daddiu, M(daddiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
-	{ insn_daddu, M(spec_op, 0, 0, 0, 0, daddu_op), RS | RT | RD },
-	{ insn_dmfc0, M(cop0_op, dmfc_op, 0, 0, 0, 0), RT | RD | SET},
-	{ insn_dmtc0, M(cop0_op, dmtc_op, 0, 0, 0, 0), RT | RD | SET},
-	{ insn_dsll, M(spec_op, 0, 0, 0, 0, dsll_op), RT | RD | RE },
-	{ insn_dsll32, M(spec_op, 0, 0, 0, 0, dsll32_op), RT | RD | RE },
-	{ insn_dsra, M(spec_op, 0, 0, 0, 0, dsra_op), RT | RD | RE },
-	{ insn_dsrl, M(spec_op, 0, 0, 0, 0, dsrl_op), RT | RD | RE },
-	{ insn_dsrl32, M(spec_op, 0, 0, 0, 0, dsrl32_op), RT | RD | RE },
-	{ insn_dsubu, M(spec_op, 0, 0, 0, 0, dsubu_op), RS | RT | RD },
-	{ insn_eret,  M(cop0_op, cop_op, 0, 0, 0, eret_op),  0 },
-	{ insn_j,  M(j_op, 0, 0, 0, 0, 0),  JIMM },
-	{ insn_jal,  M(jal_op, 0, 0, 0, 0, 0),  JIMM },
-	{ insn_jr,  M(spec_op, 0, 0, 0, 0, jr_op),  RS },
-	{ insn_ld,  M(ld_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_ll,  M(ll_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_lld,  M(lld_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_lui,  M(lui_op, 0, 0, 0, 0, 0),  RT | SIMM },
-	{ insn_lw,  M(lw_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_mfc0,  M(cop0_op, mfc_op, 0, 0, 0, 0),  RT | RD | SET},
-	{ insn_mtc0,  M(cop0_op, mtc_op, 0, 0, 0, 0),  RT | RD | SET},
-	{ insn_ori,  M(ori_op, 0, 0, 0, 0, 0),  RS | RT | UIMM },
-	{ insn_rfe,  M(cop0_op, cop_op, 0, 0, 0, rfe_op),  0 },
-	{ insn_sc,  M(sc_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_scd,  M(scd_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_sd,  M(sd_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_sll,  M(spec_op, 0, 0, 0, 0, sll_op),  RT | RD | RE },
-	{ insn_sra,  M(spec_op, 0, 0, 0, 0, sra_op),  RT | RD | RE },
-	{ insn_srl,  M(spec_op, 0, 0, 0, 0, srl_op),  RT | RD | RE },
-	{ insn_subu,  M(spec_op, 0, 0, 0, 0, subu_op),  RS | RT | RD },
-	{ insn_sw,  M(sw_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
-	{ insn_tlbp,  M(cop0_op, cop_op, 0, 0, 0, tlbp_op),  0 },
-	{ insn_tlbwi,  M(cop0_op, cop_op, 0, 0, 0, tlbwi_op),  0 },
-	{ insn_tlbwr,  M(cop0_op, cop_op, 0, 0, 0, tlbwr_op),  0 },
-	{ insn_xor,  M(spec_op, 0, 0, 0, 0, xor_op),  RS | RT | RD },
-	{ insn_xori,  M(xori_op, 0, 0, 0, 0, 0),  RS | RT | UIMM },
-	{ insn_invalid, 0, 0 }
-};
-
-#undef M
-
-static __init u32 build_rs(u32 arg)
-{
-	if (arg & ~RS_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return (arg & RS_MASK) << RS_SH;
-}
-
-static __init u32 build_rt(u32 arg)
-{
-	if (arg & ~RT_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return (arg & RT_MASK) << RT_SH;
-}
-
-static __init u32 build_rd(u32 arg)
-{
-	if (arg & ~RD_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return (arg & RD_MASK) << RD_SH;
-}
-
-static __init u32 build_re(u32 arg)
-{
-	if (arg & ~RE_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return (arg & RE_MASK) << RE_SH;
-}
-
-static __init u32 build_simm(s32 arg)
-{
-	if (arg > 0x7fff || arg < -0x8000)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return arg & 0xffff;
-}
-
-static __init u32 build_uimm(u32 arg)
-{
-	if (arg & ~IMM_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return arg & IMM_MASK;
-}
-
-static __init u32 build_bimm(s32 arg)
-{
-	if (arg > 0x1ffff || arg < -0x20000)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	if (arg & 0x3)
-		printk(KERN_WARNING "Invalid TLB synthesizer branch target\n");
-
-	return ((arg < 0) ? (1 << 15) : 0) | ((arg >> 2) & 0x7fff);
-}
-
-static __init u32 build_jimm(u32 arg)
-{
-	if (arg & ~((JIMM_MASK) << 2))
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return (arg >> 2) & JIMM_MASK;
-}
-
-static __init u32 build_func(u32 arg)
-{
-	if (arg & ~FUNC_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return arg & FUNC_MASK;
-}
-
-static __init u32 build_set(u32 arg)
-{
-	if (arg & ~SET_MASK)
-		printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
-	return arg & SET_MASK;
-}
-
-/*
- * The order of opcode arguments is implicitly left to right,
- * starting with RS and ending with FUNC or IMM.
- */
-static void __init build_insn(u32 **buf, enum opcode opc, ...)
-{
-	struct insn *ip = NULL;
-	unsigned int i;
-	va_list ap;
-	u32 op;
-
-	for (i = 0; insn_table[i].opcode != insn_invalid; i++)
-		if (insn_table[i].opcode == opc) {
-			ip = &insn_table[i];
-			break;
-		}
-
-	if (!ip)
-		panic("Unsupported TLB synthesizer instruction %d", opc);
-
-	op = ip->match;
-	va_start(ap, opc);
-	if (ip->fields & RS) op |= build_rs(va_arg(ap, u32));
-	if (ip->fields & RT) op |= build_rt(va_arg(ap, u32));
-	if (ip->fields & RD) op |= build_rd(va_arg(ap, u32));
-	if (ip->fields & RE) op |= build_re(va_arg(ap, u32));
-	if (ip->fields & SIMM) op |= build_simm(va_arg(ap, s32));
-	if (ip->fields & UIMM) op |= build_uimm(va_arg(ap, u32));
-	if (ip->fields & BIMM) op |= build_bimm(va_arg(ap, s32));
-	if (ip->fields & JIMM) op |= build_jimm(va_arg(ap, u32));
-	if (ip->fields & FUNC) op |= build_func(va_arg(ap, u32));
-	if (ip->fields & SET) op |= build_set(va_arg(ap, u32));
-	va_end(ap);
-
-	**buf = op;
-	(*buf)++;
-}
-
-#define I_u1u2u3(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b, unsigned int c)			\
-	{							\
-		build_insn(buf, insn##op, a, b, c);		\
-	}
-
-#define I_u2u1u3(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b, unsigned int c)			\
-	{							\
-		build_insn(buf, insn##op, b, a, c);		\
-	}
-
-#define I_u3u1u2(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b, unsigned int c)			\
-	{							\
-		build_insn(buf, insn##op, b, c, a);		\
-	}
-
-#define I_u1u2s3(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b, signed int c)			\
-	{							\
-		build_insn(buf, insn##op, a, b, c);		\
-	}
-
-#define I_u2s3u1(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	signed int b, unsigned int c)			\
-	{							\
-		build_insn(buf, insn##op, c, a, b);		\
-	}
-
-#define I_u2u1s3(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b, signed int c)			\
-	{							\
-		build_insn(buf, insn##op, b, a, c);		\
-	}
-
-#define I_u1u2(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	unsigned int b)					\
-	{							\
-		build_insn(buf, insn##op, a, b);		\
-	}
-
-#define I_u1s2(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a,	\
-	 	signed int b)					\
-	{							\
-		build_insn(buf, insn##op, a, b);		\
-	}
-
-#define I_u1(op)						\
-	static inline void __init i##op(u32 **buf, unsigned int a)	\
-	{							\
-		build_insn(buf, insn##op, a);			\
-	}
-
-#define I_0(op)							\
-	static inline void __init i##op(u32 **buf)		\
-	{							\
-		build_insn(buf, insn##op);			\
-	}
-
-I_u2u1s3(_addiu);
-I_u3u1u2(_addu);
-I_u2u1u3(_andi);
-I_u3u1u2(_and);
-I_u1u2s3(_beq);
-I_u1u2s3(_beql);
-I_u1s2(_bgez);
-I_u1s2(_bgezl);
-I_u1s2(_bltz);
-I_u1s2(_bltzl);
-I_u1u2s3(_bne);
-I_u1u2u3(_dmfc0);
-I_u1u2u3(_dmtc0);
-I_u2u1s3(_daddiu);
-I_u3u1u2(_daddu);
-I_u2u1u3(_dsll);
-I_u2u1u3(_dsll32);
-I_u2u1u3(_dsra);
-I_u2u1u3(_dsrl);
-I_u2u1u3(_dsrl32);
-I_u3u1u2(_dsubu);
-I_0(_eret);
-I_u1(_j);
-I_u1(_jal);
-I_u1(_jr);
-I_u2s3u1(_ld);
-I_u2s3u1(_ll);
-I_u2s3u1(_lld);
-I_u1s2(_lui);
-I_u2s3u1(_lw);
-I_u1u2u3(_mfc0);
-I_u1u2u3(_mtc0);
-I_u2u1u3(_ori);
-I_0(_rfe);
-I_u2s3u1(_sc);
-I_u2s3u1(_scd);
-I_u2s3u1(_sd);
-I_u2u1u3(_sll);
-I_u2u1u3(_sra);
-I_u2u1u3(_srl);
-I_u3u1u2(_subu);
-I_u2s3u1(_sw);
-I_0(_tlbp);
-I_0(_tlbwi);
-I_0(_tlbwr);
-I_u3u1u2(_xor)
-I_u2u1u3(_xori);
-
-/*
- * handling labels
- */
-
+/* Handle labels (which must be positive integers). */
 enum label_id {
-	label_invalid,
-	label_second_part,
+	label_second_part = 1,
 	label_leave,
 #ifdef MODULE_START
 	label_module_alloc,
@@ -452,267 +88,20 @@ enum label_id {
 	label_r3000_write_probe_fail,
 };
 
-struct label {
-	u32 *addr;
-	enum label_id lab;
-};
-
-static __init void build_label(struct label **lab, u32 *addr,
-			       enum label_id l)
-{
-	(*lab)->addr = addr;
-	(*lab)->lab = l;
-	(*lab)++;
-}
-
-#define L_LA(lb)						\
-	static inline void l##lb(struct label **lab, u32 *addr) \
-	{							\
-		build_label(lab, addr, label##lb);		\
-	}
-
-L_LA(_second_part)
-L_LA(_leave)
+UASM_L_LA(_second_part)
+UASM_L_LA(_leave)
 #ifdef MODULE_START
-L_LA(_module_alloc)
-#endif
-L_LA(_vmalloc)
-L_LA(_vmalloc_done)
-L_LA(_tlbw_hazard)
-L_LA(_split)
-L_LA(_nopage_tlbl)
-L_LA(_nopage_tlbs)
-L_LA(_nopage_tlbm)
-L_LA(_smp_pgtable_change)
-L_LA(_r3000_write_probe_fail)
-
-/* convenience macros for instructions */
-#ifdef CONFIG_64BIT
-# define i_LW(buf, rs, rt, off) i_ld(buf, rs, rt, off)
-# define i_SW(buf, rs, rt, off) i_sd(buf, rs, rt, off)
-# define i_SLL(buf, rs, rt, sh) i_dsll(buf, rs, rt, sh)
-# define i_SRA(buf, rs, rt, sh) i_dsra(buf, rs, rt, sh)
-# define i_SRL(buf, rs, rt, sh) i_dsrl(buf, rs, rt, sh)
-# define i_MFC0(buf, rt, rd...) i_dmfc0(buf, rt, rd)
-# define i_MTC0(buf, rt, rd...) i_dmtc0(buf, rt, rd)
-# define i_ADDIU(buf, rs, rt, val) i_daddiu(buf, rs, rt, val)
-# define i_ADDU(buf, rs, rt, rd) i_daddu(buf, rs, rt, rd)
-# define i_SUBU(buf, rs, rt, rd) i_dsubu(buf, rs, rt, rd)
-# define i_LL(buf, rs, rt, off) i_lld(buf, rs, rt, off)
-# define i_SC(buf, rs, rt, off) i_scd(buf, rs, rt, off)
-#else
-# define i_LW(buf, rs, rt, off) i_lw(buf, rs, rt, off)
-# define i_SW(buf, rs, rt, off) i_sw(buf, rs, rt, off)
-# define i_SLL(buf, rs, rt, sh) i_sll(buf, rs, rt, sh)
-# define i_SRA(buf, rs, rt, sh) i_sra(buf, rs, rt, sh)
-# define i_SRL(buf, rs, rt, sh) i_srl(buf, rs, rt, sh)
-# define i_MFC0(buf, rt, rd...) i_mfc0(buf, rt, rd)
-# define i_MTC0(buf, rt, rd...) i_mtc0(buf, rt, rd)
-# define i_ADDIU(buf, rs, rt, val) i_addiu(buf, rs, rt, val)
-# define i_ADDU(buf, rs, rt, rd) i_addu(buf, rs, rt, rd)
-# define i_SUBU(buf, rs, rt, rd) i_subu(buf, rs, rt, rd)
-# define i_LL(buf, rs, rt, off) i_ll(buf, rs, rt, off)
-# define i_SC(buf, rs, rt, off) i_sc(buf, rs, rt, off)
-#endif
-
-#define i_b(buf, off) i_beq(buf, 0, 0, off)
-#define i_beqz(buf, rs, off) i_beq(buf, rs, 0, off)
-#define i_beqzl(buf, rs, off) i_beql(buf, rs, 0, off)
-#define i_bnez(buf, rs, off) i_bne(buf, rs, 0, off)
-#define i_bnezl(buf, rs, off) i_bnel(buf, rs, 0, off)
-#define i_move(buf, a, b) i_ADDU(buf, a, 0, b)
-#define i_nop(buf) i_sll(buf, 0, 0, 0)
-#define i_ssnop(buf) i_sll(buf, 0, 0, 1)
-#define i_ehb(buf) i_sll(buf, 0, 0, 3)
-
-#ifdef CONFIG_64BIT
-static __init int __maybe_unused in_compat_space_p(long addr)
-{
-	/* Is this address in 32bit compat space? */
-	return (((addr) & 0xffffffff00000000L) == 0xffffffff00000000L);
-}
-
-static __init int __maybe_unused rel_highest(long val)
-{
-	return ((((val + 0x800080008000L) >> 48) & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init int __maybe_unused rel_higher(long val)
-{
-	return ((((val + 0x80008000L) >> 32) & 0xffff) ^ 0x8000) - 0x8000;
-}
-#endif
-
-static __init int rel_hi(long val)
-{
-	return ((((val + 0x8000L) >> 16) & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init int rel_lo(long val)
-{
-	return ((val & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init void i_LA_mostly(u32 **buf, unsigned int rs, long addr)
-{
-#ifdef CONFIG_64BIT
-	if (!in_compat_space_p(addr)) {
-		i_lui(buf, rs, rel_highest(addr));
-		if (rel_higher(addr))
-			i_daddiu(buf, rs, rs, rel_higher(addr));
-		if (rel_hi(addr)) {
-			i_dsll(buf, rs, rs, 16);
-			i_daddiu(buf, rs, rs, rel_hi(addr));
-			i_dsll(buf, rs, rs, 16);
-		} else
-			i_dsll32(buf, rs, rs, 0);
-	} else
+UASM_L_LA(_module_alloc)
 #endif
-		i_lui(buf, rs, rel_hi(addr));
-}
-
-static __init void __maybe_unused i_LA(u32 **buf, unsigned int rs,
-					     long addr)
-{
-	i_LA_mostly(buf, rs, addr);
-	if (rel_lo(addr))
-		i_ADDIU(buf, rs, rs, rel_lo(addr));
-}
-
-/*
- * handle relocations
- */
-
-struct reloc {
-	u32 *addr;
-	unsigned int type;
-	enum label_id lab;
-};
-
-static __init void r_mips_pc16(struct reloc **rel, u32 *addr,
-			       enum label_id l)
-{
-	(*rel)->addr = addr;
-	(*rel)->type = R_MIPS_PC16;
-	(*rel)->lab = l;
-	(*rel)++;
-}
-
-static inline void __resolve_relocs(struct reloc *rel, struct label *lab)
-{
-	long laddr = (long)lab->addr;
-	long raddr = (long)rel->addr;
-
-	switch (rel->type) {
-	case R_MIPS_PC16:
-		*rel->addr |= build_bimm(laddr - (raddr + 4));
-		break;
-
-	default:
-		panic("Unsupported TLB synthesizer relocation %d",
-		      rel->type);
-	}
-}
-
-static __init void resolve_relocs(struct reloc *rel, struct label *lab)
-{
-	struct label *l;
-
-	for (; rel->lab != label_invalid; rel++)
-		for (l = lab; l->lab != label_invalid; l++)
-			if (rel->lab == l->lab)
-				__resolve_relocs(rel, l);
-}
-
-static __init void move_relocs(struct reloc *rel, u32 *first, u32 *end,
-			       long off)
-{
-	for (; rel->lab != label_invalid; rel++)
-		if (rel->addr >= first && rel->addr < end)
-			rel->addr += off;
-}
-
-static __init void move_labels(struct label *lab, u32 *first, u32 *end,
-			       long off)
-{
-	for (; lab->lab != label_invalid; lab++)
-		if (lab->addr >= first && lab->addr < end)
-			lab->addr += off;
-}
-
-static __init void copy_handler(struct reloc *rel, struct label *lab,
-				u32 *first, u32 *end, u32 *target)
-{
-	long off = (long)(target - first);
-
-	memcpy(target, first, (end - first) * sizeof(u32));
-
-	move_relocs(rel, first, end, off);
-	move_labels(lab, first, end, off);
-}
-
-static __init int __maybe_unused insn_has_bdelay(struct reloc *rel,
-						       u32 *addr)
-{
-	for (; rel->lab != label_invalid; rel++) {
-		if (rel->addr == addr
-		    && (rel->type == R_MIPS_PC16
-			|| rel->type == R_MIPS_26))
-			return 1;
-	}
-
-	return 0;
-}
-
-/* convenience functions for labeled branches */
-static void __init __maybe_unused
-	il_bltz(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_bltz(p, reg, 0);
-}
-
-static void __init __maybe_unused il_b(u32 **p, struct reloc **r,
-					     enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_b(p, 0);
-}
-
-static void __init il_beqz(u32 **p, struct reloc **r, unsigned int reg,
-		    enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_beqz(p, reg, 0);
-}
-
-static void __init __maybe_unused
-il_beqzl(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_beqzl(p, reg, 0);
-}
-
-static void __init il_bnez(u32 **p, struct reloc **r, unsigned int reg,
-		    enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_bnez(p, reg, 0);
-}
-
-static void __init il_bgezl(u32 **p, struct reloc **r, unsigned int reg,
-		     enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_bgezl(p, reg, 0);
-}
-
-static void __init __maybe_unused
-il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
-	r_mips_pc16(r, *p, l);
-	i_bgez(p, reg, 0);
-}
+UASM_L_LA(_vmalloc)
+UASM_L_LA(_vmalloc_done)
+UASM_L_LA(_tlbw_hazard)
+UASM_L_LA(_split)
+UASM_L_LA(_nopage_tlbl)
+UASM_L_LA(_nopage_tlbs)
+UASM_L_LA(_nopage_tlbm)
+UASM_L_LA(_smp_pgtable_change)
+UASM_L_LA(_r3000_write_probe_fail)
 
 /* The only general purpose registers allowed in TLB handlers. */
 #define K0		26
@@ -730,9 +119,9 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
 #define C0_XCONTEXT	20, 0
 
 #ifdef CONFIG_64BIT
-# define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_XCONTEXT)
+# define GET_CONTEXT(buf, reg) UASM_i_MFC0(buf, reg, C0_XCONTEXT)
 #else
-# define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_CONTEXT)
+# define GET_CONTEXT(buf, reg) UASM_i_MFC0(buf, reg, C0_CONTEXT)
 #endif
 
 /* The worst case length of the handler is around 18 instructions for
@@ -746,8 +135,8 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
 static __initdata u32 tlb_handler[128];
 
 /* simply assume worst case size for labels and relocs */
-static __initdata struct label labels[128];
-static __initdata struct reloc relocs[128];
+static __initdata struct uasm_label labels[128];
+static __initdata struct uasm_reloc relocs[128];
 
 /*
  * The R3000 TLB handler is simple.
@@ -761,29 +150,29 @@ static void __init build_r3000_tlb_refill_handler(void)
 	memset(tlb_handler, 0, sizeof(tlb_handler));
 	p = tlb_handler;
 
-	i_mfc0(&p, K0, C0_BADVADDR);
-	i_lui(&p, K1, rel_hi(pgdc)); /* cp0 delay */
-	i_lw(&p, K1, rel_lo(pgdc), K1);
-	i_srl(&p, K0, K0, 22); /* load delay */
-	i_sll(&p, K0, K0, 2);
-	i_addu(&p, K1, K1, K0);
-	i_mfc0(&p, K0, C0_CONTEXT);
-	i_lw(&p, K1, 0, K1); /* cp0 delay */
-	i_andi(&p, K0, K0, 0xffc); /* load delay */
-	i_addu(&p, K1, K1, K0);
-	i_lw(&p, K0, 0, K1);
-	i_nop(&p); /* load delay */
-	i_mtc0(&p, K0, C0_ENTRYLO0);
-	i_mfc0(&p, K1, C0_EPC); /* cp0 delay */
-	i_tlbwr(&p); /* cp0 delay */
-	i_jr(&p, K1);
-	i_rfe(&p); /* branch delay */
+	uasm_i_mfc0(&p, K0, C0_BADVADDR);
+	uasm_i_lui(&p, K1, uasm_rel_hi(pgdc)); /* cp0 delay */
+	uasm_i_lw(&p, K1, uasm_rel_lo(pgdc), K1);
+	uasm_i_srl(&p, K0, K0, 22); /* load delay */
+	uasm_i_sll(&p, K0, K0, 2);
+	uasm_i_addu(&p, K1, K1, K0);
+	uasm_i_mfc0(&p, K0, C0_CONTEXT);
+	uasm_i_lw(&p, K1, 0, K1); /* cp0 delay */
+	uasm_i_andi(&p, K0, K0, 0xffc); /* load delay */
+	uasm_i_addu(&p, K1, K1, K0);
+	uasm_i_lw(&p, K0, 0, K1);
+	uasm_i_nop(&p); /* load delay */
+	uasm_i_mtc0(&p, K0, C0_ENTRYLO0);
+	uasm_i_mfc0(&p, K1, C0_EPC); /* cp0 delay */
+	uasm_i_tlbwr(&p); /* cp0 delay */
+	uasm_i_jr(&p, K1);
+	uasm_i_rfe(&p); /* branch delay */
 
 	if (p > tlb_handler + 32)
 		panic("TLB refill handler space exceeded");
 
-	pr_info("Synthesized TLB refill handler (%u instructions).\n",
-		(unsigned int)(p - tlb_handler));
+	pr_debug("Wrote TLB refill handler (%u instructions).\n",
+		 (unsigned int)(p - tlb_handler));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -833,12 +222,12 @@ static __init void __maybe_unused build_tlb_probe_entry(u32 **p)
 	case CPU_R5000:
 	case CPU_R5000A:
 	case CPU_NEVADA:
-		i_nop(p);
-		i_tlbp(p);
+		uasm_i_nop(p);
+		uasm_i_tlbp(p);
 		break;
 
 	default:
-		i_tlbp(p);
+		uasm_i_tlbp(p);
 		break;
 	}
 }
@@ -849,15 +238,15 @@ static __init void __maybe_unused build_tlb_probe_entry(u32 **p)
  */
 enum tlb_write_entry { tlb_random, tlb_indexed };
 
-static __init void build_tlb_write_entry(u32 **p, struct label **l,
-					 struct reloc **r,
+static __init void build_tlb_write_entry(u32 **p, struct uasm_label **l,
+					 struct uasm_reloc **r,
 					 enum tlb_write_entry wmode)
 {
 	void(*tlbw)(u32 **) = NULL;
 
 	switch (wmode) {
-	case tlb_random: tlbw = i_tlbwr; break;
-	case tlb_indexed: tlbw = i_tlbwi; break;
+	case tlb_random: tlbw = uasm_i_tlbwr; break;
+	case tlb_indexed: tlbw = uasm_i_tlbwi; break;
 	}
 
 	switch (current_cpu_type()) {
@@ -871,19 +260,19 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		 * This branch uses up a mtc0 hazard nop slot and saves
 		 * two nops after the tlbw instruction.
 		 */
-		il_bgezl(p, r, 0, label_tlbw_hazard);
+		uasm_il_bgezl(p, r, 0, label_tlbw_hazard);
 		tlbw(p);
-		l_tlbw_hazard(l, *p);
-		i_nop(p);
+		uasm_l_tlbw_hazard(l, *p);
+		uasm_i_nop(p);
 		break;
 
 	case CPU_R4600:
 	case CPU_R4700:
 	case CPU_R5000:
 	case CPU_R5000A:
-		i_nop(p);
+		uasm_i_nop(p);
 		tlbw(p);
-		i_nop(p);
+		uasm_i_nop(p);
 		break;
 
 	case CPU_R4300:
@@ -895,7 +284,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 	case CPU_AU1550:
 	case CPU_AU1200:
 	case CPU_PR4450:
-		i_nop(p);
+		uasm_i_nop(p);
 		tlbw(p);
 		break;
 
@@ -912,26 +301,26 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 	case CPU_BCM4710:
 	case CPU_LOONGSON2:
 		if (m4kc_tlbp_war())
-			i_nop(p);
+			uasm_i_nop(p);
 		tlbw(p);
 		break;
 
 	case CPU_NEVADA:
-		i_nop(p); /* QED specifies 2 nops hazard */
+		uasm_i_nop(p); /* QED specifies 2 nops hazard */
 		/*
 		 * This branch uses up a mtc0 hazard nop slot and saves
 		 * a nop after the tlbw instruction.
 		 */
-		il_bgezl(p, r, 0, label_tlbw_hazard);
+		uasm_il_bgezl(p, r, 0, label_tlbw_hazard);
 		tlbw(p);
-		l_tlbw_hazard(l, *p);
+		uasm_l_tlbw_hazard(l, *p);
 		break;
 
 	case CPU_RM7000:
-		i_nop(p);
-		i_nop(p);
-		i_nop(p);
-		i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
 		tlbw(p);
 		break;
 
@@ -939,7 +328,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 	case CPU_24K:
 	case CPU_34K:
 	case CPU_74K:
-		i_ehb(p);
+		uasm_i_ehb(p);
 		tlbw(p);
 		break;
 
@@ -950,15 +339,15 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 		 * cpu cycles and use for data translations should not occur
 		 * for 3 cpu cycles.
 		 */
-		i_ssnop(p);
-		i_ssnop(p);
-		i_ssnop(p);
-		i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
 		tlbw(p);
-		i_ssnop(p);
-		i_ssnop(p);
-		i_ssnop(p);
-		i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
+		uasm_i_ssnop(p);
 		break;
 
 	case CPU_VR4111:
@@ -966,18 +355,18 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
 	case CPU_VR4122:
 	case CPU_VR4181:
 	case CPU_VR4181A:
-		i_nop(p);
-		i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
 		tlbw(p);
-		i_nop(p);
-		i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
 		break;
 
 	case CPU_VR4131:
 	case CPU_VR4133:
 	case CPU_R5432:
-		i_nop(p);
-		i_nop(p);
+		uasm_i_nop(p);
+		uasm_i_nop(p);
 		tlbw(p);
 		break;
 
@@ -994,7 +383,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
  * TMP will be clobbered, PTR will hold the pmd entry.
  */
 static __init void
-build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
+build_get_pmde64(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
 		 unsigned int tmp, unsigned int ptr)
 {
 	long pgdc = (long)pgd_current;
@@ -1002,52 +391,52 @@ build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
 	/*
 	 * The vmalloc handling is not in the hotpath.
 	 */
-	i_dmfc0(p, tmp, C0_BADVADDR);
+	uasm_i_dmfc0(p, tmp, C0_BADVADDR);
 #ifdef MODULE_START
-	il_bltz(p, r, tmp, label_module_alloc);
+	uasm_il_bltz(p, r, tmp, label_module_alloc);
 #else
-	il_bltz(p, r, tmp, label_vmalloc);
+	uasm_il_bltz(p, r, tmp, label_vmalloc);
 #endif
-	/* No i_nop needed here, since the next insn doesn't touch TMP. */
+	/* No uasm_i_nop needed here, since the next insn doesn't touch TMP. */
 
 #ifdef CONFIG_SMP
 # ifdef  CONFIG_MIPS_MT_SMTC
 	/*
 	 * SMTC uses TCBind value as "CPU" index
 	 */
-	i_mfc0(p, ptr, C0_TCBIND);
-	i_dsrl(p, ptr, ptr, 19);
+	uasm_i_mfc0(p, ptr, C0_TCBIND);
+	uasm_i_dsrl(p, ptr, ptr, 19);
 # else
 	/*
 	 * 64 bit SMP running in XKPHYS has smp_processor_id() << 3
 	 * stored in CONTEXT.
 	 */
-	i_dmfc0(p, ptr, C0_CONTEXT);
-	i_dsrl(p, ptr, ptr, 23);
+	uasm_i_dmfc0(p, ptr, C0_CONTEXT);
+	uasm_i_dsrl(p, ptr, ptr, 23);
 #endif
-	i_LA_mostly(p, tmp, pgdc);
-	i_daddu(p, ptr, ptr, tmp);
-	i_dmfc0(p, tmp, C0_BADVADDR);
-	i_ld(p, ptr, rel_lo(pgdc), ptr);
+	UASM_i_LA_mostly(p, tmp, pgdc);
+	uasm_i_daddu(p, ptr, ptr, tmp);
+	uasm_i_dmfc0(p, tmp, C0_BADVADDR);
+	uasm_i_ld(p, ptr, uasm_rel_lo(pgdc), ptr);
 #else
-	i_LA_mostly(p, ptr, pgdc);
-	i_ld(p, ptr, rel_lo(pgdc), ptr);
+	UASM_i_LA_mostly(p, ptr, pgdc);
+	uasm_i_ld(p, ptr, uasm_rel_lo(pgdc), ptr);
 #endif
 
-	l_vmalloc_done(l, *p);
+	uasm_l_vmalloc_done(l, *p);
 
 	if (PGDIR_SHIFT - 3 < 32)		/* get pgd offset in bytes */
-		i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3);
+		uasm_i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3);
 	else
-		i_dsrl32(p, tmp, tmp, PGDIR_SHIFT - 3 - 32);
-
-	i_andi(p, tmp, tmp, (PTRS_PER_PGD - 1)<<3);
-	i_daddu(p, ptr, ptr, tmp); /* add in pgd offset */
-	i_dmfc0(p, tmp, C0_BADVADDR); /* get faulting address */
-	i_ld(p, ptr, 0, ptr); /* get pmd pointer */
-	i_dsrl(p, tmp, tmp, PMD_SHIFT-3); /* get pmd offset in bytes */
-	i_andi(p, tmp, tmp, (PTRS_PER_PMD - 1)<<3);
-	i_daddu(p, ptr, ptr, tmp); /* add in pmd offset */
+		uasm_i_dsrl32(p, tmp, tmp, PGDIR_SHIFT - 3 - 32);
+
+	uasm_i_andi(p, tmp, tmp, (PTRS_PER_PGD - 1)<<3);
+	uasm_i_daddu(p, ptr, ptr, tmp); /* add in pgd offset */
+	uasm_i_dmfc0(p, tmp, C0_BADVADDR); /* get faulting address */
+	uasm_i_ld(p, ptr, 0, ptr); /* get pmd pointer */
+	uasm_i_dsrl(p, tmp, tmp, PMD_SHIFT-3); /* get pmd offset in bytes */
+	uasm_i_andi(p, tmp, tmp, (PTRS_PER_PMD - 1)<<3);
+	uasm_i_daddu(p, ptr, ptr, tmp); /* add in pmd offset */
 }
 
 /*
@@ -1055,7 +444,7 @@ build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
  * PTR will hold the pgd for vmalloc.
  */
 static __init void
-build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r,
+build_get_pgd_vmalloc64(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
 			unsigned int bvaddr, unsigned int ptr)
 {
 	long swpd = (long)swapper_pg_dir;
@@ -1063,52 +452,54 @@ build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r,
 #ifdef MODULE_START
 	long modd = (long)module_pg_dir;
 
-	l_module_alloc(l, *p);
+	uasm_l_module_alloc(l, *p);
 	/*
 	 * Assumption:
 	 * VMALLOC_START >= 0xc000000000000000UL
 	 * MODULE_START >= 0xe000000000000000UL
 	 */
-	i_SLL(p, ptr, bvaddr, 2);
-	il_bgez(p, r, ptr, label_vmalloc);
+	UASM_i_SLL(p, ptr, bvaddr, 2);
+	uasm_il_bgez(p, r, ptr, label_vmalloc);
 
-	if (in_compat_space_p(MODULE_START) && !rel_lo(MODULE_START)) {
-		i_lui(p, ptr, rel_hi(MODULE_START)); /* delay slot */
+	if (uasm_in_compat_space_p(MODULE_START) &&
+	    !uasm_rel_lo(MODULE_START)) {
+		uasm_i_lui(p, ptr, uasm_rel_hi(MODULE_START)); /* delay slot */
 	} else {
 		/* unlikely configuration */
-		i_nop(p); /* delay slot */
-		i_LA(p, ptr, MODULE_START);
+		uasm_i_nop(p); /* delay slot */
+		UASM_i_LA(p, ptr, MODULE_START);
 	}
-	i_dsubu(p, bvaddr, bvaddr, ptr);
+	uasm_i_dsubu(p, bvaddr, bvaddr, ptr);
 
-	if (in_compat_space_p(modd) && !rel_lo(modd)) {
-		il_b(p, r, label_vmalloc_done);
-		i_lui(p, ptr, rel_hi(modd));
+	if (uasm_in_compat_space_p(modd) && !uasm_rel_lo(modd)) {
+		uasm_il_b(p, r, label_vmalloc_done);
+		uasm_i_lui(p, ptr, uasm_rel_hi(modd));
 	} else {
-		i_LA_mostly(p, ptr, modd);
-		il_b(p, r, label_vmalloc_done);
-		i_daddiu(p, ptr, ptr, rel_lo(modd));
+		UASM_i_LA_mostly(p, ptr, modd);
+		uasm_il_b(p, r, label_vmalloc_done);
+		uasm_i_daddiu(p, ptr, ptr, uasm_rel_lo(modd));
 	}
 
-	l_vmalloc(l, *p);
-	if (in_compat_space_p(MODULE_START) && !rel_lo(MODULE_START) &&
+	uasm_l_vmalloc(l, *p);
+	if (uasm_in_compat_space_p(MODULE_START) &&
+	    !uasm_rel_lo(MODULE_START) &&
 	    MODULE_START << 32 == VMALLOC_START)
-		i_dsll32(p, ptr, ptr, 0);	/* typical case */
+		uasm_i_dsll32(p, ptr, ptr, 0);	/* typical case */
 	else
-		i_LA(p, ptr, VMALLOC_START);
+		UASM_i_LA(p, ptr, VMALLOC_START);
 #else
-	l_vmalloc(l, *p);
-	i_LA(p, ptr, VMALLOC_START);
+	uasm_l_vmalloc(l, *p);
+	UASM_i_LA(p, ptr, VMALLOC_START);
 #endif
-	i_dsubu(p, bvaddr, bvaddr, ptr);
+	uasm_i_dsubu(p, bvaddr, bvaddr, ptr);
 
-	if (in_compat_space_p(swpd) && !rel_lo(swpd)) {
-		il_b(p, r, label_vmalloc_done);
-		i_lui(p, ptr, rel_hi(swpd));
+	if (uasm_in_compat_space_p(swpd) && !uasm_rel_lo(swpd)) {
+		uasm_il_b(p, r, label_vmalloc_done);
+		uasm_i_lui(p, ptr, uasm_rel_hi(swpd));
 	} else {
-		i_LA_mostly(p, ptr, swpd);
-		il_b(p, r, label_vmalloc_done);
-		i_daddiu(p, ptr, ptr, rel_lo(swpd));
+		UASM_i_LA_mostly(p, ptr, swpd);
+		uasm_il_b(p, r, label_vmalloc_done);
+		uasm_i_daddiu(p, ptr, ptr, uasm_rel_lo(swpd));
 	}
 }
 
@@ -1129,26 +520,26 @@ build_get_pgde32(u32 **p, unsigned int tmp, unsigned int ptr)
 	/*
 	 * SMTC uses TCBind value as "CPU" index
 	 */
-	i_mfc0(p, ptr, C0_TCBIND);
-	i_LA_mostly(p, tmp, pgdc);
-	i_srl(p, ptr, ptr, 19);
+	uasm_i_mfc0(p, ptr, C0_TCBIND);
+	UASM_i_LA_mostly(p, tmp, pgdc);
+	uasm_i_srl(p, ptr, ptr, 19);
 #else
 	/*
 	 * smp_processor_id() << 3 is stored in CONTEXT.
          */
-	i_mfc0(p, ptr, C0_CONTEXT);
-	i_LA_mostly(p, tmp, pgdc);
-	i_srl(p, ptr, ptr, 23);
+	uasm_i_mfc0(p, ptr, C0_CONTEXT);
+	UASM_i_LA_mostly(p, tmp, pgdc);
+	uasm_i_srl(p, ptr, ptr, 23);
 #endif
-	i_addu(p, ptr, tmp, ptr);
+	uasm_i_addu(p, ptr, tmp, ptr);
 #else
-	i_LA_mostly(p, ptr, pgdc);
+	UASM_i_LA_mostly(p, ptr, pgdc);
 #endif
-	i_mfc0(p, tmp, C0_BADVADDR); /* get faulting address */
-	i_lw(p, ptr, rel_lo(pgdc), ptr);
-	i_srl(p, tmp, tmp, PGDIR_SHIFT); /* get pgd only bits */
-	i_sll(p, tmp, tmp, PGD_T_LOG2);
-	i_addu(p, ptr, ptr, tmp); /* add in pgd offset */
+	uasm_i_mfc0(p, tmp, C0_BADVADDR); /* get faulting address */
+	uasm_i_lw(p, ptr, uasm_rel_lo(pgdc), ptr);
+	uasm_i_srl(p, tmp, tmp, PGDIR_SHIFT); /* get pgd only bits */
+	uasm_i_sll(p, tmp, tmp, PGD_T_LOG2);
+	uasm_i_addu(p, ptr, ptr, tmp); /* add in pgd offset */
 }
 
 #endif /* !CONFIG_64BIT */
@@ -1175,8 +566,8 @@ static __init void build_adjust_context(u32 **p, unsigned int ctx)
 	}
 
 	if (shift)
-		i_SRL(p, ctx, ctx, shift);
-	i_andi(p, ctx, ctx, mask);
+		UASM_i_SRL(p, ctx, ctx, shift);
+	uasm_i_andi(p, ctx, ctx, mask);
 }
 
 static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr)
@@ -1190,18 +581,18 @@ static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr)
 	 */
 	switch (current_cpu_type()) {
 	case CPU_NEVADA:
-		i_LW(p, ptr, 0, ptr);
+		UASM_i_LW(p, ptr, 0, ptr);
 		GET_CONTEXT(p, tmp); /* get context reg */
 		break;
 
 	default:
 		GET_CONTEXT(p, tmp); /* get context reg */
-		i_LW(p, ptr, 0, ptr);
+		UASM_i_LW(p, ptr, 0, ptr);
 		break;
 	}
 
 	build_adjust_context(p, tmp);
-	i_ADDU(p, ptr, ptr, tmp); /* add in offset */
+	UASM_i_ADDU(p, ptr, ptr, tmp); /* add in offset */
 }
 
 static __init void build_update_entries(u32 **p, unsigned int tmp,
@@ -1213,45 +604,45 @@ static __init void build_update_entries(u32 **p, unsigned int tmp,
 	 */
 #ifdef CONFIG_64BIT_PHYS_ADDR
 	if (cpu_has_64bits) {
-		i_ld(p, tmp, 0, ptep); /* get even pte */
-		i_ld(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
-		i_dsrl(p, tmp, tmp, 6); /* convert to entrylo0 */
-		i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
-		i_dsrl(p, ptep, ptep, 6); /* convert to entrylo1 */
-		i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+		uasm_i_ld(p, tmp, 0, ptep); /* get even pte */
+		uasm_i_ld(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
+		uasm_i_dsrl(p, tmp, tmp, 6); /* convert to entrylo0 */
+		uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+		uasm_i_dsrl(p, ptep, ptep, 6); /* convert to entrylo1 */
+		uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
 	} else {
 		int pte_off_even = sizeof(pte_t) / 2;
 		int pte_off_odd = pte_off_even + sizeof(pte_t);
 
 		/* The pte entries are pre-shifted */
-		i_lw(p, tmp, pte_off_even, ptep); /* get even pte */
-		i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
-		i_lw(p, ptep, pte_off_odd, ptep); /* get odd pte */
-		i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+		uasm_i_lw(p, tmp, pte_off_even, ptep); /* get even pte */
+		uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+		uasm_i_lw(p, ptep, pte_off_odd, ptep); /* get odd pte */
+		uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
 	}
 #else
-	i_LW(p, tmp, 0, ptep); /* get even pte */
-	i_LW(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
+	UASM_i_LW(p, tmp, 0, ptep); /* get even pte */
+	UASM_i_LW(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
 	if (r45k_bvahwbug())
 		build_tlb_probe_entry(p);
-	i_SRL(p, tmp, tmp, 6); /* convert to entrylo0 */
+	UASM_i_SRL(p, tmp, tmp, 6); /* convert to entrylo0 */
 	if (r4k_250MHZhwbug())
-		i_mtc0(p, 0, C0_ENTRYLO0);
-	i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
-	i_SRL(p, ptep, ptep, 6); /* convert to entrylo1 */
+		uasm_i_mtc0(p, 0, C0_ENTRYLO0);
+	uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+	UASM_i_SRL(p, ptep, ptep, 6); /* convert to entrylo1 */
 	if (r45k_bvahwbug())
-		i_mfc0(p, tmp, C0_INDEX);
+		uasm_i_mfc0(p, tmp, C0_INDEX);
 	if (r4k_250MHZhwbug())
-		i_mtc0(p, 0, C0_ENTRYLO1);
-	i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+		uasm_i_mtc0(p, 0, C0_ENTRYLO1);
+	uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
 #endif
 }
 
 static void __init build_r4000_tlb_refill_handler(void)
 {
 	u32 *p = tlb_handler;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	u32 *f;
 	unsigned int final_len;
 	int i;
@@ -1265,12 +656,12 @@ static void __init build_r4000_tlb_refill_handler(void)
 	 * create the plain linear handler
 	 */
 	if (bcm1250_m3_war()) {
-		i_MFC0(&p, K0, C0_BADVADDR);
-		i_MFC0(&p, K1, C0_ENTRYHI);
-		i_xor(&p, K0, K0, K1);
-		i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
-		il_bnez(&p, &r, K0, label_leave);
-		/* No need for i_nop */
+		UASM_i_MFC0(&p, K0, C0_BADVADDR);
+		UASM_i_MFC0(&p, K1, C0_ENTRYHI);
+		uasm_i_xor(&p, K0, K0, K1);
+		UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+		uasm_il_bnez(&p, &r, K0, label_leave);
+		/* No need for uasm_i_nop */
 	}
 
 #ifdef CONFIG_64BIT
@@ -1282,8 +673,8 @@ static void __init build_r4000_tlb_refill_handler(void)
 	build_get_ptep(&p, K0, K1);
 	build_update_entries(&p, K0, K1);
 	build_tlb_write_entry(&p, &l, &r, tlb_random);
-	l_leave(&l, p);
-	i_eret(&p); /* return from trap */
+	uasm_l_leave(&l, p);
+	uasm_i_eret(&p); /* return from trap */
 
 #ifdef CONFIG_64BIT
 	build_get_pgd_vmalloc64(&p, &l, &r, K0, K1);
@@ -1303,7 +694,7 @@ static void __init build_r4000_tlb_refill_handler(void)
 #else
 	if (((p - tlb_handler) > 63)
 	    || (((p - tlb_handler) > 61)
-		&& insn_has_bdelay(relocs, tlb_handler + 29)))
+		&& uasm_insn_has_bdelay(relocs, tlb_handler + 29)))
 		panic("TLB refill handler space exceeded");
 #endif
 
@@ -1313,13 +704,13 @@ static void __init build_r4000_tlb_refill_handler(void)
 #if defined(CONFIG_32BIT) || defined(CONFIG_CPU_LOONGSON2)
 	f = final_handler;
 	/* Simplest case, just copy the handler. */
-	copy_handler(relocs, labels, tlb_handler, p, f);
+	uasm_copy_handler(relocs, labels, tlb_handler, p, f);
 	final_len = p - tlb_handler;
 #else /* CONFIG_64BIT */
 	f = final_handler + 32;
 	if ((p - tlb_handler) <= 32) {
 		/* Just copy the handler. */
-		copy_handler(relocs, labels, tlb_handler, p, f);
+		uasm_copy_handler(relocs, labels, tlb_handler, p, f);
 		final_len = p - tlb_handler;
 	} else {
 		u32 *split = tlb_handler + 30;
@@ -1327,34 +718,34 @@ static void __init build_r4000_tlb_refill_handler(void)
 		/*
 		 * Find the split point.
 		 */
-		if (insn_has_bdelay(relocs, split - 1))
+		if (uasm_insn_has_bdelay(relocs, split - 1))
 			split--;
 
 		/* Copy first part of the handler. */
-		copy_handler(relocs, labels, tlb_handler, split, f);
+		uasm_copy_handler(relocs, labels, tlb_handler, split, f);
 		f += split - tlb_handler;
 
 		/* Insert branch. */
-		l_split(&l, final_handler);
-		il_b(&f, &r, label_split);
-		if (insn_has_bdelay(relocs, split))
-			i_nop(&f);
+		uasm_l_split(&l, final_handler);
+		uasm_il_b(&f, &r, label_split);
+		if (uasm_insn_has_bdelay(relocs, split))
+			uasm_i_nop(&f);
 		else {
-			copy_handler(relocs, labels, split, split + 1, f);
-			move_labels(labels, f, f + 1, -1);
+			uasm_copy_handler(relocs, labels, split, split + 1, f);
+			uasm_move_labels(labels, f, f + 1, -1);
 			f++;
 			split++;
 		}
 
 		/* Copy the rest of the handler. */
-		copy_handler(relocs, labels, split, p, final_handler);
+		uasm_copy_handler(relocs, labels, split, p, final_handler);
 		final_len = (f - (final_handler + 32)) + (p - split);
 	}
 #endif /* CONFIG_64BIT */
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB refill handler (%u instructions).\n",
-		final_len);
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB refill handler (%u instructions).\n",
+		 final_len);
 
 	f = final_handler;
 #if defined(CONFIG_64BIT) && !defined(CONFIG_CPU_LOONGSON2)
@@ -1395,75 +786,75 @@ u32 __tlb_handler_align handle_tlbs[FASTPATH_SIZE];
 u32 __tlb_handler_align handle_tlbm[FASTPATH_SIZE];
 
 static void __init
-iPTE_LW(u32 **p, struct label **l, unsigned int pte, unsigned int ptr)
+iPTE_LW(u32 **p, struct uasm_label **l, unsigned int pte, unsigned int ptr)
 {
 #ifdef CONFIG_SMP
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (cpu_has_64bits)
-		i_lld(p, pte, 0, ptr);
+		uasm_i_lld(p, pte, 0, ptr);
 	else
 # endif
-		i_LL(p, pte, 0, ptr);
+		UASM_i_LL(p, pte, 0, ptr);
 #else
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (cpu_has_64bits)
-		i_ld(p, pte, 0, ptr);
+		uasm_i_ld(p, pte, 0, ptr);
 	else
 # endif
-		i_LW(p, pte, 0, ptr);
+		UASM_i_LW(p, pte, 0, ptr);
 #endif
 }
 
 static void __init
-iPTE_SW(u32 **p, struct reloc **r, unsigned int pte, unsigned int ptr,
+iPTE_SW(u32 **p, struct uasm_reloc **r, unsigned int pte, unsigned int ptr,
 	unsigned int mode)
 {
 #ifdef CONFIG_64BIT_PHYS_ADDR
 	unsigned int hwmode = mode & (_PAGE_VALID | _PAGE_DIRTY);
 #endif
 
-	i_ori(p, pte, pte, mode);
+	uasm_i_ori(p, pte, pte, mode);
 #ifdef CONFIG_SMP
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (cpu_has_64bits)
-		i_scd(p, pte, 0, ptr);
+		uasm_i_scd(p, pte, 0, ptr);
 	else
 # endif
-		i_SC(p, pte, 0, ptr);
+		UASM_i_SC(p, pte, 0, ptr);
 
 	if (r10000_llsc_war())
-		il_beqzl(p, r, pte, label_smp_pgtable_change);
+		uasm_il_beqzl(p, r, pte, label_smp_pgtable_change);
 	else
-		il_beqz(p, r, pte, label_smp_pgtable_change);
+		uasm_il_beqz(p, r, pte, label_smp_pgtable_change);
 
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (!cpu_has_64bits) {
-		/* no i_nop needed */
-		i_ll(p, pte, sizeof(pte_t) / 2, ptr);
-		i_ori(p, pte, pte, hwmode);
-		i_sc(p, pte, sizeof(pte_t) / 2, ptr);
-		il_beqz(p, r, pte, label_smp_pgtable_change);
-		/* no i_nop needed */
-		i_lw(p, pte, 0, ptr);
+		/* no uasm_i_nop needed */
+		uasm_i_ll(p, pte, sizeof(pte_t) / 2, ptr);
+		uasm_i_ori(p, pte, pte, hwmode);
+		uasm_i_sc(p, pte, sizeof(pte_t) / 2, ptr);
+		uasm_il_beqz(p, r, pte, label_smp_pgtable_change);
+		/* no uasm_i_nop needed */
+		uasm_i_lw(p, pte, 0, ptr);
 	} else
-		i_nop(p);
+		uasm_i_nop(p);
 # else
-	i_nop(p);
+	uasm_i_nop(p);
 # endif
 #else
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (cpu_has_64bits)
-		i_sd(p, pte, 0, ptr);
+		uasm_i_sd(p, pte, 0, ptr);
 	else
 # endif
-		i_SW(p, pte, 0, ptr);
+		UASM_i_SW(p, pte, 0, ptr);
 
 # ifdef CONFIG_64BIT_PHYS_ADDR
 	if (!cpu_has_64bits) {
-		i_lw(p, pte, sizeof(pte_t) / 2, ptr);
-		i_ori(p, pte, pte, hwmode);
-		i_sw(p, pte, sizeof(pte_t) / 2, ptr);
-		i_lw(p, pte, 0, ptr);
+		uasm_i_lw(p, pte, sizeof(pte_t) / 2, ptr);
+		uasm_i_ori(p, pte, pte, hwmode);
+		uasm_i_sw(p, pte, sizeof(pte_t) / 2, ptr);
+		uasm_i_lw(p, pte, 0, ptr);
 	}
 # endif
 #endif
@@ -1475,18 +866,18 @@ iPTE_SW(u32 **p, struct reloc **r, unsigned int pte, unsigned int ptr,
  * with it's original value.
  */
 static void __init
-build_pte_present(u32 **p, struct label **l, struct reloc **r,
+build_pte_present(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
 		  unsigned int pte, unsigned int ptr, enum label_id lid)
 {
-	i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
-	i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
-	il_bnez(p, r, pte, lid);
+	uasm_i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+	uasm_i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+	uasm_il_bnez(p, r, pte, lid);
 	iPTE_LW(p, l, pte, ptr);
 }
 
 /* Make PTE valid, store result in PTR. */
 static void __init
-build_make_valid(u32 **p, struct reloc **r, unsigned int pte,
+build_make_valid(u32 **p, struct uasm_reloc **r, unsigned int pte,
 		 unsigned int ptr)
 {
 	unsigned int mode = _PAGE_VALID | _PAGE_ACCESSED;
@@ -1499,12 +890,12 @@ build_make_valid(u32 **p, struct reloc **r, unsigned int pte,
  * restore PTE with value from PTR when done.
  */
 static void __init
-build_pte_writable(u32 **p, struct label **l, struct reloc **r,
+build_pte_writable(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
 		   unsigned int pte, unsigned int ptr, enum label_id lid)
 {
-	i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
-	i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
-	il_bnez(p, r, pte, lid);
+	uasm_i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+	uasm_i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+	uasm_il_bnez(p, r, pte, lid);
 	iPTE_LW(p, l, pte, ptr);
 }
 
@@ -1512,7 +903,7 @@ build_pte_writable(u32 **p, struct label **l, struct reloc **r,
  * at PTR.
  */
 static void __init
-build_make_write(u32 **p, struct reloc **r, unsigned int pte,
+build_make_write(u32 **p, struct uasm_reloc **r, unsigned int pte,
 		 unsigned int ptr)
 {
 	unsigned int mode = (_PAGE_ACCESSED | _PAGE_MODIFIED | _PAGE_VALID
@@ -1526,11 +917,11 @@ build_make_write(u32 **p, struct reloc **r, unsigned int pte,
  * restore PTE with value from PTR when done.
  */
 static void __init
-build_pte_modifiable(u32 **p, struct label **l, struct reloc **r,
+build_pte_modifiable(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
 		     unsigned int pte, unsigned int ptr, enum label_id lid)
 {
-	i_andi(p, pte, pte, _PAGE_WRITE);
-	il_beqz(p, r, pte, lid);
+	uasm_i_andi(p, pte, pte, _PAGE_WRITE);
+	uasm_il_beqz(p, r, pte, lid);
 	iPTE_LW(p, l, pte, ptr);
 }
 
@@ -1545,11 +936,11 @@ build_pte_modifiable(u32 **p, struct label **l, struct reloc **r,
 static void __init
 build_r3000_pte_reload_tlbwi(u32 **p, unsigned int pte, unsigned int tmp)
 {
-	i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
-	i_mfc0(p, tmp, C0_EPC); /* cp0 delay */
-	i_tlbwi(p);
-	i_jr(p, tmp);
-	i_rfe(p); /* branch delay */
+	uasm_i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
+	uasm_i_mfc0(p, tmp, C0_EPC); /* cp0 delay */
+	uasm_i_tlbwi(p);
+	uasm_i_jr(p, tmp);
+	uasm_i_rfe(p); /* branch delay */
 }
 
 /*
@@ -1559,20 +950,21 @@ build_r3000_pte_reload_tlbwi(u32 **p, unsigned int pte, unsigned int tmp)
  * kseg2 access, i.e. without refill.  Then it returns.
  */
 static void __init
-build_r3000_tlb_reload_write(u32 **p, struct label **l, struct reloc **r,
-			     unsigned int pte, unsigned int tmp)
-{
-	i_mfc0(p, tmp, C0_INDEX);
-	i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
-	il_bltz(p, r, tmp, label_r3000_write_probe_fail); /* cp0 delay */
-	i_mfc0(p, tmp, C0_EPC); /* branch delay */
-	i_tlbwi(p); /* cp0 delay */
-	i_jr(p, tmp);
-	i_rfe(p); /* branch delay */
-	l_r3000_write_probe_fail(l, *p);
-	i_tlbwr(p); /* cp0 delay */
-	i_jr(p, tmp);
-	i_rfe(p); /* branch delay */
+build_r3000_tlb_reload_write(u32 **p, struct uasm_label **l,
+			     struct uasm_reloc **r, unsigned int pte,
+			     unsigned int tmp)
+{
+	uasm_i_mfc0(p, tmp, C0_INDEX);
+	uasm_i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
+	uasm_il_bltz(p, r, tmp, label_r3000_write_probe_fail); /* cp0 delay */
+	uasm_i_mfc0(p, tmp, C0_EPC); /* branch delay */
+	uasm_i_tlbwi(p); /* cp0 delay */
+	uasm_i_jr(p, tmp);
+	uasm_i_rfe(p); /* branch delay */
+	uasm_l_r3000_write_probe_fail(l, *p);
+	uasm_i_tlbwr(p); /* cp0 delay */
+	uasm_i_jr(p, tmp);
+	uasm_i_rfe(p); /* branch delay */
 }
 
 static void __init
@@ -1581,25 +973,25 @@ build_r3000_tlbchange_handler_head(u32 **p, unsigned int pte,
 {
 	long pgdc = (long)pgd_current;
 
-	i_mfc0(p, pte, C0_BADVADDR);
-	i_lui(p, ptr, rel_hi(pgdc)); /* cp0 delay */
-	i_lw(p, ptr, rel_lo(pgdc), ptr);
-	i_srl(p, pte, pte, 22); /* load delay */
-	i_sll(p, pte, pte, 2);
-	i_addu(p, ptr, ptr, pte);
-	i_mfc0(p, pte, C0_CONTEXT);
-	i_lw(p, ptr, 0, ptr); /* cp0 delay */
-	i_andi(p, pte, pte, 0xffc); /* load delay */
-	i_addu(p, ptr, ptr, pte);
-	i_lw(p, pte, 0, ptr);
-	i_tlbp(p); /* load delay */
+	uasm_i_mfc0(p, pte, C0_BADVADDR);
+	uasm_i_lui(p, ptr, uasm_rel_hi(pgdc)); /* cp0 delay */
+	uasm_i_lw(p, ptr, uasm_rel_lo(pgdc), ptr);
+	uasm_i_srl(p, pte, pte, 22); /* load delay */
+	uasm_i_sll(p, pte, pte, 2);
+	uasm_i_addu(p, ptr, ptr, pte);
+	uasm_i_mfc0(p, pte, C0_CONTEXT);
+	uasm_i_lw(p, ptr, 0, ptr); /* cp0 delay */
+	uasm_i_andi(p, pte, pte, 0xffc); /* load delay */
+	uasm_i_addu(p, ptr, ptr, pte);
+	uasm_i_lw(p, pte, 0, ptr);
+	uasm_i_tlbp(p); /* load delay */
 }
 
 static void __init build_r3000_tlb_load_handler(void)
 {
 	u32 *p = handle_tlbl;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbl, 0, sizeof(handle_tlbl));
@@ -1608,20 +1000,20 @@ static void __init build_r3000_tlb_load_handler(void)
 
 	build_r3000_tlbchange_handler_head(&p, K0, K1);
 	build_pte_present(&p, &l, &r, K0, K1, label_nopage_tlbl);
-	i_nop(&p); /* load delay */
+	uasm_i_nop(&p); /* load delay */
 	build_make_valid(&p, &r, K0, K1);
 	build_r3000_tlb_reload_write(&p, &l, &r, K0, K1);
 
-	l_nopage_tlbl(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbl(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbl) > FASTPATH_SIZE)
 		panic("TLB load handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB load handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbl));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB load handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbl));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -1633,8 +1025,8 @@ static void __init build_r3000_tlb_load_handler(void)
 static void __init build_r3000_tlb_store_handler(void)
 {
 	u32 *p = handle_tlbs;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbs, 0, sizeof(handle_tlbs));
@@ -1643,20 +1035,20 @@ static void __init build_r3000_tlb_store_handler(void)
 
 	build_r3000_tlbchange_handler_head(&p, K0, K1);
 	build_pte_writable(&p, &l, &r, K0, K1, label_nopage_tlbs);
-	i_nop(&p); /* load delay */
+	uasm_i_nop(&p); /* load delay */
 	build_make_write(&p, &r, K0, K1);
 	build_r3000_tlb_reload_write(&p, &l, &r, K0, K1);
 
-	l_nopage_tlbs(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbs(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbs) > FASTPATH_SIZE)
 		panic("TLB store handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB store handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbs));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB store handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbs));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -1668,8 +1060,8 @@ static void __init build_r3000_tlb_store_handler(void)
 static void __init build_r3000_tlb_modify_handler(void)
 {
 	u32 *p = handle_tlbm;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbm, 0, sizeof(handle_tlbm));
@@ -1678,20 +1070,20 @@ static void __init build_r3000_tlb_modify_handler(void)
 
 	build_r3000_tlbchange_handler_head(&p, K0, K1);
 	build_pte_modifiable(&p, &l, &r, K0, K1, label_nopage_tlbm);
-	i_nop(&p); /* load delay */
+	uasm_i_nop(&p); /* load delay */
 	build_make_write(&p, &r, K0, K1);
 	build_r3000_pte_reload_tlbwi(&p, K0, K1);
 
-	l_nopage_tlbm(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbm(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbm) > FASTPATH_SIZE)
 		panic("TLB modify handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbm));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB modify handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbm));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -1704,8 +1096,8 @@ static void __init build_r3000_tlb_modify_handler(void)
  * R4000 style TLB load/store/modify handlers.
  */
 static void __init
-build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
-				   struct reloc **r, unsigned int pte,
+build_r4000_tlbchange_handler_head(u32 **p, struct uasm_label **l,
+				   struct uasm_reloc **r, unsigned int pte,
 				   unsigned int ptr)
 {
 #ifdef CONFIG_64BIT
@@ -1714,14 +1106,14 @@ build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
 	build_get_pgde32(p, pte, ptr); /* get pgd in ptr */
 #endif
 
-	i_MFC0(p, pte, C0_BADVADDR);
-	i_LW(p, ptr, 0, ptr);
-	i_SRL(p, pte, pte, PAGE_SHIFT + PTE_ORDER - PTE_T_LOG2);
-	i_andi(p, pte, pte, (PTRS_PER_PTE - 1) << PTE_T_LOG2);
-	i_ADDU(p, ptr, ptr, pte);
+	UASM_i_MFC0(p, pte, C0_BADVADDR);
+	UASM_i_LW(p, ptr, 0, ptr);
+	UASM_i_SRL(p, pte, pte, PAGE_SHIFT + PTE_ORDER - PTE_T_LOG2);
+	uasm_i_andi(p, pte, pte, (PTRS_PER_PTE - 1) << PTE_T_LOG2);
+	UASM_i_ADDU(p, ptr, ptr, pte);
 
 #ifdef CONFIG_SMP
-	l_smp_pgtable_change(l, *p);
+	uasm_l_smp_pgtable_change(l, *p);
 # endif
 	iPTE_LW(p, l, pte, ptr); /* get even pte */
 	if (!m4kc_tlbp_war())
@@ -1729,16 +1121,16 @@ build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
 }
 
 static void __init
-build_r4000_tlbchange_handler_tail(u32 **p, struct label **l,
-				   struct reloc **r, unsigned int tmp,
+build_r4000_tlbchange_handler_tail(u32 **p, struct uasm_label **l,
+				   struct uasm_reloc **r, unsigned int tmp,
 				   unsigned int ptr)
 {
-	i_ori(p, ptr, ptr, sizeof(pte_t));
-	i_xori(p, ptr, ptr, sizeof(pte_t));
+	uasm_i_ori(p, ptr, ptr, sizeof(pte_t));
+	uasm_i_xori(p, ptr, ptr, sizeof(pte_t));
 	build_update_entries(p, tmp, ptr);
 	build_tlb_write_entry(p, l, r, tlb_indexed);
-	l_leave(l, *p);
-	i_eret(p); /* return from trap */
+	uasm_l_leave(l, *p);
+	uasm_i_eret(p); /* return from trap */
 
 #ifdef CONFIG_64BIT
 	build_get_pgd_vmalloc64(p, l, r, tmp, ptr);
@@ -1748,8 +1140,8 @@ build_r4000_tlbchange_handler_tail(u32 **p, struct label **l,
 static void __init build_r4000_tlb_load_handler(void)
 {
 	u32 *p = handle_tlbl;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbl, 0, sizeof(handle_tlbl));
@@ -1757,12 +1149,12 @@ static void __init build_r4000_tlb_load_handler(void)
 	memset(relocs, 0, sizeof(relocs));
 
 	if (bcm1250_m3_war()) {
-		i_MFC0(&p, K0, C0_BADVADDR);
-		i_MFC0(&p, K1, C0_ENTRYHI);
-		i_xor(&p, K0, K0, K1);
-		i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
-		il_bnez(&p, &r, K0, label_leave);
-		/* No need for i_nop */
+		UASM_i_MFC0(&p, K0, C0_BADVADDR);
+		UASM_i_MFC0(&p, K1, C0_ENTRYHI);
+		uasm_i_xor(&p, K0, K0, K1);
+		UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+		uasm_il_bnez(&p, &r, K0, label_leave);
+		/* No need for uasm_i_nop */
 	}
 
 	build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1);
@@ -1772,16 +1164,16 @@ static void __init build_r4000_tlb_load_handler(void)
 	build_make_valid(&p, &r, K0, K1);
 	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
 
-	l_nopage_tlbl(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbl(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbl) > FASTPATH_SIZE)
 		panic("TLB load handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB load handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbl));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB load handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbl));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -1793,8 +1185,8 @@ static void __init build_r4000_tlb_load_handler(void)
 static void __init build_r4000_tlb_store_handler(void)
 {
 	u32 *p = handle_tlbs;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbs, 0, sizeof(handle_tlbs));
@@ -1808,16 +1200,16 @@ static void __init build_r4000_tlb_store_handler(void)
 	build_make_write(&p, &r, K0, K1);
 	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
 
-	l_nopage_tlbs(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbs(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbs) > FASTPATH_SIZE)
 		panic("TLB store handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB store handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbs));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB store handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbs));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
@@ -1829,8 +1221,8 @@ static void __init build_r4000_tlb_store_handler(void)
 static void __init build_r4000_tlb_modify_handler(void)
 {
 	u32 *p = handle_tlbm;
-	struct label *l = labels;
-	struct reloc *r = relocs;
+	struct uasm_label *l = labels;
+	struct uasm_reloc *r = relocs;
 	int i;
 
 	memset(handle_tlbm, 0, sizeof(handle_tlbm));
@@ -1845,16 +1237,16 @@ static void __init build_r4000_tlb_modify_handler(void)
 	build_make_write(&p, &r, K0, K1);
 	build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
 
-	l_nopage_tlbm(&l, p);
-	i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
-	i_nop(&p);
+	uasm_l_nopage_tlbm(&l, p);
+	uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+	uasm_i_nop(&p);
 
 	if ((p - handle_tlbm) > FASTPATH_SIZE)
 		panic("TLB modify handler fastpath space exceeded");
 
-	resolve_relocs(relocs, labels);
-	pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n",
-		(unsigned int)(p - handle_tlbm));
+	uasm_resolve_relocs(relocs, labels);
+	pr_debug("Wrote TLB modify handler fastpath (%u instructions).\n",
+		 (unsigned int)(p - handle_tlbm));
 
 	pr_debug("\t.set push\n");
 	pr_debug("\t.set noreorder\n");
diff --git a/arch/mips/mm/uasm.c b/arch/mips/mm/uasm.c
new file mode 100644
index 0000000..889176a
--- /dev/null
+++ b/arch/mips/mm/uasm.c
@@ -0,0 +1,566 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * A small micro-assembler. It is intentionally kept simple, does only
+ * support a subset of instructions, and does not try to hide pipeline
+ * effects like branch delay slots.
+ *
+ * Copyright (C) 2004,2005,2006,2008  Thiemo Seufer
+ * Copyright (C) 2005  Maciej W. Rozycki
+ * Copyright (C) 2006  Ralf Baechle (ralf@linux-mips.org)
+ */
+
+#include <stdarg.h>
+
+#include <linux/mm.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+
+#include <asm/inst.h>
+#include <asm/elf.h>
+
+#include "uasm.h"
+
+enum fields {
+	RS = 0x001,
+	RT = 0x002,
+	RD = 0x004,
+	RE = 0x008,
+	SIMM = 0x010,
+	UIMM = 0x020,
+	BIMM = 0x040,
+	JIMM = 0x080,
+	FUNC = 0x100,
+	SET = 0x200
+};
+
+#define OP_MASK		0x3f
+#define OP_SH		26
+#define RS_MASK		0x1f
+#define RS_SH		21
+#define RT_MASK		0x1f
+#define RT_SH		16
+#define RD_MASK		0x1f
+#define RD_SH		11
+#define RE_MASK		0x1f
+#define RE_SH		6
+#define IMM_MASK	0xffff
+#define IMM_SH		0
+#define JIMM_MASK	0x3ffffff
+#define JIMM_SH		0
+#define FUNC_MASK	0x3f
+#define FUNC_SH		0
+#define SET_MASK	0x7
+#define SET_SH		0
+
+enum opcode {
+	insn_invalid,
+	insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
+	insn_beql, insn_bgez, insn_bgezl, insn_bltz, insn_bltzl,
+	insn_bne, insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0,
+	insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32,
+	insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld,
+	insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0,
+	insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll,
+	insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi,
+	insn_tlbwr, insn_xor, insn_xori
+};
+
+struct insn {
+	enum opcode opcode;
+	u32 match;
+	enum fields fields;
+};
+
+/* This macro sets the non-variable bits of an instruction. */
+#define M(a, b, c, d, e, f)					\
+	((a) << OP_SH						\
+	 | (b) << RS_SH						\
+	 | (c) << RT_SH						\
+	 | (d) << RD_SH						\
+	 | (e) << RE_SH						\
+	 | (f) << FUNC_SH)
+
+static __initdata struct insn insn_table[] = {
+	{ insn_addiu, M(addiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+	{ insn_addu, M(spec_op, 0, 0, 0, 0, addu_op), RS | RT | RD },
+	{ insn_and, M(spec_op, 0, 0, 0, 0, and_op), RS | RT | RD },
+	{ insn_andi, M(andi_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
+	{ insn_beq, M(beq_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+	{ insn_beql, M(beql_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+	{ insn_bgez, M(bcond_op, 0, bgez_op, 0, 0, 0), RS | BIMM },
+	{ insn_bgezl, M(bcond_op, 0, bgezl_op, 0, 0, 0), RS | BIMM },
+	{ insn_bltz, M(bcond_op, 0, bltz_op, 0, 0, 0), RS | BIMM },
+	{ insn_bltzl, M(bcond_op, 0, bltzl_op, 0, 0, 0), RS | BIMM },
+	{ insn_bne, M(bne_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+	{ insn_daddiu, M(daddiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+	{ insn_daddu, M(spec_op, 0, 0, 0, 0, daddu_op), RS | RT | RD },
+	{ insn_dmfc0, M(cop0_op, dmfc_op, 0, 0, 0, 0), RT | RD | SET},
+	{ insn_dmtc0, M(cop0_op, dmtc_op, 0, 0, 0, 0), RT | RD | SET},
+	{ insn_dsll, M(spec_op, 0, 0, 0, 0, dsll_op), RT | RD | RE },
+	{ insn_dsll32, M(spec_op, 0, 0, 0, 0, dsll32_op), RT | RD | RE },
+	{ insn_dsra, M(spec_op, 0, 0, 0, 0, dsra_op), RT | RD | RE },
+	{ insn_dsrl, M(spec_op, 0, 0, 0, 0, dsrl_op), RT | RD | RE },
+	{ insn_dsrl32, M(spec_op, 0, 0, 0, 0, dsrl32_op), RT | RD | RE },
+	{ insn_dsubu, M(spec_op, 0, 0, 0, 0, dsubu_op), RS | RT | RD },
+	{ insn_eret,  M(cop0_op, cop_op, 0, 0, 0, eret_op),  0 },
+	{ insn_j,  M(j_op, 0, 0, 0, 0, 0),  JIMM },
+	{ insn_jal,  M(jal_op, 0, 0, 0, 0, 0),  JIMM },
+	{ insn_jr,  M(spec_op, 0, 0, 0, 0, jr_op),  RS },
+	{ insn_ld,  M(ld_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_ll,  M(ll_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_lld,  M(lld_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_lui,  M(lui_op, 0, 0, 0, 0, 0),  RT | SIMM },
+	{ insn_lw,  M(lw_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_mfc0,  M(cop0_op, mfc_op, 0, 0, 0, 0),  RT | RD | SET},
+	{ insn_mtc0,  M(cop0_op, mtc_op, 0, 0, 0, 0),  RT | RD | SET},
+	{ insn_ori,  M(ori_op, 0, 0, 0, 0, 0),  RS | RT | UIMM },
+	{ insn_rfe,  M(cop0_op, cop_op, 0, 0, 0, rfe_op),  0 },
+	{ insn_sc,  M(sc_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_scd,  M(scd_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_sd,  M(sd_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_sll,  M(spec_op, 0, 0, 0, 0, sll_op),  RT | RD | RE },
+	{ insn_sra,  M(spec_op, 0, 0, 0, 0, sra_op),  RT | RD | RE },
+	{ insn_srl,  M(spec_op, 0, 0, 0, 0, srl_op),  RT | RD | RE },
+	{ insn_subu,  M(spec_op, 0, 0, 0, 0, subu_op),  RS | RT | RD },
+	{ insn_sw,  M(sw_op, 0, 0, 0, 0, 0),  RS | RT | SIMM },
+	{ insn_tlbp,  M(cop0_op, cop_op, 0, 0, 0, tlbp_op),  0 },
+	{ insn_tlbwi,  M(cop0_op, cop_op, 0, 0, 0, tlbwi_op),  0 },
+	{ insn_tlbwr,  M(cop0_op, cop_op, 0, 0, 0, tlbwr_op),  0 },
+	{ insn_xor,  M(spec_op, 0, 0, 0, 0, xor_op),  RS | RT | RD },
+	{ insn_xori,  M(xori_op, 0, 0, 0, 0, 0),  RS | RT | UIMM },
+	{ insn_invalid, 0, 0 }
+};
+
+#undef M
+
+static inline __init u32 build_rs(u32 arg)
+{
+	if (arg & ~RS_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return (arg & RS_MASK) << RS_SH;
+}
+
+static inline __init u32 build_rt(u32 arg)
+{
+	if (arg & ~RT_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return (arg & RT_MASK) << RT_SH;
+}
+
+static inline __init u32 build_rd(u32 arg)
+{
+	if (arg & ~RD_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return (arg & RD_MASK) << RD_SH;
+}
+
+static inline __init u32 build_re(u32 arg)
+{
+	if (arg & ~RE_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return (arg & RE_MASK) << RE_SH;
+}
+
+static inline __init u32 build_simm(s32 arg)
+{
+	if (arg > 0x7fff || arg < -0x8000)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return arg & 0xffff;
+}
+
+static inline __init u32 build_uimm(u32 arg)
+{
+	if (arg & ~IMM_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return arg & IMM_MASK;
+}
+
+static inline __init u32 build_bimm(s32 arg)
+{
+	if (arg > 0x1ffff || arg < -0x20000)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	if (arg & 0x3)
+		printk(KERN_WARNING "Invalid micro-assembler branch target\n");
+
+	return ((arg < 0) ? (1 << 15) : 0) | ((arg >> 2) & 0x7fff);
+}
+
+static inline __init u32 build_jimm(u32 arg)
+{
+	if (arg & ~((JIMM_MASK) << 2))
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return (arg >> 2) & JIMM_MASK;
+}
+
+static inline __init u32 build_func(u32 arg)
+{
+	if (arg & ~FUNC_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return arg & FUNC_MASK;
+}
+
+static inline __init u32 build_set(u32 arg)
+{
+	if (arg & ~SET_MASK)
+		printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+	return arg & SET_MASK;
+}
+
+/*
+ * The order of opcode arguments is implicitly left to right,
+ * starting with RS and ending with FUNC or IMM.
+ */
+static void __init build_insn(u32 **buf, enum opcode opc, ...)
+{
+	struct insn *ip = NULL;
+	unsigned int i;
+	va_list ap;
+	u32 op;
+
+	for (i = 0; insn_table[i].opcode != insn_invalid; i++)
+		if (insn_table[i].opcode == opc) {
+			ip = &insn_table[i];
+			break;
+		}
+
+	if (!ip)
+		panic("Unsupported Micro-assembler instruction %d", opc);
+
+	op = ip->match;
+	va_start(ap, opc);
+	if (ip->fields & RS)
+		op |= build_rs(va_arg(ap, u32));
+	if (ip->fields & RT)
+		op |= build_rt(va_arg(ap, u32));
+	if (ip->fields & RD)
+		op |= build_rd(va_arg(ap, u32));
+	if (ip->fields & RE)
+		op |= build_re(va_arg(ap, u32));
+	if (ip->fields & SIMM)
+		op |= build_simm(va_arg(ap, s32));
+	if (ip->fields & UIMM)
+		op |= build_uimm(va_arg(ap, u32));
+	if (ip->fields & BIMM)
+		op |= build_bimm(va_arg(ap, s32));
+	if (ip->fields & JIMM)
+		op |= build_jimm(va_arg(ap, u32));
+	if (ip->fields & FUNC)
+		op |= build_func(va_arg(ap, u32));
+	if (ip->fields & SET)
+		op |= build_set(va_arg(ap, u32));
+	va_end(ap);
+
+	**buf = op;
+	(*buf)++;
+}
+
+#define I_u1u2u3(op)					\
+Ip_u1u2u3(op)						\
+{							\
+	build_insn(buf, insn##op, a, b, c);		\
+}
+
+#define I_u2u1u3(op)					\
+Ip_u2u1u3(op)						\
+{							\
+	build_insn(buf, insn##op, b, a, c);		\
+}
+
+#define I_u3u1u2(op)					\
+Ip_u3u1u2(op)						\
+{							\
+	build_insn(buf, insn##op, b, c, a);		\
+}
+
+#define I_u1u2s3(op)					\
+Ip_u1u2s3(op)						\
+{							\
+	build_insn(buf, insn##op, a, b, c);		\
+}
+
+#define I_u2s3u1(op)					\
+Ip_u2s3u1(op)						\
+{							\
+	build_insn(buf, insn##op, c, a, b);		\
+}
+
+#define I_u2u1s3(op)					\
+Ip_u2u1s3(op)						\
+{							\
+	build_insn(buf, insn##op, b, a, c);		\
+}
+
+#define I_u1u2(op)					\
+Ip_u1u2(op)						\
+{							\
+	build_insn(buf, insn##op, a, b);		\
+}
+
+#define I_u1s2(op)					\
+Ip_u1s2(op)						\
+{							\
+	build_insn(buf, insn##op, a, b);		\
+}
+
+#define I_u1(op)					\
+Ip_u1(op)						\
+{							\
+	build_insn(buf, insn##op, a);			\
+}
+
+#define I_0(op)						\
+Ip_0(op)						\
+{							\
+	build_insn(buf, insn##op);			\
+}
+
+I_u2u1s3(_addiu)
+I_u3u1u2(_addu)
+I_u2u1u3(_andi)
+I_u3u1u2(_and)
+I_u1u2s3(_beq)
+I_u1u2s3(_beql)
+I_u1s2(_bgez)
+I_u1s2(_bgezl)
+I_u1s2(_bltz)
+I_u1s2(_bltzl)
+I_u1u2s3(_bne)
+I_u1u2u3(_dmfc0)
+I_u1u2u3(_dmtc0)
+I_u2u1s3(_daddiu)
+I_u3u1u2(_daddu)
+I_u2u1u3(_dsll)
+I_u2u1u3(_dsll32)
+I_u2u1u3(_dsra)
+I_u2u1u3(_dsrl)
+I_u2u1u3(_dsrl32)
+I_u3u1u2(_dsubu)
+I_0(_eret)
+I_u1(_j)
+I_u1(_jal)
+I_u1(_jr)
+I_u2s3u1(_ld)
+I_u2s3u1(_ll)
+I_u2s3u1(_lld)
+I_u1s2(_lui)
+I_u2s3u1(_lw)
+I_u1u2u3(_mfc0)
+I_u1u2u3(_mtc0)
+I_u2u1u3(_ori)
+I_0(_rfe)
+I_u2s3u1(_sc)
+I_u2s3u1(_scd)
+I_u2s3u1(_sd)
+I_u2u1u3(_sll)
+I_u2u1u3(_sra)
+I_u2u1u3(_srl)
+I_u3u1u2(_subu)
+I_u2s3u1(_sw)
+I_0(_tlbp)
+I_0(_tlbwi)
+I_0(_tlbwr)
+I_u3u1u2(_xor)
+I_u2u1u3(_xori)
+
+/* Handle labels. */
+__init void uasm_build_label(struct uasm_label **lab, u32 *addr, int lid)
+{
+	(*lab)->addr = addr;
+	(*lab)->lab = lid;
+	(*lab)++;
+}
+
+#ifdef CONFIG_64BIT
+__init int uasm_in_compat_space_p(long addr)
+{
+	/* Is this address in 32bit compat space? */
+	return (((addr) & 0xffffffff00000000L) == 0xffffffff00000000L);
+}
+
+__init int uasm_rel_highest(long val)
+{
+	return ((((val + 0x800080008000L) >> 48) & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init int uasm_rel_higher(long val)
+{
+	return ((((val + 0x80008000L) >> 32) & 0xffff) ^ 0x8000) - 0x8000;
+}
+#endif
+
+__init int uasm_rel_hi(long val)
+{
+	return ((((val + 0x8000L) >> 16) & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init int uasm_rel_lo(long val)
+{
+	return ((val & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init void UASM_i_LA_mostly(u32 **buf, unsigned int rs, long addr)
+{
+#ifdef CONFIG_64BIT
+	if (!uasm_in_compat_space_p(addr)) {
+		uasm_i_lui(buf, rs, uasm_rel_highest(addr));
+		if (uasm_rel_higher(addr))
+			uasm_i_daddiu(buf, rs, rs, uasm_rel_higher(addr));
+		if (uasm_rel_hi(addr)) {
+			uasm_i_dsll(buf, rs, rs, 16);
+			uasm_i_daddiu(buf, rs, rs, uasm_rel_hi(addr));
+			uasm_i_dsll(buf, rs, rs, 16);
+		} else
+			uasm_i_dsll32(buf, rs, rs, 0);
+	} else
+#endif
+		uasm_i_lui(buf, rs, uasm_rel_hi(addr));
+}
+
+__init void UASM_i_LA(u32 **buf, unsigned int rs, long addr)
+{
+	UASM_i_LA_mostly(buf, rs, addr);
+	if (uasm_rel_lo(addr))
+		UASM_i_ADDIU(buf, rs, rs, uasm_rel_lo(addr));
+}
+
+/* Handle relocations. */
+__init void
+uasm_r_mips_pc16(struct uasm_reloc **rel, u32 *addr, int lid)
+{
+	(*rel)->addr = addr;
+	(*rel)->type = R_MIPS_PC16;
+	(*rel)->lab = lid;
+	(*rel)++;
+}
+
+static inline void
+__resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab)
+{
+	long laddr = (long)lab->addr;
+	long raddr = (long)rel->addr;
+
+	switch (rel->type) {
+	case R_MIPS_PC16:
+		*rel->addr |= build_bimm(laddr - (raddr + 4));
+		break;
+
+	default:
+		panic("Unsupported Micro-assembler relocation %d",
+		      rel->type);
+	}
+}
+
+__init void
+uasm_resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab)
+{
+	struct uasm_label *l;
+
+	for (; rel->lab != UASM_LABEL_INVALID; rel++)
+		for (l = lab; l->lab != UASM_LABEL_INVALID; l++)
+			if (rel->lab == l->lab)
+				__resolve_relocs(rel, l);
+}
+
+__init void
+uasm_move_relocs(struct uasm_reloc *rel, u32 *first, u32 *end, long off)
+{
+	for (; rel->lab != UASM_LABEL_INVALID; rel++)
+		if (rel->addr >= first && rel->addr < end)
+			rel->addr += off;
+}
+
+__init void
+uasm_move_labels(struct uasm_label *lab, u32 *first, u32 *end, long off)
+{
+	for (; lab->lab != UASM_LABEL_INVALID; lab++)
+		if (lab->addr >= first && lab->addr < end)
+			lab->addr += off;
+}
+
+__init void
+uasm_copy_handler(struct uasm_reloc *rel, struct uasm_label *lab, u32 *first,
+		  u32 *end, u32 *target)
+{
+	long off = (long)(target - first);
+
+	memcpy(target, first, (end - first) * sizeof(u32));
+
+	uasm_move_relocs(rel, first, end, off);
+	uasm_move_labels(lab, first, end, off);
+}
+
+__init int uasm_insn_has_bdelay(struct uasm_reloc *rel, u32 *addr)
+{
+	for (; rel->lab != UASM_LABEL_INVALID; rel++) {
+		if (rel->addr == addr
+		    && (rel->type == R_MIPS_PC16
+			|| rel->type == R_MIPS_26))
+			return 1;
+	}
+
+	return 0;
+}
+
+/* Convenience functions for labeled branches. */
+void __init
+uasm_il_bltz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_bltz(p, reg, 0);
+}
+
+void __init
+uasm_il_b(u32 **p, struct uasm_reloc **r, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_b(p, 0);
+}
+
+void __init
+uasm_il_beqz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_beqz(p, reg, 0);
+}
+
+void __init
+uasm_il_beqzl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_beqzl(p, reg, 0);
+}
+
+void __init
+uasm_il_bnez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_bnez(p, reg, 0);
+}
+
+void __init
+uasm_il_bgezl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_bgezl(p, reg, 0);
+}
+
+void __init
+uasm_il_bgez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+	uasm_r_mips_pc16(r, *p, lid);
+	uasm_i_bgez(p, reg, 0);
+}
diff --git a/arch/mips/mm/uasm.h b/arch/mips/mm/uasm.h
new file mode 100644
index 0000000..e0053b0
--- /dev/null
+++ b/arch/mips/mm/uasm.h
@@ -0,0 +1,192 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2004,2005,2006,2008  Thiemo Seufer
+ * Copyright (C) 2005  Maciej W. Rozycki
+ * Copyright (C) 2006  Ralf Baechle (ralf@linux-mips.org)
+ */
+
+#include <linux/types.h>
+
+#define Ip_u1u2u3(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u2u1u3(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u3u1u2(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u1u2s3(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, signed int c)
+
+#define Ip_u2s3u1(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, signed int b, unsigned int c)
+
+#define Ip_u2u1s3(op)							\
+void __init								\
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, signed int c)
+
+#define Ip_u1u2(op)							\
+void __init uasm_i##op(u32 **buf, unsigned int a, unsigned int b)
+
+#define Ip_u1s2(op)							\
+void __init uasm_i##op(u32 **buf, unsigned int a, signed int b)
+
+#define Ip_u1(op) void __init uasm_i##op(u32 **buf, unsigned int a)
+
+#define Ip_0(op) void __init uasm_i##op(u32 **buf)
+
+Ip_u2u1s3(_addiu);
+Ip_u3u1u2(_addu);
+Ip_u2u1u3(_andi);
+Ip_u3u1u2(_and);
+Ip_u1u2s3(_beq);
+Ip_u1u2s3(_beql);
+Ip_u1s2(_bgez);
+Ip_u1s2(_bgezl);
+Ip_u1s2(_bltz);
+Ip_u1s2(_bltzl);
+Ip_u1u2s3(_bne);
+Ip_u1u2u3(_dmfc0);
+Ip_u1u2u3(_dmtc0);
+Ip_u2u1s3(_daddiu);
+Ip_u3u1u2(_daddu);
+Ip_u2u1u3(_dsll);
+Ip_u2u1u3(_dsll32);
+Ip_u2u1u3(_dsra);
+Ip_u2u1u3(_dsrl);
+Ip_u2u1u3(_dsrl32);
+Ip_u3u1u2(_dsubu);
+Ip_0(_eret);
+Ip_u1(_j);
+Ip_u1(_jal);
+Ip_u1(_jr);
+Ip_u2s3u1(_ld);
+Ip_u2s3u1(_ll);
+Ip_u2s3u1(_lld);
+Ip_u1s2(_lui);
+Ip_u2s3u1(_lw);
+Ip_u1u2u3(_mfc0);
+Ip_u1u2u3(_mtc0);
+Ip_u2u1u3(_ori);
+Ip_0(_rfe);
+Ip_u2s3u1(_sc);
+Ip_u2s3u1(_scd);
+Ip_u2s3u1(_sd);
+Ip_u2u1u3(_sll);
+Ip_u2u1u3(_sra);
+Ip_u2u1u3(_srl);
+Ip_u3u1u2(_subu);
+Ip_u2s3u1(_sw);
+Ip_0(_tlbp);
+Ip_0(_tlbwi);
+Ip_0(_tlbwr);
+Ip_u3u1u2(_xor);
+Ip_u2u1u3(_xori);
+
+/* Handle labels. */
+struct uasm_label {
+	u32 *addr;
+	int lab;
+};
+
+__init void uasm_build_label(struct uasm_label **lab, u32 *addr, int lid);
+#ifdef CONFIG_64BIT
+__init int uasm_in_compat_space_p(long addr);
+__init int uasm_rel_highest(long val);
+__init int uasm_rel_higher(long val);
+#endif
+__init int uasm_rel_hi(long val);
+__init int uasm_rel_lo(long val);
+__init void UASM_i_LA_mostly(u32 **buf, unsigned int rs, long addr);
+__init void UASM_i_LA(u32 **buf, unsigned int rs, long addr);
+
+#define UASM_L_LA(lb)							\
+static inline void uasm_l##lb(struct uasm_label **lab, u32 *addr)	\
+{									\
+	uasm_build_label(lab, addr, label##lb);				\
+}
+
+/* convenience macros for instructions */
+#ifdef CONFIG_64BIT
+# define UASM_i_LW(buf, rs, rt, off) uasm_i_ld(buf, rs, rt, off)
+# define UASM_i_SW(buf, rs, rt, off) uasm_i_sd(buf, rs, rt, off)
+# define UASM_i_SLL(buf, rs, rt, sh) uasm_i_dsll(buf, rs, rt, sh)
+# define UASM_i_SRA(buf, rs, rt, sh) uasm_i_dsra(buf, rs, rt, sh)
+# define UASM_i_SRL(buf, rs, rt, sh) uasm_i_dsrl(buf, rs, rt, sh)
+# define UASM_i_MFC0(buf, rt, rd...) uasm_i_dmfc0(buf, rt, rd)
+# define UASM_i_MTC0(buf, rt, rd...) uasm_i_dmtc0(buf, rt, rd)
+# define UASM_i_ADDIU(buf, rs, rt, val) uasm_i_daddiu(buf, rs, rt, val)
+# define UASM_i_ADDU(buf, rs, rt, rd) uasm_i_daddu(buf, rs, rt, rd)
+# define UASM_i_SUBU(buf, rs, rt, rd) uasm_i_dsubu(buf, rs, rt, rd)
+# define UASM_i_LL(buf, rs, rt, off) uasm_i_lld(buf, rs, rt, off)
+# define UASM_i_SC(buf, rs, rt, off) uasm_i_scd(buf, rs, rt, off)
+#else
+# define UASM_i_LW(buf, rs, rt, off) uasm_i_lw(buf, rs, rt, off)
+# define UASM_i_SW(buf, rs, rt, off) uasm_i_sw(buf, rs, rt, off)
+# define UASM_i_SLL(buf, rs, rt, sh) uasm_i_sll(buf, rs, rt, sh)
+# define UASM_i_SRA(buf, rs, rt, sh) uasm_i_sra(buf, rs, rt, sh)
+# define UASM_i_SRL(buf, rs, rt, sh) uasm_i_srl(buf, rs, rt, sh)
+# define UASM_i_MFC0(buf, rt, rd...) uasm_i_mfc0(buf, rt, rd)
+# define UASM_i_MTC0(buf, rt, rd...) uasm_i_mtc0(buf, rt, rd)
+# define UASM_i_ADDIU(buf, rs, rt, val) uasm_i_addiu(buf, rs, rt, val)
+# define UASM_i_ADDU(buf, rs, rt, rd) uasm_i_addu(buf, rs, rt, rd)
+# define UASM_i_SUBU(buf, rs, rt, rd) uasm_i_subu(buf, rs, rt, rd)
+# define UASM_i_LL(buf, rs, rt, off) uasm_i_ll(buf, rs, rt, off)
+# define UASM_i_SC(buf, rs, rt, off) uasm_i_sc(buf, rs, rt, off)
+#endif
+
+#define uasm_i_b(buf, off) uasm_i_beq(buf, 0, 0, off)
+#define uasm_i_beqz(buf, rs, off) uasm_i_beq(buf, rs, 0, off)
+#define uasm_i_beqzl(buf, rs, off) uasm_i_beql(buf, rs, 0, off)
+#define uasm_i_bnez(buf, rs, off) uasm_i_bne(buf, rs, 0, off)
+#define uasm_i_bnezl(buf, rs, off) uasm_i_bnel(buf, rs, 0, off)
+#define uasm_i_move(buf, a, b) UASM_i_ADDU(buf, a, 0, b)
+#define uasm_i_nop(buf) uasm_i_sll(buf, 0, 0, 0)
+#define uasm_i_ssnop(buf) uasm_i_sll(buf, 0, 0, 1)
+#define uasm_i_ehb(buf) uasm_i_sll(buf, 0, 0, 3)
+
+/* Handle relocations. */
+struct uasm_reloc {
+	u32 *addr;
+	unsigned int type;
+	int lab;
+};
+
+/* This is zero so we can use zeroed label arrays. */
+#define UASM_LABEL_INVALID 0
+
+__init void uasm_r_mips_pc16(struct uasm_reloc **rel, u32 *addr, int lid);
+__init void
+uasm_resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab);
+__init void
+uasm_move_relocs(struct uasm_reloc *rel, u32 *first, u32 *end, long off);
+__init void
+uasm_move_labels(struct uasm_label *lab, u32 *first, u32 *end, long off);
+__init void
+uasm_copy_handler(struct uasm_reloc *rel, struct uasm_label *lab, u32 *first,
+		  u32 *end, u32 *target);
+__init int uasm_insn_has_bdelay(struct uasm_reloc *rel, u32 *addr);
+
+/* Convenience functions for labeled branches. */
+void __init
+uasm_il_bltz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init uasm_il_b(u32 **p, struct uasm_reloc **r, int lid);
+void __init
+uasm_il_beqz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_beqzl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bnez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bgezl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bgez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);

(no subject)

[Jed Davidow]

unsubscribe linux-raid

(no subject)

[Abhishek Gupta]

[-- Attachment #1.1: Type: text/plain, Size: 426 bytes --]

msg=audit(1116360555.329:2401771).

How to interpret above message?what does 1116360555,329,2401771 means here?
By looking at this type of audit message how can i interpret all the things
related to a particular process?
If i want to trace all syscalls called by particular process how to do that
without using ausearch(means by looking at above type messages)
how can i obtain strace output by this this auditing subsystem ?

[-- Attachment #1.2: Type: text/html, Size: 499 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Steve Grubb]

On Saturday 12 January 2008 08:45:09 Abhishek Gupta wrote:
> msg=audit(1116360555.329:2401771).
>
> How to interpret above message?what does 1116360555,329,2401771 means here?

seconds.msec:serial number

The seconds can be converted with ctime().


> By looking at this type of audit message how can i interpret all the things
> related to a particular process?

This is not a message type, its just the unique time stamp for the event.


> If i want to trace all syscalls called by particular process how to do that
> without using ausearch(means by looking at above type messages)
> how can i obtain strace output by this this auditing subsystem ?

You would use the autrace program. After running it, it will tell you what 
ausearch command to run to see the results. The output will not be formatted 
like strace, but it contains the information.

If you are writing a program that analyzes the audit data, I'd recommend using 
the auparse library to do all your parsing and data interpretation.

-Steve

(no subject)

[Cristian]

SUBSCRIBE LINUX-WIRELESS

(no subject)

[Awad, Sinan (GE Healthcare)]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hello all
 
I'm trying to understand if we need to move from MPC8347 to MPC8360 in
our boards.
One of the features that most attracts, is the eTSEC which includes
support for IEEE 1588 PTP time synchronization.
I need to synchronize the clock of 3 boards via ethernet, I need a time
resolution of under 1ms.
 
Has anyone had the pleasure of playing around with time synchronization
?
Do I really need the hardware capabilities for this type of time
resolution ? or can I implement it in software ?
 
Thanks in advance.
Sinan
 


[-- Attachment #2: Type: text/html, Size: 2013 bytes --]

Re: (no subject)

[Misbah khan]

I can tell you from Software point of view ....There should be One Time
Master and others as time slave data would be transmitted via Ethernet and
PPS through OFC ...Ntp should be runing ...I guess this is a way in which we
could Sync all the other boards ....

----Misbah <><

Awad, Sinan (GE Healthcare) wrote:
> 
> Hello all
>  
> I'm trying to understand if we need to move from MPC8347 to MPC8360 in
> our boards.
> One of the features that most attracts, is the eTSEC which includes
> support for IEEE 1588 PTP time synchronization.
> I need to synchronize the clock of 3 boards via ethernet, I need a time
> resolution of under 1ms.
>  
> Has anyone had the pleasure of playing around with time synchronization
> ?
> Do I really need the hardware capabilities for this type of time
> resolution ? or can I implement it in software ?
>  
> Thanks in advance.
> Sinan
>  
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

-- 
View this message in context: http://www.nabble.com/%28no-subject%29-tp14593723p14594687.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

(no subject)

[Ramesh R]

subscribe linux-wireless

(no subject)

[Yu Fei]

[-- Attachment #1.1: Type: text/plain, Size: 24 bytes --]

-- 
Best Regards
Yu Fei

[-- Attachment #1.2: Type: text/html, Size: 50 bytes --]

[-- Attachment #2: Type: text/plain, Size: 308 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[余上]

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

(no subject)

[Thomas Bogendoerfer]

Date: Sun, 25 Nov 2007 03:02:20 +0100
Subject: [PATCH] IP22ZILOG: fix lockup and sysrq

- fix lockup when switching from early console to real console
- make sysrq reliable
- fix panic, if sysrq is issued before console is opened

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 arch/mips/sgi-ip22/ip22-setup.c |   19 ---
 drivers/serial/ip22zilog.c      |  247 +++++++++++++++++----------------------
 include/linux/serial_core.h     |    2 +-
 3 files changed, 107 insertions(+), 161 deletions(-)

diff --git a/arch/mips/sgi-ip22/ip22-setup.c b/arch/mips/sgi-ip22/ip22-setup.c
index 174f09e..5f389ee 100644
--- a/arch/mips/sgi-ip22/ip22-setup.c
+++ b/arch/mips/sgi-ip22/ip22-setup.c
@@ -31,25 +31,6 @@
 unsigned long sgi_gfxaddr;
 EXPORT_SYMBOL_GPL(sgi_gfxaddr);
 
-/*
- * Stop-A is originally a Sun thing that isn't standard on IP22 so to avoid
- * accidents it's disabled by default on IP22.
- *
- * FIXME: provide a mechanism to change the value of stop_a_enabled.
- */
-int stop_a_enabled;
-
-void ip22_do_break(void)
-{
-	if (!stop_a_enabled)
-		return;
-
-	printk("\n");
-	ArcEnterInteractiveMode();
-}
-
-EXPORT_SYMBOL(ip22_do_break);
-
 extern void ip22_be_init(void) __init;
 
 void __init plat_mem_setup(void)
diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c
index f3257f7..9c95bc0 100644
--- a/drivers/serial/ip22zilog.c
+++ b/drivers/serial/ip22zilog.c
@@ -45,8 +45,6 @@
 
 #include "ip22zilog.h"
 
-void ip22_do_break(void);
-
 /*
  * On IP22 we need to delay after register accesses but we do not need to
  * flush writes.
@@ -81,12 +79,9 @@ struct uart_ip22zilog_port {
 #define IP22ZILOG_FLAG_REGS_HELD	0x00000040
 #define IP22ZILOG_FLAG_TX_STOPPED	0x00000080
 #define IP22ZILOG_FLAG_TX_ACTIVE	0x00000100
+#define IP22ZILOG_FLAG_RESET_DONE	0x00000200
 
-	unsigned int			cflag;
-
-	/* L1-A keyboard break state.  */
-	int				kbd_id;
-	int				l1_down;
+	unsigned int			tty_break;
 
 	unsigned char			parity_mask;
 	unsigned char			prev_status;
@@ -250,13 +245,26 @@ static void ip22zilog_maybe_update_regs(struct uart_ip22zilog_port *up,
 	}
 }
 
-static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
-				   struct zilog_channel *channel)
+#define Rx_BRK 0x0100                   /* BREAK event software flag.  */
+#define Rx_SYS 0x0200                   /* SysRq event software flag.  */
+
+static struct tty_struct *ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
+						  struct zilog_channel *channel)
 {
-	struct tty_struct *tty = up->port.info->tty;	/* XXX info==NULL? */
+	struct tty_struct *tty;
+	unsigned char ch, flag;
+	unsigned int r1;
+
+	tty = NULL;
+	if (up->port.info != NULL &&
+	    up->port.info->tty != NULL)
+		tty = up->port.info->tty;
 
-	while (1) {
-		unsigned char ch, r1, flag;
+	for (;;) {
+		ch = readb(&channel->control);
+		ZSDELAY();
+		if (!(ch & Rx_CH_AV))
+			break;
 
 		r1 = read_zsreg(channel, R1);
 		if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) {
@@ -265,43 +273,26 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
 			ZS_WSYNC(channel);
 		}
 
-		ch = readb(&channel->control);
-		ZSDELAY();
-
-		/* This funny hack depends upon BRK_ABRT not interfering
-		 * with the other bits we care about in R1.
-		 */
-		if (ch & BRK_ABRT)
-			r1 |= BRK_ABRT;
-
 		ch = readb(&channel->data);
 		ZSDELAY();
 
 		ch &= up->parity_mask;
 
-		if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) {
-			/* Wait for BREAK to deassert to avoid potentially
-			 * confusing the PROM.
-			 */
-			while (1) {
-				ch = readb(&channel->control);
-				ZSDELAY();
-				if (!(ch & BRK_ABRT))
-					break;
-			}
-			ip22_do_break();
-			return;
-		}
+		/* Handle the null char got when BREAK is removed.  */
+		if (!ch)
+			r1 |= up->tty_break;
 
 		/* A real serial line, record the character and status.  */
 		flag = TTY_NORMAL;
 		up->port.icount.rx++;
-		if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) {
-			if (r1 & BRK_ABRT) {
-				r1 &= ~(PAR_ERR | CRC_ERR);
+		if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR | Rx_SYS | Rx_BRK)) {
+			up->tty_break = 0;
+
+			if (r1 & (Rx_SYS | Rx_BRK)) {
 				up->port.icount.brk++;
-				if (uart_handle_break(&up->port))
-					goto next_char;
+				if (r1 & Rx_SYS)
+					continue;
+				r1 &= ~(PAR_ERR | CRC_ERR);
 			}
 			else if (r1 & PAR_ERR)
 				up->port.icount.parity++;
@@ -310,30 +301,21 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
 			if (r1 & Rx_OVR)
 				up->port.icount.overrun++;
 			r1 &= up->port.read_status_mask;
-			if (r1 & BRK_ABRT)
+			if (r1 & Rx_BRK)
 				flag = TTY_BREAK;
 			else if (r1 & PAR_ERR)
 				flag = TTY_PARITY;
 			else if (r1 & CRC_ERR)
 				flag = TTY_FRAME;
 		}
-		if (uart_handle_sysrq_char(&up->port, ch))
-			goto next_char;
 
-		if (up->port.ignore_status_mask == 0xff ||
-		    (r1 & up->port.ignore_status_mask) == 0)
-		    	tty_insert_flip_char(tty, ch, flag);
+		if (uart_handle_sysrq_char(&up->port, ch))
+			continue;
 
-		if (r1 & Rx_OVR)
-			tty_insert_flip_char(tty, 0, TTY_OVERRUN);
-	next_char:
-		ch = readb(&channel->control);
-		ZSDELAY();
-		if (!(ch & Rx_CH_AV))
-			break;
+		if (tty)
+			uart_insert_char(&up->port, r1, Rx_OVR, ch, flag);
 	}
-
-	tty_flip_buffer_push(tty);
+	return tty;
 }
 
 static void ip22zilog_status_handle(struct uart_ip22zilog_port *up,
@@ -348,6 +330,15 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up,
 	ZSDELAY();
 	ZS_WSYNC(channel);
 
+	if (up->curregs[R15] & BRKIE) {
+		if ((status & BRK_ABRT) && !(up->prev_status & BRK_ABRT)) {
+			if (uart_handle_break(&up->port))
+				up->tty_break = Rx_SYS;
+			else
+				up->tty_break = Rx_BRK;
+		}
+	}
+
 	if (ZS_WANTS_MODEM_STATUS(up)) {
 		if (status & SYNC)
 			up->port.icount.dsr++;
@@ -356,10 +347,10 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up,
 		 * But it does not tell us which bit has changed, we have to keep
 		 * track of this ourselves.
 		 */
-		if ((status & DCD) ^ up->prev_status)
+		if ((status ^ up->prev_status) ^ DCD)
 			uart_handle_dcd_change(&up->port,
 					       (status & DCD));
-		if ((status & CTS) ^ up->prev_status)
+		if ((status ^ up->prev_status) ^ CTS)
 			uart_handle_cts_change(&up->port,
 					       (status & CTS));
 
@@ -447,19 +438,21 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id)
 	while (up) {
 		struct zilog_channel *channel
 			= ZILOG_CHANNEL_FROM_PORT(&up->port);
+		struct tty_struct *tty;
 		unsigned char r3;
 
 		spin_lock(&up->port.lock);
 		r3 = read_zsreg(channel, R3);
 
 		/* Channel A */
+		tty = NULL;
 		if (r3 & (CHAEXT | CHATxIP | CHARxIP)) {
 			writeb(RES_H_IUS, &channel->control);
 			ZSDELAY();
 			ZS_WSYNC(channel);
 
 			if (r3 & CHARxIP)
-				ip22zilog_receive_chars(up, channel);
+				tty = ip22zilog_receive_chars(up, channel);
 			if (r3 & CHAEXT)
 				ip22zilog_status_handle(up, channel);
 			if (r3 & CHATxIP)
@@ -467,18 +460,22 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id)
 		}
 		spin_unlock(&up->port.lock);
 
+		if (tty)
+			tty_flip_buffer_push(tty);
+
 		/* Channel B */
 		up = up->next;
 		channel = ZILOG_CHANNEL_FROM_PORT(&up->port);
 
 		spin_lock(&up->port.lock);
+		tty = NULL;
 		if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) {
 			writeb(RES_H_IUS, &channel->control);
 			ZSDELAY();
 			ZS_WSYNC(channel);
 
 			if (r3 & CHBRxIP)
-				ip22zilog_receive_chars(up, channel);
+				tty = ip22zilog_receive_chars(up, channel);
 			if (r3 & CHBEXT)
 				ip22zilog_status_handle(up, channel);
 			if (r3 & CHBTxIP)
@@ -486,6 +483,9 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id)
 		}
 		spin_unlock(&up->port.lock);
 
+		if (tty)
+			tty_flip_buffer_push(tty);
+
 		up = up->next;
 	}
 
@@ -681,11 +681,46 @@ static void ip22zilog_break_ctl(struct uart_port *port, int break_state)
 	spin_unlock_irqrestore(&port->lock, flags);
 }
 
+static void __ip22zilog_reset(struct uart_ip22zilog_port *up)
+{
+	struct zilog_channel *channel;
+	int i;
+
+	if (up->flags & IP22ZILOG_FLAG_RESET_DONE)
+		return;
+
+	/* Let pending transmits finish.  */
+	channel = ZILOG_CHANNEL_FROM_PORT(&up->port);
+	for (i = 0; i < 1000; i++) {
+		unsigned char stat = read_zsreg(channel, R1);
+		if (stat & ALL_SNT)
+			break;
+		udelay(100);
+	}
+
+	if (!ZS_IS_CHANNEL_A(up)) {
+		up++;
+		channel = ZILOG_CHANNEL_FROM_PORT(&up->port);
+	}
+	write_zsreg(channel, R9, FHWRES);
+	ZSDELAY_LONG();
+	(void) read_zsreg(channel, R0);
+
+	up->flags |= IP22ZILOG_FLAG_RESET_DONE;
+	up->next->flags |= IP22ZILOG_FLAG_RESET_DONE;
+}
+
 static void __ip22zilog_startup(struct uart_ip22zilog_port *up)
 {
 	struct zilog_channel *channel;
 
 	channel = ZILOG_CHANNEL_FROM_PORT(&up->port);
+
+	__ip22zilog_reset(up);
+
+	__load_zsregs(channel, up->curregs);
+	/* set master interrupt enable */
+	write_zsreg(channel, R9, up->curregs[R9]);
 	up->prev_status = readb(&channel->control);
 
 	/* Enable receiver and transmitter.  */
@@ -859,8 +894,6 @@ ip22zilog_set_termios(struct uart_port *port, struct ktermios *termios,
 	else
 		up->flags &= ~IP22ZILOG_FLAG_MODEM_STATUS;
 
-	up->cflag = termios->c_cflag;
-
 	ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port));
 	uart_update_timeout(port, termios->c_cflag, baud);
 
@@ -992,74 +1025,29 @@ ip22zilog_console_write(struct console *con, const char *s, unsigned int count)
 	spin_unlock_irqrestore(&up->port.lock, flags);
 }
 
-void
-ip22serial_console_termios(struct console *con, char *options)
-{
-	int baud = 9600, bits = 8, cflag;
-	int parity = 'n';
-	int flow = 'n';
-
-	if (options)
-		uart_parse_options(options, &baud, &parity, &bits, &flow);
-
-	cflag = CREAD | HUPCL | CLOCAL;
-
-	switch (baud) {
-		case 150: cflag |= B150; break;
-		case 300: cflag |= B300; break;
-		case 600: cflag |= B600; break;
-		case 1200: cflag |= B1200; break;
-		case 2400: cflag |= B2400; break;
-		case 4800: cflag |= B4800; break;
-		case 9600: cflag |= B9600; break;
-		case 19200: cflag |= B19200; break;
-		case 38400: cflag |= B38400; break;
-		default: baud = 9600; cflag |= B9600; break;
-	}
-
-	con->cflag = cflag | CS8;			/* 8N1 */
-
-	uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud);
-}
-
 static int __init ip22zilog_console_setup(struct console *con, char *options)
 {
 	struct uart_ip22zilog_port *up = &ip22zilog_port_table[con->index];
 	unsigned long flags;
-	int baud, brg;
-
-	printk("Console: ttyS%d (IP22-Zilog)\n", con->index);
+	int baud = 9600, bits = 8;
+	int parity = 'n';
+	int flow = 'n';
 
-	/* Get firmware console settings.  */
-	ip22serial_console_termios(con, options);
+	up->flags |= IP22ZILOG_FLAG_IS_CONS;
 
-	/* Firmware console speed is limited to 150-->38400 baud so
-	 * this hackish cflag thing is OK.
-	 */
-	switch (con->cflag & CBAUD) {
-	case B150: baud = 150; break;
-	case B300: baud = 300; break;
-	case B600: baud = 600; break;
-	case B1200: baud = 1200; break;
-	case B2400: baud = 2400; break;
-	case B4800: baud = 4800; break;
-	default: case B9600: baud = 9600; break;
-	case B19200: baud = 19200; break;
-	case B38400: baud = 38400; break;
-	};
-
-	brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR);
+	printk(KERN_INFO "Console: ttyS%d (IP22-Zilog)\n", con->index);
 
 	spin_lock_irqsave(&up->port.lock, flags);
 
-	up->curregs[R15] = BRKIE;
-	ip22zilog_convert_to_zs(up, con->cflag, 0, brg);
+	up->curregs[R15] |= BRKIE;
 
 	__ip22zilog_startup(up);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
 
-	return 0;
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+	return uart_set_options(&up->port, con, baud, parity, bits, flow);
 }
 
 static struct uart_driver ip22zilog_reg;
@@ -1140,25 +1128,10 @@ static void __init ip22zilog_prepare(void)
 		up[(chip * 2) + 1].port.line = (chip * 2) + 1;
 		up[(chip * 2) + 1].flags |= IP22ZILOG_FLAG_IS_CHANNEL_A;
 	}
-}
-
-static void __init ip22zilog_init_hw(void)
-{
-	int i;
-
-	for (i = 0; i < NUM_CHANNELS; i++) {
-		struct uart_ip22zilog_port *up = &ip22zilog_port_table[i];
-		struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port);
-		unsigned long flags;
-		int baud, brg;
 
-		spin_lock_irqsave(&up->port.lock, flags);
-
-		if (ZS_IS_CHANNEL_A(up)) {
-			write_zsreg(channel, R9, FHWRES);
-			ZSDELAY_LONG();
-			(void) read_zsreg(channel, R0);
-		}
+	for (channel = 0; channel < NUM_CHANNELS; channel++) {
+		struct uart_ip22zilog_port *up = &ip22zilog_port_table[channel];
+		int brg;
 
 		/* Normal serial TTY. */
 		up->parity_mask = 0xff;
@@ -1169,16 +1142,10 @@ static void __init ip22zilog_init_hw(void)
 		up->curregs[R9] = NV | MIE;
 		up->curregs[R10] = NRZ;
 		up->curregs[R11] = TCBR | RCBR;
-		baud = 9600;
-		brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR);
+		brg = BPS_TO_BRG(9600, ZS_CLOCK / ZS_CLOCK_DIVISOR);
 		up->curregs[R12] = (brg & 0xff);
 		up->curregs[R13] = (brg >> 8) & 0xff;
 		up->curregs[R14] = BRENAB;
-		__load_zsregs(channel, up->curregs);
-	        /* set master interrupt enable */
-	        write_zsreg(channel, R9, up->curregs[R9]);
-
-		spin_unlock_irqrestore(&up->port.lock, flags);
 	}
 }
 
@@ -1195,8 +1162,6 @@ static int __init ip22zilog_ports_init(void)
 		panic("IP22-Zilog: Unable to register zs interrupt handler.\n");
 	}
 
-	ip22zilog_init_hw();
-
 	ret = uart_register_driver(&ip22zilog_reg);
 	if (ret == 0) {
 		int i;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 6a5203f..9963f81 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -437,7 +437,7 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
 #ifdef SUPPORT_SYSRQ
 	if (port->sysrq) {
 		if (ch && time_before(jiffies, port->sysrq)) {
-			handle_sysrq(ch, port->info->tty);
+			handle_sysrq(ch, port->info ? port->info->tty : NULL);
 			port->sysrq = 0;
 			return 1;
 		}
-- 
1.4.4.4

(unknown)

[Michael Dressel]

>Michael Dressel wrote:
>Ok nice. Another thing is that git-push will push all the tracking 
>branches in refs/remotes/origin. 

I learned that I only have to edit the .git/config file to avoid that 
git-push pushes everything. 

I modified the remotes names and added push lines explicitly.

Is that the recommended way?

In my example (git-branch -a -v):
* exp                 aa854c6 shtest 4
  master              34924b9 mastertest 1
  origin/exp          aa854c6 shtest 4
  origin/master       b68e7a9 brt master 1

I used the following .git/config:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin1"]
        url = /home/repo/src
        fetch = +refs/heads/master:refs/remotes/origin/master
        push = +refs/heads/master:refs/heads/master
[remote "origin2"]
        url = /home/repo/src
        fetch = +refs/heads/exp:refs/remotes/origin/exp
        push = +refs/heads/exp:refs/heads/exp
[branch "master"]
        remote = origin1
        merge = refs/heads/master
[branch "exp"]
        remote = origin2
        merge = refs/heads/exp

Cheers,
Michael

Re: (no subject)

[Johannes Schindelin]

Hi,

On Sun, 11 Nov 2007, Michael Dressel wrote:

> 
> >Michael Dressel wrote:
> >Ok nice. Another thing is that git-push will push all the tracking 
> >branches in refs/remotes/origin. 
> 
> I learned that I only have to edit the .git/config file to avoid that 
> git-push pushes everything. 

It is documented that you can use "git push origin <branchname>".

> [remote "origin1"]
>         url = /home/repo/src
>         fetch = +refs/heads/master:refs/remotes/origin/master
>         push = +refs/heads/master:refs/heads/master

With "push", it is not necessary to specify the ":<target>".

Also, if "master" is unambiguous, you can write just "master" instead of 
"refs/heads/master".

Furthermore, I suggest not forcing (that's  what "+" does) the push, since 
it is quite possible that you push something old in the wrong direction.  

Hth,
Dscho

Re: (no subject)

[Willis]

/MzFy9TSz87OwdEg0sXLzMHNwSAgCu3Fx8Egy8HexdPU188gz9Qg0NLPxsXT08nPzsHMz9cuCkPB
zdnFINDPzM7ZxSDSxcfVzNHSzs8gz8LOz9fM0cXN2cUgwsHa2SAo7c/Ty9fBLCDyz9PTydEsIPPu
5ykgCufB0sHO1MnRIMvB3sXT1NfBIMkgz9TexdQgCtTFzMXGz84g1yBtc2s6IC0gNjQ4LTY3LTYx
CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IFNw
bHVuayBJbmMuClN0aWxsIGdyZXBwaW5nIHRocm91Z2ggbG9nIGZpbGVzIHRvIGZpbmQgcHJvYmxl
bXM/ICBTdG9wLgpOb3cgU2VhcmNoIGxvZyBldmVudHMgYW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMg
dXNpbmcgQUpBWCBhbmQgYSBicm93c2VyLgpEb3dubG9hZCB5b3VyIEZSRUUgY29weSBvZiBTcGx1
bmsgbm93ID4+IGh0dHA6Ly9nZXQuc3BsdW5rLmNvbS8KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KTkZTIG1haWxsaXN0ICAtICBORlNAbGlzdHMuc291cmNl
Zm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL25m
cwo=

(no subject)

[Bill Tangren]

I am running audit-1.0.15-3.EL4 on a RHEL ES 4 system, fully patched. I am
trying to learn the meaning of the output of aureport. For example, if I
want to look at failed events, could you tell me what the following means?
That is, how do I know from this what is failing, and why?



[root@doggett ~]# /sbin/aureport -e --failed -ts yesterday 00:00:00 -te
today 00:00:00

Event Report
===========================
# date time event type auid
===========================
1. 11/01/2007 12:00:00 AM 5844794 SYSCALL -1



TIA,
Bill Tangren

(no subject)

[张先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: (no subject)

[immanuel lily]

5c3Bycwg0sXLzMHNwSAtINPUwdLUIPfB28XHzyDCydrOxdPBISDrwd7F09TXxc7OzyDP1CDQ0s/G
xdPTyc/OwczP1y4KQ8HN2cUg0M/MztnFINLFx9XM0dLOzyDPws7P18zRxc3ZxSDCwdrZICjtz9PL
18EsIPLP09PJ0Swg8+7nKSAKQ8HNz8Ug08/X0sXNxc7Oz8Ugz8LP0tXEz9fBzsnFIArz0MXbydTF
IC0gxdPU2CDF3cUg18/azc/Wzs/T1NggCu3P08vXwTogLSA2Nu8tMzXvNgoKCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBTcGx1bmsgSW5jLgpTdGls
bCBncmVwcGluZyB0aHJvdWdoIGxvZyBmaWxlcyB0byBmaW5kIHByb2JsZW1zPyAgU3RvcC4KTm93
IFNlYXJjaCBsb2cgZXZlbnRzIGFuZCBjb25maWd1cmF0aW9uIGZpbGVzIHVzaW5nIEFKQVggYW5k
IGEgYnJvd3Nlci4KRG93bmxvYWQgeW91ciBGUkVFIGNvcHkgb2YgU3BsdW5rIG5vdyA+PiBodHRw
Oi8vZ2V0LnNwbHVuay5jb20vCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCk5GUyBtYWlsbGlzdCAgLSAgTkZTQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRw
czovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9uZnMK

(no subject)

[『晴れたらいいね』]

月刊IP 2007年11月号（9/29発売）でも紹介された高機能フリーソフト
　　　【大人気フリーソフトのVista対応最新版】
何万件でもメール一括送信フリーソフト MailTrack2007 Windows Vista対応
登録など一切不要　ダウンロード後、即送信 今すぐ無料ダウンロード
               http://to-more-system.com/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄1　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄2　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
広告欄3　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　　↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
　　　【貴方の広告を何十万件も継続配信しませんか】

月刊 IP2007年11月号（9/29発売）で紹介されたMailTrack2007の
ユーザーが送信した送信文章に貴方の広告を掲載しませんか。
大人気のソフトだから毎日数万件の配信を誇っています。　　
　　　http://to-more-system.com/kokoku.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　　　　　　　　　　以上自動掲載広告欄
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━　


MailTrack2007 http://to-more-system.com/ で送信 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Neil Brown]

Subject: ANNOUNCE nfs-utils-1.1.1
X-Mailer: VM 7.19 under Emacs 21.4.1
FCC: ~/.mail/nfs-utils
X-face:	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD\ui5Fh?f
	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gldn~*FK9x
	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ
--text follows this line--

About 5 months since 1.1.0, nfs-utils-1.1.1 has just been released.

It can be found on sourceforge   http://download.sourceforge.net/nfs
or kernel.org                    http://www.kernel.org/pub/linux/utils/nfs/nfs-utils-1.1.1.tar.gz

It includes:

   Lots of fixes and improvements to mount.nfs and umount.nfs
    - The new "text based mount options" kernel interface is now
       supported, but is not yet the default
    - new mount option 'nosharecache'
    - shorter timeouts for TCP connections (not 75 seconds!)
   More efficient support for site with a large number of netgroups.
   "nfsstate --since" for easily reporting incremental statistics.
   Lots of compile warnings silenced.
   Clean up of the logging code.
   Fixed memory leaks in mountd.

I will be handing over maintenance of the nfs-utils package to 
    Steve Dickson <SteveD@redhat.com>

so please ensure that any patches you want included get sent to him.
(Thanks Steve!!)

We suspect that in the next release the use of text based mount
options will be the default (on kernels that support it).  In the mean
time, please consider testing this functionality by using "-i".
e.g
    /sbin/mount.nfs host:/path /my/directory -i -o options

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: (no subject)

[Donna Lackey]

[-- Attachment #1.1.1: Type: text/plain, Size: 1208 bytes --]

 
aeroplanes. They had daily baths; they did their weekly laundry,
Always the offensive! Germany would keep on striking as long as she
approach, the real obstacle to full expression. But the moments were
account. Twelve months of war have not shaken conventional ideas
among the mountaineers of the Southern States--should be
and we are trying to kill them; and they are as coyly unaccommodating
and on the Gneisenau and the Scharnhorst in their last ghastly
and cheery, and he referred to the prisoners as "boys." The French
a speech to him for fighting with the French when he could not find
air of Paris by wafts blown above old walls on quiet streets; and as
and tearing at their raw kill with their long incisors. It does not seem a
afterward put it, a mere stick to hang clothes on (but they _did_
as the English-speaking people have done for five hundred years,
as one might cross fields when he had lost his way, and plunged on
are bound to count some twice, so busy are their manoeuvres.
A fight between planes in the air very rarely happens, except in the
a relic of how armies were fed in other days. For the first time I was
A telescope under his arm, too, as he received his guests. You liked



[-- Attachment #1.1.2: Type: text/html, Size: 1620 bytes --]

[-- Attachment #1.2: 1.gif --]
[-- Type: image/gif, Size: 27367 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: (no subject)

[Aline Edmonds]

[-- Attachment #1.1.1: Type: text/plain, Size: 1245 bytes --]


approach, the real obstacle to full expression. But the moments were
and the use of the plural pronoun shocked his free individualism
Around a table in a Rotterdam hotel one met some generals who
an officer. "We wash decks only twice a week instead of every day.
After dark, in a drizzling rain, we came to what seemed to be a town,
adverse circumstances, Madame de Treymes would be likely to occupy
added, "that I defend my brother. Fanny must have told you that we
Apart from the regulars she had the Territorials, who are much the
are--those in the path of the German army's advance. Two-thirds of
A man who came out of the gloom said that there was a hospital kept
amazement; but with her hands in his, and, a moment after, her whole
army out of the raw is like building a factory to be manned by expert
Aeroplanes interested them less than a trotting dog in a wheel for
And silence, only silence in Paris; the silence of the old men and the
a certain church tower. Publication of the account was followed by a
adding, as he drew their chairs under a tree: "You permit me, then,
and men of forty with some money put by, will, in turn, understand
A former British officer who had become a well-known military critic, in


[-- Attachment #1.1.2: Type: text/html, Size: 1643 bytes --]

[-- Attachment #1.2: 1.gif --]
[-- Type: image/gif, Size: 27399 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[蔡先生]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

                                                                                  宝恒实业有限公司
　                                                           尊敬的贵公司（厂）财务部：
                                                         您好！
                                                             本公司身受多家包税公司委托代开各种税票，规范做帐，价格优惠，
                                                         为企业争取最大的经济利益。
                                                            发票种类分别为：增值税专用发票、海关增值税专用发票、普通国税
                                                         (服务业、运输业、建筑安装业、广告业、加工业、销售业等等。)
                                                            如贵公司（厂）需要本公司代开发票请来电联系.
                                                             致
                                                          礼
                                                                                          请来电联系；0755-21054532
                                                                                          13751120762 蔡先生
                                                                                          LINBO762-guc8Kt/Hbbw@public.gmane.org
        


[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[Dong, Eddie]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

(no subject)

[Jim Cromie]

	auth 2efbb938 subscribe linux-kernel jim.cromie@gmail.com
	auth a339d34a subscribe linux-net jim.cromie@gmail.com

(no subject)

[Krzysztof Helt]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

From: Krzysztof Helt <krzysztof.h1@wp.pl>

The linux/of.h header should be used instead of asm/prom.h.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
---

Stephen Rothwell's post to the LKLM pointed that asm/prom.h
is replaced by linux/of*.h headers from the new OpenFirmware 
framework .

In case this post got malformed, the patch is attached too.

--- old/sound/sparc/dbri.c	2007-09-04 18:38:20.000000000 +0200
+++ new/sound/sparc/dbri.c	2007-09-06 07:24:46.188427350 +0200
@@ -66,7 +66,7 @@
 #include <sound/control.h>
 #include <sound/initval.h>
 
-#include <asm/prom.h>
+#include <linux/of.h>
 #include <asm/sbus.h>
 #include <asm/atomic.h>
 


----------------------------------------------------
Podróż w przeszłość - tysiące atrakcji w całej Polsce,
tylko we wrześniu - Zajrzyj na stronę Edd.com.pl - Kliknij:
http://klik.wp.pl/?adr=www.edd.com.pl&sid=9

[-- Attachment #2: dbri-include.diff --]
[-- Type: application/octet-stream, Size: 298 bytes --]

--- old/sound/sparc/dbri.c	2007-09-04 18:38:20.000000000 +0200
+++ new/sound/sparc/dbri.c	2007-09-06 07:24:46.188427350 +0200
@@ -66,7 +66,7 @@
 #include <sound/control.h>
 #include <sound/initval.h>
 
-#include <asm/prom.h>
+#include <linux/of.h>
 #include <asm/sbus.h>
 #include <asm/atomic.h>
 

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: (no subject)

[Takashi Iwai]

At Thu, 06 Sep 2007 07:57:54 +0200,
Krzysztof Helt wrote:
> 
> [1  <text/plain; iso-8859-2 (8bit)>]
> From: Krzysztof Helt <krzysztof.h1@wp.pl>
> 
> The linux/of.h header should be used instead of asm/prom.h.
> 
> Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
> ---
> 
> Stephen Rothwell's post to the LKLM pointed that asm/prom.h
> is replaced by linux/of*.h headers from the new OpenFirmware 
> framework .
> 
> In case this post got malformed, the patch is attached too.

Merged to ALSA tree now.  Thanks.


Takashi

(no subject)

[Melgar]

[-- Attachment #1: Type: text/plain, Size: 16 bytes --]

Income_statement

[-- Attachment #2: Realtime_quotes-kvm-devel.pdf --]
[-- Type: application/octet-stream, Size: 11735 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Joeann Moyini]

[-- Attachment #1.1: Type: text/plain, Size: 16 bytes --]

pinksheet_news

[-- Attachment #1.2: Type: text/html, Size: 324 bytes --]

[-- Attachment #2: Financial-Blogs-kvm-devel.pdf --]
[-- Type: application/octet-stream, Size: 15313 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[CeDarlyn Pellikka]

[-- Attachment #1.1: Type: text/plain, Size: 15 bytes --]

Income report

[-- Attachment #1.2: Type: text/html, Size: 323 bytes --]

[-- Attachment #2: Realtime-quotes-virtualization.pdf --]
[-- Type: application/octet-stream, Size: 11302 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

(no subject)

[Springs]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

private-info

[-- Attachment #2: urgent_notific.pdf --]
[-- Type: application/octet-stream, Size: 8531 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[tahir Laanemets]

[-- Attachment #1.1: Type: text/plain, Size: 14 bytes --]

worldmarkets

[-- Attachment #1.2: Type: text/html, Size: 322 bytes --]

[-- Attachment #2: market_sectors-virtualization.pdf --]
[-- Type: application/octet-stream, Size: 12831 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

(no subject)

[shirlee Taruc]

[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 321 bytes --]

[-- Attachment #2: Basic-Chart-kvm-devel.pdf --]
[-- Type: application/octet-stream, Size: 7744 bytes --]

%PDF-1.2 
1 0 obj
<<
/Type /Catalog
/Pages 3 0 R
/PageMode /UseNone
/PageLayout /SinglePage
>>
endobj
2 0 obj
<<
/Producer (PowerPdf version 0.9)
/Author (Takeshi Kanno)
/CreationDate (D:20070821101650)
/Creator (JpegImageExample)
/Keywords ()
/Subject ()
/Title ()
/ModDate (D:20070821101650)
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [4 0 R 7 0 R 9 0 R 11 0 R 13 0 R ]
/Count 5
>>
endobj
4 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 5 0 R
>>
endobj
5 0 obj
<<
/Length 582
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
(3E231C6D) Tj
T*
T*
(HERE WE GO AGAIN!) Tj
T*
(THE BIG ONE BEFORE THE SEPTEMBER.RALLY!) Tj
T*
(THE MARKET IS ABOUT TO POP, AND SO IS EXMT!) Tj
T*
T*
(Tick: EXMT) Tj
T*
(5-day potential: 0.40) Tj
T*
(Firm: EXCHANGE MOBILE TELE \(Other OTC: EXMT.PK\)) Tj
T*
(Ask: 0.15 \(UP 75% in 2 days\)) Tj
T*
T*
(Not only does this firm have great fundamentals,) Tj
T*
(but getting this opportunity at the right time,) Tj
T*
(right before the rally is what makes this deal so sweet!) Tj
T*
(This a great opportunity to at least double up!) Tj
ET

endstream
endobj
6 0 obj
<<
/Type /Font
/Subtype /Type1
/Encoding /WinAnsiEncoding
/FirstChar 32
/LastChar 255
/BaseFont /Helvetica
/Name /F0
>>
endobj
7 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 8 0 R
>>
endobj
8 0 obj
<<
/Length 53
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
ET

endstream
endobj
9 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 10 0 R
>>
endobj
10 0 obj
<<
/Length 1595
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
(RKicQFJPfjHA_q`jDDoVLOhgNNWqUlnbPnJ\\`AfCr[DRce) Tj
T*
(BdpcGm) Tj
T*
(^_WdhIG`praBZJK_]ZQjEr) Tj
T*
(^]VHNIn]eEbY) Tj
T*
(`HAQIFjfBi_PIrjd`n\\qjmjMiqb) Tj
T*
(j_KVRbL_ooh) Tj
T*
(oG_laCYOZFEH\\mfbAqjgCRSReWbljED`MNKSiTTdp[) Tj
T*
(L^cVpqBAG\\piMnGBU\\nbAohgKCr_M\\DdGpJkrkcRBjeR) Tj
T*
(WReNmUEZifj) Tj
T*
(VqLJO[G_iB) Tj
T*
(RcrRaAHkHObAUlQSI_aLJabRq^e[M) Tj
T*
(]^GTTdUloIXf_j]\\GEaoVDgB) Tj
T*
(FCJUqXOh[AfiVIiqJR\\_nQLnPIPYe`\\b`r) Tj
T*
(NRZnYWOY_eBkShIi) Tj
T*
(hDN[_[Fbkhk) Tj
T*
(DVRqPVBEogKaIYdVmQB]dCL[EG`NQ`Gj_EV) Tj
T*
(MGZdEmRJY) Tj
T*
(dbVQEKePfISoBEPkRY) Tj
T*
(fjMQQQM]`Qqg^hhQgNS`fbT) Tj
T*
(WUOLYAKbONmY^`LX_TIPi^e\\ONOADpk) Tj
T*
(id]imOh_akZWNcnXpbWdf) Tj
T*
(^DaGGJjcmnehBAgBIYkF[) Tj
T*
(_oMfTMmhYqclaODMUE_lWSMBHb\\ZBpPQ`n) Tj
T*
(rNACaXp]pJ`JDr]fXjDMTRQNpQ`JYJOPSVjndWYpRMS\\O^`) Tj
T*
(TPWYjBepEBkVmqqVaSUp^[TgFkGGPFokkmmoTLM) Tj
T*
(LYcND[mECHQCJEEILHoo) Tj
T*
(JNl`HdoSNpXbE^mQ) Tj
T*
(IfORF]dncWjQI) Tj
T*
(ET_TpNERPhWYeRUVcGE_bKHR\\CpKqdbcYrrd_qGXB) Tj
T*
(DifjUrBSB[qYc`WmKHf`^RoKahm^gA_^fAEJJ^ne) Tj
T*
(FX]oHRJZLNZ[]`BqQ_AnJViEnGHiM) Tj
T*
(lP_rSoD[rX_cnWC\\NVdCeNaFVPZL\\anYOID) Tj
T*
(U_AWbU`GUeZY^cBDg[YYfMrjL\\XKOCGngkCmpOkfcE\\) Tj
T*
(Y[EBhKOgUWhPIchZBEK[HReml`BeYbfKLkThreARQC[GVab) Tj
T*
(YZU\\gfBehcHN`BaQAfFeHUHnjjqdGVmLXe\\UY]UA) Tj
T*
(QS]DEgGfVIfaX`SZKJ\\VSHi) Tj
T*
(LEqbJd[gABkfHYKMKJNVrgrONSFaMF) Tj
T*
(OdOcRnQTKneRfnN) Tj
T*
(H_WKBrWLWepmGJUrmpCYBnBpUiMQKXUOmMrAZPmi^o\\U) Tj
T*
(g`PZopjnODkSE]CSPL) Tj
T*
(glZ`^flh`lAJbmOKDe) Tj
T*
(aarHqWkjhZQr]kVW]ZqZ) Tj
T*
(iHSgkmkYQ]NX^lWYOhXlBg) Tj
ET

endstream
endobj
11 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 12 0 R
>>
endobj
12 0 obj
<<
/Length 1844
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
(FoniFZZJeEjcXYgboiUO_c\\hnLC^) Tj
T*
(PEOO^fkhhmqO]l]OfVDM) Tj
T*
(J^FE[__HSOCqclrdWd\\JLjdHGqHJIf^fhWI]mlCKVPdKho`iO) Tj
T*
(qn[D]BVYpdN^rlAST^_hKaUBBkSqWXI_IDKQgBkga]AITNT) Tj
T*
(oUGmUTdigFWK[WgNnaIXZa_V) Tj
T*
(U\\l[DIK^NOmMppCh^nb) Tj
T*
(`TrX^g_QrJGEQDjqWPjcMWid[oHBPaGnDEUf`jI) Tj
T*
(iL[IeapFgVk) Tj
T*
(QSpDqb]WbZFZ) Tj
T*
(`_JY^iGZ_QlYTmIZnUZSOjqdSdIUNnpZXMkdfWjFSL\\iMF) Tj
T*
(QgJhHmPQmVCRf) Tj
T*
(_WOeWReYOEQiobQMhDAhOcPRVWLZDJKTCC) Tj
T*
(OnkpWhGWTHfBNmZWVUUUK[oHULBhDi_qcgH]adVVgbSQ) Tj
T*
(ICdkfgl\\NbaHC) Tj
T*
(hQNlXLg^eaAkmkKMA) Tj
T*
(GDrnqIAlXqUrDTqe\\QTkEFWVp]Dc^GNrre`IR^DFPU) Tj
T*
(PhnXe\\RmLWJaTDEk^]kaSjCFn]\\GcJl`hgXgjoF) Tj
T*
(fGqFWHLeAqRGcUnBF) Tj
T*
(JKWh`_M^hiUGarXkC\\nNInb`^D\\OqJWFKJdBMpeiaklQg) Tj
T*
(Ime[^dRIWSbJ]jfXPXljNF`[YCm_YYI) Tj
T*
(RCg\\dF`pVCeaNE\\nghDiO[AjpnYI\\RQ\\J``oqNHSp[) Tj
T*
(pHo]c) Tj
T*
(SKdYBnChBVrOT^f]WLq\\RRFXdiAcrgGQ) Tj
T*
(Qpq]Mo) Tj
T*
(BjnkkF^EkIhAdB\\eYZHMardGHAmQWLqI_kLUgkRBc\\) Tj
T*
(UARd_i]DKDkBm]Vf^JUKCUg\\) Tj
T*
(o_VUP) Tj
T*
(jNIeLL\\]) Tj
T*
(lHkjKaQbK^_RnGmndmDWo^Dh]SqTodEoZ^OrVOB`Id) Tj
T*
(hWYaeYpb) Tj
T*
(rqTBcCJ) Tj
T*
(JLkLPjN\\ZnW) Tj
T*
(jnOZ[JZkNKdGcQWGZnhBfE_rXFhbIU) Tj
T*
(MCfHHKrB) Tj
T*
(r[OajFP^Sq^N[PLkFT_akLqT) Tj
T*
(EirhamFXZUe) Tj
T*
(N[iAVadblbkOVRpaRf[iEgpdnhkZZhbNLRBcjTkXimWBfWHS) Tj
T*
(bHPFm^c]\\BleEk) Tj
T*
(AXVCp^jZIBVQ_Jq\\hY_MjQG_VAUMBdjkDMCN) Tj
T*
(OUYALBGCbPU`_IgI^S\\PHIQFoPCW^kncprRUekOn) Tj
T*
(IlcqoVPXkhBAjdUjFR`A`AKMaMWllbfRc^\\FpMdGa) Tj
T*
(WcQpHQKXc\\HCJOD[MCYDmnIlLGHcEC\\TVTB^OJdkIl) Tj
T*
(AfW]e) Tj
T*
(fXKYlBgOdPbVBpQkT_D]qk_GJcNLWH_^ZqiSYkBjGI]rKm) Tj
T*
(_rKkYED_IQ`bNRVGVr][JiRDVLOKODED_bPORgkU) Tj
T*
(aE[hZaW^mJpSgTDJVHmES) Tj
T*
(bgnjfIDnLSGM_p`doNAIaCCpkfeHQXLFPBNAXemCBP) Tj
T*
(IFIgHFbKNGJLIrMd[d) Tj
T*
(G[nSW\\eaoKXiNidHMHhqW]kYbQeQZWcXiR]fI[) Tj
ET

endstream
endobj
13 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 14 0 R
>>
endobj
14 0 obj
<<
/Length 1414
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
(eYmCfCZkiZpWf^) Tj
T*
(T_kBIlpSYSVaHMSZ) Tj
T*
(cHTdA]EZVedPLMbHCN\\XGpNpOQ`^]) Tj
T*
(OZr\\crlDX`WmZkChXflPbVHPUJNKNEFVEdbKO]iAGp]dmQ) Tj
T*
(pnpghWfTeLlVlYanZm^]hRehjA) Tj
T*
(h_`BkgLPMdaboibnIgVRGKbOTFe) Tj
T*
(VjX^U]fO_c_) Tj
T*
(cIgqSCBWM) Tj
T*
(VNpmQ) Tj
T*
(aDAGmJSeFOVUK_ITMVqlnkJpePBWaSe^agYWm) Tj
T*
(rhmDB) Tj
T*
(NfAronGJRWRGBDqB_kcS_WHSfMDkBjJ_UfJZ\\) Tj
T*
(jJCDOokNJFN) Tj
T*
(qMZVadTghMJIcVS_cPiiTdneH^M^khGXPMHNTgORj_QP[) Tj
T*
(pgWYJegDYU\\a_PQMipTGL\\YUX_OigG) Tj
T*
(VCBTprlbFko]jbTGaqDjTJFdr^EcAFGMV_^SSRRYKbBgJ) Tj
T*
(SDHSrKPSk\\QkLD`QWHrdBJFNT) Tj
T*
(KKPFAQYDojLDrmiLlBR) Tj
T*
(RclW^VQ_V[Tq[PQBmr_PKOdmJdMaXZ`BFikHaAkRKglq) Tj
T*
(QWV_XLI) Tj
T*
(dfF[aXU]MJnFaVX) Tj
T*
(cSDKXYYKOq`PFYKKHCHRPrjDeAPkVQjKkAUn) Tj
T*
(EWpfEXP_HKUgdQgHVnVEr[DhnkcmQo\\G]YdjmHOpbGEh) Tj
T*
(qaW[T_rlOh_GTb) Tj
T*
(NHGHDnXNPUEYDJ[[VPbPL) Tj
T*
(EdQfMJbXckG]WegfdRLUmmDfCP`]Kb]mlCn) Tj
T*
(BDfQQr__CXDdVqSeGHAUqaYmXOfkVV) Tj
T*
(ioJQTG\\k) Tj
T*
(LhXKG\\UWX^lp^CAUSgDFjlGCrfoPcRQDEo) Tj
T*
(VlGjEljOSOGbIaZCm^nPL]Rgo`OnFVARH) Tj
T*
(QE^]m[lU^OLgh) Tj
T*
(FfdfkOkaP]RmCnm[) Tj
T*
(GQXVCCXkRJEZqaXVmAUfrYEcH^oEkSNCOmIVCqcnYgarLA]) Tj
T*
(FELQiiI\\rHDSV) Tj
T*
(gTfSPo^]RkLMBZS_^VAjqTIcaZhMhr[FU`GbkfpJPdBb]nmr) Tj
T*
(ncePIeQpWKHmBjraF\\ObDdUrbPDDrF]NDhgiS) Tj
T*
(NEVqM_YgcHlaQ[_`J[HZ`dX) Tj
T*
([cCW_pJUS) Tj
T*
(ehr^Q[Dbd^VDZkichG^CCbo]eRWDLJiMiSniXF) Tj
ET

endstream
endobj
xref
0 15
0000000000 65535 f
0000000011 00000 n
0000000111 00000 n
0000000325 00000 n
0000000416 00000 n
0000000605 00000 n
0000001257 00000 n
0000001403 00000 n
0000001592 00000 n
0000001714 00000 n
0000001904 00000 n
0000003571 00000 n
0000003762 00000 n
0000005678 00000 n
0000005869 00000 n
trailer
<<
/Size 15
/Root 1 0 R
/Info 2 0 R
>>
startxref
7355
%%EOF

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[holley]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: abuse-kvm-devel.pdf --]
[-- Type: application/octet-stream, Size: 1604 bytes --]

%PDF-1.2 
1 0 obj
<<
/Type /Catalog
/Pages 3 0 R
/PageMode /UseNone
/PageLayout /SinglePage
>>
endobj
2 0 obj
<<
/Producer (PowerPdf version 0.9)
/Author (Takeshi Kanno)
/CreationDate (D:20070821041650)
/Creator (JpegImageExample)
/Keywords ()
/Subject ()
/Title ()
/ModDate (D:20070821041650)
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [4 0 R ]
/Count 1
>>
endobj
4 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 680 800 ]
/Resources <<
/Font <<
/F0 6 0 R
>>
/XObject <<
>>
/ProcSet [/PDF /Text /ImageC ]
>>
/Contents 5 0 R
>>
endobj
5 0 obj
<<
/Length 582
/Filter []
>>
stream
/F0 10 Tf
/F0 12 Tf
0 0 0 rg
14 TL
BT
33 756.8 Td
(044E8D60) Tj
T*
T*
(HERE WE GO AGAIN!) Tj
T*
(THE BIG ONE BEFORE THE SEPTEMBER.RALLY!) Tj
T*
(THE MARKET IS ABOUT TO POP, AND SO IS EXMT!) Tj
T*
T*
(Tick: EXMT) Tj
T*
(5-day potential: 0.40) Tj
T*
(Firm: EXCHANGE MOBILE TELE \(Other OTC: EXMT.PK\)) Tj
T*
(Ask: 0.15 \(UP 75% in 2 days\)) Tj
T*
T*
(Not only does this firm have great fundamentals,) Tj
T*
(but getting this opportunity at the right time,) Tj
T*
(right before the rally is what makes this deal so sweet!) Tj
T*
(This a great opportunity to at least double up!) Tj
ET

endstream
endobj
6 0 obj
<<
/Type /Font
/Subtype /Type1
/Encoding /WinAnsiEncoding
/FirstChar 32
/LastChar 255
/BaseFont /Helvetica
/Name /F0
>>
endobj
xref
0 7
0000000000 65535 f
0000000011 00000 n
0000000111 00000 n
0000000325 00000 n
0000000390 00000 n
0000000579 00000 n
0000001231 00000 n
trailer
<<
/Size 7
/Root 1 0 R
/Info 2 0 R
>>
startxref
1377
%%EOF

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Gmagm sssssssssssa]

http://finance.yahoo.com/q?s=EXMT.PK 




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[Henning, Arthur C. (CSL)]

[-- Attachment #1.1: Type: text/plain, Size: 695 bytes --]

RHEL 5

Have two events having difficulty capturing or reviewing with the audit
sub-system.

1. su - "non_existent_account". Using the nispom.rules provided by audit
1.5.6-1. Using various ausearch parameters, am unable to find a
corresponding failure when attempting to "su" to a non-existent account.

2. Non-privileged user attempting to change the date/time on the server.
Of course the user fails to be able to do so, but am unable to capture
or review the event.

Not sure if these are audit rule configuration or search unknowns or
audit sub-system limitations.

Thank you
Art Henning (CSL) 
Enterprise IT Solutions
Northrop Grumman Corporation
art.henning@ngc.com


[-- Attachment #1.2: Type: text/html, Size: 1419 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Guzman]

[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 321 bytes --]

[-- Attachment #2: report.pdf --]
[-- Type: application/pdf, Size: 19948 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[aanidi-CYedFwHYa5iBl8o7nT1L3dBPR1lH4CV8]

I am glad you liked my pics, here.s a few you will really like.
http://79.113.242.115/


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[Krzysztof Helt]

[-- Attachment #1: Type: text/plain, Size: 119752 bytes --]

From: Krzysztof Helt <krzysztof.h1@wp.pl>

This patch fixes over 850 errors and warnings pointed
out by the checkpatch.pl script.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>

---

I run the checkpatch.pl script on the whole drivers/video
directory. The most errors are in drivers which share code
with X11 (sis, nvidia). The cirrus driver had the most errors
as a non-X11 driver.

--- linux-2.6.23.old/drivers/video/cirrusfb.c	2007-07-09 01:
32:16.000000000 +0200
+++ linux-2.6.23/drivers/video/cirrusfb.c	2007-08-16 19:43:
03.000000000 +0200
@@ -59,7 +59,7 @@
 #endif
 #ifdef CONFIG_PPC_PREP
 #include <asm/machdep.h>
-#define isPReP (machine_is(prep))
+#define isPReP(machine_is(prep))
 #else
 #define isPReP 0
 #endif
@@ -67,7 +67,6 @@
 #include "video/vga.h"
 #include "video/cirrus.h"
 
-
 
/****************************************************************
*
  *
  * debugging and utility macros
@@ -82,7 +81,8 @@
 
 /* debug output */
 #ifdef CIRRUSFB_DEBUG
-#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, 
__FUNCTION__ , ## args)
+#define DPRINTK(fmt, args...) \
+	printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
 #else
 #define DPRINTK(fmt, args...)
 #endif
@@ -90,20 +90,19 @@
 /* debugging assertions */
 #ifndef CIRRUSFB_NDEBUG
 #define assert(expr) \
-        if(!(expr)) { \
-        printk( "Assertion failed! %s,%s,%s,line=%d\n",\
-        #expr,__FILE__,__FUNCTION__,__LINE__); \
-        }
+	if (!(expr)) { \
+		printk("Assertion failed! %s,%s,%s,line=%d\n", \
+		#expr, __FILE__, __FUNCTION__, __LINE__); \
+	}
 #else
 #define assert(expr)
 #endif
 
-#define MB_ (1024*1024)
+#define MB_ (1024 * 1024)
 #define KB_ (1024)
 
 #define MAX_NUM_BOARDS 7
 
-
 
/****************************************************************
*
  *
  * chipset information
@@ -123,7 +122,6 @@ typedef enum {
 	BT_LAGUNA,	/* GD546x */
 } cirrusfb_board_t;
 
-
 /*
  * per-board-type information, used for enumerating and 
abstracting
  * chip-specific information
@@ -139,7 +137,8 @@ static const struct cirrusfb_board_info_
 	/* for  1/4bpp, 8bpp 15/16bpp, 24bpp, 32bpp - numbers from 
xorg code */
 	bool init_sr07 : 1; /* init SR07 during init_vgachip() */
 	bool init_sr1f : 1; /* write SR1F during init_vgachip() */
-	bool scrn_start_bit19 : 1; /* construct bit 19 of screen 
start address */
+	/* construct bit 19 of screen start address */
+	bool scrn_start_bit19 : 1;
 
 	/* initial SR07 value, then for each mode */
 	unsigned char sr07;
@@ -261,30 +260,28 @@ static const struct cirrusfb_board_info_
 	}
 };
 
-
 #ifdef CONFIG_PCI
 #define CHIP(id, btype) \
 	{ PCI_VENDOR_ID_CIRRUS, id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
(btype) }
 
 static struct pci_device_id cirrusfb_pci_table[] = {
-	CHIP( PCI_DEVICE_ID_CIRRUS_5436, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5434_8, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5434_4, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5430, BT_ALPINE ), /* GD-5440 is 
same id */
-	CHIP( PCI_DEVICE_ID_CIRRUS_7543, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_7548, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5480, BT_GD5480 ), /* MacPicasso 
likely */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5446, BT_PICASSO4 ), /* Picasso 
4 is 5446 */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5462, BT_LAGUNA ), /* CL Laguna 
*/
-	CHIP( PCI_DEVICE_ID_CIRRUS_5464, BT_LAGUNA ), /* CL Laguna 
3D */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5465, BT_LAGUNA ), /* CL Laguna 
3DA*/
+	CHIP(PCI_DEVICE_ID_CIRRUS_5436, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5434_8, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5434_4, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5430, BT_ALPINE), /* GD-5440 is 
same id */
+	CHIP(PCI_DEVICE_ID_CIRRUS_7543, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_7548, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5480, BT_GD5480), /* MacPicasso 
likely */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5446, BT_PICASSO4), /* Picasso 4 
is 5446 */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5462, BT_LAGUNA), /* CL Laguna */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5464, BT_LAGUNA), /* CL Laguna 3D 
*/
+	CHIP(PCI_DEVICE_ID_CIRRUS_5465, BT_LAGUNA), /* CL Laguna 
3DA*/
 	{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, cirrusfb_pci_table);
 #undef CHIP
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
 static const struct zorro_device_id cirrusfb_zorro_table[] = {
 	{
@@ -294,7 +291,7 @@ static const struct zorro_device_id cirr
 		.id		= ZORRO_PROD_HELFRICH_PICCOLO_RAM,
 		.driver_data	= BT_PICCOLO,
 	}, {
-		.id		= 
ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
+		.id	= 
ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
 		.driver_data	= BT_PICASSO,
 	}, {
 		.id		= ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_RAM,
@@ -333,7 +330,6 @@ static const struct {
 };
 #endif /* CONFIG_ZORRO */
 
-
 struct cirrusfb_regs {
 	__u32 line_length;	/* in BYTES! */
 	__u32 visual;
@@ -364,17 +360,12 @@ struct cirrusfb_regs {
 	long VertBlankEnd;
 };
 
-
-
 #ifdef CIRRUSFB_DEBUG
 typedef enum {
-        CRT,
-        SEQ
+	CRT,
+	SEQ
 } cirrusfb_dbg_reg_class_t;
-#endif                          /* CIRRUSFB_DEBUG */
-
-
-
+#endif		/* CIRRUSFB_DEBUG */
 
 /* info about board */
 struct cirrusfb_info {
@@ -405,9 +396,8 @@ struct cirrusfb_info {
 	void (*unmap)(struct cirrusfb_info *cinfo);
 };
 
-
 static unsigned cirrusfb_def_mode = 1;
-static int noaccel = 0;
+static int noaccel;
 
 /*
  *    Predefined Video Modes
@@ -441,7 +431,7 @@ static const struct {
 			.lower_margin	= 8,
 			.hsync_len	= 96,
 			.vsync_len	= 4,
-			.sync		= FB_SYNC_HOR_HIGH_ACT | 
FB_SYNC_VERT_HIGH_ACT,
+			.sync	= FB_SYNC_HOR_HIGH_ACT | 
FB_SYNC_VERT_HIGH_ACT,
 			.vmode		= FB_VMODE_NONINTERLACED
 		 }
 	}, {
@@ -502,27 +492,29 @@ static const struct {
 
/****************************************************************
************/
 /**** BEGIN PROTOTYPES 
******************************************************/
 
-
 /*--- Interface used by the world 
------------------------------------------*/
-static int cirrusfb_init (void);
+static int cirrusfb_init(void);
 #ifndef MODULE
-static int cirrusfb_setup (char *options);
+static int cirrusfb_setup(char *options);
 #endif
 
-static int cirrusfb_open (struct fb_info *info, int user);
-static int cirrusfb_release (struct fb_info *info, int user);
-static int cirrusfb_setcolreg (unsigned regno, unsigned red, 
unsigned green,
-			       unsigned blue, unsigned transp,
-			       struct fb_info *info);
-static int cirrusfb_check_var (struct fb_var_screeninfo *var,
-			       struct fb_info *info);
-static int cirrusfb_set_par (struct fb_info *info);
-static int cirrusfb_pan_display (struct fb_var_screeninfo *var,
-				 struct fb_info *info);
-static int cirrusfb_blank (int blank_mode, struct fb_info *info)
;
-static void cirrusfb_fillrect (struct fb_info *info, const 
struct fb_fillrect *region);
-static void cirrusfb_copyarea(struct fb_info *info, const struct 
fb_copyarea *area);
-static void cirrusfb_imageblit(struct fb_info *info, const 
struct fb_image *image);
+static int cirrusfb_open(struct fb_info *info, int user);
+static int cirrusfb_release(struct fb_info *info, int user);
+static int cirrusfb_setcolreg(unsigned regno, unsigned red, 
unsigned green,
+			      unsigned blue, unsigned transp,
+			      struct fb_info *info);
+static int cirrusfb_check_var(struct fb_var_screeninfo *var,
+			      struct fb_info *info);
+static int cirrusfb_set_par(struct fb_info *info);
+static int cirrusfb_pan_display(struct fb_var_screeninfo *var,
+				struct fb_info *info);
+static int cirrusfb_blank(int blank_mode, struct fb_info *info);
+static void cirrusfb_fillrect(struct fb_info *info,
+			      const struct fb_fillrect *region);
+static void cirrusfb_copyarea(struct fb_info *info,
+			      const struct fb_copyarea *area);
+static void cirrusfb_imageblit(struct fb_info *info,
+			       const struct fb_image *image);
 
 /* function table of the above functions */
 static struct fb_ops cirrusfb_ops = {
@@ -540,68 +532,68 @@ static struct fb_ops cirrusfb_ops = {
 };
 
 /*--- Hardware Specific Routines 
-------------------------------------------*/
-static int cirrusfb_decode_var (const struct fb_var_screeninfo 
*var,
+static int cirrusfb_decode_var(const struct fb_var_screeninfo 
*var,
 				struct cirrusfb_regs *regs,
 				const struct fb_info *info);
 /*--- Internal routines 
----------------------------------------------------*/
-static void init_vgachip (struct cirrusfb_info *cinfo);
-static void switch_monitor (struct cirrusfb_info *cinfo, int on)
;
-static void WGen (const struct cirrusfb_info *cinfo,
-		  int regnum, unsigned char val);
-static unsigned char RGen (const struct cirrusfb_info *cinfo, 
int regnum);
-static void AttrOn (const struct cirrusfb_info *cinfo);
-static void WHDR (const struct cirrusfb_info *cinfo, unsigned 
char val);
-static void WSFR (struct cirrusfb_info *cinfo, unsigned char 
val);
-static void WSFR2 (struct cirrusfb_info *cinfo, unsigned char 
val);
-static void WClut (struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char red,
-		   unsigned char green,
-		   unsigned char blue);
+static void init_vgachip(struct cirrusfb_info *cinfo);
+static void switch_monitor(struct cirrusfb_info *cinfo, int on);
+static void WGen(const struct cirrusfb_info *cinfo,
+		 int regnum, unsigned char val);
+static unsigned char RGen(const struct cirrusfb_info *cinfo, int 
regnum);
+static void AttrOn(const struct cirrusfb_info *cinfo);
+static void WHDR(const struct cirrusfb_info *cinfo, unsigned 
char val);
+static void WSFR(struct cirrusfb_info *cinfo, unsigned char val)
;
+static void WSFR2(struct cirrusfb_info *cinfo, unsigned char 
val);
+static void WClut(struct cirrusfb_info *cinfo, unsigned char 
regnum,
+		  unsigned char red, unsigned char green, unsigned char 
blue);
 #if 0
-static void RClut (struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char *red,
-		   unsigned char *green,
-		   unsigned char *blue);
-#endif
-static void cirrusfb_WaitBLT (u8 __iomem *regbase);
-static void cirrusfb_BitBLT (u8 __iomem *regbase, int 
bits_per_pixel,
-			     u_short curx, u_short cury,
-			     u_short destx, u_short desty,
-			     u_short width, u_short height,
-			     u_short line_length);
-static void cirrusfb_RectFill (u8 __iomem *regbase, int 
bits_per_pixel,
-			       u_short x, u_short y,
-			       u_short width, u_short height,
-			       u_char color, u_short line_length);
-
-static void bestclock (long freq, long *best,
-		       long *nom, long *den,
-		       long *div, long maxfreq);
+static void RClut(struct cirrusfb_info *cinfo, unsigned char 
regnum,
+		  unsigned char *red, unsigned char *green,
+		  unsigned char *blue);
+#endif
+static void cirrusfb_WaitBLT(u8 __iomem *regbase);
+static void cirrusfb_BitBLT(u8 __iomem *regbase, int 
bits_per_pixel,
+			    u_short curx, u_short cury,
+			    u_short destx, u_short desty,
+			    u_short width, u_short height,
+			    u_short line_length);
+static void cirrusfb_RectFill(u8 __iomem *regbase, int 
bits_per_pixel,
+			      u_short x, u_short y,
+			      u_short width, u_short height,
+			      u_char color, u_short line_length);
+
+static void bestclock(long freq, long *best,
+		      long *nom, long *den,
+		      long *div, long maxfreq);
 
 #ifdef CIRRUSFB_DEBUG
-static void cirrusfb_dump (void);
-static void cirrusfb_dbg_reg_dump (caddr_t regbase);
-static void cirrusfb_dbg_print_regs (caddr_t regbase, 
cirrusfb_dbg_reg_class_t reg_class,...);
-static void cirrusfb_dbg_print_byte (const char *name, unsigned 
char val);
+static void cirrusfb_dump(void);
+static void cirrusfb_dbg_reg_dump(caddr_t regbase);
+static void cirrusfb_dbg_print_regs(caddr_t regbase,
+				    cirrusfb_dbg_reg_class_t reg_class, ...);
+static void cirrusfb_dbg_print_byte(const char *name, unsigned 
char val);
 #endif /* CIRRUSFB_DEBUG */
 
 /*** END   PROTOTYPES 
********************************************************/
 
/****************************************************************
*************/
 /*** BEGIN Interface Used by the World 
***************************************/
 
-static int opencount = 0;
+static int opencount;
 
 /*--- Open /dev/fbx 
---------------------------------------------------------*/
-static int cirrusfb_open (struct fb_info *info, int user)
+static int cirrusfb_open(struct fb_info *info, int user)
 {
 	if (opencount++ == 0)
-		switch_monitor (info->par, 1);
+		switch_monitor(info->par, 1);
 	return 0;
 }
 
 /*--- Close /dev/fbx 
--------------------------------------------------------*/
-static int cirrusfb_release (struct fb_info *info, int user)
+static int cirrusfb_release(struct fb_info *info, int user)
 {
 	if (--opencount == 0)
-		switch_monitor (info->par, 0);
+		switch_monitor(info->par, 0);
 	return 0;
 }
 
@@ -610,11 +602,11 @@ static int cirrusfb_release (struct fb_i
 /**** BEGIN Hardware specific Routines 
**************************************/
 
 /* Get a good MCLK value */
-static long cirrusfb_get_mclk (long freq, int bpp, long *div)
+static long cirrusfb_get_mclk(long freq, int bpp, long *div)
 {
 	long mclk;
 
-	assert (div != NULL);
+	assert(div != NULL);
 
 	/* Calculate MCLK, in case VCLK is high enough to require > 
50MHz.
 	 * Assume a 64-bit data path for now.  The formula is:
@@ -624,23 +616,23 @@ static long cirrusfb_get_mclk (long freq
 	mclk = (mclk * 12) / 10;
 	if (mclk < 50000)
 		mclk = 50000;
-	DPRINTK ("Use MCLK of %ld kHz\n", mclk);
+	DPRINTK("Use MCLK of %ld kHz\n", mclk);
 
 	/* Calculate value for SR1F.  Multiply by 2 so we can round 
up. */
 	mclk = ((mclk * 16) / 14318);
 	mclk = (mclk + 1) / 2;
-	DPRINTK ("Set SR1F[5:0] to 0x%lx\n", mclk);
+	DPRINTK("Set SR1F[5:0] to 0x%lx\n", mclk);
 
 	/* Determine if we should use MCLK instead of VCLK, and if 
so, what we
 	   * should divide it by to get VCLK */
 	switch (freq) {
 	case 24751 ... 25249:
 		*div = 2;
-		DPRINTK ("Using VCLK = MCLK/2\n");
+		DPRINTK("Using VCLK = MCLK/2\n");
 		break;
 	case 49501 ... 50499:
 		*div = 1;
-		DPRINTK ("Using VCLK = MCLK\n");
+		DPRINTK("Using VCLK = MCLK\n");
 		break;
 	default:
 		*div = 0;
@@ -691,37 +683,42 @@ static int cirrusfb_check_var(struct fb_
 		den = 1;
 		break;		/* 4 bytes per pixel */
 	default:
-		printk ("cirrusfb: mode %dx%dx%d rejected...color depth 
not supported.\n",
+		printk(KERN_ERR "cirrusfb: mode %dx%dx%d rejected..."
+			"color depth not supported.\n",
 			var->xres, var->yres, var->bits_per_pixel);
-		DPRINTK ("EXIT - EINVAL error\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	if (var->xres * nom / den * var->yres > cinfo->size) {
-		printk ("cirrusfb: mode %dx%dx%d rejected...resolution 
too high to fit into video memory!\n",
+		printk(KERN_ERR "cirrusfb: mode %dx%dx%d rejected..."
+			"resolution too high to fit into video memory!\n",
 			var->xres, var->yres, var->bits_per_pixel);
-		DPRINTK ("EXIT - EINVAL error\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	/* use highest possible virtual resolution */
 	if (var->xres_virtual == -1 &&
 	    var->yres_virtual == -1) {
-		printk ("cirrusfb: using maximum available virtual 
resolution\n");
+		printk(KERN_INFO
+		     "cirrusfb: using maximum available virtual 
resolution\n");
 		for (i = 0; modes[i].xres != -1; i++) {
 			if (modes[i].xres * nom / den * modes[i].yres < 
cinfo->size / 2)
 				break;
 		}
 		if (modes[i].xres == -1) {
-			printk ("cirrusfb: could not find a virtual 
resolution that fits into video memory!!\n");
-			DPRINTK ("EXIT - EINVAL error\n");
+			printk(KERN_ERR "cirrusfb: could not find a virtual "
+				"resolution that fits into video memory!!\n");
+			DPRINTK("EXIT - EINVAL error\n");
 			return -EINVAL;
 		}
 		var->xres_virtual = modes[i].xres;
 		var->yres_virtual = modes[i].yres;
 
-		printk ("cirrusfb: virtual resolution set to maximum of 
%dx%d\n",
-			var->xres_virtual, var->yres_virtual);
+		printk(KERN_INFO "cirrusfb: virtual resolution set to "
+			"maximum of %dx%d\n", var->xres_virtual,
+			var->yres_virtual);
 	}
 
 	if (var->xres_virtual < var->xres)
@@ -760,7 +757,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 16:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 2;
 			var->green.offset = -3;
 			var->blue.offset = 8;
@@ -775,7 +772,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 24:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 8;
 			var->green.offset = 16;
 			var->blue.offset = 24;
@@ -790,7 +787,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 32:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 8;
 			var->green.offset = 16;
 			var->blue.offset = 24;
@@ -825,15 +822,16 @@ static int cirrusfb_check_var(struct fb_
 		yres = (yres + 1) / 2;
 
 	if (yres >= 1280) {
-		printk (KERN_WARNING "cirrusfb: ERROR: VerticalTotal >= 
1280; special treatment required! (TODO)\n");
-		DPRINTK ("EXIT - EINVAL error\n");
+		printk(KERN_ERR "cirrusfb: ERROR: VerticalTotal >= 1280; 
"
+			"special treatment required! (TODO)\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	return 0;
 }
 
-static int cirrusfb_decode_var (const struct fb_var_screeninfo 
*var,
+static int cirrusfb_decode_var(const struct fb_var_screeninfo 
*var,
 				struct cirrusfb_regs *regs,
 				const struct fb_info *info)
 {
@@ -844,7 +842,7 @@ static int cirrusfb_decode_var (const st
 	int xres, hfront, hsync, hback;
 	int yres, vfront, vsync, vback;
 
-	switch(var->bits_per_pixel) {
+	switch (var->bits_per_pixel) {
 	case 1:
 		regs->line_length = var->xres_virtual / 8;
 		regs->visual = FB_VISUAL_MONO10;
@@ -887,7 +885,7 @@ static int cirrusfb_decode_var (const st
 	/* convert from ps to kHz */
 	freq = 1000000000 / var->pixclock;
 
-	DPRINTK ("desired pixclock: %ld kHz\n", freq);
+	DPRINTK("desired pixclock: %ld kHz\n", freq);
 
 	maxclock = cirrusfb_board_info[cinfo->btype].
maxclock[maxclockidx];
 	regs->multiplexing = 0;
@@ -902,8 +900,9 @@ static int cirrusfb_decode_var (const st
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: ERROR: Frequency 
greater than maxclock (%ld kHz)\n", maxclock);
-			DPRINTK ("EXIT - return -EINVAL\n");
+			printk(KERN_ERR "cirrusfb: Frequency greater "
+				"than maxclock (%ld kHz)\n", maxclock);
+			DPRINTK("EXIT - return -EINVAL\n");
 			return -EINVAL;
 		}
 	}
@@ -914,14 +913,16 @@ static int cirrusfb_decode_var (const st
 	case 16:
 	case 32:
 		if (regs->HorizRes <= 800)
-			freq /= 2;	/* Xbh has this type of clock for 
32-bit */
+			/* Xbh has this type of clock for 32-bit */
+			freq /= 2;
 		break;
 	}
 #endif
 
-	bestclock (freq, &regs->freq, &regs->nom, &regs->den, 
&regs->div,
-		   maxclock);
-	regs->mclk = cirrusfb_get_mclk (freq, var->bits_per_pixel, 
&regs->divMCLK);
+	bestclock(freq, &regs->freq, &regs->nom, &regs->den, 
&regs->div,
+		  maxclock);
+	regs->mclk = cirrusfb_get_mclk(freq, var->bits_per_pixel,
+					&regs->divMCLK);
 
 	xres = var->xres;
 	hfront = var->right_margin;
@@ -948,7 +949,8 @@ static int cirrusfb_decode_var (const st
 	regs->HorizTotal = (xres + hfront + hsync + hback) / 8 - 5;
 	regs->HorizDispEnd = xres / 8 - 1;
 	regs->HorizBlankStart = xres / 8;
-	regs->HorizBlankEnd = regs->HorizTotal + 5;	/* does not 
count with "-5" */
+	/* does not count with "-5" */
+	regs->HorizBlankEnd = regs->HorizTotal + 5;
 	regs->HorizSyncStart = (xres + hfront) / 8 + 1;
 	regs->HorizSyncEnd = (xres + hfront + hsync) / 8 + 1;
 
@@ -976,23 +978,23 @@ static int cirrusfb_decode_var (const st
 	return 0;
 }
 
-
-static void cirrusfb_set_mclk (const struct cirrusfb_info 
*cinfo, int val, int div)
+static void cirrusfb_set_mclk(const struct cirrusfb_info *cinfo, 
int val,
+				int div)
 {
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
 	if (div == 2) {
 		/* VCLK = MCLK/2 */
-		unsigned char old = vga_rseq (cinfo->regbase, CL_SEQR1E)
;
-		vga_wseq (cinfo->regbase, CL_SEQR1E, old | 0x1);
-		vga_wseq (cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f)
);
+		unsigned char old = vga_rseq(cinfo->regbase, CL_SEQR1E);
+		vga_wseq(cinfo->regbase, CL_SEQR1E, old | 0x1);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f))
;
 	} else if (div == 1) {
 		/* VCLK = MCLK */
-		unsigned char old = vga_rseq (cinfo->regbase, CL_SEQR1E)
;
-		vga_wseq (cinfo->regbase, CL_SEQR1E, old & ~0x1);
-		vga_wseq (cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f)
);
+		unsigned char old = vga_rseq(cinfo->regbase, CL_SEQR1E);
+		vga_wseq(cinfo->regbase, CL_SEQR1E, old & ~0x1);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f))
;
 	} else {
-		vga_wseq (cinfo->regbase, CL_SEQR1F, val & 0x3f);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, val & 0x3f);
 	}
 }
 
@@ -1001,7 +1003,7 @@ static void cirrusfb_set_mclk (const str
 
 	actually writes the values for a new video mode into the 
hardware,
 
*****************************************************************
*********/
-static int cirrusfb_set_par_foo (struct fb_info *info)
+static int cirrusfb_set_par_foo(struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_var_screeninfo *var = &info->var;
@@ -1011,15 +1013,15 @@ static int cirrusfb_set_par_foo (struct 
 	int offset = 0, err;
 	const struct cirrusfb_board_info_rec *bi;
 
-	DPRINTK ("ENTER\n");
-	DPRINTK ("Requested mode: %dx%dx%d\n",
+	DPRINTK("ENTER\n");
+	DPRINTK("Requested mode: %dx%dx%d\n",
 	       var->xres, var->yres, var->bits_per_pixel);
-	DPRINTK ("pixclock: %d\n", var->pixclock);
+	DPRINTK("pixclock: %d\n", var->pixclock);
 
-	init_vgachip (cinfo);
+	init_vgachip(cinfo);
 
 	err = cirrusfb_decode_var(var, &regs, info);
-	if(err) {
+	if (err) {
 		/* should never happen */
 		DPRINTK("mode change aborted.  invalid var.\n");
 		return -EINVAL;
@@ -1027,34 +1029,35 @@ static int cirrusfb_set_par_foo (struct 
 
 	bi = &cirrusfb_board_info[cinfo->btype];
 
-
 	/* unlock register VGA_CRTC_H_TOTAL..CRT7 */
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, 0x20);	/* 
previously: 0x00) */
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, 0x20);	/* 
previously: 0x00) */
 
 	/* if debugging is enabled, all parameters get output 
before writing */
-	DPRINTK ("CRT0: %ld\n", regs.HorizTotal);
-	vga_wcrt (regbase, VGA_CRTC_H_TOTAL, regs.HorizTotal);
+	DPRINTK("CRT0: %ld\n", regs.HorizTotal);
+	vga_wcrt(regbase, VGA_CRTC_H_TOTAL, regs.HorizTotal);
 
-	DPRINTK ("CRT1: %ld\n", regs.HorizDispEnd);
-	vga_wcrt (regbase, VGA_CRTC_H_DISP, regs.HorizDispEnd);
+	DPRINTK("CRT1: %ld\n", regs.HorizDispEnd);
+	vga_wcrt(regbase, VGA_CRTC_H_DISP, regs.HorizDispEnd);
 
-	DPRINTK ("CRT2: %ld\n", regs.HorizBlankStart);
-	vga_wcrt (regbase, VGA_CRTC_H_BLANK_START, regs.
HorizBlankStart);
+	DPRINTK("CRT2: %ld\n", regs.HorizBlankStart);
+	vga_wcrt(regbase, VGA_CRTC_H_BLANK_START, regs.
HorizBlankStart);
 
-	DPRINTK ("CRT3: 128+%ld\n", regs.HorizBlankEnd % 32);
	/*  + 128: Compatible read */
-	vga_wcrt (regbase, VGA_CRTC_H_BLANK_END, 128 + (regs.
HorizBlankEnd % 32));
+	/*  + 128: Compatible read */
+	DPRINTK("CRT3: 128+%ld\n", regs.HorizBlankEnd % 32);
+	vga_wcrt(regbase, VGA_CRTC_H_BLANK_END,
+		 128 + (regs.HorizBlankEnd % 32));
 
-	DPRINTK ("CRT4: %ld\n", regs.HorizSyncStart);
-	vga_wcrt (regbase, VGA_CRTC_H_SYNC_START, regs.
HorizSyncStart);
+	DPRINTK("CRT4: %ld\n", regs.HorizSyncStart);
+	vga_wcrt(regbase, VGA_CRTC_H_SYNC_START, regs.
HorizSyncStart);
 
 	tmp = regs.HorizSyncEnd % 32;
 	if (regs.HorizBlankEnd & 32)
 		tmp += 128;
-	DPRINTK ("CRT5: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_H_SYNC_END, tmp);
+	DPRINTK("CRT5: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_H_SYNC_END, tmp);
 
-	DPRINTK ("CRT6: %ld\n", regs.VertTotal & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_TOTAL, (regs.VertTotal & 
0xff));
+	DPRINTK("CRT6: %ld\n", regs.VertTotal & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_TOTAL, (regs.VertTotal & 0xff)
);
 
 	tmp = 16;		/* LineCompare bit #9 */
 	if (regs.VertTotal & 256)
@@ -1071,34 +1074,34 @@ static int cirrusfb_set_par_foo (struct 
 		tmp |= 64;
 	if (regs.VertSyncStart & 512)
 		tmp |= 128;
-	DPRINTK ("CRT7: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_OVERFLOW, tmp);
+	DPRINTK("CRT7: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_OVERFLOW, tmp);
 
 	tmp = 0x40;		/* LineCompare bit #8 */
 	if (regs.VertBlankStart & 512)
 		tmp |= 0x20;
 	if (var->vmode & FB_VMODE_DOUBLE)
 		tmp |= 0x80;
-	DPRINTK ("CRT9: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_MAX_SCAN, tmp);
+	DPRINTK("CRT9: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_MAX_SCAN, tmp);
 
-	DPRINTK ("CRT10: %ld\n", regs.VertSyncStart & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_START, (regs.
VertSyncStart & 0xff));
+	DPRINTK("CRT10: %ld\n", regs.VertSyncStart & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_START, regs.VertSyncStart 
& 0xff);
 
-	DPRINTK ("CRT11: 64+32+%ld\n", regs.VertSyncEnd % 16);
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, (regs.VertSyncEnd % 
16 + 64 + 32));
+	DPRINTK("CRT11: 64+32+%ld\n", regs.VertSyncEnd % 16);
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, regs.VertSyncEnd % 
16 + 64 + 32);
 
-	DPRINTK ("CRT12: %ld\n", regs.VertDispEnd & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_DISP_END, (regs.VertDispEnd & 
0xff));
+	DPRINTK("CRT12: %ld\n", regs.VertDispEnd & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_DISP_END, regs.VertDispEnd & 
0xff);
 
-	DPRINTK ("CRT15: %ld\n", regs.VertBlankStart & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_BLANK_START, (regs.
VertBlankStart & 0xff));
+	DPRINTK("CRT15: %ld\n", regs.VertBlankStart & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_BLANK_START, regs.
VertBlankStart & 0xff);
 
-	DPRINTK ("CRT16: %ld\n", regs.VertBlankEnd & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_BLANK_END, (regs.VertBlankEnd 
& 0xff));
+	DPRINTK("CRT16: %ld\n", regs.VertBlankEnd & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_BLANK_END, regs.VertBlankEnd & 
0xff);
 
-	DPRINTK ("CRT18: 0xff\n");
-	vga_wcrt (regbase, VGA_CRTC_LINE_COMPARE, 0xff);
+	DPRINTK("CRT18: 0xff\n");
+	vga_wcrt(regbase, VGA_CRTC_LINE_COMPARE, 0xff);
 
 	tmp = 0;
 	if (var->vmode & FB_VMODE_INTERLACED)
@@ -1112,57 +1115,63 @@ static int cirrusfb_set_par_foo (struct 
 	if (regs.VertBlankEnd & 512)
 		tmp |= 128;
 
-	DPRINTK ("CRT1a: %d\n", tmp);
-	vga_wcrt (regbase, CL_CRT1A, tmp);
+	DPRINTK("CRT1a: %d\n", tmp);
+	vga_wcrt(regbase, CL_CRT1A, tmp);
 
 	/* set VCLK0 */
 	/* hardware RefClock: 14.31818 MHz */
 	/* formula: VClk = (OSC * N) / (D * (1+P)) */
 	/* Example: VClk = (14.31818 * 91) / (23 * (1+1)) = 28.325 
MHz */
 
-	vga_wseq (regbase, CL_SEQRB, regs.nom);
+	vga_wseq(regbase, CL_SEQRB, regs.nom);
 	tmp = regs.den << 1;
 	if (regs.div != 0)
 		tmp |= 1;
 
+	/* 6 bit denom; ONLY 5434!!! (bugged me 10 days) */
 	if ((cinfo->btype == BT_SD64) ||
 	    (cinfo->btype == BT_ALPINE) ||
 	    (cinfo->btype == BT_GD5480))
-		tmp |= 0x80;	/* 6 bit denom; ONLY 5434!!! (bugged me 
10 days) */
+		tmp |= 0x80;
 
-	DPRINTK ("CL_SEQR1B: %ld\n", (long) tmp);
-	vga_wseq (regbase, CL_SEQR1B, tmp);
+	DPRINTK("CL_SEQR1B: %ld\n", (long) tmp);
+	vga_wseq(regbase, CL_SEQR1B, tmp);
 
 	if (regs.VertRes >= 1024)
 		/* 1280x1024 */
-		vga_wcrt (regbase, VGA_CRTC_MODE, 0xc7);
+		vga_wcrt(regbase, VGA_CRTC_MODE, 0xc7);
 	else
 		/* mode control: VGA_CRTC_START_HI enable, ROTATE(?), 
16bit
 		 * address wrap, no compat. */
-		vga_wcrt (regbase, VGA_CRTC_MODE, 0xc3);
+		vga_wcrt(regbase, VGA_CRTC_MODE, 0xc3);
 
-/* HAEH?        vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, 0x20);  
* previously: 0x00  unlock VGA_CRTC_H_TOTAL..CRT7 */
+/* HAEH?	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, 0x20);
+ * previously: 0x00  unlock VGA_CRTC_H_TOTAL..CRT7 */
 
 	/* don't know if it would hurt to also program this if no 
interlaced */
 	/* mode is used, but I feel better this way.. :-) */
 	if (var->vmode & FB_VMODE_INTERLACED)
-		vga_wcrt (regbase, VGA_CRTC_REGS, regs.HorizTotal / 2);
+		vga_wcrt(regbase, VGA_CRTC_REGS, regs.HorizTotal / 2);
 	else
-		vga_wcrt (regbase, VGA_CRTC_REGS, 0x00);	/* 
interlace control */
+		vga_wcrt(regbase, VGA_CRTC_REGS, 0x00);	/* interlace 
control */
 
-	vga_wseq (regbase, VGA_SEQ_CHARACTER_MAP, 0);
+	vga_wseq(regbase, VGA_SEQ_CHARACTER_MAP, 0);
 
 	/* adjust horizontal/vertical sync type (low/high) */
-	tmp = 0x03;		/* enable display memory & CRTC I/O 
address for color mode */
+	/* enable display memory & CRTC I/O address for color mode 
*/
+	tmp = 0x03;
 	if (var->sync & FB_SYNC_HOR_HIGH_ACT)
 		tmp |= 0x40;
 	if (var->sync & FB_SYNC_VERT_HIGH_ACT)
 		tmp |= 0x80;
-	WGen (cinfo, VGA_MIS_W, tmp);
+	WGen(cinfo, VGA_MIS_W, tmp);
 
-	vga_wcrt (regbase, VGA_CRTC_PRESET_ROW, 0);	/* Screen A 
Preset Row-Scan register */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_START, 0);	/* text 
cursor on and start line */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_END, 31);	/* text 
cursor end line */
+	/* Screen A Preset Row-Scan register */
+	vga_wcrt(regbase, VGA_CRTC_PRESET_ROW, 0);
+	/* text cursor on and start line */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_START, 0);
+	/* text cursor end line */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_END, 31);
 
 	/******************************************************
 	 *
@@ -1172,8 +1181,8 @@ static int cirrusfb_set_par_foo (struct 
 
 	/* programming for different color depths */
 	if (var->bits_per_pixel == 1) {
-		DPRINTK ("cirrusfb: preparing for 1 bit deep display\n")
;
-		vga_wgfx (regbase, VGA_GFX_MODE, 0);	/* mode 
register */
+		DPRINTK("cirrusfb: preparing for 1 bit deep display\n");
+		vga_wgfx(regbase, VGA_GFX_MODE, 0);	/* mode register 
*/
 
 		/* SR07 */
 		switch (cinfo->btype) {
@@ -1184,71 +1193,85 @@ static int cirrusfb_set_par_foo (struct 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
-			DPRINTK (" (for GD54xx)\n");
-			vga_wseq (regbase, CL_SEQR7,
+			DPRINTK(" (for GD54xx)\n");
+			vga_wseq(regbase, CL_SEQR7,
 				  regs.multiplexing ?
 					bi->sr07_1bpp_mux : bi->sr07_1bpp);
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
 		/* Extended Sequencer Mode */
 		switch (cinfo->btype) {
 		case BT_SD64:
-			/* setting the SEQRF on SD64 is not necessary (only 
during init) */
-			DPRINTK ("(for SD64)\n");
-			vga_wseq (regbase, CL_SEQR1F, 0x1a);		/*  MCLK 
select */
+			/* setting the SEQRF on SD64 is not necessary
+			 * (only during init)
+			 */
+			DPRINTK("(for SD64)\n");
+			/*  MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1a);
 			break;
 
 		case BT_PICCOLO:
-			DPRINTK ("(for Piccolo)\n");
-/* ### ueberall 0x22? */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* 
##vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* evtl d0 
bei 1 bit? avoid FIFO underruns..? */
+			DPRINTK("(for Piccolo)\n");
+			/* ### ueberall 0x22? */
+			/* ##vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* evtl d0 bei 1 bit? avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO:
-			DPRINTK ("(for Picasso)\n");
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* 
##vorher 22 MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xd0);	/* ## vorher 
d0 avoid FIFO underruns..? */
+			DPRINTK("(for Picasso)\n");
+			/* ##vorher 22 MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* ## vorher d0 avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xd0);
 			break;
 
 		case BT_SPECTRUM:
-			DPRINTK ("(for Spectrum)\n");
-/* ### ueberall 0x22? */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* 
##vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* evtl d0? 
avoid FIFO underruns..? */
+			DPRINTK("(for Spectrum)\n");
+			/* ### ueberall 0x22? */
+			/* ##vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* evtl d0? avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
 		case BT_LAGUNA:
-			DPRINTK (" (for GD54xx)\n");
+			DPRINTK(" (for GD54xx)\n");
 			/* do nothing */
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		WGen (cinfo, VGA_PEL_MSK, 0x01);	/* pixel mask: 
pass-through for first plane */
+		/* pixel mask: pass-through for first plane */
+		WGen(cinfo, VGA_PEL_MSK, 0x01);
 		if (regs.multiplexing)
-			WHDR (cinfo, 0x4a);	/* hidden dac reg: 1280x1024 
*/
+			/* hidden dac reg: 1280x1024 */
+			WHDR(cinfo, 0x4a);
 		else
-			WHDR (cinfo, 0);	/* hidden dac: nothing */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x06);	/* 
memory mode: odd/even, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0x01);	/* 
plane mask: only write to first plane */
+			/* hidden dac: nothing */
+			WHDR(cinfo, 0);
+		/* memory mode: odd/even, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x06);
+		/* plane mask: only write to first plane */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0x01);
 		offset = var->xres_virtual / 16;
 	}
 
@@ -1259,7 +1282,7 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 8) {
-		DPRINTK ("cirrusfb: preparing for 8 bit deep display\n")
;
+		DPRINTK("cirrusfb: preparing for 8 bit deep display\n");
 		switch (cinfo->btype) {
 		case BT_SD64:
 		case BT_PICCOLO:
@@ -1268,75 +1291,89 @@ static int cirrusfb_set_par_foo (struct 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
-			DPRINTK (" (for GD54xx)\n");
-			vga_wseq (regbase, CL_SEQR7,
+			DPRINTK(" (for GD54xx)\n");
+			vga_wseq(regbase, CL_SEQR7,
 				  regs.multiplexing ?
 					bi->sr07_8bpp_mux : bi->sr07_8bpp);
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) | 0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) | 0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR1F, 0x1d);		/* MCLK 
select */
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1d);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### 
vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### 
vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### 
vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO4:
 #ifdef CONFIG_ZORRO
-			vga_wseq (regbase, CL_SEQRF, 0xb8);	/* ### 
INCOMPLETE!! */
+			/* ### INCOMPLETE!! */
+			vga_wseq(regbase, CL_SEQRF, 0xb8);
 #endif
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c); */
+/*	  		vga_wseq(regbase, CL_SEQR1F, 0x1c); */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+			DPRINTK(" (for GD543x)\n");
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_GD5480:
 		case BT_LAGUNA:
-			DPRINTK (" (for GD54xx)\n");
+			DPRINTK(" (for GD54xx)\n");
 			/* do nothing */
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode 
register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: 
pass-through all planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
 		if (regs.multiplexing)
-			WHDR (cinfo, 0x4a);	/* hidden dac reg: 1280x1024 
*/
+			/* hidden dac reg: 1280x1024 */
+			WHDR(cinfo, 0x4a);
 		else
-			WHDR (cinfo, 0);	/* hidden dac: nothing */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* 
memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* 
plane mask: enable writing to all 4 planes */
+			/* hidden dac: nothing */
+			WHDR(cinfo, 0);
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 8;
 	}
 
@@ -1347,72 +1384,84 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 16) {
-		DPRINTK ("cirrusfb: preparing for 16 bit deep 
display\n");
+		DPRINTK("cirrusfb: preparing for 16 bit deep display\n")
;
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR7, 0xf7);	/* Extended 
Sequencer Mode: 256c col. mode */
-			vga_wseq (regbase, CL_SEQR1F, 0x1e);		/* MCLK 
select */
+			/* Extended Sequencer Mode: 256c col. mode */
+			vga_wseq(regbase, CL_SEQR7, 0xf7);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1e);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR7, 0x87);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x87);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR7, 0x27);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x27);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR7, 0x87);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x87);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO4:
-			vga_wseq (regbase, CL_SEQR7, 0x27);
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c);  */
+			vga_wseq(regbase, CL_SEQR7, 0x27);
+/*			vga_wseq(regbase, CL_SEQR1F, 0x1c);  */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
+			DPRINTK(" (for GD543x)\n");
 			if (regs.HorizRes >= 1024)
-				vga_wseq (regbase, CL_SEQR7, 0xa7);
+				vga_wseq(regbase, CL_SEQR7, 0xa7);
 			else
-				vga_wseq (regbase, CL_SEQR7, 0xa3);
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+				vga_wseq(regbase, CL_SEQR7, 0xa3);
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			break;
 
 		case BT_GD5480:
-			DPRINTK (" (for GD5480)\n");
-			vga_wseq (regbase, CL_SEQR7, 0x17);
+			DPRINTK(" (for GD5480)\n");
+			vga_wseq(regbase, CL_SEQR7, 0x17);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "CIRRUSFB: unknown Board\n");
+			printk(KERN_WARNING "CIRRUSFB: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode 
register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: 
pass-through all planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
 #ifdef CONFIG_PCI
-		WHDR (cinfo, 0xc0);	/* Copy Xbh */
+		WHDR(cinfo, 0xc0);	/* Copy Xbh */
 #elif defined(CONFIG_ZORRO)
 		/* FIXME: CONFIG_PCI and CONFIG_ZORRO may be defined 
both */
-		WHDR (cinfo, 0xa0);	/* hidden dac reg: nothing 
special */
+		WHDR(cinfo, 0xa0);	/* hidden dac reg: nothing 
special */
 #endif
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* 
memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* 
plane mask: enable writing to all 4 planes */
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 4;
 	}
 
@@ -1423,64 +1472,77 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 32) {
-		DPRINTK ("cirrusfb: preparing for 24/32 bit deep 
display\n");
+		DPRINTK("cirrusfb: preparing for 24/32 bit deep 
display\n");
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR7, 0xf9);	/* Extended 
Sequencer Mode: 256c col. mode */
-			vga_wseq (regbase, CL_SEQR1F, 0x1e);		/* MCLK 
select */
+			/* Extended Sequencer Mode: 256c col. mode */
+			vga_wseq(regbase, CL_SEQR7, 0xf9);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1e);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR7, 0x85);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x85);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR7, 0x25);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x25);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR7, 0x85);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast 
Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK 
select */
+			vga_wseq(regbase, CL_SEQR7, 0x85);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO4:
-			vga_wseq (regbase, CL_SEQR7, 0x25);
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c);  */
+			vga_wseq(regbase, CL_SEQR7, 0x25);
+/*			vga_wseq(regbase, CL_SEQR1F, 0x1c);  */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
-			vga_wseq (regbase, CL_SEQR7, 0xa9);
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+			DPRINTK(" (for GD543x)\n");
+			vga_wseq(regbase, CL_SEQR7, 0xa9);
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			break;
 
 		case BT_GD5480:
-			DPRINTK (" (for GD5480)\n");
-			vga_wseq (regbase, CL_SEQR7, 0x19);
+			DPRINTK(" (for GD5480)\n");
+			vga_wseq(regbase, CL_SEQR7, 0x19);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode 
register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: 
pass-through all planes */
-		WHDR (cinfo, 0xc5);	/* hidden dac reg: 8-8-8 mode 
(24 or 32) */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* 
memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* 
plane mask: enable writing to all 4 planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
+		/* hidden dac reg: 8-8-8 mode (24 or 32) */
+		WHDR(cinfo, 0xc5);
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 4;
 	}
 
@@ -1490,48 +1552,67 @@ static int cirrusfb_set_par_foo (struct 
 	 *
 	 */
 
-	else {
-		printk (KERN_ERR "cirrusfb: What's this?? requested 
color depth == %d.\n",
+	else
+		printk(KERN_ERR "cirrusfb: What's this?? "
+			" requested color depth == %d.\n",
 			var->bits_per_pixel);
-	}
 
-	vga_wcrt (regbase, VGA_CRTC_OFFSET, offset & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_OFFSET, offset & 0xff);
 	tmp = 0x22;
 	if (offset & 0x100)
 		tmp |= 0x10;	/* offset overflow bit */
 
-	vga_wcrt (regbase, CL_CRT1B, tmp);	/* screen start addr 
#16-18, fastpagemode cycles */
+	/* screen start addr #16-18, fastpagemode cycles */
+	vga_wcrt(regbase, CL_CRT1B, tmp);
 
 	if (cinfo->btype == BT_SD64 ||
 	    cinfo->btype == BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE ||
 	    cinfo->btype == BT_GD5480)
-		vga_wcrt (regbase, CL_CRT1D, 0x00);	/* screen start 
address bit 19 */
+		/* screen start address bit 19 */
+		vga_wcrt(regbase, CL_CRT1D, 0x00);
 
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_HI, 0);	/* text 
cursor location high */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_LO, 0);	/* text 
cursor location low */
-	vga_wcrt (regbase, VGA_CRTC_UNDERLINE, 0);	/* underline 
row scanline = at very bottom */
-
-	vga_wattr (regbase, VGA_ATC_MODE, 1);	/* controller 
mode */
-	vga_wattr (regbase, VGA_ATC_OVERSCAN, 0);		/* 
overscan (border) color */
-	vga_wattr (regbase, VGA_ATC_PLANE_ENABLE, 15);	/* color 
plane enable */
-	vga_wattr (regbase, CL_AR33, 0);	/* pixel panning */
-	vga_wattr (regbase, VGA_ATC_COLOR_PAGE, 0);	/* color 
select */
+	/* text cursor location high */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_HI, 0);
+	/* text cursor location low */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_LO, 0);
+	/* underline row scanline = at very bottom */
+	vga_wcrt(regbase, VGA_CRTC_UNDERLINE, 0);
+
+	/* controller mode */
+	vga_wattr(regbase, VGA_ATC_MODE, 1);
+	/* overscan (border) color */
+	vga_wattr(regbase, VGA_ATC_OVERSCAN, 0);
+	/* color plane enable */
+	vga_wattr(regbase, VGA_ATC_PLANE_ENABLE, 15);
+	/* pixel panning */
+	vga_wattr(regbase, CL_AR33, 0);
+	/* color select */
+	vga_wattr(regbase, VGA_ATC_COLOR_PAGE, 0);
 
 	/* [ EGS: SetOffset(); ] */
 	/* From SetOffset(): Turn on VideoEnable bit in Attribute 
controller */
-	AttrOn (cinfo);
+	AttrOn(cinfo);
 
-	vga_wgfx (regbase, VGA_GFX_SR_VALUE, 0);	/* set/reset 
register */
-	vga_wgfx (regbase, VGA_GFX_SR_ENABLE, 0);		/* 
set/reset enable */
-	vga_wgfx (regbase, VGA_GFX_COMPARE_VALUE, 0);	/* color 
compare */
-	vga_wgfx (regbase, VGA_GFX_DATA_ROTATE, 0);	/* data 
rotate */
-	vga_wgfx (regbase, VGA_GFX_PLANE_READ, 0);	/* read map 
select */
-	vga_wgfx (regbase, VGA_GFX_MISC, 1);	/* miscellaneous 
register */
-	vga_wgfx (regbase, VGA_GFX_COMPARE_MASK, 15);	/* color 
don't care */
-	vga_wgfx (regbase, VGA_GFX_BIT_MASK, 255);	/* bit mask 
*/
+	/* set/reset register */
+	vga_wgfx(regbase, VGA_GFX_SR_VALUE, 0);
+	/* set/reset enable */
+	vga_wgfx(regbase, VGA_GFX_SR_ENABLE, 0);
+	/* color compare */
+	vga_wgfx(regbase, VGA_GFX_COMPARE_VALUE, 0);
+	/* data rotate */
+	vga_wgfx(regbase, VGA_GFX_DATA_ROTATE, 0);
+	/* read map select */
+	vga_wgfx(regbase, VGA_GFX_PLANE_READ, 0);
+	/* miscellaneous register */
+	vga_wgfx(regbase, VGA_GFX_MISC, 1);
+	/* color don't care */
+	vga_wgfx(regbase, VGA_GFX_COMPARE_MASK, 15);
+	/* bit mask */
+	vga_wgfx(regbase, VGA_GFX_BIT_MASK, 255);
 
-	vga_wseq (regbase, CL_SEQR12, 0x0);	/* graphics cursor 
attributes: nothing special */
+	/* graphics cursor attributes: nothing special */
+	vga_wseq(regbase, CL_SEQR12, 0x0);
 
 	/* finally, turn on everything - turn off "FullBandwidth" 
bit */
 	/* also, set "DotClock%2" bit where requested */
@@ -1542,8 +1623,8 @@ static int cirrusfb_set_par_foo (struct 
 	tmp |= 0x08;
 */
 
-	vga_wseq (regbase, VGA_SEQ_CLOCK_MODE, tmp);
-	DPRINTK ("CL_SEQR1: %d\n", tmp);
+	vga_wseq(regbase, VGA_SEQ_CLOCK_MODE, tmp);
+	DPRINTK("CL_SEQR1: %d\n", tmp);
 
 	cinfo->currentmode = regs;
 	info->fix.type = regs.type;
@@ -1551,27 +1632,27 @@ static int cirrusfb_set_par_foo (struct 
 	info->fix.line_length = regs.line_length;
 
 	/* pan to requested offset */
-	cirrusfb_pan_display (var, info);
+	cirrusfb_pan_display(var, info);
 
 #ifdef CIRRUSFB_DEBUG
-	cirrusfb_dump ();
+	cirrusfb_dump();
 #endif
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 	return 0;
 }
 
 /* for some reason incomprehensible to me, cirrusfb requires 
that you write
  * the registers twice for the settings to take..grr. -dte */
-static int cirrusfb_set_par (struct fb_info *info)
+static int cirrusfb_set_par(struct fb_info *info)
 {
-	cirrusfb_set_par_foo (info);
-	return cirrusfb_set_par_foo (info);
+	cirrusfb_set_par_foo(info);
+	return cirrusfb_set_par_foo(info);
 }
 
-static int cirrusfb_setcolreg (unsigned regno, unsigned red, 
unsigned green,
-			       unsigned blue, unsigned transp,
-			       struct fb_info *info)
+static int cirrusfb_setcolreg(unsigned regno, unsigned red, 
unsigned green,
+			      unsigned blue, unsigned transp,
+			      struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
 
@@ -1584,23 +1665,23 @@ static int cirrusfb_setcolreg (unsigned 
 		green >>= (16 - info->var.green.length);
 		blue >>= (16 - info->var.blue.length);
 
-		if (regno>=16)
+		if (regno >= 16)
 			return 1;
 		v = (red << info->var.red.offset) |
 		    (green << info->var.green.offset) |
 		    (blue << info->var.blue.offset);
 
 		switch (info->var.bits_per_pixel) {
-			case 8:
-				cinfo->pseudo_palette[regno] = v;
-				break;
-			case 16:
-				cinfo->pseudo_palette[regno] = v;
-				break;
-			case 24:
-			case 32:
-				cinfo->pseudo_palette[regno] = v;
-				break;
+		case 8:
+			cinfo->pseudo_palette[regno] = v;
+			break;
+		case 16:
+			cinfo->pseudo_palette[regno] = v;
+			break;
+		case 24:
+		case 32:
+			cinfo->pseudo_palette[regno] = v;
+			break;
 		}
 		return 0;
 	}
@@ -1609,9 +1690,8 @@ static int cirrusfb_setcolreg (unsigned 
 	cinfo->palette[regno].green = green;
 	cinfo->palette[regno].blue = blue;
 
-	if (info->var.bits_per_pixel == 8) {
-			WClut (cinfo, regno, red >> 10, green >> 10, blue >> 
10);
-	}
+	if (info->var.bits_per_pixel == 8)
+		WClut(cinfo, regno, red >> 10, green >> 10, blue >> 10);
 
 	return 0;
 
@@ -1622,8 +1702,8 @@ static int cirrusfb_setcolreg (unsigned 
 
 	performs display panning - provided hardware permits this
 
*****************************************************************
*********/
-static int cirrusfb_pan_display (struct fb_var_screeninfo *var,
-				 struct fb_info *info)
+static int cirrusfb_pan_display(struct fb_var_screeninfo *var,
+				struct fb_info *info)
 {
 	int xoffset = 0;
 	int yoffset = 0;
@@ -1631,8 +1711,8 @@ static int cirrusfb_pan_display (struct 
 	unsigned char tmp = 0, tmp2 = 0, xpix;
 	struct cirrusfb_info *cinfo = info->par;
 
-	DPRINTK ("ENTER\n");
-	DPRINTK ("virtual offset: (%d,%d)\n", var->xoffset, 
var->yoffset);
+	DPRINTK("ENTER\n");
+	DPRINTK("virtual offset: (%d,%d)\n", var->xoffset, 
var->yoffset);
 
 	/* no range checks for xoffset and yoffset,   */
 	/* as fb_pan_display has already done this */
@@ -1655,11 +1735,13 @@ static int cirrusfb_pan_display (struct 
 		xpix = (unsigned char) ((xoffset % 4) * 2);
 	}
 
-        cirrusfb_WaitBLT(cinfo->regbase); /* make sure all the 
BLT's are done */
+	cirrusfb_WaitBLT(cinfo->regbase); /* make sure all the 
BLT's are done */
 
 	/* lower 8 + 8 bits of screen start address */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_LO, (unsigned 
char) (base & 0xff));
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_HI, (unsigned 
char) (base >> 8));
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_LO,
+		 (unsigned char) (base & 0xff));
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_HI,
+		 (unsigned char) (base >> 8));
 
 	/* construct bits 16, 17 and 18 of screen start address */
 	if (base & 0x10000)
@@ -1669,50 +1751,53 @@ static int cirrusfb_pan_display (struct 
 	if (base & 0x40000)
 		tmp |= 0x08;
 
-	tmp2 = (vga_rcrt (cinfo->regbase, CL_CRT1B) & 0xf2) | tmp;
	/* 0xf2 is %11110010, exclude tmp bits */
-	vga_wcrt (cinfo->regbase, CL_CRT1B, tmp2);
+	/* 0xf2 is %11110010, exclude tmp bits */
+	tmp2 = (vga_rcrt(cinfo->regbase, CL_CRT1B) & 0xf2) | tmp;
+	vga_wcrt(cinfo->regbase, CL_CRT1B, tmp2);
 
 	/* construct bit 19 of screen start address */
 	if (cirrusfb_board_info[cinfo->btype].scrn_start_bit19) {
 		tmp2 = 0;
 		if (base & 0x80000)
 			tmp2 = 0x80;
-		vga_wcrt (cinfo->regbase, CL_CRT1D, tmp2);
+		vga_wcrt(cinfo->regbase, CL_CRT1D, tmp2);
 	}
 
-	/* write pixel panning value to AR33; this does not quite 
work in 8bpp */
-	/* ### Piccolo..? Will this work? */
+	/* write pixel panning value to AR33; this does not quite 
work in 8bpp
+	 *
+	 * ### Piccolo..? Will this work?
+	 */
 	if (info->var.bits_per_pixel == 1)
-		vga_wattr (cinfo->regbase, CL_AR33, xpix);
+		vga_wattr(cinfo->regbase, CL_AR33, xpix);
 
-	cirrusfb_WaitBLT (cinfo->regbase);
+	cirrusfb_WaitBLT(cinfo->regbase);
 
-	DPRINTK ("EXIT\n");
-	return (0);
+	DPRINTK("EXIT\n");
+	return 0;
 }
 
-
-static int cirrusfb_blank (int blank_mode, struct fb_info *info)
+static int cirrusfb_blank(int blank_mode, struct fb_info *info)
 {
 	/*
-	 *  Blank the screen if blank_mode != 0, else unblank. If 
blank == NULL
-	 *  then the caller blanks by setting the CLUT (Color Look Up 
Table) to all
-	 *  black. Return 0 if blanking succeeded, != 0 if 
un-/blanking failed due
-	 *  to e.g. a video mode which doesn't support it. Implements 
VESA suspend
-	 *  and powerdown modes on hardware that supports disabling 
hsync/vsync:
-	 *    blank_mode == 2: suspend vsync
-	 *    blank_mode == 3: suspend hsync
-	 *    blank_mode == 4: powerdown
+	 * Blank the screen if blank_mode != 0, else unblank. If 
blank == NULL
+	 * then the caller blanks by setting the CLUT (Color Look Up 
Table)
+	 * to all black. Return 0 if blanking succeeded, != 0 if 
un-/blanking
+	 * failed due to e.g. a video mode which doesn't support it.
+	 * Implements VESA suspend and powerdown modes on hardware 
that
+	 * supports disabling hsync/vsync:
+	 *   blank_mode == 2: suspend vsync
+	 *   blank_mode == 3: suspend hsync
+	 *   blank_mode == 4: powerdown
 	 */
 	unsigned char val;
 	struct cirrusfb_info *cinfo = info->par;
 	int current_mode = cinfo->blank_mode;
 
-	DPRINTK ("ENTER, blank mode = %d\n", blank_mode);
+	DPRINTK("ENTER, blank mode = %d\n", blank_mode);
 
 	if (info->state != FBINFO_STATE_RUNNING ||
 	    current_mode == blank_mode) {
-		DPRINTK ("EXIT, returning 0\n");
+		DPRINTK("EXIT, returning 0\n");
 		return 0;
 	}
 
@@ -1720,17 +1805,19 @@ static int cirrusfb_blank (int blank_mod
 	if (current_mode == FB_BLANK_NORMAL ||
 	    current_mode == FB_BLANK_UNBLANK) {
 		/* unblank the screen */
-		val = vga_rseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE);
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, val & 
0xdf);	/* clear "FullBandwidth" bit */
+		val = vga_rseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE);
+		/* clear "FullBandwidth" bit */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, val & 0xdf)
;
 		/* and undo VESA suspend trickery */
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x00);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x00);
 	}
 
 	/* set new */
-	if(blank_mode > FB_BLANK_NORMAL) {
+	if (blank_mode > FB_BLANK_NORMAL) {
 		/* blank the screen */
-		val = vga_rseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE);
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, val | 
0x20);	/* set "FullBandwidth" bit */
+		val = vga_rseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE);
+		/* set "FullBandwidth" bit */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, val | 0x20)
;
 	}
 
 	switch (blank_mode) {
@@ -1738,21 +1825,21 @@ static int cirrusfb_blank (int blank_mod
 	case FB_BLANK_NORMAL:
 		break;
 	case FB_BLANK_VSYNC_SUSPEND:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x04);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x04);
 		break;
 	case FB_BLANK_HSYNC_SUSPEND:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x02);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x02);
 		break;
 	case FB_BLANK_POWERDOWN:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x06);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x06);
 		break;
 	default:
-		DPRINTK ("EXIT, returning 1\n");
+		DPRINTK("EXIT, returning 1\n");
 		return 1;
 	}
 
 	cinfo->blank_mode = blank_mode;
-	DPRINTK ("EXIT, returning 0\n");
+	DPRINTK("EXIT, returning 0\n");
 
 	/* Let fbcon do a soft blank for us */
 	return (blank_mode == FB_BLANK_NORMAL) ? 1 : 0;
@@ -1761,45 +1848,50 @@ static int cirrusfb_blank (int blank_mod
 
/****************************************************************
************/
 /**** BEGIN Internal Routines 
***********************************************/
 
-static void init_vgachip (struct cirrusfb_info *cinfo)
+static void init_vgachip(struct cirrusfb_info *cinfo)
 {
 	const struct cirrusfb_board_info_rec *bi;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
 	bi = &cirrusfb_board_info[cinfo->btype];
 
 	/* reset board globally */
 	switch (cinfo->btype) {
 	case BT_PICCOLO:
-		WSFR (cinfo, 0x01);
-		udelay (500);
-		WSFR (cinfo, 0x51);
-		udelay (500);
+		WSFR(cinfo, 0x01);
+		udelay(500);
+		WSFR(cinfo, 0x51);
+		udelay(500);
 		break;
 	case BT_PICASSO:
-		WSFR2 (cinfo, 0xff);
-		udelay (500);
+		WSFR2(cinfo, 0xff);
+		udelay(500);
 		break;
 	case BT_SD64:
 	case BT_SPECTRUM:
-		WSFR (cinfo, 0x1f);
-		udelay (500);
-		WSFR (cinfo, 0x4f);
-		udelay (500);
+		WSFR(cinfo, 0x1f);
+		udelay(500);
+		WSFR(cinfo, 0x4f);
+		udelay(500);
 		break;
 	case BT_PICASSO4:
-		vga_wcrt (cinfo->regbase, CL_CRT51, 0x00);	/* 
disable flickerfixer */
-		mdelay (100);
-		vga_wgfx (cinfo->regbase, CL_GR2F, 0x00);	/* from 
Klaus' NetBSD driver: */
-		vga_wgfx (cinfo->regbase, CL_GR33, 0x00);	/* put 
blitter into 542x compat */
-		vga_wgfx (cinfo->regbase, CL_GR31, 0x00);	/* mode */
+		/* disable flickerfixer */
+		vga_wcrt(cinfo->regbase, CL_CRT51, 0x00);
+		mdelay(100);
+		/* from Klaus' NetBSD driver: */
+		vga_wgfx(cinfo->regbase, CL_GR2F, 0x00);
+		/* put blitter into 542x compat */
+		vga_wgfx(cinfo->regbase, CL_GR33, 0x00);
+		/* mode */
+		vga_wgfx(cinfo->regbase, CL_GR31, 0x00);
 		break;
 
 	case BT_GD5480:
-		vga_wgfx (cinfo->regbase, CL_GR2F, 0x00);	/* from 
Klaus' NetBSD driver: */
+		/* from Klaus' NetBSD driver: */
+		vga_wgfx(cinfo->regbase, CL_GR2F, 0x00);
 		break;
 
 	case BT_ALPINE:
@@ -1807,153 +1899,207 @@ static void init_vgachip (struct 
cirrusf
 		break;
 
 	default:
-		printk (KERN_ERR "cirrusfb: Warning: Unknown board 
type\n");
+		printk(KERN_ERR "cirrusfb: Warning: Unknown board 
type\n");
 		break;
 	}
 
-	assert (cinfo->size > 0); /* make sure RAM size set by this 
point */
+	assert(cinfo->size > 0); /* make sure RAM size set by this 
point */
 
 	/* the P4 is not fully initialized here; I rely on it 
having been */
 	/* inited under AmigaOS already, which seems to work just 
fine    */
-	/* (Klaus advised to do it this way)                        
      */
+	/* (Klaus advised to do it this way)			      */
 
 	if (cinfo->btype != BT_PICASSO4) {
-		WGen (cinfo, CL_VSSM, 0x10);	/* EGS: 0x16 */
-		WGen (cinfo, CL_POS102, 0x01);
-		WGen (cinfo, CL_VSSM, 0x08);	/* EGS: 0x0e */
+		WGen(cinfo, CL_VSSM, 0x10);	/* EGS: 0x16 */
+		WGen(cinfo, CL_POS102, 0x01);
+		WGen(cinfo, CL_VSSM, 0x08);	/* EGS: 0x0e */
 
 		if (cinfo->btype != BT_SD64)
-			WGen (cinfo, CL_VSSM2, 0x01);
+			WGen(cinfo, CL_VSSM2, 0x01);
 
-		vga_wseq (cinfo->regbase, CL_SEQR0, 0x03);	/* reset 
sequencer logic */
+		/* reset sequencer logic */
+		vga_wseq(cinfo->regbase, CL_SEQR0, 0x03);
 
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, 0x21);
	/* FullBandwidth (video off) and 8/9 dot clock */
-		WGen (cinfo, VGA_MIS_W, 0xc1);	/* polarity (-/-), 
disable access to display memory, VGA_CRTC_START_HI base address: 
color */
+		/* FullBandwidth (video off) and 8/9 dot clock */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, 0x21);
+		/* polarity (-/-), disable access to display memory,
+		 * VGA_CRTC_START_HI base address: color
+		 */
+		WGen(cinfo, VGA_MIS_W, 0xc1);
 
-/*      vga_wgfx (cinfo->regbase, CL_GRA, 0xce);    "magic 
cookie" - doesn't make any sense to me.. */
-		vga_wseq (cinfo->regbase, CL_SEQR6, 0x12);	/* unlock 
all extension registers */
+		/* "magic cookie" - doesn't make any sense to me.. */
+/*      vga_wgfx(cinfo->regbase, CL_GRA, 0xce);   */
+		/* unlock all extension registers */
+		vga_wseq(cinfo->regbase, CL_SEQR6, 0x12);
 
-		vga_wgfx (cinfo->regbase, CL_GR31, 0x04);	/* reset 
blitter */
+		/* reset blitter */
+		vga_wgfx(cinfo->regbase, CL_GR31, 0x04);
 
 		switch (cinfo->btype) {
 		case BT_GD5480:
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0x98);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0x98);
 			break;
 		case BT_ALPINE:
 			break;
 		case BT_SD64:
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0xb8);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0xb8);
 			break;
 		default:
-			vga_wseq (cinfo->regbase, CL_SEQR16, 0x0f);
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0xb0);
+			vga_wseq(cinfo->regbase, CL_SEQR16, 0x0f);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0xb0);
 			break;
 		}
 	}
-	vga_wseq (cinfo->regbase, VGA_SEQ_PLANE_WRITE, 0xff);
	/* plane mask: nothing */
-	vga_wseq (cinfo->regbase, VGA_SEQ_CHARACTER_MAP, 0x00);
	/* character map select: doesn't even matter in gx mode */
-	vga_wseq (cinfo->regbase, VGA_SEQ_MEMORY_MODE, 0x0e);
	/* memory mode: chain-4, no odd/even, ext. memory */
+	/* plane mask: nothing */
+	vga_wseq(cinfo->regbase, VGA_SEQ_PLANE_WRITE, 0xff);
+	/* character map select: doesn't even matter in gx mode */
+	vga_wseq(cinfo->regbase, VGA_SEQ_CHARACTER_MAP, 0x00);
+	/* memory mode: chain-4, no odd/even, ext. memory */
+	vga_wseq(cinfo->regbase, VGA_SEQ_MEMORY_MODE, 0x0e);
 
 	/* controller-internal base address of video memory */
 	if (bi->init_sr07)
-		vga_wseq (cinfo->regbase, CL_SEQR7, bi->sr07);
+		vga_wseq(cinfo->regbase, CL_SEQR7, bi->sr07);
 
-	/*  vga_wseq (cinfo->regbase, CL_SEQR8, 0x00); *//* EEPROM 
control: shouldn't be necessary to write to this at all.. */
+	/*  vga_wseq(cinfo->regbase, CL_SEQR8, 0x00); */
+	/* EEPROM control: shouldn't be necessary to write to this 
at all.. */
 
-	vga_wseq (cinfo->regbase, CL_SEQR10, 0x00);		/* 
graphics cursor X position (incomplete; position gives rem. 3 
bits */
-	vga_wseq (cinfo->regbase, CL_SEQR11, 0x00);		/* 
graphics cursor Y position (..."... ) */
-	vga_wseq (cinfo->regbase, CL_SEQR12, 0x00);		/* 
graphics cursor attributes */
-	vga_wseq (cinfo->regbase, CL_SEQR13, 0x00);		/* 
graphics cursor pattern address */
+	/* graphics cursor X position (incomplete; position gives 
rem. 3 bits */
+	vga_wseq(cinfo->regbase, CL_SEQR10, 0x00);
+	/* graphics cursor Y position (..."... ) */
+	vga_wseq(cinfo->regbase, CL_SEQR11, 0x00);
+	/* graphics cursor attributes */
+	vga_wseq(cinfo->regbase, CL_SEQR12, 0x00);
+	/* graphics cursor pattern address */
+	vga_wseq(cinfo->regbase, CL_SEQR13, 0x00);
 
 	/* writing these on a P4 might give problems..  */
 	if (cinfo->btype != BT_PICASSO4) {
-		vga_wseq (cinfo->regbase, CL_SEQR17, 0x00);		/* 
configuration readback and ext. color */
-		vga_wseq (cinfo->regbase, CL_SEQR18, 0x02);		/* 
signature generator */
+		/* configuration readback and ext. color */
+		vga_wseq(cinfo->regbase, CL_SEQR17, 0x00);
+		/* signature generator */
+		vga_wseq(cinfo->regbase, CL_SEQR18, 0x02);
 	}
 
 	/* MCLK select etc. */
 	if (bi->init_sr1f)
-		vga_wseq (cinfo->regbase, CL_SEQR1F, bi->sr1f);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, bi->sr1f);
 
-	vga_wcrt (cinfo->regbase, VGA_CRTC_PRESET_ROW, 0x00);
	/* Screen A preset row scan: none */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_START, 0x20);
	/* Text cursor start: disable text cursor */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_END, 0x00);
	/* Text cursor end: - */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_HI, 0x00);	/* 
Screen start address high: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_LO, 0x00);	/* 
Screen start address low: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_HI, 0x00);	/* 
text cursor location high: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_LO, 0x00);	/* 
text cursor location low: 0 */
-
-	vga_wcrt (cinfo->regbase, VGA_CRTC_UNDERLINE, 0x00);	/* 
Underline Row scanline: - */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_MODE, 0xc3);	/* mode 
control: timing enable, byte mode, no compat modes */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_LINE_COMPARE, 0x00);
	/* Line Compare: not needed */
+	/* Screen A preset row scan: none */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_PRESET_ROW, 0x00);
+	/* Text cursor start: disable text cursor */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_START, 0x20);
+	/* Text cursor end: - */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_END, 0x00);
+	/* Screen start address high: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_HI, 0x00);
+	/* Screen start address low: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_LO, 0x00);
+	/* text cursor location high: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_HI, 0x00);
+	/* text cursor location low: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_LO, 0x00);
+
+	/* Underline Row scanline: - */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_UNDERLINE, 0x00);
+	/* mode control: timing enable, byte mode, no compat modes 
*/
+	vga_wcrt(cinfo->regbase, VGA_CRTC_MODE, 0xc3);
+	/* Line Compare: not needed */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_LINE_COMPARE, 0x00);
 	/* ### add 0x40 for text modes with > 30 MHz pixclock */
-	vga_wcrt (cinfo->regbase, CL_CRT1B, 0x02);	/* ext. 
display controls: ext.adr. wrap */
+	/* ext. display controls: ext.adr. wrap */
+	vga_wcrt(cinfo->regbase, CL_CRT1B, 0x02);
 
-	vga_wgfx (cinfo->regbase, VGA_GFX_SR_VALUE, 0x00);	/* 
Set/Reset registes: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_SR_ENABLE, 0x00);	/* 
Set/Reset enable: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_COMPARE_VALUE, 0x00);
	/* Color Compare: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_DATA_ROTATE, 0x00);
	/* Data Rotate: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_PLANE_READ, 0x00);	/* 
Read Map Select: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_MODE, 0x00);	/* Mode: 
conf. for 16/4/2 color mode, no odd/even, read/write mode 0 */
-	vga_wgfx (cinfo->regbase, VGA_GFX_MISC, 0x01);	/* 
Miscellaneous: memory map base address, graphics mode */
-	vga_wgfx (cinfo->regbase, VGA_GFX_COMPARE_MASK, 0x0f);
	/* Color Don't care: involve all planes */
-	vga_wgfx (cinfo->regbase, VGA_GFX_BIT_MASK, 0xff);	/* 
Bit Mask: no mask at all */
+	/* Set/Reset registes: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_SR_VALUE, 0x00);
+	/* Set/Reset enable: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_SR_ENABLE, 0x00);
+	/* Color Compare: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_COMPARE_VALUE, 0x00);
+	/* Data Rotate: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_DATA_ROTATE, 0x00);
+	/* Read Map Select: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_PLANE_READ, 0x00);
+	/* Mode: conf. for 16/4/2 color mode, no odd/even, 
read/write mode 0 */
+	vga_wgfx(cinfo->regbase, VGA_GFX_MODE, 0x00);
+	/* Miscellaneous: memory map base address, graphics mode */
+	vga_wgfx(cinfo->regbase, VGA_GFX_MISC, 0x01);
+	/* Color Don't care: involve all planes */
+	vga_wgfx(cinfo->regbase, VGA_GFX_COMPARE_MASK, 0x0f);
+	/* Bit Mask: no mask at all */
+	vga_wgfx(cinfo->regbase, VGA_GFX_BIT_MASK, 0xff);
 	if (cinfo->btype == BT_ALPINE)
-		vga_wgfx (cinfo->regbase, CL_GRB, 0x20);	/* (5434 
can't have bit 3 set for bitblt) */
+		/* (5434 can't have bit 3 set for bitblt) */
+		vga_wgfx(cinfo->regbase, CL_GRB, 0x20);
 	else
-		vga_wgfx (cinfo->regbase, CL_GRB, 0x28);	/* Graphics 
controller mode extensions: finer granularity, 8byte data latches 
*/
+	/* Graphics controller mode extensions: finer granularity,
+	 * 8byte data latches
+	 */
+		vga_wgfx(cinfo->regbase, CL_GRB, 0x28);
 
-	vga_wgfx (cinfo->regbase, CL_GRC, 0xff);	/* Color Key 
compare: - */
-	vga_wgfx (cinfo->regbase, CL_GRD, 0x00);	/* Color Key 
compare mask: - */
-	vga_wgfx (cinfo->regbase, CL_GRE, 0x00);	/* 
Miscellaneous control: - */
-	/*  vga_wgfx (cinfo->regbase, CL_GR10, 0x00); *//* 
Background color byte 1: - */
-/*  vga_wgfx (cinfo->regbase, CL_GR11, 0x00); */
-
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE0, 0x00);	/* 
Attribute Controller palette registers: "identity mapping" */
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE1, 0x01);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE2, 0x02);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE3, 0x03);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE4, 0x04);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE5, 0x05);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE6, 0x06);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE7, 0x07);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE8, 0x08);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE9, 0x09);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEA, 0x0a);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEB, 0x0b);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEC, 0x0c);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTED, 0x0d);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEE, 0x0e);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEF, 0x0f);
-
-	vga_wattr (cinfo->regbase, VGA_ATC_MODE, 0x01);	/* 
Attribute Controller mode: graphics mode */
-	vga_wattr (cinfo->regbase, VGA_ATC_OVERSCAN, 0x00);	/* 
Overscan color reg.: reg. 0 */
-	vga_wattr (cinfo->regbase, VGA_ATC_PLANE_ENABLE, 0x0f);
	/* Color Plane enable: Enable all 4 planes */
-/* ###  vga_wattr (cinfo->regbase, CL_AR33, 0x00); * Pixel 
Panning: - */
-	vga_wattr (cinfo->regbase, VGA_ATC_COLOR_PAGE, 0x00);
	/* Color Select: - */
+	vga_wgfx(cinfo->regbase, CL_GRC, 0xff);	/* Color Key 
compare: - */
+	vga_wgfx(cinfo->regbase, CL_GRD, 0x00);	/* Color Key 
compare mask: - */
+	vga_wgfx(cinfo->regbase, CL_GRE, 0x00);	/* 
Miscellaneous control: - */
+	/* Background color byte 1: - */
+	/*  vga_wgfx (cinfo->regbase, CL_GR10, 0x00); */
+	/*  vga_wgfx (cinfo->regbase, CL_GR11, 0x00); */
+
+	/* Attribute Controller palette registers: "identity 
mapping" */
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE0, 0x00);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE1, 0x01);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE2, 0x02);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE3, 0x03);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE4, 0x04);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE5, 0x05);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE6, 0x06);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE7, 0x07);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE8, 0x08);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE9, 0x09);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEA, 0x0a);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEB, 0x0b);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEC, 0x0c);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTED, 0x0d);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEE, 0x0e);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEF, 0x0f);
+
+	/* Attribute Controller mode: graphics mode */
+	vga_wattr(cinfo->regbase, VGA_ATC_MODE, 0x01);
+	/* Overscan color reg.: reg. 0 */
+	vga_wattr(cinfo->regbase, VGA_ATC_OVERSCAN, 0x00);
+	/* Color Plane enable: Enable all 4 planes */
+	vga_wattr(cinfo->regbase, VGA_ATC_PLANE_ENABLE, 0x0f);
+/* ###  vga_wattr(cinfo->regbase, CL_AR33, 0x00); * Pixel 
Panning: - */
+	/* Color Select: - */
+	vga_wattr(cinfo->regbase, VGA_ATC_COLOR_PAGE, 0x00);
 
-	WGen (cinfo, VGA_PEL_MSK, 0xff);	/* Pixel mask: no mask 
*/
+	WGen(cinfo, VGA_PEL_MSK, 0xff);	/* Pixel mask: no mask 
*/
 
 	if (cinfo->btype != BT_ALPINE && cinfo->btype != BT_GD5480)
-		WGen (cinfo, VGA_MIS_W, 0xc3);	/* polarity (-/-), 
enable display mem, VGA_CRTC_START_HI i/o base = color */
+	/* polarity (-/-), enable display mem,
+	 * VGA_CRTC_START_HI i/o base = color
+	 */
+		WGen(cinfo, VGA_MIS_W, 0xc3);
 
-	vga_wgfx (cinfo->regbase, CL_GR31, 0x04);	/* BLT 
Start/status: Blitter reset */
-	vga_wgfx (cinfo->regbase, CL_GR31, 0x00);	/* - " -      
     : "end-of-reset" */
+	/* BLT Start/status: Blitter reset */
+	vga_wgfx(cinfo->regbase, CL_GR31, 0x04);
+	/* - " -	   : "end-of-reset" */
+	vga_wgfx(cinfo->regbase, CL_GR31, 0x00);
 
 	/* misc... */
-	WHDR (cinfo, 0);	/* Hidden DAC register: - */
+	WHDR(cinfo, 0);	/* Hidden DAC register: - */
 
-	printk (KERN_DEBUG "cirrusfb: This board has %ld bytes of 
DRAM memory\n", cinfo->size);
-	DPRINTK ("EXIT\n");
+	printk(KERN_DEBUG "cirrusfb: This board has %ld bytes of 
DRAM memory\n",
+		cinfo->size);
+	DPRINTK("EXIT\n");
 	return;
 }
 
-static void switch_monitor (struct cirrusfb_info *cinfo, int on)
+static void switch_monitor(struct cirrusfb_info *cinfo, int on)
 {
 #ifdef CONFIG_ZORRO /* only works on Zorro boards */
 	static int IsOn = 0;	/* XXX not ok for multiple boards 
*/
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (cinfo->btype == BT_PICASSO4)
 		return;		/* nothing to switch */
@@ -1963,44 +2109,43 @@ static void switch_monitor (struct cirru
 		return;		/* nothing to switch */
 	if (cinfo->btype == BT_PICASSO) {
 		if ((on && !IsOn) || (!on && IsOn))
-			WSFR (cinfo, 0xff);
+			WSFR(cinfo, 0xff);
 
-		DPRINTK ("EXIT\n");
+		DPRINTK("EXIT\n");
 		return;
 	}
 	if (on) {
 		switch (cinfo->btype) {
 		case BT_SD64:
-			WSFR (cinfo, cinfo->SFR | 0x21);
+			WSFR(cinfo, cinfo->SFR | 0x21);
 			break;
 		case BT_PICCOLO:
-			WSFR (cinfo, cinfo->SFR | 0x28);
+			WSFR(cinfo, cinfo->SFR | 0x28);
 			break;
 		case BT_SPECTRUM:
-			WSFR (cinfo, 0x6f);
+			WSFR(cinfo, 0x6f);
 			break;
 		default: /* do nothing */ break;
 		}
 	} else {
 		switch (cinfo->btype) {
 		case BT_SD64:
-			WSFR (cinfo, cinfo->SFR & 0xde);
+			WSFR(cinfo, cinfo->SFR & 0xde);
 			break;
 		case BT_PICCOLO:
-			WSFR (cinfo, cinfo->SFR & 0xd7);
+			WSFR(cinfo, cinfo->SFR & 0xd7);
 			break;
 		case BT_SPECTRUM:
-			WSFR (cinfo, 0x4f);
+			WSFR(cinfo, 0x4f);
 			break;
 		default: /* do nothing */ break;
 		}
 	}
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 #endif /* CONFIG_ZORRO */
 }
 
-
 /******************************************/
 /* Linux 2.6-style  accelerated functions */
 /******************************************/
@@ -2012,15 +2157,17 @@ static void cirrusfb_prim_fillrect(struc
 	u32 color = (cinfo->info->fix.visual == 
FB_VISUAL_TRUECOLOR) ?
 		cinfo->pseudo_palette[region->color] : region->color;
 
-	if(cinfo->info->var.bits_per_pixel == 1) {
-		cirrusfb_RectFill(cinfo->regbase, cinfo->info->var.
bits_per_pixel,
+	if (cinfo->info->var.bits_per_pixel == 1) {
+		cirrusfb_RectFill(cinfo->regbase,
+				  cinfo->info->var.bits_per_pixel,
 				  region->dx / 8, region->dy,
 				  region->width / 8, region->height,
 				  color,
 				  cinfo->currentmode.line_length);
 	} else {
-		m = ( cinfo->info->var.bits_per_pixel + 7 ) / 8;
-		cirrusfb_RectFill(cinfo->regbase, cinfo->info->var.
bits_per_pixel,
+		m = (cinfo->info->var.bits_per_pixel + 7) / 8;
+		cirrusfb_RectFill(cinfo->regbase,
+				  cinfo->info->var.bits_per_pixel,
 				  region->dx * m, region->dy,
 				  region->width * m, region->height,
 				  color,
@@ -2029,7 +2176,8 @@ static void cirrusfb_prim_fillrect(struc
 	return;
 }
 
-static void cirrusfb_fillrect (struct fb_info *info, const 
struct fb_fillrect *region)
+static void cirrusfb_fillrect(struct fb_info *info,
+			      const struct fb_fillrect *region)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_fillrect modded;
@@ -2047,12 +2195,14 @@ static void cirrusfb_fillrect (struct fb
 
 	memcpy(&modded, region, sizeof(struct fb_fillrect));
 
-	if(!modded.width || !modded.height ||
+	if (!modded.width || !modded.height ||
 	   modded.dx >= vxres || modded.dy >= vyres)
 		return;
 
-	if(modded.dx + modded.width  > vxres) modded.width  = vxres 
- modded.dx;
-	if(modded.dy + modded.height > vyres) modded.height = vyres 
- modded.dy;
+	if (modded.dx + modded.width  > vxres)
+		modded.width  = vxres - modded.dx;
+	if (modded.dy + modded.height > vyres)
+		modded.height = vyres - modded.dy;
 
 	cirrusfb_prim_fillrect(cinfo, &modded);
 }
@@ -2061,14 +2211,14 @@ static void cirrusfb_prim_copyarea(struc
 				   const struct fb_copyarea *area)
 {
 	int m; /* bytes per pixel */
-	if(cinfo->info->var.bits_per_pixel == 1) {
+	if (cinfo->info->var.bits_per_pixel == 1) {
 		cirrusfb_BitBLT(cinfo->regbase, cinfo->info->var.
bits_per_pixel,
 				area->sx / 8, area->sy,
 				area->dx / 8, area->dy,
 				area->width / 8, area->height,
 				cinfo->currentmode.line_length);
 	} else {
-		m = ( cinfo->info->var.bits_per_pixel + 7 ) / 8;
+		m = (cinfo->info->var.bits_per_pixel + 7) / 8;
 		cirrusfb_BitBLT(cinfo->regbase, cinfo->info->var.
bits_per_pixel,
 				area->sx * m, area->sy,
 				area->dx * m, area->dy,
@@ -2078,8 +2228,8 @@ static void cirrusfb_prim_copyarea(struc
 	return;
 }
 
-
-static void cirrusfb_copyarea(struct fb_info *info, const struct 
fb_copyarea *area)
+static void cirrusfb_copyarea(struct fb_info *info,
+			      const struct fb_copyarea *area)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_copyarea modded;
@@ -2101,89 +2251,99 @@ static void cirrusfb_copyarea(struct fb_
 	vxres = info->var.xres_virtual;
 	vyres = info->var.yres_virtual;
 
-	if(!modded.width || !modded.height ||
+	if (!modded.width || !modded.height ||
 	   modded.sx >= vxres || modded.sy >= vyres ||
 	   modded.dx >= vxres || modded.dy >= vyres)
 		return;
 
-	if(modded.sx + modded.width > vxres)  modded.width = vxres 
- modded.sx;
-	if(modded.dx + modded.width > vxres)  modded.width = vxres 
- modded.dx;
-	if(modded.sy + modded.height > vyres) modded.height = vyres 
- modded.sy;
-	if(modded.dy + modded.height > vyres) modded.height = vyres 
- modded.dy;
+	if (modded.sx + modded.width > vxres)
+		modded.width = vxres - modded.sx;
+	if (modded.dx + modded.width > vxres)
+		modded.width = vxres - modded.dx;
+	if (modded.sy + modded.height > vyres)
+		modded.height = vyres - modded.sy;
+	if (modded.dy + modded.height > vyres)
+		modded.height = vyres - modded.dy;
 
 	cirrusfb_prim_copyarea(cinfo, &modded);
 }
 
-static void cirrusfb_imageblit(struct fb_info *info, const 
struct fb_image *image)
+static void cirrusfb_imageblit(struct fb_info *info,
+			       const struct fb_image *image)
 {
 	struct cirrusfb_info *cinfo = info->par;
 
-        cirrusfb_WaitBLT(cinfo->regbase);
+	cirrusfb_WaitBLT(cinfo->regbase);
 	cfb_imageblit(info, image);
 }
 
-
 #ifdef CONFIG_PPC_PREP
 #define PREP_VIDEO_BASE ((volatile unsigned long) 0xC0000000)
 #define PREP_IO_BASE    ((volatile unsigned char *) 0x80000000)
-static void get_prep_addrs (unsigned long *display, unsigned 
long *registers)
+static void get_prep_addrs(unsigned long *display, unsigned long 
*registers)
 {
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	*display = PREP_VIDEO_BASE;
 	*registers = (unsigned long) PREP_IO_BASE;
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 #endif				/* CONFIG_PPC_PREP */
 
-
 #ifdef CONFIG_PCI
-static int release_io_ports = 0;
+static int release_io_ports;
 
 /* Pulled the logic from XFree86 Cirrus driver to get the memory 
size,
  * based on the DRAM bandwidth bit and DRAM bank switching bit.  
This
  * works with 1MB, 2MB and 4MB configurations (which the 
Motorola boards
  * seem to have. */
-static unsigned int cirrusfb_get_memsize (u8 __iomem *regbase)
+static unsigned int cirrusfb_get_memsize(u8 __iomem *regbase)
 {
 	unsigned long mem;
 	unsigned char SRF;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	SRF = vga_rseq (regbase, CL_SEQRF);
+	SRF = vga_rseq(regbase, CL_SEQRF);
 	switch ((SRF & 0x18)) {
-	    case 0x08: mem = 512 * 1024; break;
-	    case 0x10: mem = 1024 * 1024; break;
-		/* 64-bit DRAM data bus width; assume 2MB. Also 
indicates 2MB memory
-		   * on the 5430. */
-	    case 0x18: mem = 2048 * 1024; break;
-	    default: printk ("CLgenfb: Unknown memory size!\n");
+	case 0x08:
+		mem = 512 * 1024;
+		break;
+	case 0x10:
+		mem = 1024 * 1024;
+		break;
+	/* 64-bit DRAM data bus width; assume 2MB. Also indicates 
2MB memory
+	 * on the 5430.
+	 */
+	case 0x18:
+		mem = 2048 * 1024;
+		break;
+	default:
+		printk(KERN_WARNING "CLgenfb: Unknown memory size!\n");
 		mem = 1024 * 1024;
 	}
-	if (SRF & 0x80) {
-		/* If DRAM bank switching is enabled, there must be 
twice as much
-		   * memory installed. (4MB on the 5434) */
+	if (SRF & 0x80)
+	/* If DRAM bank switching is enabled, there must be twice 
as much
+	 * memory installed. (4MB on the 5434)
+	 */
 		mem *= 2;
-	}
+
 	/* TODO: Handling of GD5446/5480 (see XF86 sources ...) */
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 	return mem;
 }
 
-
-
-static void get_pci_addrs (const struct pci_dev *pdev,
-			   unsigned long *display, unsigned long *registers)
+static void get_pci_addrs(const struct pci_dev *pdev,
+			  unsigned long *display, unsigned long *registers)
 {
-	assert (pdev != NULL);
-	assert (display != NULL);
-	assert (registers != NULL);
+	assert(pdev != NULL);
+	assert(display != NULL);
+	assert(registers != NULL);
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	*display = 0;
 	*registers = 0;
@@ -2198,13 +2358,12 @@ static void get_pci_addrs (const struct 
 		*registers = pci_resource_start(pdev, 1);
 	}
 
-	assert (*display != 0);
+	assert(*display != 0);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
-static void cirrusfb_pci_unmap (struct cirrusfb_info *cinfo)
+static void cirrusfb_pci_unmap(struct cirrusfb_info *cinfo)
 {
 	struct pci_dev *pdev = cinfo->pdev;
 
@@ -2219,19 +2378,18 @@ static void cirrusfb_pci_unmap (struct c
 }
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
-static void __devexit cirrusfb_zorro_unmap (struct cirrusfb_info 
*cinfo)
+static void __devexit cirrusfb_zorro_unmap(struct cirrusfb_info 
*cinfo)
 {
 	zorro_release_device(cinfo->zdev);
 
 	if (cinfo->btype == BT_PICASSO4) {
 		cinfo->regbase -= 0x600000;
-		iounmap ((void *)cinfo->regbase);
-		iounmap ((void *)cinfo->fbmem);
+		iounmap((void *)cinfo->regbase);
+		iounmap((void *)cinfo->fbmem);
 	} else {
 		if (zorro_resource_start(cinfo->zdev) > 0x01000000)
-			iounmap ((void *)cinfo->fbmem);
+			iounmap((void *)cinfo->fbmem);
 	}
 	framebuffer_release(cinfo->info);
 }
@@ -2267,7 +2425,8 @@ static int cirrusfb_set_fbinfo(struct ci
 	/* monochrome: only 1 memory plane */
 	/* 8 bit and above: Use whole memory area */
 	info->fix.smem_start = cinfo->fbmem_phys;
-	info->fix.smem_len   = (var->bits_per_pixel == 1) ? 
cinfo->size / 4 : cinfo->size;
+	info->fix.smem_len   =
+		(var->bits_per_pixel == 1) ? cinfo->size / 4 : 
cinfo->size;
 	info->fix.type       = cinfo->currentmode.type;
 	info->fix.type_aux   = 0;
 	info->fix.visual     = cinfo->currentmode.visual;
@@ -2292,17 +2451,18 @@ static int cirrusfb_register(struct cirr
 	int err;
 	cirrusfb_board_t btype;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	printk (KERN_INFO "cirrusfb: Driver for Cirrus Logic based 
graphic boards, v" CIRRUSFB_VERSION "\n");
+	printk(KERN_INFO "cirrusfb: Driver for Cirrus Logic based "
+		"graphic boards, v" CIRRUSFB_VERSION "\n");
 
 	info = cinfo->info;
 	btype = cinfo->btype;
 
 	/* sanity checks */
-	assert (btype != BT_NONE);
+	assert(btype != BT_NONE);
 
-	DPRINTK ("cirrusfb: (RAM start set to: 0x%p)\n", 
cinfo->fbmem);
+	DPRINTK("cirrusfb: (RAM start set to: 0x%p)\n", 
cinfo->fbmem);
 
 	/* Make pretend we've set the var so our structures are in 
a "good" */
 	/* state, even though we haven't written the mode to the hw 
yet...  */
@@ -2321,11 +2481,12 @@ static int cirrusfb_register(struct cirr
 
 	err = register_framebuffer(info);
 	if (err < 0) {
-		printk (KERN_ERR "cirrusfb: could not register fb 
device; err = %d!\n", err);
+		printk(KERN_ERR "cirrusfb: could not register "
+			"fb device; err = %d!\n", err);
 		goto err_dealloc_cmap;
 	}
 
-	DPRINTK ("EXIT, returning 0\n");
+	DPRINTK("EXIT, returning 0\n");
 	return 0;
 
 err_dealloc_cmap:
@@ -2335,24 +2496,23 @@ err_unmap_cirrusfb:
 	return err;
 }
 
-static void __devexit cirrusfb_cleanup (struct fb_info *info)
+static void __devexit cirrusfb_cleanup(struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	switch_monitor (cinfo, 0);
+	switch_monitor(cinfo, 0);
 
-	unregister_framebuffer (info);
-	fb_dealloc_cmap (&info->cmap);
-	printk ("Framebuffer unregistered\n");
+	unregister_framebuffer(info);
+	fb_dealloc_cmap(&info->cmap);
+	printk("Framebuffer unregistered\n");
 	cinfo->unmap(cinfo);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 #ifdef CONFIG_PCI
-static int cirrusfb_pci_register (struct pci_dev *pdev,
+static int cirrusfb_pci_register(struct pci_dev *pdev,
 				  const struct pci_device_id *ent)
 {
 	struct cirrusfb_info *cinfo;
@@ -2379,31 +2539,34 @@ static int cirrusfb_pci_register (struct
 	cinfo->pdev = pdev;
 	cinfo->btype = btype = (cirrusfb_board_t) ent->driver_data;
 
-	DPRINTK (" Found PCI device, base address 0 is 0x%lx, btype 
set to %d\n",
+	DPRINTK(" Found PCI device, base address 0 is 0x%lx, btype 
set to %d\n",
 		pdev->resource[0].start, btype);
-	DPRINTK (" base address 1 is 0x%lx\n", pdev->resource[1].
start);
+	DPRINTK(" base address 1 is 0x%lx\n", pdev->resource[1].
start);
 
-	if(isPReP) {
-		pci_write_config_dword (pdev, PCI_BASE_ADDRESS_0, 
0x00000000);
+	if (isPReP) {
+		pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, 
0x00000000);
 #ifdef CONFIG_PPC_PREP
-		get_prep_addrs (&board_addr, &cinfo->fbregs_phys);
+		get_prep_addrs(&board_addr, &cinfo->fbregs_phys);
 #endif
-		/* PReP dies if we ioremap the IO registers, but it 
works w/out... */
+	/* PReP dies if we ioremap the IO registers, but it works 
w/out... */
 		cinfo->regbase = (char __iomem *) cinfo->fbregs_phys;
 	} else {
-		DPRINTK ("Attempt to get PCI info for Cirrus Graphics 
Card\n");
-		get_pci_addrs (pdev, &board_addr, &cinfo->fbregs_phys);
-		cinfo->regbase = NULL;		/* FIXME: this forces VGA. 
 alternatives? */
+		DPRINTK("Attempt to get PCI info for Cirrus Graphics 
Card\n");
+		get_pci_addrs(pdev, &board_addr, &cinfo->fbregs_phys);
+		/* FIXME: this forces VGA.  alternatives? */
+		cinfo->regbase = NULL;
 	}
 
-	DPRINTK ("Board address: 0x%lx, register address: 0x%lx\n", 
board_addr, cinfo->fbregs_phys);
+	DPRINTK("Board address: 0x%lx, register address: 0x%lx\n",
+		board_addr, cinfo->fbregs_phys);
 
 	board_size = (btype == BT_GD5480) ?
-		32 * MB_ : cirrusfb_get_memsize (cinfo->regbase);
+		32 * MB_ : cirrusfb_get_memsize(cinfo->regbase);
 
 	ret = pci_request_regions(pdev, "cirrusfb");
-	if (ret <0) {
-		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, 
abort\n",
+	if (ret < 0) {
+		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, 
"
+		       "abort\n",
 		       board_addr);
 		goto err_release_fb;
 	}
@@ -2429,8 +2592,9 @@ static int cirrusfb_pci_register (struct
 	cinfo->size = board_size;
 	cinfo->unmap = cirrusfb_pci_unmap;
 
-	printk (" RAM (%lu kB) at 0xx%lx, ", cinfo->size / KB_, 
board_addr);
-	printk ("Cirrus Logic chipset on PCI bus\n");
+	printk(KERN_INFO " RAM (%lu kB) at 0xx%lx, ",
+		cinfo->size / KB_, board_addr);
+	printk(KERN_INFO "Cirrus Logic chipset on PCI bus\n");
 	pci_set_drvdata(pdev, info);
 
 	ret = cirrusfb_register(cinfo);
@@ -2453,14 +2617,14 @@ err_out:
 	return ret;
 }
 
-static void __devexit cirrusfb_pci_unregister (struct pci_dev 
*pdev)
+static void __devexit cirrusfb_pci_unregister(struct pci_dev 
*pdev)
 {
 	struct fb_info *info = pci_get_drvdata(pdev);
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	cirrusfb_cleanup (info);
+	cirrusfb_cleanup(info);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 static struct pci_driver cirrusfb_pci_driver = {
@@ -2477,7 +2641,6 @@ static struct pci_driver cirrusfb_pci_dr
 };
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
 static int cirrusfb_zorro_register(struct zorro_dev *z,
 				   const struct zorro_device_id *ent)
@@ -2498,7 +2661,7 @@ static int cirrusfb_zorro_register(struc
 
 	info = framebuffer_alloc(sizeof(struct cirrusfb_info), 
&z->dev);
 	if (!info) {
-		printk (KERN_ERR "cirrusfb: could not allocate 
memory\n");
+		printk(KERN_ERR "cirrusfb: could not allocate memory\n")
;
 		ret = -ENOMEM;
 		goto err_out;
 	}
@@ -2507,9 +2670,9 @@ static int cirrusfb_zorro_register(struc
 	cinfo->info = info;
 	cinfo->btype = btype;
 
-	assert (z > 0);
-	assert (z2 >= 0);
-	assert (btype != BT_NONE);
+	assert(z > 0);
+	assert(z2 >= 0);
+	assert(btype != BT_NONE);
 
 	cinfo->zdev = z;
 	board_addr = zorro_resource_start(z);
@@ -2517,55 +2680,59 @@ static int cirrusfb_zorro_register(struc
 	cinfo->size = size;
 
 	if (!zorro_request_device(z, "cirrusfb")) {
-		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, 
abort\n",
+		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, 
"
+		       "abort\n",
 		       board_addr);
 		ret = -EBUSY;
 		goto err_release_fb;
 	}
 
-	printk (" RAM (%lu MB) at $%lx, ", board_size / MB_, 
board_addr);
+	printk(" RAM (%lu MB) at $%lx, ", board_size / MB_, 
board_addr);
 
 	ret = -EIO;
 
 	if (btype == BT_PICASSO4) {
-		printk (" REG at $%lx\n", board_addr + 0x600000);
+		printk(KERN_INFO " REG at $%lx\n", board_addr + 
0x600000);
 
 		/* To be precise, for the P4 this is not the */
 		/* begin of the board, but the begin of RAM. */
 		/* for P4, map in its address space in 2 chunks (### 
TEST! ) */
 		/* (note the ugly hardcoded 16M number) */
-		cinfo->regbase = ioremap (board_addr, 16777216);
+		cinfo->regbase = ioremap(board_addr, 16777216);
 		if (!cinfo->regbase)
 			goto err_release_region;
 
-		DPRINTK ("cirrusfb: Virtual address for board set to: $%
p\n", cinfo->regbase);
+		DPRINTK("cirrusfb: Virtual address for board set to: $%
p\n",
+			cinfo->regbase);
 		cinfo->regbase += 0x600000;
 		cinfo->fbregs_phys = board_addr + 0x600000;
 
 		cinfo->fbmem_phys = board_addr + 16777216;
-		cinfo->fbmem = ioremap (cinfo->fbmem_phys, 16777216);
+		cinfo->fbmem = ioremap(cinfo->fbmem_phys, 16777216);
 		if (!cinfo->fbmem)
 			goto err_unmap_regbase;
 	} else {
-		printk (" REG at $%lx\n", (unsigned long) z2->resource.
start);
+		printk(KERN_INFO " REG at $%lx\n",
+			(unsigned long) z2->resource.start);
 
 		cinfo->fbmem_phys = board_addr;
 		if (board_addr > 0x01000000)
-			cinfo->fbmem = ioremap (board_addr, board_size);
+			cinfo->fbmem = ioremap(board_addr, board_size);
 		else
-			cinfo->fbmem = (caddr_t) ZTWO_VADDR (board_addr);
+			cinfo->fbmem = (caddr_t) ZTWO_VADDR(board_addr);
 		if (!cinfo->fbmem)
 			goto err_release_region;
 
 		/* set address for REG area of board */
-		cinfo->regbase = (caddr_t) ZTWO_VADDR (z2->resource.
start);
+		cinfo->regbase = (caddr_t) ZTWO_VADDR(z2->resource.
start);
 		cinfo->fbregs_phys = z2->resource.start;
 
-		DPRINTK ("cirrusfb: Virtual address for board set to: $%
p\n", cinfo->regbase);
+		DPRINTK("cirrusfb: Virtual address for board set to: $%
p\n",
+			cinfo->regbase);
 	}
 	cinfo->unmap = cirrusfb_zorro_unmap;
 
-	printk (KERN_INFO "Cirrus Logic chipset on Zorro bus\n");
+	printk(KERN_INFO "Cirrus Logic chipset on Zorro bus\n");
 	zorro_set_drvdata(z, info);
 
 	ret = cirrusfb_register(cinfo);
@@ -2592,11 +2759,11 @@ err_out:
 void __devexit cirrusfb_zorro_unregister(struct zorro_dev *z)
 {
 	struct fb_info *info = zorro_get_drvdata(z);
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	cirrusfb_cleanup (info);
+	cirrusfb_cleanup(info);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 static struct zorro_driver cirrusfb_zorro_driver = {
@@ -2628,26 +2795,24 @@ static int __init cirrusfb_init(void)
 	return error;
 }
 
-
-
 #ifndef MODULE
 static int __init cirrusfb_setup(char *options) {
 	char *this_opt, s[32];
 	int i;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (!options || !*options)
 		return 0;
 
-	while ((this_opt = strsep (&options, ",")) != NULL) {	
+	while ((this_opt = strsep(&options, ",")) != NULL) {
 		if (!*this_opt) continue;
 
 		DPRINTK("cirrusfb_setup: option '%s'\n", this_opt);
 
 		for (i = 0; i < NUM_TOTAL_MODES; i++) {
-			sprintf (s, "mode:%s", cirrusfb_predefined[i].name);
-			if (strcmp (this_opt, s) == 0)
+			sprintf(s, "mode:%s", cirrusfb_predefined[i].name);
+			if (strcmp(this_opt, s) == 0)
 				cirrusfb_def_mode = i;
 		}
 		if (!strcmp(this_opt, "noaccel"))
@@ -2657,7 +2822,6 @@ static int __init cirrusfb_setup(char *o
 }
 #endif
 
-
     /*
      *  Modularization
      */
@@ -2666,7 +2830,7 @@ MODULE_AUTHOR("Copyright 1999,2000 Jeff 
 MODULE_DESCRIPTION("Accelerated FBDev driver for Cirrus Logic 
chips");
 MODULE_LICENSE("GPL");
 
-static void __exit cirrusfb_exit (void)
+static void __exit cirrusfb_exit(void)
 {
 #ifdef CONFIG_PCI
 	pci_unregister_driver(&cirrusfb_pci_driver);
@@ -2682,66 +2846,67 @@ module_init(cirrusfb_init);
 module_exit(cirrusfb_exit);
 #endif
 
-
 
/****************************************************************
******/
 /* about the following functions - I have used the same names 
for the */
 /* functions as Markus Wild did in his Retina driver for NetBSD 
as    */
 /* they just made sense for this purpose. Apart from that, I 
wrote    */
-/* these functions myself.                                       
     */
+/* these functions myself.					    */
 
/****************************************************************
******/
 
 /*** WGen() - write into one of the external/general registers 
***/
-static void WGen (const struct cirrusfb_info *cinfo,
+static void WGen(const struct cirrusfb_info *cinfo,
 		  int regnum, unsigned char val)
 {
 	unsigned long regofs = 0;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Picasso II specific hack */
-/*              if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D 
|| regnum == CL_VSSM2) */
+/*	      if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D ||
+		  regnum == CL_VSSM2) */
 		if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D)
 			regofs = 0xfff;
 	}
 
-	vga_w (cinfo->regbase, regofs + regnum, val);
+	vga_w(cinfo->regbase, regofs + regnum, val);
 }
 
 /*** RGen() - read out one of the external/general registers 
***/
-static unsigned char RGen (const struct cirrusfb_info *cinfo, 
int regnum)
+static unsigned char RGen(const struct cirrusfb_info *cinfo, int 
regnum)
 {
 	unsigned long regofs = 0;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Picasso II specific hack */
-/*              if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D 
|| regnum == CL_VSSM2) */
+/*	      if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D ||
+		  regnum == CL_VSSM2) */
 		if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D)
 			regofs = 0xfff;
 	}
 
-	return vga_r (cinfo->regbase, regofs + regnum);
+	return vga_r(cinfo->regbase, regofs + regnum);
 }
 
 /*** AttrOn() - turn on VideoEnable for Attribute controller 
***/
-static void AttrOn (const struct cirrusfb_info *cinfo)
+static void AttrOn(const struct cirrusfb_info *cinfo)
 {
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	if (vga_rcrt (cinfo->regbase, CL_CRT24) & 0x80) {
+	if (vga_rcrt(cinfo->regbase, CL_CRT24) & 0x80) {
 		/* if we're just in "write value" mode, write back the 
*/
 		/* same value as before to not modify anything */
-		vga_w (cinfo->regbase, VGA_ATT_IW,
-		       vga_r (cinfo->regbase, VGA_ATT_R));
+		vga_w(cinfo->regbase, VGA_ATT_IW,
+		      vga_r(cinfo->regbase, VGA_ATT_R));
 	}
 	/* turn on video bit */
-/*      vga_w (cinfo->regbase, VGA_ATT_IW, 0x20); */
-	vga_w (cinfo->regbase, VGA_ATT_IW, 0x33);
+/*      vga_w(cinfo->regbase, VGA_ATT_IW, 0x20); */
+	vga_w(cinfo->regbase, VGA_ATT_IW, 0x33);
 
 	/* dummy write on Reg0 to be on "write index" mode next 
time */
-	vga_w (cinfo->regbase, VGA_ATT_IW, 0x00);
+	vga_w(cinfo->regbase, VGA_ATT_IW, 0x00);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 /*** WHDR() - write into the Hidden DAC register ***/
@@ -2750,119 +2915,115 @@ static void AttrOn (const struct 
cirrusf
  * registers of their functional group) here is a specialized 
routine for
  * accessing the HDR
  */
-static void WHDR (const struct cirrusfb_info *cinfo, unsigned 
char val)
+static void WHDR(const struct cirrusfb_info *cinfo, unsigned 
char val)
 {
 	unsigned char dummy;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Klaus' hint for correct access to HDR on some boards 
*/
 		/* first write 0 to pixel mask (3c6) */
-		WGen (cinfo, VGA_PEL_MSK, 0x00);
-		udelay (200);
+		WGen(cinfo, VGA_PEL_MSK, 0x00);
+		udelay(200);
 		/* next read dummy from pixel address (3c8) */
-		dummy = RGen (cinfo, VGA_PEL_IW);
-		udelay (200);
+		dummy = RGen(cinfo, VGA_PEL_IW);
+		udelay(200);
 	}
 	/* now do the usual stuff to access the HDR */
 
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
 
-	WGen (cinfo, VGA_PEL_MSK, val);
-	udelay (200);
+	WGen(cinfo, VGA_PEL_MSK, val);
+	udelay(200);
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* now first reset HDR access counter */
-		dummy = RGen (cinfo, VGA_PEL_IW);
-		udelay (200);
+		dummy = RGen(cinfo, VGA_PEL_IW);
+		udelay(200);
 
 		/* and at the end, restore the mask value */
 		/* ## is this mask always 0xff? */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);
-		udelay (200);
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
+		udelay(200);
 	}
 }
 
-
 /*** WSFR() - write to the "special function register" (SFR) 
***/
-static void WSFR (struct cirrusfb_info *cinfo, unsigned char 
val)
+static void WSFR(struct cirrusfb_info *cinfo, unsigned char val)
 {
 #ifdef CONFIG_ZORRO
-	assert (cinfo->regbase != NULL);
+	assert(cinfo->regbase != NULL);
 	cinfo->SFR = val;
-	z_writeb (val, cinfo->regbase + 0x8000);
+	z_writeb(val, cinfo->regbase + 0x8000);
 #endif
 }
 
 /* The Picasso has a second register for switching the monitor 
bit */
-static void WSFR2 (struct cirrusfb_info *cinfo, unsigned char 
val)
+static void WSFR2(struct cirrusfb_info *cinfo, unsigned char 
val)
 {
 #ifdef CONFIG_ZORRO
 	/* writing an arbitrary value to this one causes the 
monitor switcher */
 	/* to flip to Amiga display */
-	assert (cinfo->regbase != NULL);
+	assert(cinfo->regbase != NULL);
 	cinfo->SFR = val;
-	z_writeb (val, cinfo->regbase + 0x9000);
+	z_writeb(val, cinfo->regbase + 0x9000);
 #endif
 }
 
-
 /*** WClut - set CLUT entry (range: 0..63) ***/
-static void WClut (struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char red,
+static void WClut(struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char red,
 	    unsigned char green, unsigned char blue)
 {
 	unsigned int data = VGA_PEL_D;
 
 	/* address write mode register is not translated.. */
-	vga_w (cinfo->regbase, VGA_PEL_IW, regnum);
+	vga_w(cinfo->regbase, VGA_PEL_IW, regnum);
 
 	if (cinfo->btype == BT_PICASSO || cinfo->btype == 
BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE || cinfo->btype == BT_GD5480) {
 		/* but DAC data register IS, at least for Picasso II */
 		if (cinfo->btype == BT_PICASSO)
 			data += 0xfff;
-		vga_w (cinfo->regbase, data, red);
-		vga_w (cinfo->regbase, data, green);
-		vga_w (cinfo->regbase, data, blue);
+		vga_w(cinfo->regbase, data, red);
+		vga_w(cinfo->regbase, data, green);
+		vga_w(cinfo->regbase, data, blue);
 	} else {
-		vga_w (cinfo->regbase, data, blue);
-		vga_w (cinfo->regbase, data, green);
-		vga_w (cinfo->regbase, data, red);
+		vga_w(cinfo->regbase, data, blue);
+		vga_w(cinfo->regbase, data, green);
+		vga_w(cinfo->regbase, data, red);
 	}
 }
 
-
 #if 0
 /*** RClut - read CLUT entry (range 0..63) ***/
-static void RClut (struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char *red,
+static void RClut(struct cirrusfb_info *cinfo, unsigned char 
regnum, unsigned char *red,
 	    unsigned char *green, unsigned char *blue)
 {
 	unsigned int data = VGA_PEL_D;
 
-	vga_w (cinfo->regbase, VGA_PEL_IR, regnum);
+	vga_w(cinfo->regbase, VGA_PEL_IR, regnum);
 
 	if (cinfo->btype == BT_PICASSO || cinfo->btype == 
BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE || cinfo->btype == BT_GD5480) {
 		if (cinfo->btype == BT_PICASSO)
 			data += 0xfff;
-		*red = vga_r (cinfo->regbase, data);
-		*green = vga_r (cinfo->regbase, data);
-		*blue = vga_r (cinfo->regbase, data);
+		*red = vga_r(cinfo->regbase, data);
+		*green = vga_r(cinfo->regbase, data);
+		*blue = vga_r(cinfo->regbase, data);
 	} else {
-		*blue = vga_r (cinfo->regbase, data);
-		*green = vga_r (cinfo->regbase, data);
-		*red = vga_r (cinfo->regbase, data);
+		*blue = vga_r(cinfo->regbase, data);
+		*green = vga_r(cinfo->regbase, data);
+		*red = vga_r(cinfo->regbase, data);
 	}
 }
 #endif
 
-
 
/****************************************************************
***
 	cirrusfb_WaitBLT()
 
@@ -2870,10 +3031,10 @@ static void RClut (struct cirrusfb_info 
 
*****************************************************************
****/
 
 /* FIXME: use interrupts instead */
-static void cirrusfb_WaitBLT (u8 __iomem *regbase)
+static void cirrusfb_WaitBLT(u8 __iomem *regbase)
 {
 	/* now busy-wait until we're done */
-	while (vga_rgfx (regbase, CL_GR31) & 0x08)
+	while (vga_rgfx(regbase, CL_GR31) & 0x08)
 		/* do nothing */ ;
 }
 
@@ -2883,15 +3044,17 @@ static void cirrusfb_WaitBLT (u8 __iomem
 	perform accelerated "scrolling"
 
*****************************************************************
***/
 
-static void cirrusfb_BitBLT (u8 __iomem *regbase, int 
bits_per_pixel,
-			     u_short curx, u_short cury, u_short destx, u_short 
desty,
-			     u_short width, u_short height, u_short 
line_length)
+static void cirrusfb_BitBLT(u8 __iomem *regbase, int 
bits_per_pixel,
+			    u_short curx, u_short cury,
+			    u_short destx, u_short desty,
+			    u_short width, u_short height,
+			    u_short line_length)
 {
 	u_short nwidth, nheight;
 	u_long nsrc, ndest;
 	u_char bltmode;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	nwidth = width - 1;
 	nheight = height - 1;
@@ -2911,9 +3074,13 @@ static void cirrusfb_BitBLT (u8 __iomem 
 		nsrc = (cury * line_length) + curx;
 		ndest = (desty * line_length) + destx;
 	} else {
-		/* this means start addresses are at the end, counting 
backwards */
-		nsrc = cury * line_length + curx + nheight * line_length 
+ nwidth;
-		ndest = desty * line_length + destx + nheight * 
line_length + nwidth;
+		/* this means start addresses are at the end,
+		 * counting backwards
+		 */
+		nsrc = cury * line_length + curx +
+			nheight * line_length + nwidth;
+		ndest = desty * line_length + destx +
+			nheight * line_length + nwidth;
 	}
 
 	/*
@@ -2929,52 +3096,65 @@ static void cirrusfb_BitBLT (u8 __iomem 
 	   start/stop
 	 */
 
-        cirrusfb_WaitBLT(regbase);
+	cirrusfb_WaitBLT(regbase);
 
 	/* pitch: set to line_length */
-	vga_wgfx (regbase, CL_GR24, line_length & 0xff);	/* 
dest pitch low */
-	vga_wgfx (regbase, CL_GR25, (line_length >> 8));	/* 
dest pitch hi */
-	vga_wgfx (regbase, CL_GR26, line_length & 0xff);	/* 
source pitch low */
-	vga_wgfx (regbase, CL_GR27, (line_length >> 8));	/* 
source pitch hi */
+	/* dest pitch low */
+	vga_wgfx(regbase, CL_GR24, line_length & 0xff);
+	/* dest pitch hi */
+	vga_wgfx(regbase, CL_GR25, line_length >> 8);
+	/* source pitch low */
+	vga_wgfx(regbase, CL_GR26, line_length & 0xff);
+	/* source pitch hi */
+	vga_wgfx(regbase, CL_GR27, line_length >> 8);
 
 	/* BLT width: actual number of pixels - 1 */
-	vga_wgfx (regbase, CL_GR20, nwidth & 0xff);	/* BLT 
width low */
-	vga_wgfx (regbase, CL_GR21, (nwidth >> 8));	/* BLT 
width hi */
+	/* BLT width low */
+	vga_wgfx(regbase, CL_GR20, nwidth & 0xff);
+	/* BLT width hi */
+	vga_wgfx(regbase, CL_GR21, nwidth >> 8);
 
 	/* BLT height: actual number of lines -1 */
-	vga_wgfx (regbase, CL_GR22, nheight & 0xff);	/* BLT 
height low */
-	vga_wgfx (regbase, CL_GR23, (nheight >> 8));	/* BLT 
width hi */
+	/* BLT height low */
+	vga_wgfx(regbase, CL_GR22, nheight & 0xff);
+	/* BLT width hi */
+	vga_wgfx(regbase, CL_GR23, nheight >> 8);
 
 	/* BLT destination */
-	vga_wgfx (regbase, CL_GR28, (u_char) (ndest & 0xff));
	/* BLT dest low */
-	vga_wgfx (regbase, CL_GR29, (u_char) (ndest >> 8));	/* 
BLT dest mid */
-	vga_wgfx (regbase, CL_GR2A, (u_char) (ndest >> 16));	/* 
BLT dest hi */
+	/* BLT dest low */
+	vga_wgfx(regbase, CL_GR28, (u_char) (ndest & 0xff));
+	/* BLT dest mid */
+	vga_wgfx(regbase, CL_GR29, (u_char) (ndest >> 8));
+	/* BLT dest hi */
+	vga_wgfx(regbase, CL_GR2A, (u_char) (ndest >> 16));
 
 	/* BLT source */
-	vga_wgfx (regbase, CL_GR2C, (u_char) (nsrc & 0xff));	/* 
BLT src low */
-	vga_wgfx (regbase, CL_GR2D, (u_char) (nsrc >> 8));
		/* BLT src mid */
-	vga_wgfx (regbase, CL_GR2E, (u_char) (nsrc >> 16));	/* 
BLT src hi */
+	/* BLT src low */
+	vga_wgfx(regbase, CL_GR2C, (u_char) (nsrc & 0xff));
+	/* BLT src mid */
+	vga_wgfx(regbase, CL_GR2D, (u_char) (nsrc >> 8));
+	/* BLT src hi */
+	vga_wgfx(regbase, CL_GR2E, (u_char) (nsrc >> 16));
 
 	/* BLT mode */
-	vga_wgfx (regbase, CL_GR30, bltmode);	/* BLT mode */
+	vga_wgfx(regbase, CL_GR30, bltmode);	/* BLT mode */
 
 	/* BLT ROP: SrcCopy */
-	vga_wgfx (regbase, CL_GR32, 0x0d);		/* BLT ROP */
+	vga_wgfx(regbase, CL_GR32, 0x0d);	/* BLT ROP */
 
 	/* and finally: GO! */
-	vga_wgfx (regbase, CL_GR31, 0x02);		/* BLT 
Start/status */
+	vga_wgfx(regbase, CL_GR31, 0x02);	/* BLT Start/status 
*/
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 
/****************************************************************
***
 	cirrusfb_RectFill()
 
 	perform accelerated rectangle fill
 
*****************************************************************
***/
 
-static void cirrusfb_RectFill (u8 __iomem *regbase, int 
bits_per_pixel,
+static void cirrusfb_RectFill(u8 __iomem *regbase, int 
bits_per_pixel,
 		     u_short x, u_short y, u_short width, u_short height,
 		     u_char color, u_short line_length)
 {
@@ -2982,93 +3162,95 @@ static void cirrusfb_RectFill (u8 __iome
 	u_long ndest;
 	u_char op;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	nwidth = width - 1;
 	nheight = height - 1;
 
 	ndest = (y * line_length) + x;
 
-        cirrusfb_WaitBLT(regbase);
+	cirrusfb_WaitBLT(regbase);
 
 	/* pitch: set to line_length */
-	vga_wgfx (regbase, CL_GR24, line_length & 0xff);	/* 
dest pitch low */
-	vga_wgfx (regbase, CL_GR25, (line_length >> 8));	/* 
dest pitch hi */
-	vga_wgfx (regbase, CL_GR26, line_length & 0xff);	/* 
source pitch low */
-	vga_wgfx (regbase, CL_GR27, (line_length >> 8));	/* 
source pitch hi */
+	vga_wgfx(regbase, CL_GR24, line_length & 0xff);	/* dest 
pitch low */
+	vga_wgfx(regbase, CL_GR25, line_length >> 8);	/* dest 
pitch hi */
+	vga_wgfx(regbase, CL_GR26, line_length & 0xff);	/* 
source pitch low */
+	vga_wgfx(regbase, CL_GR27, line_length >> 8);	/* source 
pitch hi */
 
 	/* BLT width: actual number of pixels - 1 */
-	vga_wgfx (regbase, CL_GR20, nwidth & 0xff);	/* BLT 
width low */
-	vga_wgfx (regbase, CL_GR21, (nwidth >> 8));	/* BLT 
width hi */
+	vga_wgfx(regbase, CL_GR20, nwidth & 0xff);	/* BLT width 
low */
+	vga_wgfx(regbase, CL_GR21, nwidth >> 8);	/* BLT width 
hi */
 
 	/* BLT height: actual number of lines -1 */
-	vga_wgfx (regbase, CL_GR22, nheight & 0xff);		/* BLT 
height low */
-	vga_wgfx (regbase, CL_GR23, (nheight >> 8));		/* BLT 
width hi */
+	vga_wgfx(regbase, CL_GR22, nheight & 0xff);	/* BLT 
height low */
+	vga_wgfx(regbase, CL_GR23, nheight >> 8);	/* BLT width 
hi */
 
 	/* BLT destination */
-	vga_wgfx (regbase, CL_GR28, (u_char) (ndest & 0xff));
	/* BLT dest low */
-	vga_wgfx (regbase, CL_GR29, (u_char) (ndest >> 8));	/* 
BLT dest mid */
-	vga_wgfx (regbase, CL_GR2A, (u_char) (ndest >> 16));
		/* BLT dest hi */
+	/* BLT dest low */
+	vga_wgfx(regbase, CL_GR28, (u_char) (ndest & 0xff));
+	/* BLT dest mid */
+	vga_wgfx(regbase, CL_GR29, (u_char) (ndest >> 8));
+	/* BLT dest hi */
+	vga_wgfx(regbase, CL_GR2A, (u_char) (ndest >> 16));
 
 	/* BLT source: set to 0 (is a dummy here anyway) */
-	vga_wgfx (regbase, CL_GR2C, 0x00);	/* BLT src low */
-	vga_wgfx (regbase, CL_GR2D, 0x00);	/* BLT src mid */
-	vga_wgfx (regbase, CL_GR2E, 0x00);	/* BLT src hi */
+	vga_wgfx(regbase, CL_GR2C, 0x00);	/* BLT src low */
+	vga_wgfx(regbase, CL_GR2D, 0x00);	/* BLT src mid */
+	vga_wgfx(regbase, CL_GR2E, 0x00);	/* BLT src hi */
 
 	/* This is a ColorExpand Blt, using the */
 	/* same color for foreground and background */
-	vga_wgfx (regbase, VGA_GFX_SR_VALUE, color);	/* 
foreground color */
-	vga_wgfx (regbase, VGA_GFX_SR_ENABLE, color);	/* 
background color */
+	vga_wgfx(regbase, VGA_GFX_SR_VALUE, color);	/* 
foreground color */
+	vga_wgfx(regbase, VGA_GFX_SR_ENABLE, color);	/* 
background color */
 
 	op = 0xc0;
 	if (bits_per_pixel == 16) {
-		vga_wgfx (regbase, CL_GR10, color);	/* foreground 
color */
-		vga_wgfx (regbase, CL_GR11, color);	/* background 
color */
+		vga_wgfx(regbase, CL_GR10, color);	/* foreground 
color */
+		vga_wgfx(regbase, CL_GR11, color);	/* background 
color */
 		op = 0x50;
 		op = 0xd0;
 	} else if (bits_per_pixel == 32) {
-		vga_wgfx (regbase, CL_GR10, color);	/* foreground 
color */
-		vga_wgfx (regbase, CL_GR11, color);	/* background 
color */
-		vga_wgfx (regbase, CL_GR12, color);	/* foreground 
color */
-		vga_wgfx (regbase, CL_GR13, color);	/* background 
color */
-		vga_wgfx (regbase, CL_GR14, 0);	/* foreground color 
*/
-		vga_wgfx (regbase, CL_GR15, 0);	/* background color 
*/
+		vga_wgfx(regbase, CL_GR10, color);	/* foreground 
color */
+		vga_wgfx(regbase, CL_GR11, color);	/* background 
color */
+		vga_wgfx(regbase, CL_GR12, color);	/* foreground 
color */
+		vga_wgfx(regbase, CL_GR13, color);	/* background 
color */
+		vga_wgfx(regbase, CL_GR14, 0);	/* foreground color 
*/
+		vga_wgfx(regbase, CL_GR15, 0);	/* background color 
*/
 		op = 0x50;
 		op = 0xf0;
 	}
 	/* BLT mode: color expand, Enable 8x8 copy (faster?) */
-	vga_wgfx (regbase, CL_GR30, op);	/* BLT mode */
+	vga_wgfx(regbase, CL_GR30, op);	/* BLT mode */
 
 	/* BLT ROP: SrcCopy */
-	vga_wgfx (regbase, CL_GR32, 0x0d);	/* BLT ROP */
+	vga_wgfx(regbase, CL_GR32, 0x0d);	/* BLT ROP */
 
 	/* and finally: GO! */
-	vga_wgfx (regbase, CL_GR31, 0x02);	/* BLT Start/status 
*/
+	vga_wgfx(regbase, CL_GR31, 0x02);	/* BLT Start/status 
*/
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 
/****************************************************************
**********
  * bestclock() - determine closest possible clock lower(?) than 
the
  * desired pixel clock
  
*****************************************************************
*********/
-static void bestclock (long freq, long *best, long *nom,
+static void bestclock(long freq, long *best, long *nom,
 		       long *den, long *div, long maxfreq)
 {
 	long n, h, d, f;
 
-	assert (best != NULL);
-	assert (nom != NULL);
-	assert (den != NULL);
-	assert (div != NULL);
-	assert (maxfreq > 0);
+	assert(best != NULL);
+	assert(nom != NULL);
+	assert(den != NULL);
+	assert(div != NULL);
+	assert(maxfreq > 0);
 
 	*nom = 0;
 	*den = 0;
 	*div = 0;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (freq < 8000)
 		freq = 8000;
@@ -3085,7 +3267,7 @@ static void bestclock (long freq, long *
 			if (d > 31)
 				d = (d / 2) * 2;
 			h = (14318 * n) / d;
-			if (abs (h - freq) < abs (*best - freq)) {
+			if (abs(h - freq) < abs(*best - freq)) {
 				*best = h;
 				*nom = n;
 				if (d < 32) {
@@ -3102,7 +3284,7 @@ static void bestclock (long freq, long *
 			if (d > 31)
 				d = (d / 2) * 2;
 			h = (14318 * n) / d;
-			if (abs (h - freq) < abs (*best - freq)) {
+			if (abs(h - freq) < abs(*best - freq)) {
 				*best = h;
 				*nom = n;
 				if (d < 32) {
@@ -3116,14 +3298,13 @@ static void bestclock (long freq, long *
 		}
 	}
 
-	DPRINTK ("Best possible values for given frequency:\n");
-	DPRINTK ("        best: %ld kHz  nom: %ld  den: %ld  div: %
ld\n",
-		 freq, *nom, *den, *div);
+	DPRINTK("Best possible values for given frequency:\n");
+	DPRINTK("	best: %ld kHz  nom: %ld  den: %ld  div: %
ld\n",
+		freq, *nom, *den, *div);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 /* 
-----------------------------------------------------------------
--------
  *
  * debugging functions
@@ -3145,21 +3326,20 @@ static void bestclock (long freq, long *
  */
 
 static
-void cirrusfb_dbg_print_byte (const char *name, unsigned char 
val)
+void cirrusfb_dbg_print_byte(const char *name, unsigned char 
val)
 {
-	DPRINTK ("%8s = 0x%02X (bits 7-0: %c%c%c%c%c%c%c%c)\n",
-		 name, val,
-		 val & 0x80 ? '1' : '0',
-		 val & 0x40 ? '1' : '0',
-		 val & 0x20 ? '1' : '0',
-		 val & 0x10 ? '1' : '0',
-		 val & 0x08 ? '1' : '0',
-		 val & 0x04 ? '1' : '0',
-		 val & 0x02 ? '1' : '0',
-		 val & 0x01 ? '1' : '0');
+	DPRINTK("%8s = 0x%02X (bits 7-0: %c%c%c%c%c%c%c%c)\n",
+		name, val,
+		val & 0x80 ? '1' : '0',
+		val & 0x40 ? '1' : '0',
+		val & 0x20 ? '1' : '0',
+		val & 0x10 ? '1' : '0',
+		val & 0x08 ? '1' : '0',
+		val & 0x04 ? '1' : '0',
+		val & 0x02 ? '1' : '0',
+		val & 0x01 ? '1' : '0');
 }
 
-
 /**
  * cirrusfb_dbg_print_regs
  * @base: If using newmmio, the newmmio base address, otherwise 
%NULL
@@ -3172,25 +3352,26 @@ void cirrusfb_dbg_print_byte (const char
  */
 
 static
-void cirrusfb_dbg_print_regs (caddr_t regbase, 
cirrusfb_dbg_reg_class_t reg_class,...)
+void cirrusfb_dbg_print_regs(caddr_t regbase,
+			     cirrusfb_dbg_reg_class_t reg_class, ...)
 {
 	va_list list;
 	unsigned char val = 0;
 	unsigned reg;
 	char *name;
 
-	va_start (list, reg_class);
+	va_start(list, reg_class);
 
-	name = va_arg (list, char *);
+	name = va_arg(list, char *);
 	while (name != NULL) {
-		reg = va_arg (list, int);
+		reg = va_arg(list, int);
 
 		switch (reg_class) {
 		case CRT:
-			val = vga_rcrt (regbase, (unsigned char) reg);
+			val = vga_rcrt(regbase, (unsigned char) reg);
 			break;
 		case SEQ:
-			val = vga_rseq (regbase, (unsigned char) reg);
+			val = vga_rseq(regbase, (unsigned char) reg);
 			break;
 		default:
 			/* should never occur */
@@ -3198,15 +3379,14 @@ void cirrusfb_dbg_print_regs (caddr_t re
 			break;
 		}
 
-		cirrusfb_dbg_print_byte (name, val);
+		cirrusfb_dbg_print_byte(name, val);
 
-		name = va_arg (list, char *);
+		name = va_arg(list, char *);
 	}
 
-	va_end (list);
+	va_end(list);
 }
 
-
 /**
  * cirrusfb_dump
  * @cirrusfbinfo:
@@ -3214,13 +3394,11 @@ void cirrusfb_dbg_print_regs (caddr_t re
  * DESCRIPTION:
  */
 
-static
-void cirrusfb_dump (void)
+static void cirrusfb_dump(void)
 {
-	cirrusfb_dbg_reg_dump (NULL);
+	cirrusfb_dbg_reg_dump(NULL);
 }
 
-
 /**
  * cirrusfb_dbg_reg_dump
  * @base: If using newmmio, the newmmio base address, otherwise 
%NULL
@@ -3232,11 +3410,11 @@ void cirrusfb_dump (void)
  */
 
 static
-void cirrusfb_dbg_reg_dump (caddr_t regbase)
+void cirrusfb_dbg_reg_dump(caddr_t regbase)
 {
-	DPRINTK ("CIRRUSFB VGA CRTC register dump:\n");
+	DPRINTK("CIRRUSFB VGA CRTC register dump:\n");
 
-	cirrusfb_dbg_print_regs (regbase, CRT,
+	cirrusfb_dbg_print_regs(regbase, CRT,
 			   "CR00", 0x00,
 			   "CR01", 0x01,
 			   "CR02", 0x02,
@@ -3286,11 +3464,11 @@ void cirrusfb_dbg_reg_dump (caddr_t regb
 			   "CR3F", 0x3F,
 			   NULL);
 
-	DPRINTK ("\n");
+	DPRINTK("\n");
 
-	DPRINTK ("CIRRUSFB VGA SEQ register dump:\n");
+	DPRINTK("CIRRUSFB VGA SEQ register dump:\n");
 
-	cirrusfb_dbg_print_regs (regbase, SEQ,
+	cirrusfb_dbg_print_regs(regbase, SEQ,
 			   "SR00", 0x00,
 			   "SR01", 0x01,
 			   "SR02", 0x02,
@@ -3319,7 +3497,7 @@ void cirrusfb_dbg_reg_dump (caddr_t regb
 			   "SR1F", 0x1F,
 			   NULL);
 
-	DPRINTK ("\n");
+	DPRINTK("\n");
 }
 
 #endif				/* CIRRUSFB_DEBUG */


----------------------------------------------------
Poznaj nowego wybrańca Boga... i jego trzódkę! Rewelacyjna
komedia EVAN WSZECHMOGĄCY - w kinach od 24 sierpnia!
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fevanwszechmogacy_zwiastun.html&sid=1263

[-- Attachment #2: cirrus-cleanup.diff --]
[-- Type: application/octet-stream, Size: 115130 bytes --]

From: Krzysztof Helt <krzysztof.h1@wp.pl>

This patch fixes over 850 errors and warnings pointed
out by the checkpatch.pl script.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>

---

I run the checkpatch.pl script on the whole drivers/video
directory. The most errors are in drivers which share code
with X11 (sis, nvidia). The cirrus driver had the most errors
as a non-X11 driver.

--- linux-2.6.23.old/drivers/video/cirrusfb.c	2007-07-09 01:32:16.000000000 +0200
+++ linux-2.6.23/drivers/video/cirrusfb.c	2007-08-16 19:43:03.000000000 +0200
@@ -59,7 +59,7 @@
 #endif
 #ifdef CONFIG_PPC_PREP
 #include <asm/machdep.h>
-#define isPReP (machine_is(prep))
+#define isPReP(machine_is(prep))
 #else
 #define isPReP 0
 #endif
@@ -67,7 +67,6 @@
 #include "video/vga.h"
 #include "video/cirrus.h"
 
-
 /*****************************************************************
  *
  * debugging and utility macros
@@ -82,7 +81,8 @@
 
 /* debug output */
 #ifdef CIRRUSFB_DEBUG
-#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
+#define DPRINTK(fmt, args...) \
+	printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
 #else
 #define DPRINTK(fmt, args...)
 #endif
@@ -90,20 +90,19 @@
 /* debugging assertions */
 #ifndef CIRRUSFB_NDEBUG
 #define assert(expr) \
-        if(!(expr)) { \
-        printk( "Assertion failed! %s,%s,%s,line=%d\n",\
-        #expr,__FILE__,__FUNCTION__,__LINE__); \
-        }
+	if (!(expr)) { \
+		printk("Assertion failed! %s,%s,%s,line=%d\n", \
+		#expr, __FILE__, __FUNCTION__, __LINE__); \
+	}
 #else
 #define assert(expr)
 #endif
 
-#define MB_ (1024*1024)
+#define MB_ (1024 * 1024)
 #define KB_ (1024)
 
 #define MAX_NUM_BOARDS 7
 
-
 /*****************************************************************
  *
  * chipset information
@@ -123,7 +122,6 @@ typedef enum {
 	BT_LAGUNA,	/* GD546x */
 } cirrusfb_board_t;
 
-
 /*
  * per-board-type information, used for enumerating and abstracting
  * chip-specific information
@@ -139,7 +137,8 @@ static const struct cirrusfb_board_info_
 	/* for  1/4bpp, 8bpp 15/16bpp, 24bpp, 32bpp - numbers from xorg code */
 	bool init_sr07 : 1; /* init SR07 during init_vgachip() */
 	bool init_sr1f : 1; /* write SR1F during init_vgachip() */
-	bool scrn_start_bit19 : 1; /* construct bit 19 of screen start address */
+	/* construct bit 19 of screen start address */
+	bool scrn_start_bit19 : 1;
 
 	/* initial SR07 value, then for each mode */
 	unsigned char sr07;
@@ -261,30 +260,28 @@ static const struct cirrusfb_board_info_
 	}
 };
 
-
 #ifdef CONFIG_PCI
 #define CHIP(id, btype) \
 	{ PCI_VENDOR_ID_CIRRUS, id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (btype) }
 
 static struct pci_device_id cirrusfb_pci_table[] = {
-	CHIP( PCI_DEVICE_ID_CIRRUS_5436, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5434_8, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5434_4, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5430, BT_ALPINE ), /* GD-5440 is same id */
-	CHIP( PCI_DEVICE_ID_CIRRUS_7543, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_7548, BT_ALPINE ),
-	CHIP( PCI_DEVICE_ID_CIRRUS_5480, BT_GD5480 ), /* MacPicasso likely */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5446, BT_PICASSO4 ), /* Picasso 4 is 5446 */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5462, BT_LAGUNA ), /* CL Laguna */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5464, BT_LAGUNA ), /* CL Laguna 3D */
-	CHIP( PCI_DEVICE_ID_CIRRUS_5465, BT_LAGUNA ), /* CL Laguna 3DA*/
+	CHIP(PCI_DEVICE_ID_CIRRUS_5436, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5434_8, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5434_4, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5430, BT_ALPINE), /* GD-5440 is same id */
+	CHIP(PCI_DEVICE_ID_CIRRUS_7543, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_7548, BT_ALPINE),
+	CHIP(PCI_DEVICE_ID_CIRRUS_5480, BT_GD5480), /* MacPicasso likely */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5446, BT_PICASSO4), /* Picasso 4 is 5446 */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5462, BT_LAGUNA), /* CL Laguna */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5464, BT_LAGUNA), /* CL Laguna 3D */
+	CHIP(PCI_DEVICE_ID_CIRRUS_5465, BT_LAGUNA), /* CL Laguna 3DA*/
 	{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, cirrusfb_pci_table);
 #undef CHIP
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
 static const struct zorro_device_id cirrusfb_zorro_table[] = {
 	{
@@ -294,7 +291,7 @@ static const struct zorro_device_id cirr
 		.id		= ZORRO_PROD_HELFRICH_PICCOLO_RAM,
 		.driver_data	= BT_PICCOLO,
 	}, {
-		.id		= ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
+		.id	= ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
 		.driver_data	= BT_PICASSO,
 	}, {
 		.id		= ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_RAM,
@@ -333,7 +330,6 @@ static const struct {
 };
 #endif /* CONFIG_ZORRO */
 
-
 struct cirrusfb_regs {
 	__u32 line_length;	/* in BYTES! */
 	__u32 visual;
@@ -364,17 +360,12 @@ struct cirrusfb_regs {
 	long VertBlankEnd;
 };
 
-
-
 #ifdef CIRRUSFB_DEBUG
 typedef enum {
-        CRT,
-        SEQ
+	CRT,
+	SEQ
 } cirrusfb_dbg_reg_class_t;
-#endif                          /* CIRRUSFB_DEBUG */
-
-
-
+#endif		/* CIRRUSFB_DEBUG */
 
 /* info about board */
 struct cirrusfb_info {
@@ -405,9 +396,8 @@ struct cirrusfb_info {
 	void (*unmap)(struct cirrusfb_info *cinfo);
 };
 
-
 static unsigned cirrusfb_def_mode = 1;
-static int noaccel = 0;
+static int noaccel;
 
 /*
  *    Predefined Video Modes
@@ -441,7 +431,7 @@ static const struct {
 			.lower_margin	= 8,
 			.hsync_len	= 96,
 			.vsync_len	= 4,
-			.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+			.sync	= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
 			.vmode		= FB_VMODE_NONINTERLACED
 		 }
 	}, {
@@ -502,27 +492,29 @@ static const struct {
 /****************************************************************************/
 /**** BEGIN PROTOTYPES ******************************************************/
 
-
 /*--- Interface used by the world ------------------------------------------*/
-static int cirrusfb_init (void);
+static int cirrusfb_init(void);
 #ifndef MODULE
-static int cirrusfb_setup (char *options);
+static int cirrusfb_setup(char *options);
 #endif
 
-static int cirrusfb_open (struct fb_info *info, int user);
-static int cirrusfb_release (struct fb_info *info, int user);
-static int cirrusfb_setcolreg (unsigned regno, unsigned red, unsigned green,
-			       unsigned blue, unsigned transp,
-			       struct fb_info *info);
-static int cirrusfb_check_var (struct fb_var_screeninfo *var,
-			       struct fb_info *info);
-static int cirrusfb_set_par (struct fb_info *info);
-static int cirrusfb_pan_display (struct fb_var_screeninfo *var,
-				 struct fb_info *info);
-static int cirrusfb_blank (int blank_mode, struct fb_info *info);
-static void cirrusfb_fillrect (struct fb_info *info, const struct fb_fillrect *region);
-static void cirrusfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
-static void cirrusfb_imageblit(struct fb_info *info, const struct fb_image *image);
+static int cirrusfb_open(struct fb_info *info, int user);
+static int cirrusfb_release(struct fb_info *info, int user);
+static int cirrusfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			      unsigned blue, unsigned transp,
+			      struct fb_info *info);
+static int cirrusfb_check_var(struct fb_var_screeninfo *var,
+			      struct fb_info *info);
+static int cirrusfb_set_par(struct fb_info *info);
+static int cirrusfb_pan_display(struct fb_var_screeninfo *var,
+				struct fb_info *info);
+static int cirrusfb_blank(int blank_mode, struct fb_info *info);
+static void cirrusfb_fillrect(struct fb_info *info,
+			      const struct fb_fillrect *region);
+static void cirrusfb_copyarea(struct fb_info *info,
+			      const struct fb_copyarea *area);
+static void cirrusfb_imageblit(struct fb_info *info,
+			       const struct fb_image *image);
 
 /* function table of the above functions */
 static struct fb_ops cirrusfb_ops = {
@@ -540,68 +532,68 @@ static struct fb_ops cirrusfb_ops = {
 };
 
 /*--- Hardware Specific Routines -------------------------------------------*/
-static int cirrusfb_decode_var (const struct fb_var_screeninfo *var,
+static int cirrusfb_decode_var(const struct fb_var_screeninfo *var,
 				struct cirrusfb_regs *regs,
 				const struct fb_info *info);
 /*--- Internal routines ----------------------------------------------------*/
-static void init_vgachip (struct cirrusfb_info *cinfo);
-static void switch_monitor (struct cirrusfb_info *cinfo, int on);
-static void WGen (const struct cirrusfb_info *cinfo,
-		  int regnum, unsigned char val);
-static unsigned char RGen (const struct cirrusfb_info *cinfo, int regnum);
-static void AttrOn (const struct cirrusfb_info *cinfo);
-static void WHDR (const struct cirrusfb_info *cinfo, unsigned char val);
-static void WSFR (struct cirrusfb_info *cinfo, unsigned char val);
-static void WSFR2 (struct cirrusfb_info *cinfo, unsigned char val);
-static void WClut (struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char red,
-		   unsigned char green,
-		   unsigned char blue);
+static void init_vgachip(struct cirrusfb_info *cinfo);
+static void switch_monitor(struct cirrusfb_info *cinfo, int on);
+static void WGen(const struct cirrusfb_info *cinfo,
+		 int regnum, unsigned char val);
+static unsigned char RGen(const struct cirrusfb_info *cinfo, int regnum);
+static void AttrOn(const struct cirrusfb_info *cinfo);
+static void WHDR(const struct cirrusfb_info *cinfo, unsigned char val);
+static void WSFR(struct cirrusfb_info *cinfo, unsigned char val);
+static void WSFR2(struct cirrusfb_info *cinfo, unsigned char val);
+static void WClut(struct cirrusfb_info *cinfo, unsigned char regnum,
+		  unsigned char red, unsigned char green, unsigned char blue);
 #if 0
-static void RClut (struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char *red,
-		   unsigned char *green,
-		   unsigned char *blue);
-#endif
-static void cirrusfb_WaitBLT (u8 __iomem *regbase);
-static void cirrusfb_BitBLT (u8 __iomem *regbase, int bits_per_pixel,
-			     u_short curx, u_short cury,
-			     u_short destx, u_short desty,
-			     u_short width, u_short height,
-			     u_short line_length);
-static void cirrusfb_RectFill (u8 __iomem *regbase, int bits_per_pixel,
-			       u_short x, u_short y,
-			       u_short width, u_short height,
-			       u_char color, u_short line_length);
-
-static void bestclock (long freq, long *best,
-		       long *nom, long *den,
-		       long *div, long maxfreq);
+static void RClut(struct cirrusfb_info *cinfo, unsigned char regnum,
+		  unsigned char *red, unsigned char *green,
+		  unsigned char *blue);
+#endif
+static void cirrusfb_WaitBLT(u8 __iomem *regbase);
+static void cirrusfb_BitBLT(u8 __iomem *regbase, int bits_per_pixel,
+			    u_short curx, u_short cury,
+			    u_short destx, u_short desty,
+			    u_short width, u_short height,
+			    u_short line_length);
+static void cirrusfb_RectFill(u8 __iomem *regbase, int bits_per_pixel,
+			      u_short x, u_short y,
+			      u_short width, u_short height,
+			      u_char color, u_short line_length);
+
+static void bestclock(long freq, long *best,
+		      long *nom, long *den,
+		      long *div, long maxfreq);
 
 #ifdef CIRRUSFB_DEBUG
-static void cirrusfb_dump (void);
-static void cirrusfb_dbg_reg_dump (caddr_t regbase);
-static void cirrusfb_dbg_print_regs (caddr_t regbase, cirrusfb_dbg_reg_class_t reg_class,...);
-static void cirrusfb_dbg_print_byte (const char *name, unsigned char val);
+static void cirrusfb_dump(void);
+static void cirrusfb_dbg_reg_dump(caddr_t regbase);
+static void cirrusfb_dbg_print_regs(caddr_t regbase,
+				    cirrusfb_dbg_reg_class_t reg_class, ...);
+static void cirrusfb_dbg_print_byte(const char *name, unsigned char val);
 #endif /* CIRRUSFB_DEBUG */
 
 /*** END   PROTOTYPES ********************************************************/
 /*****************************************************************************/
 /*** BEGIN Interface Used by the World ***************************************/
 
-static int opencount = 0;
+static int opencount;
 
 /*--- Open /dev/fbx ---------------------------------------------------------*/
-static int cirrusfb_open (struct fb_info *info, int user)
+static int cirrusfb_open(struct fb_info *info, int user)
 {
 	if (opencount++ == 0)
-		switch_monitor (info->par, 1);
+		switch_monitor(info->par, 1);
 	return 0;
 }
 
 /*--- Close /dev/fbx --------------------------------------------------------*/
-static int cirrusfb_release (struct fb_info *info, int user)
+static int cirrusfb_release(struct fb_info *info, int user)
 {
 	if (--opencount == 0)
-		switch_monitor (info->par, 0);
+		switch_monitor(info->par, 0);
 	return 0;
 }
 
@@ -610,11 +602,11 @@ static int cirrusfb_release (struct fb_i
 /**** BEGIN Hardware specific Routines **************************************/
 
 /* Get a good MCLK value */
-static long cirrusfb_get_mclk (long freq, int bpp, long *div)
+static long cirrusfb_get_mclk(long freq, int bpp, long *div)
 {
 	long mclk;
 
-	assert (div != NULL);
+	assert(div != NULL);
 
 	/* Calculate MCLK, in case VCLK is high enough to require > 50MHz.
 	 * Assume a 64-bit data path for now.  The formula is:
@@ -624,23 +616,23 @@ static long cirrusfb_get_mclk (long freq
 	mclk = (mclk * 12) / 10;
 	if (mclk < 50000)
 		mclk = 50000;
-	DPRINTK ("Use MCLK of %ld kHz\n", mclk);
+	DPRINTK("Use MCLK of %ld kHz\n", mclk);
 
 	/* Calculate value for SR1F.  Multiply by 2 so we can round up. */
 	mclk = ((mclk * 16) / 14318);
 	mclk = (mclk + 1) / 2;
-	DPRINTK ("Set SR1F[5:0] to 0x%lx\n", mclk);
+	DPRINTK("Set SR1F[5:0] to 0x%lx\n", mclk);
 
 	/* Determine if we should use MCLK instead of VCLK, and if so, what we
 	   * should divide it by to get VCLK */
 	switch (freq) {
 	case 24751 ... 25249:
 		*div = 2;
-		DPRINTK ("Using VCLK = MCLK/2\n");
+		DPRINTK("Using VCLK = MCLK/2\n");
 		break;
 	case 49501 ... 50499:
 		*div = 1;
-		DPRINTK ("Using VCLK = MCLK\n");
+		DPRINTK("Using VCLK = MCLK\n");
 		break;
 	default:
 		*div = 0;
@@ -691,37 +683,42 @@ static int cirrusfb_check_var(struct fb_
 		den = 1;
 		break;		/* 4 bytes per pixel */
 	default:
-		printk ("cirrusfb: mode %dx%dx%d rejected...color depth not supported.\n",
+		printk(KERN_ERR "cirrusfb: mode %dx%dx%d rejected..."
+			"color depth not supported.\n",
 			var->xres, var->yres, var->bits_per_pixel);
-		DPRINTK ("EXIT - EINVAL error\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	if (var->xres * nom / den * var->yres > cinfo->size) {
-		printk ("cirrusfb: mode %dx%dx%d rejected...resolution too high to fit into video memory!\n",
+		printk(KERN_ERR "cirrusfb: mode %dx%dx%d rejected..."
+			"resolution too high to fit into video memory!\n",
 			var->xres, var->yres, var->bits_per_pixel);
-		DPRINTK ("EXIT - EINVAL error\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	/* use highest possible virtual resolution */
 	if (var->xres_virtual == -1 &&
 	    var->yres_virtual == -1) {
-		printk ("cirrusfb: using maximum available virtual resolution\n");
+		printk(KERN_INFO
+		     "cirrusfb: using maximum available virtual resolution\n");
 		for (i = 0; modes[i].xres != -1; i++) {
 			if (modes[i].xres * nom / den * modes[i].yres < cinfo->size / 2)
 				break;
 		}
 		if (modes[i].xres == -1) {
-			printk ("cirrusfb: could not find a virtual resolution that fits into video memory!!\n");
-			DPRINTK ("EXIT - EINVAL error\n");
+			printk(KERN_ERR "cirrusfb: could not find a virtual "
+				"resolution that fits into video memory!!\n");
+			DPRINTK("EXIT - EINVAL error\n");
 			return -EINVAL;
 		}
 		var->xres_virtual = modes[i].xres;
 		var->yres_virtual = modes[i].yres;
 
-		printk ("cirrusfb: virtual resolution set to maximum of %dx%d\n",
-			var->xres_virtual, var->yres_virtual);
+		printk(KERN_INFO "cirrusfb: virtual resolution set to "
+			"maximum of %dx%d\n", var->xres_virtual,
+			var->yres_virtual);
 	}
 
 	if (var->xres_virtual < var->xres)
@@ -760,7 +757,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 16:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 2;
 			var->green.offset = -3;
 			var->blue.offset = 8;
@@ -775,7 +772,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 24:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 8;
 			var->green.offset = 16;
 			var->blue.offset = 24;
@@ -790,7 +787,7 @@ static int cirrusfb_check_var(struct fb_
 		break;
 
 	case 32:
-		if(isPReP) {
+		if (isPReP) {
 			var->red.offset = 8;
 			var->green.offset = 16;
 			var->blue.offset = 24;
@@ -825,15 +822,16 @@ static int cirrusfb_check_var(struct fb_
 		yres = (yres + 1) / 2;
 
 	if (yres >= 1280) {
-		printk (KERN_WARNING "cirrusfb: ERROR: VerticalTotal >= 1280; special treatment required! (TODO)\n");
-		DPRINTK ("EXIT - EINVAL error\n");
+		printk(KERN_ERR "cirrusfb: ERROR: VerticalTotal >= 1280; "
+			"special treatment required! (TODO)\n");
+		DPRINTK("EXIT - EINVAL error\n");
 		return -EINVAL;
 	}
 
 	return 0;
 }
 
-static int cirrusfb_decode_var (const struct fb_var_screeninfo *var,
+static int cirrusfb_decode_var(const struct fb_var_screeninfo *var,
 				struct cirrusfb_regs *regs,
 				const struct fb_info *info)
 {
@@ -844,7 +842,7 @@ static int cirrusfb_decode_var (const st
 	int xres, hfront, hsync, hback;
 	int yres, vfront, vsync, vback;
 
-	switch(var->bits_per_pixel) {
+	switch (var->bits_per_pixel) {
 	case 1:
 		regs->line_length = var->xres_virtual / 8;
 		regs->visual = FB_VISUAL_MONO10;
@@ -887,7 +885,7 @@ static int cirrusfb_decode_var (const st
 	/* convert from ps to kHz */
 	freq = 1000000000 / var->pixclock;
 
-	DPRINTK ("desired pixclock: %ld kHz\n", freq);
+	DPRINTK("desired pixclock: %ld kHz\n", freq);
 
 	maxclock = cirrusfb_board_info[cinfo->btype].maxclock[maxclockidx];
 	regs->multiplexing = 0;
@@ -902,8 +900,9 @@ static int cirrusfb_decode_var (const st
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: ERROR: Frequency greater than maxclock (%ld kHz)\n", maxclock);
-			DPRINTK ("EXIT - return -EINVAL\n");
+			printk(KERN_ERR "cirrusfb: Frequency greater "
+				"than maxclock (%ld kHz)\n", maxclock);
+			DPRINTK("EXIT - return -EINVAL\n");
 			return -EINVAL;
 		}
 	}
@@ -914,14 +913,16 @@ static int cirrusfb_decode_var (const st
 	case 16:
 	case 32:
 		if (regs->HorizRes <= 800)
-			freq /= 2;	/* Xbh has this type of clock for 32-bit */
+			/* Xbh has this type of clock for 32-bit */
+			freq /= 2;
 		break;
 	}
 #endif
 
-	bestclock (freq, &regs->freq, &regs->nom, &regs->den, &regs->div,
-		   maxclock);
-	regs->mclk = cirrusfb_get_mclk (freq, var->bits_per_pixel, &regs->divMCLK);
+	bestclock(freq, &regs->freq, &regs->nom, &regs->den, &regs->div,
+		  maxclock);
+	regs->mclk = cirrusfb_get_mclk(freq, var->bits_per_pixel,
+					&regs->divMCLK);
 
 	xres = var->xres;
 	hfront = var->right_margin;
@@ -948,7 +949,8 @@ static int cirrusfb_decode_var (const st
 	regs->HorizTotal = (xres + hfront + hsync + hback) / 8 - 5;
 	regs->HorizDispEnd = xres / 8 - 1;
 	regs->HorizBlankStart = xres / 8;
-	regs->HorizBlankEnd = regs->HorizTotal + 5;	/* does not count with "-5" */
+	/* does not count with "-5" */
+	regs->HorizBlankEnd = regs->HorizTotal + 5;
 	regs->HorizSyncStart = (xres + hfront) / 8 + 1;
 	regs->HorizSyncEnd = (xres + hfront + hsync) / 8 + 1;
 
@@ -976,23 +978,23 @@ static int cirrusfb_decode_var (const st
 	return 0;
 }
 
-
-static void cirrusfb_set_mclk (const struct cirrusfb_info *cinfo, int val, int div)
+static void cirrusfb_set_mclk(const struct cirrusfb_info *cinfo, int val,
+				int div)
 {
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
 	if (div == 2) {
 		/* VCLK = MCLK/2 */
-		unsigned char old = vga_rseq (cinfo->regbase, CL_SEQR1E);
-		vga_wseq (cinfo->regbase, CL_SEQR1E, old | 0x1);
-		vga_wseq (cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f));
+		unsigned char old = vga_rseq(cinfo->regbase, CL_SEQR1E);
+		vga_wseq(cinfo->regbase, CL_SEQR1E, old | 0x1);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f));
 	} else if (div == 1) {
 		/* VCLK = MCLK */
-		unsigned char old = vga_rseq (cinfo->regbase, CL_SEQR1E);
-		vga_wseq (cinfo->regbase, CL_SEQR1E, old & ~0x1);
-		vga_wseq (cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f));
+		unsigned char old = vga_rseq(cinfo->regbase, CL_SEQR1E);
+		vga_wseq(cinfo->regbase, CL_SEQR1E, old & ~0x1);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, 0x40 | (val & 0x3f));
 	} else {
-		vga_wseq (cinfo->regbase, CL_SEQR1F, val & 0x3f);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, val & 0x3f);
 	}
 }
 
@@ -1001,7 +1003,7 @@ static void cirrusfb_set_mclk (const str
 
 	actually writes the values for a new video mode into the hardware,
 **************************************************************************/
-static int cirrusfb_set_par_foo (struct fb_info *info)
+static int cirrusfb_set_par_foo(struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_var_screeninfo *var = &info->var;
@@ -1011,15 +1013,15 @@ static int cirrusfb_set_par_foo (struct 
 	int offset = 0, err;
 	const struct cirrusfb_board_info_rec *bi;
 
-	DPRINTK ("ENTER\n");
-	DPRINTK ("Requested mode: %dx%dx%d\n",
+	DPRINTK("ENTER\n");
+	DPRINTK("Requested mode: %dx%dx%d\n",
 	       var->xres, var->yres, var->bits_per_pixel);
-	DPRINTK ("pixclock: %d\n", var->pixclock);
+	DPRINTK("pixclock: %d\n", var->pixclock);
 
-	init_vgachip (cinfo);
+	init_vgachip(cinfo);
 
 	err = cirrusfb_decode_var(var, &regs, info);
-	if(err) {
+	if (err) {
 		/* should never happen */
 		DPRINTK("mode change aborted.  invalid var.\n");
 		return -EINVAL;
@@ -1027,34 +1029,35 @@ static int cirrusfb_set_par_foo (struct 
 
 	bi = &cirrusfb_board_info[cinfo->btype];
 
-
 	/* unlock register VGA_CRTC_H_TOTAL..CRT7 */
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, 0x20);	/* previously: 0x00) */
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, 0x20);	/* previously: 0x00) */
 
 	/* if debugging is enabled, all parameters get output before writing */
-	DPRINTK ("CRT0: %ld\n", regs.HorizTotal);
-	vga_wcrt (regbase, VGA_CRTC_H_TOTAL, regs.HorizTotal);
+	DPRINTK("CRT0: %ld\n", regs.HorizTotal);
+	vga_wcrt(regbase, VGA_CRTC_H_TOTAL, regs.HorizTotal);
 
-	DPRINTK ("CRT1: %ld\n", regs.HorizDispEnd);
-	vga_wcrt (regbase, VGA_CRTC_H_DISP, regs.HorizDispEnd);
+	DPRINTK("CRT1: %ld\n", regs.HorizDispEnd);
+	vga_wcrt(regbase, VGA_CRTC_H_DISP, regs.HorizDispEnd);
 
-	DPRINTK ("CRT2: %ld\n", regs.HorizBlankStart);
-	vga_wcrt (regbase, VGA_CRTC_H_BLANK_START, regs.HorizBlankStart);
+	DPRINTK("CRT2: %ld\n", regs.HorizBlankStart);
+	vga_wcrt(regbase, VGA_CRTC_H_BLANK_START, regs.HorizBlankStart);
 
-	DPRINTK ("CRT3: 128+%ld\n", regs.HorizBlankEnd % 32);	/*  + 128: Compatible read */
-	vga_wcrt (regbase, VGA_CRTC_H_BLANK_END, 128 + (regs.HorizBlankEnd % 32));
+	/*  + 128: Compatible read */
+	DPRINTK("CRT3: 128+%ld\n", regs.HorizBlankEnd % 32);
+	vga_wcrt(regbase, VGA_CRTC_H_BLANK_END,
+		 128 + (regs.HorizBlankEnd % 32));
 
-	DPRINTK ("CRT4: %ld\n", regs.HorizSyncStart);
-	vga_wcrt (regbase, VGA_CRTC_H_SYNC_START, regs.HorizSyncStart);
+	DPRINTK("CRT4: %ld\n", regs.HorizSyncStart);
+	vga_wcrt(regbase, VGA_CRTC_H_SYNC_START, regs.HorizSyncStart);
 
 	tmp = regs.HorizSyncEnd % 32;
 	if (regs.HorizBlankEnd & 32)
 		tmp += 128;
-	DPRINTK ("CRT5: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_H_SYNC_END, tmp);
+	DPRINTK("CRT5: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_H_SYNC_END, tmp);
 
-	DPRINTK ("CRT6: %ld\n", regs.VertTotal & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_TOTAL, (regs.VertTotal & 0xff));
+	DPRINTK("CRT6: %ld\n", regs.VertTotal & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_TOTAL, (regs.VertTotal & 0xff));
 
 	tmp = 16;		/* LineCompare bit #9 */
 	if (regs.VertTotal & 256)
@@ -1071,34 +1074,34 @@ static int cirrusfb_set_par_foo (struct 
 		tmp |= 64;
 	if (regs.VertSyncStart & 512)
 		tmp |= 128;
-	DPRINTK ("CRT7: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_OVERFLOW, tmp);
+	DPRINTK("CRT7: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_OVERFLOW, tmp);
 
 	tmp = 0x40;		/* LineCompare bit #8 */
 	if (regs.VertBlankStart & 512)
 		tmp |= 0x20;
 	if (var->vmode & FB_VMODE_DOUBLE)
 		tmp |= 0x80;
-	DPRINTK ("CRT9: %d\n", tmp);
-	vga_wcrt (regbase, VGA_CRTC_MAX_SCAN, tmp);
+	DPRINTK("CRT9: %d\n", tmp);
+	vga_wcrt(regbase, VGA_CRTC_MAX_SCAN, tmp);
 
-	DPRINTK ("CRT10: %ld\n", regs.VertSyncStart & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_START, (regs.VertSyncStart & 0xff));
+	DPRINTK("CRT10: %ld\n", regs.VertSyncStart & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_START, regs.VertSyncStart & 0xff);
 
-	DPRINTK ("CRT11: 64+32+%ld\n", regs.VertSyncEnd % 16);
-	vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, (regs.VertSyncEnd % 16 + 64 + 32));
+	DPRINTK("CRT11: 64+32+%ld\n", regs.VertSyncEnd % 16);
+	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, regs.VertSyncEnd % 16 + 64 + 32);
 
-	DPRINTK ("CRT12: %ld\n", regs.VertDispEnd & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_DISP_END, (regs.VertDispEnd & 0xff));
+	DPRINTK("CRT12: %ld\n", regs.VertDispEnd & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_DISP_END, regs.VertDispEnd & 0xff);
 
-	DPRINTK ("CRT15: %ld\n", regs.VertBlankStart & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_BLANK_START, (regs.VertBlankStart & 0xff));
+	DPRINTK("CRT15: %ld\n", regs.VertBlankStart & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_BLANK_START, regs.VertBlankStart & 0xff);
 
-	DPRINTK ("CRT16: %ld\n", regs.VertBlankEnd & 0xff);
-	vga_wcrt (regbase, VGA_CRTC_V_BLANK_END, (regs.VertBlankEnd & 0xff));
+	DPRINTK("CRT16: %ld\n", regs.VertBlankEnd & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_V_BLANK_END, regs.VertBlankEnd & 0xff);
 
-	DPRINTK ("CRT18: 0xff\n");
-	vga_wcrt (regbase, VGA_CRTC_LINE_COMPARE, 0xff);
+	DPRINTK("CRT18: 0xff\n");
+	vga_wcrt(regbase, VGA_CRTC_LINE_COMPARE, 0xff);
 
 	tmp = 0;
 	if (var->vmode & FB_VMODE_INTERLACED)
@@ -1112,57 +1115,63 @@ static int cirrusfb_set_par_foo (struct 
 	if (regs.VertBlankEnd & 512)
 		tmp |= 128;
 
-	DPRINTK ("CRT1a: %d\n", tmp);
-	vga_wcrt (regbase, CL_CRT1A, tmp);
+	DPRINTK("CRT1a: %d\n", tmp);
+	vga_wcrt(regbase, CL_CRT1A, tmp);
 
 	/* set VCLK0 */
 	/* hardware RefClock: 14.31818 MHz */
 	/* formula: VClk = (OSC * N) / (D * (1+P)) */
 	/* Example: VClk = (14.31818 * 91) / (23 * (1+1)) = 28.325 MHz */
 
-	vga_wseq (regbase, CL_SEQRB, regs.nom);
+	vga_wseq(regbase, CL_SEQRB, regs.nom);
 	tmp = regs.den << 1;
 	if (regs.div != 0)
 		tmp |= 1;
 
+	/* 6 bit denom; ONLY 5434!!! (bugged me 10 days) */
 	if ((cinfo->btype == BT_SD64) ||
 	    (cinfo->btype == BT_ALPINE) ||
 	    (cinfo->btype == BT_GD5480))
-		tmp |= 0x80;	/* 6 bit denom; ONLY 5434!!! (bugged me 10 days) */
+		tmp |= 0x80;
 
-	DPRINTK ("CL_SEQR1B: %ld\n", (long) tmp);
-	vga_wseq (regbase, CL_SEQR1B, tmp);
+	DPRINTK("CL_SEQR1B: %ld\n", (long) tmp);
+	vga_wseq(regbase, CL_SEQR1B, tmp);
 
 	if (regs.VertRes >= 1024)
 		/* 1280x1024 */
-		vga_wcrt (regbase, VGA_CRTC_MODE, 0xc7);
+		vga_wcrt(regbase, VGA_CRTC_MODE, 0xc7);
 	else
 		/* mode control: VGA_CRTC_START_HI enable, ROTATE(?), 16bit
 		 * address wrap, no compat. */
-		vga_wcrt (regbase, VGA_CRTC_MODE, 0xc3);
+		vga_wcrt(regbase, VGA_CRTC_MODE, 0xc3);
 
-/* HAEH?        vga_wcrt (regbase, VGA_CRTC_V_SYNC_END, 0x20);  * previously: 0x00  unlock VGA_CRTC_H_TOTAL..CRT7 */
+/* HAEH?	vga_wcrt(regbase, VGA_CRTC_V_SYNC_END, 0x20);
+ * previously: 0x00  unlock VGA_CRTC_H_TOTAL..CRT7 */
 
 	/* don't know if it would hurt to also program this if no interlaced */
 	/* mode is used, but I feel better this way.. :-) */
 	if (var->vmode & FB_VMODE_INTERLACED)
-		vga_wcrt (regbase, VGA_CRTC_REGS, regs.HorizTotal / 2);
+		vga_wcrt(regbase, VGA_CRTC_REGS, regs.HorizTotal / 2);
 	else
-		vga_wcrt (regbase, VGA_CRTC_REGS, 0x00);	/* interlace control */
+		vga_wcrt(regbase, VGA_CRTC_REGS, 0x00);	/* interlace control */
 
-	vga_wseq (regbase, VGA_SEQ_CHARACTER_MAP, 0);
+	vga_wseq(regbase, VGA_SEQ_CHARACTER_MAP, 0);
 
 	/* adjust horizontal/vertical sync type (low/high) */
-	tmp = 0x03;		/* enable display memory & CRTC I/O address for color mode */
+	/* enable display memory & CRTC I/O address for color mode */
+	tmp = 0x03;
 	if (var->sync & FB_SYNC_HOR_HIGH_ACT)
 		tmp |= 0x40;
 	if (var->sync & FB_SYNC_VERT_HIGH_ACT)
 		tmp |= 0x80;
-	WGen (cinfo, VGA_MIS_W, tmp);
+	WGen(cinfo, VGA_MIS_W, tmp);
 
-	vga_wcrt (regbase, VGA_CRTC_PRESET_ROW, 0);	/* Screen A Preset Row-Scan register */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_START, 0);	/* text cursor on and start line */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_END, 31);	/* text cursor end line */
+	/* Screen A Preset Row-Scan register */
+	vga_wcrt(regbase, VGA_CRTC_PRESET_ROW, 0);
+	/* text cursor on and start line */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_START, 0);
+	/* text cursor end line */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_END, 31);
 
 	/******************************************************
 	 *
@@ -1172,8 +1181,8 @@ static int cirrusfb_set_par_foo (struct 
 
 	/* programming for different color depths */
 	if (var->bits_per_pixel == 1) {
-		DPRINTK ("cirrusfb: preparing for 1 bit deep display\n");
-		vga_wgfx (regbase, VGA_GFX_MODE, 0);	/* mode register */
+		DPRINTK("cirrusfb: preparing for 1 bit deep display\n");
+		vga_wgfx(regbase, VGA_GFX_MODE, 0);	/* mode register */
 
 		/* SR07 */
 		switch (cinfo->btype) {
@@ -1184,71 +1193,85 @@ static int cirrusfb_set_par_foo (struct 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
-			DPRINTK (" (for GD54xx)\n");
-			vga_wseq (regbase, CL_SEQR7,
+			DPRINTK(" (for GD54xx)\n");
+			vga_wseq(regbase, CL_SEQR7,
 				  regs.multiplexing ?
 					bi->sr07_1bpp_mux : bi->sr07_1bpp);
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
 		/* Extended Sequencer Mode */
 		switch (cinfo->btype) {
 		case BT_SD64:
-			/* setting the SEQRF on SD64 is not necessary (only during init) */
-			DPRINTK ("(for SD64)\n");
-			vga_wseq (regbase, CL_SEQR1F, 0x1a);		/*  MCLK select */
+			/* setting the SEQRF on SD64 is not necessary
+			 * (only during init)
+			 */
+			DPRINTK("(for SD64)\n");
+			/*  MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1a);
 			break;
 
 		case BT_PICCOLO:
-			DPRINTK ("(for Piccolo)\n");
-/* ### ueberall 0x22? */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ##vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* evtl d0 bei 1 bit? avoid FIFO underruns..? */
+			DPRINTK("(for Piccolo)\n");
+			/* ### ueberall 0x22? */
+			/* ##vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* evtl d0 bei 1 bit? avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO:
-			DPRINTK ("(for Picasso)\n");
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ##vorher 22 MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xd0);	/* ## vorher d0 avoid FIFO underruns..? */
+			DPRINTK("(for Picasso)\n");
+			/* ##vorher 22 MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* ## vorher d0 avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xd0);
 			break;
 
 		case BT_SPECTRUM:
-			DPRINTK ("(for Spectrum)\n");
-/* ### ueberall 0x22? */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ##vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* evtl d0? avoid FIFO underruns..? */
+			DPRINTK("(for Spectrum)\n");
+			/* ### ueberall 0x22? */
+			/* ##vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* evtl d0? avoid FIFO underruns..? */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
 		case BT_LAGUNA:
-			DPRINTK (" (for GD54xx)\n");
+			DPRINTK(" (for GD54xx)\n");
 			/* do nothing */
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		WGen (cinfo, VGA_PEL_MSK, 0x01);	/* pixel mask: pass-through for first plane */
+		/* pixel mask: pass-through for first plane */
+		WGen(cinfo, VGA_PEL_MSK, 0x01);
 		if (regs.multiplexing)
-			WHDR (cinfo, 0x4a);	/* hidden dac reg: 1280x1024 */
+			/* hidden dac reg: 1280x1024 */
+			WHDR(cinfo, 0x4a);
 		else
-			WHDR (cinfo, 0);	/* hidden dac: nothing */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x06);	/* memory mode: odd/even, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0x01);	/* plane mask: only write to first plane */
+			/* hidden dac: nothing */
+			WHDR(cinfo, 0);
+		/* memory mode: odd/even, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x06);
+		/* plane mask: only write to first plane */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0x01);
 		offset = var->xres_virtual / 16;
 	}
 
@@ -1259,7 +1282,7 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 8) {
-		DPRINTK ("cirrusfb: preparing for 8 bit deep display\n");
+		DPRINTK("cirrusfb: preparing for 8 bit deep display\n");
 		switch (cinfo->btype) {
 		case BT_SD64:
 		case BT_PICCOLO:
@@ -1268,75 +1291,89 @@ static int cirrusfb_set_par_foo (struct 
 		case BT_PICASSO4:
 		case BT_ALPINE:
 		case BT_GD5480:
-			DPRINTK (" (for GD54xx)\n");
-			vga_wseq (regbase, CL_SEQR7,
+			DPRINTK(" (for GD54xx)\n");
+			vga_wseq(regbase, CL_SEQR7,
 				  regs.multiplexing ?
 					bi->sr07_8bpp_mux : bi->sr07_8bpp);
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) | 0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) | 0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR1F, 0x1d);		/* MCLK select */
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1d);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* ### vorher 1c MCLK select */
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
+			/* ### vorher 1c MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
 			break;
 
 		case BT_PICASSO4:
 #ifdef CONFIG_ZORRO
-			vga_wseq (regbase, CL_SEQRF, 0xb8);	/* ### INCOMPLETE!! */
+			/* ### INCOMPLETE!! */
+			vga_wseq(regbase, CL_SEQRF, 0xb8);
 #endif
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c); */
+/*	  		vga_wseq(regbase, CL_SEQR1F, 0x1c); */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+			DPRINTK(" (for GD543x)\n");
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_GD5480:
 		case BT_LAGUNA:
-			DPRINTK (" (for GD54xx)\n");
+			DPRINTK(" (for GD54xx)\n");
 			/* do nothing */
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: pass-through all planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
 		if (regs.multiplexing)
-			WHDR (cinfo, 0x4a);	/* hidden dac reg: 1280x1024 */
+			/* hidden dac reg: 1280x1024 */
+			WHDR(cinfo, 0x4a);
 		else
-			WHDR (cinfo, 0);	/* hidden dac: nothing */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* plane mask: enable writing to all 4 planes */
+			/* hidden dac: nothing */
+			WHDR(cinfo, 0);
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 8;
 	}
 
@@ -1347,72 +1384,84 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 16) {
-		DPRINTK ("cirrusfb: preparing for 16 bit deep display\n");
+		DPRINTK("cirrusfb: preparing for 16 bit deep display\n");
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR7, 0xf7);	/* Extended Sequencer Mode: 256c col. mode */
-			vga_wseq (regbase, CL_SEQR1F, 0x1e);		/* MCLK select */
+			/* Extended Sequencer Mode: 256c col. mode */
+			vga_wseq(regbase, CL_SEQR7, 0xf7);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1e);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR7, 0x87);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x87);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR7, 0x27);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x27);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR7, 0x87);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x87);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO4:
-			vga_wseq (regbase, CL_SEQR7, 0x27);
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c);  */
+			vga_wseq(regbase, CL_SEQR7, 0x27);
+/*			vga_wseq(regbase, CL_SEQR1F, 0x1c);  */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
+			DPRINTK(" (for GD543x)\n");
 			if (regs.HorizRes >= 1024)
-				vga_wseq (regbase, CL_SEQR7, 0xa7);
+				vga_wseq(regbase, CL_SEQR7, 0xa7);
 			else
-				vga_wseq (regbase, CL_SEQR7, 0xa3);
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+				vga_wseq(regbase, CL_SEQR7, 0xa3);
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			break;
 
 		case BT_GD5480:
-			DPRINTK (" (for GD5480)\n");
-			vga_wseq (regbase, CL_SEQR7, 0x17);
+			DPRINTK(" (for GD5480)\n");
+			vga_wseq(regbase, CL_SEQR7, 0x17);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "CIRRUSFB: unknown Board\n");
+			printk(KERN_WARNING "CIRRUSFB: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: pass-through all planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
 #ifdef CONFIG_PCI
-		WHDR (cinfo, 0xc0);	/* Copy Xbh */
+		WHDR(cinfo, 0xc0);	/* Copy Xbh */
 #elif defined(CONFIG_ZORRO)
 		/* FIXME: CONFIG_PCI and CONFIG_ZORRO may be defined both */
-		WHDR (cinfo, 0xa0);	/* hidden dac reg: nothing special */
+		WHDR(cinfo, 0xa0);	/* hidden dac reg: nothing special */
 #endif
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* plane mask: enable writing to all 4 planes */
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 4;
 	}
 
@@ -1423,64 +1472,77 @@ static int cirrusfb_set_par_foo (struct 
 	 */
 
 	else if (var->bits_per_pixel == 32) {
-		DPRINTK ("cirrusfb: preparing for 24/32 bit deep display\n");
+		DPRINTK("cirrusfb: preparing for 24/32 bit deep display\n");
 		switch (cinfo->btype) {
 		case BT_SD64:
-			vga_wseq (regbase, CL_SEQR7, 0xf9);	/* Extended Sequencer Mode: 256c col. mode */
-			vga_wseq (regbase, CL_SEQR1F, 0x1e);		/* MCLK select */
+			/* Extended Sequencer Mode: 256c col. mode */
+			vga_wseq(regbase, CL_SEQR7, 0xf9);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x1e);
 			break;
 
 		case BT_PICCOLO:
-			vga_wseq (regbase, CL_SEQR7, 0x85);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x85);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO:
-			vga_wseq (regbase, CL_SEQR7, 0x25);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x25);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_SPECTRUM:
-			vga_wseq (regbase, CL_SEQR7, 0x85);
-			vga_wseq (regbase, CL_SEQRF, 0xb0);	/* Fast Page-Mode writes */
-			vga_wseq (regbase, CL_SEQR1F, 0x22);		/* MCLK select */
+			vga_wseq(regbase, CL_SEQR7, 0x85);
+			/* Fast Page-Mode writes */
+			vga_wseq(regbase, CL_SEQRF, 0xb0);
+			/* MCLK select */
+			vga_wseq(regbase, CL_SEQR1F, 0x22);
 			break;
 
 		case BT_PICASSO4:
-			vga_wseq (regbase, CL_SEQR7, 0x25);
-/*          vga_wseq (regbase, CL_SEQR1F, 0x1c);  */
+			vga_wseq(regbase, CL_SEQR7, 0x25);
+/*			vga_wseq(regbase, CL_SEQR1F, 0x1c);  */
 			break;
 
 		case BT_ALPINE:
-			DPRINTK (" (for GD543x)\n");
-			vga_wseq (regbase, CL_SEQR7, 0xa9);
-			cirrusfb_set_mclk (cinfo, regs.mclk, regs.divMCLK);
+			DPRINTK(" (for GD543x)\n");
+			vga_wseq(regbase, CL_SEQR7, 0xa9);
+			cirrusfb_set_mclk(cinfo, regs.mclk, regs.divMCLK);
 			break;
 
 		case BT_GD5480:
-			DPRINTK (" (for GD5480)\n");
-			vga_wseq (regbase, CL_SEQR7, 0x19);
+			DPRINTK(" (for GD5480)\n");
+			vga_wseq(regbase, CL_SEQR7, 0x19);
 			/* We already set SRF and SR1F */
 			break;
 
 		case BT_LAGUNA:
-			DPRINTK (" (for GD546x)\n");
-			vga_wseq (regbase, CL_SEQR7,
-				vga_rseq (regbase, CL_SEQR7) & ~0x01);
+			DPRINTK(" (for GD546x)\n");
+			vga_wseq(regbase, CL_SEQR7,
+				vga_rseq(regbase, CL_SEQR7) & ~0x01);
 			break;
 
 		default:
-			printk (KERN_WARNING "cirrusfb: unknown Board\n");
+			printk(KERN_WARNING "cirrusfb: unknown Board\n");
 			break;
 		}
 
-		vga_wgfx (regbase, VGA_GFX_MODE, 64);	/* mode register: 256 color mode */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);	/* pixel mask: pass-through all planes */
-		WHDR (cinfo, 0xc5);	/* hidden dac reg: 8-8-8 mode (24 or 32) */
-		vga_wseq (regbase, VGA_SEQ_MEMORY_MODE, 0x0a);	/* memory mode: chain4, ext. memory */
-		vga_wseq (regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* plane mask: enable writing to all 4 planes */
+		/* mode register: 256 color mode */
+		vga_wgfx(regbase, VGA_GFX_MODE, 64);
+		/* pixel mask: pass-through all planes */
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
+		/* hidden dac reg: 8-8-8 mode (24 or 32) */
+		WHDR(cinfo, 0xc5);
+		/* memory mode: chain4, ext. memory */
+		vga_wseq(regbase, VGA_SEQ_MEMORY_MODE, 0x0a);
+		/* plane mask: enable writing to all 4 planes */
+		vga_wseq(regbase, VGA_SEQ_PLANE_WRITE, 0xff);
 		offset = var->xres_virtual / 4;
 	}
 
@@ -1490,48 +1552,67 @@ static int cirrusfb_set_par_foo (struct 
 	 *
 	 */
 
-	else {
-		printk (KERN_ERR "cirrusfb: What's this?? requested color depth == %d.\n",
+	else
+		printk(KERN_ERR "cirrusfb: What's this?? "
+			" requested color depth == %d.\n",
 			var->bits_per_pixel);
-	}
 
-	vga_wcrt (regbase, VGA_CRTC_OFFSET, offset & 0xff);
+	vga_wcrt(regbase, VGA_CRTC_OFFSET, offset & 0xff);
 	tmp = 0x22;
 	if (offset & 0x100)
 		tmp |= 0x10;	/* offset overflow bit */
 
-	vga_wcrt (regbase, CL_CRT1B, tmp);	/* screen start addr #16-18, fastpagemode cycles */
+	/* screen start addr #16-18, fastpagemode cycles */
+	vga_wcrt(regbase, CL_CRT1B, tmp);
 
 	if (cinfo->btype == BT_SD64 ||
 	    cinfo->btype == BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE ||
 	    cinfo->btype == BT_GD5480)
-		vga_wcrt (regbase, CL_CRT1D, 0x00);	/* screen start address bit 19 */
+		/* screen start address bit 19 */
+		vga_wcrt(regbase, CL_CRT1D, 0x00);
 
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_HI, 0);	/* text cursor location high */
-	vga_wcrt (regbase, VGA_CRTC_CURSOR_LO, 0);	/* text cursor location low */
-	vga_wcrt (regbase, VGA_CRTC_UNDERLINE, 0);	/* underline row scanline = at very bottom */
-
-	vga_wattr (regbase, VGA_ATC_MODE, 1);	/* controller mode */
-	vga_wattr (regbase, VGA_ATC_OVERSCAN, 0);		/* overscan (border) color */
-	vga_wattr (regbase, VGA_ATC_PLANE_ENABLE, 15);	/* color plane enable */
-	vga_wattr (regbase, CL_AR33, 0);	/* pixel panning */
-	vga_wattr (regbase, VGA_ATC_COLOR_PAGE, 0);	/* color select */
+	/* text cursor location high */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_HI, 0);
+	/* text cursor location low */
+	vga_wcrt(regbase, VGA_CRTC_CURSOR_LO, 0);
+	/* underline row scanline = at very bottom */
+	vga_wcrt(regbase, VGA_CRTC_UNDERLINE, 0);
+
+	/* controller mode */
+	vga_wattr(regbase, VGA_ATC_MODE, 1);
+	/* overscan (border) color */
+	vga_wattr(regbase, VGA_ATC_OVERSCAN, 0);
+	/* color plane enable */
+	vga_wattr(regbase, VGA_ATC_PLANE_ENABLE, 15);
+	/* pixel panning */
+	vga_wattr(regbase, CL_AR33, 0);
+	/* color select */
+	vga_wattr(regbase, VGA_ATC_COLOR_PAGE, 0);
 
 	/* [ EGS: SetOffset(); ] */
 	/* From SetOffset(): Turn on VideoEnable bit in Attribute controller */
-	AttrOn (cinfo);
+	AttrOn(cinfo);
 
-	vga_wgfx (regbase, VGA_GFX_SR_VALUE, 0);	/* set/reset register */
-	vga_wgfx (regbase, VGA_GFX_SR_ENABLE, 0);		/* set/reset enable */
-	vga_wgfx (regbase, VGA_GFX_COMPARE_VALUE, 0);	/* color compare */
-	vga_wgfx (regbase, VGA_GFX_DATA_ROTATE, 0);	/* data rotate */
-	vga_wgfx (regbase, VGA_GFX_PLANE_READ, 0);	/* read map select */
-	vga_wgfx (regbase, VGA_GFX_MISC, 1);	/* miscellaneous register */
-	vga_wgfx (regbase, VGA_GFX_COMPARE_MASK, 15);	/* color don't care */
-	vga_wgfx (regbase, VGA_GFX_BIT_MASK, 255);	/* bit mask */
+	/* set/reset register */
+	vga_wgfx(regbase, VGA_GFX_SR_VALUE, 0);
+	/* set/reset enable */
+	vga_wgfx(regbase, VGA_GFX_SR_ENABLE, 0);
+	/* color compare */
+	vga_wgfx(regbase, VGA_GFX_COMPARE_VALUE, 0);
+	/* data rotate */
+	vga_wgfx(regbase, VGA_GFX_DATA_ROTATE, 0);
+	/* read map select */
+	vga_wgfx(regbase, VGA_GFX_PLANE_READ, 0);
+	/* miscellaneous register */
+	vga_wgfx(regbase, VGA_GFX_MISC, 1);
+	/* color don't care */
+	vga_wgfx(regbase, VGA_GFX_COMPARE_MASK, 15);
+	/* bit mask */
+	vga_wgfx(regbase, VGA_GFX_BIT_MASK, 255);
 
-	vga_wseq (regbase, CL_SEQR12, 0x0);	/* graphics cursor attributes: nothing special */
+	/* graphics cursor attributes: nothing special */
+	vga_wseq(regbase, CL_SEQR12, 0x0);
 
 	/* finally, turn on everything - turn off "FullBandwidth" bit */
 	/* also, set "DotClock%2" bit where requested */
@@ -1542,8 +1623,8 @@ static int cirrusfb_set_par_foo (struct 
 	tmp |= 0x08;
 */
 
-	vga_wseq (regbase, VGA_SEQ_CLOCK_MODE, tmp);
-	DPRINTK ("CL_SEQR1: %d\n", tmp);
+	vga_wseq(regbase, VGA_SEQ_CLOCK_MODE, tmp);
+	DPRINTK("CL_SEQR1: %d\n", tmp);
 
 	cinfo->currentmode = regs;
 	info->fix.type = regs.type;
@@ -1551,27 +1632,27 @@ static int cirrusfb_set_par_foo (struct 
 	info->fix.line_length = regs.line_length;
 
 	/* pan to requested offset */
-	cirrusfb_pan_display (var, info);
+	cirrusfb_pan_display(var, info);
 
 #ifdef CIRRUSFB_DEBUG
-	cirrusfb_dump ();
+	cirrusfb_dump();
 #endif
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 	return 0;
 }
 
 /* for some reason incomprehensible to me, cirrusfb requires that you write
  * the registers twice for the settings to take..grr. -dte */
-static int cirrusfb_set_par (struct fb_info *info)
+static int cirrusfb_set_par(struct fb_info *info)
 {
-	cirrusfb_set_par_foo (info);
-	return cirrusfb_set_par_foo (info);
+	cirrusfb_set_par_foo(info);
+	return cirrusfb_set_par_foo(info);
 }
 
-static int cirrusfb_setcolreg (unsigned regno, unsigned red, unsigned green,
-			       unsigned blue, unsigned transp,
-			       struct fb_info *info)
+static int cirrusfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			      unsigned blue, unsigned transp,
+			      struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
 
@@ -1584,23 +1665,23 @@ static int cirrusfb_setcolreg (unsigned 
 		green >>= (16 - info->var.green.length);
 		blue >>= (16 - info->var.blue.length);
 
-		if (regno>=16)
+		if (regno >= 16)
 			return 1;
 		v = (red << info->var.red.offset) |
 		    (green << info->var.green.offset) |
 		    (blue << info->var.blue.offset);
 
 		switch (info->var.bits_per_pixel) {
-			case 8:
-				cinfo->pseudo_palette[regno] = v;
-				break;
-			case 16:
-				cinfo->pseudo_palette[regno] = v;
-				break;
-			case 24:
-			case 32:
-				cinfo->pseudo_palette[regno] = v;
-				break;
+		case 8:
+			cinfo->pseudo_palette[regno] = v;
+			break;
+		case 16:
+			cinfo->pseudo_palette[regno] = v;
+			break;
+		case 24:
+		case 32:
+			cinfo->pseudo_palette[regno] = v;
+			break;
 		}
 		return 0;
 	}
@@ -1609,9 +1690,8 @@ static int cirrusfb_setcolreg (unsigned 
 	cinfo->palette[regno].green = green;
 	cinfo->palette[regno].blue = blue;
 
-	if (info->var.bits_per_pixel == 8) {
-			WClut (cinfo, regno, red >> 10, green >> 10, blue >> 10);
-	}
+	if (info->var.bits_per_pixel == 8)
+		WClut(cinfo, regno, red >> 10, green >> 10, blue >> 10);
 
 	return 0;
 
@@ -1622,8 +1702,8 @@ static int cirrusfb_setcolreg (unsigned 
 
 	performs display panning - provided hardware permits this
 **************************************************************************/
-static int cirrusfb_pan_display (struct fb_var_screeninfo *var,
-				 struct fb_info *info)
+static int cirrusfb_pan_display(struct fb_var_screeninfo *var,
+				struct fb_info *info)
 {
 	int xoffset = 0;
 	int yoffset = 0;
@@ -1631,8 +1711,8 @@ static int cirrusfb_pan_display (struct 
 	unsigned char tmp = 0, tmp2 = 0, xpix;
 	struct cirrusfb_info *cinfo = info->par;
 
-	DPRINTK ("ENTER\n");
-	DPRINTK ("virtual offset: (%d,%d)\n", var->xoffset, var->yoffset);
+	DPRINTK("ENTER\n");
+	DPRINTK("virtual offset: (%d,%d)\n", var->xoffset, var->yoffset);
 
 	/* no range checks for xoffset and yoffset,   */
 	/* as fb_pan_display has already done this */
@@ -1655,11 +1735,13 @@ static int cirrusfb_pan_display (struct 
 		xpix = (unsigned char) ((xoffset % 4) * 2);
 	}
 
-        cirrusfb_WaitBLT(cinfo->regbase); /* make sure all the BLT's are done */
+	cirrusfb_WaitBLT(cinfo->regbase); /* make sure all the BLT's are done */
 
 	/* lower 8 + 8 bits of screen start address */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_LO, (unsigned char) (base & 0xff));
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_HI, (unsigned char) (base >> 8));
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_LO,
+		 (unsigned char) (base & 0xff));
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_HI,
+		 (unsigned char) (base >> 8));
 
 	/* construct bits 16, 17 and 18 of screen start address */
 	if (base & 0x10000)
@@ -1669,50 +1751,53 @@ static int cirrusfb_pan_display (struct 
 	if (base & 0x40000)
 		tmp |= 0x08;
 
-	tmp2 = (vga_rcrt (cinfo->regbase, CL_CRT1B) & 0xf2) | tmp;	/* 0xf2 is %11110010, exclude tmp bits */
-	vga_wcrt (cinfo->regbase, CL_CRT1B, tmp2);
+	/* 0xf2 is %11110010, exclude tmp bits */
+	tmp2 = (vga_rcrt(cinfo->regbase, CL_CRT1B) & 0xf2) | tmp;
+	vga_wcrt(cinfo->regbase, CL_CRT1B, tmp2);
 
 	/* construct bit 19 of screen start address */
 	if (cirrusfb_board_info[cinfo->btype].scrn_start_bit19) {
 		tmp2 = 0;
 		if (base & 0x80000)
 			tmp2 = 0x80;
-		vga_wcrt (cinfo->regbase, CL_CRT1D, tmp2);
+		vga_wcrt(cinfo->regbase, CL_CRT1D, tmp2);
 	}
 
-	/* write pixel panning value to AR33; this does not quite work in 8bpp */
-	/* ### Piccolo..? Will this work? */
+	/* write pixel panning value to AR33; this does not quite work in 8bpp
+	 *
+	 * ### Piccolo..? Will this work?
+	 */
 	if (info->var.bits_per_pixel == 1)
-		vga_wattr (cinfo->regbase, CL_AR33, xpix);
+		vga_wattr(cinfo->regbase, CL_AR33, xpix);
 
-	cirrusfb_WaitBLT (cinfo->regbase);
+	cirrusfb_WaitBLT(cinfo->regbase);
 
-	DPRINTK ("EXIT\n");
-	return (0);
+	DPRINTK("EXIT\n");
+	return 0;
 }
 
-
-static int cirrusfb_blank (int blank_mode, struct fb_info *info)
+static int cirrusfb_blank(int blank_mode, struct fb_info *info)
 {
 	/*
-	 *  Blank the screen if blank_mode != 0, else unblank. If blank == NULL
-	 *  then the caller blanks by setting the CLUT (Color Look Up Table) to all
-	 *  black. Return 0 if blanking succeeded, != 0 if un-/blanking failed due
-	 *  to e.g. a video mode which doesn't support it. Implements VESA suspend
-	 *  and powerdown modes on hardware that supports disabling hsync/vsync:
-	 *    blank_mode == 2: suspend vsync
-	 *    blank_mode == 3: suspend hsync
-	 *    blank_mode == 4: powerdown
+	 * Blank the screen if blank_mode != 0, else unblank. If blank == NULL
+	 * then the caller blanks by setting the CLUT (Color Look Up Table)
+	 * to all black. Return 0 if blanking succeeded, != 0 if un-/blanking
+	 * failed due to e.g. a video mode which doesn't support it.
+	 * Implements VESA suspend and powerdown modes on hardware that
+	 * supports disabling hsync/vsync:
+	 *   blank_mode == 2: suspend vsync
+	 *   blank_mode == 3: suspend hsync
+	 *   blank_mode == 4: powerdown
 	 */
 	unsigned char val;
 	struct cirrusfb_info *cinfo = info->par;
 	int current_mode = cinfo->blank_mode;
 
-	DPRINTK ("ENTER, blank mode = %d\n", blank_mode);
+	DPRINTK("ENTER, blank mode = %d\n", blank_mode);
 
 	if (info->state != FBINFO_STATE_RUNNING ||
 	    current_mode == blank_mode) {
-		DPRINTK ("EXIT, returning 0\n");
+		DPRINTK("EXIT, returning 0\n");
 		return 0;
 	}
 
@@ -1720,17 +1805,19 @@ static int cirrusfb_blank (int blank_mod
 	if (current_mode == FB_BLANK_NORMAL ||
 	    current_mode == FB_BLANK_UNBLANK) {
 		/* unblank the screen */
-		val = vga_rseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE);
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, val & 0xdf);	/* clear "FullBandwidth" bit */
+		val = vga_rseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE);
+		/* clear "FullBandwidth" bit */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, val & 0xdf);
 		/* and undo VESA suspend trickery */
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x00);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x00);
 	}
 
 	/* set new */
-	if(blank_mode > FB_BLANK_NORMAL) {
+	if (blank_mode > FB_BLANK_NORMAL) {
 		/* blank the screen */
-		val = vga_rseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE);
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, val | 0x20);	/* set "FullBandwidth" bit */
+		val = vga_rseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE);
+		/* set "FullBandwidth" bit */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, val | 0x20);
 	}
 
 	switch (blank_mode) {
@@ -1738,21 +1825,21 @@ static int cirrusfb_blank (int blank_mod
 	case FB_BLANK_NORMAL:
 		break;
 	case FB_BLANK_VSYNC_SUSPEND:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x04);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x04);
 		break;
 	case FB_BLANK_HSYNC_SUSPEND:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x02);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x02);
 		break;
 	case FB_BLANK_POWERDOWN:
-		vga_wgfx (cinfo->regbase, CL_GRE, 0x06);
+		vga_wgfx(cinfo->regbase, CL_GRE, 0x06);
 		break;
 	default:
-		DPRINTK ("EXIT, returning 1\n");
+		DPRINTK("EXIT, returning 1\n");
 		return 1;
 	}
 
 	cinfo->blank_mode = blank_mode;
-	DPRINTK ("EXIT, returning 0\n");
+	DPRINTK("EXIT, returning 0\n");
 
 	/* Let fbcon do a soft blank for us */
 	return (blank_mode == FB_BLANK_NORMAL) ? 1 : 0;
@@ -1761,45 +1848,50 @@ static int cirrusfb_blank (int blank_mod
 /****************************************************************************/
 /**** BEGIN Internal Routines ***********************************************/
 
-static void init_vgachip (struct cirrusfb_info *cinfo)
+static void init_vgachip(struct cirrusfb_info *cinfo)
 {
 	const struct cirrusfb_board_info_rec *bi;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
 	bi = &cirrusfb_board_info[cinfo->btype];
 
 	/* reset board globally */
 	switch (cinfo->btype) {
 	case BT_PICCOLO:
-		WSFR (cinfo, 0x01);
-		udelay (500);
-		WSFR (cinfo, 0x51);
-		udelay (500);
+		WSFR(cinfo, 0x01);
+		udelay(500);
+		WSFR(cinfo, 0x51);
+		udelay(500);
 		break;
 	case BT_PICASSO:
-		WSFR2 (cinfo, 0xff);
-		udelay (500);
+		WSFR2(cinfo, 0xff);
+		udelay(500);
 		break;
 	case BT_SD64:
 	case BT_SPECTRUM:
-		WSFR (cinfo, 0x1f);
-		udelay (500);
-		WSFR (cinfo, 0x4f);
-		udelay (500);
+		WSFR(cinfo, 0x1f);
+		udelay(500);
+		WSFR(cinfo, 0x4f);
+		udelay(500);
 		break;
 	case BT_PICASSO4:
-		vga_wcrt (cinfo->regbase, CL_CRT51, 0x00);	/* disable flickerfixer */
-		mdelay (100);
-		vga_wgfx (cinfo->regbase, CL_GR2F, 0x00);	/* from Klaus' NetBSD driver: */
-		vga_wgfx (cinfo->regbase, CL_GR33, 0x00);	/* put blitter into 542x compat */
-		vga_wgfx (cinfo->regbase, CL_GR31, 0x00);	/* mode */
+		/* disable flickerfixer */
+		vga_wcrt(cinfo->regbase, CL_CRT51, 0x00);
+		mdelay(100);
+		/* from Klaus' NetBSD driver: */
+		vga_wgfx(cinfo->regbase, CL_GR2F, 0x00);
+		/* put blitter into 542x compat */
+		vga_wgfx(cinfo->regbase, CL_GR33, 0x00);
+		/* mode */
+		vga_wgfx(cinfo->regbase, CL_GR31, 0x00);
 		break;
 
 	case BT_GD5480:
-		vga_wgfx (cinfo->regbase, CL_GR2F, 0x00);	/* from Klaus' NetBSD driver: */
+		/* from Klaus' NetBSD driver: */
+		vga_wgfx(cinfo->regbase, CL_GR2F, 0x00);
 		break;
 
 	case BT_ALPINE:
@@ -1807,153 +1899,207 @@ static void init_vgachip (struct cirrusf
 		break;
 
 	default:
-		printk (KERN_ERR "cirrusfb: Warning: Unknown board type\n");
+		printk(KERN_ERR "cirrusfb: Warning: Unknown board type\n");
 		break;
 	}
 
-	assert (cinfo->size > 0); /* make sure RAM size set by this point */
+	assert(cinfo->size > 0); /* make sure RAM size set by this point */
 
 	/* the P4 is not fully initialized here; I rely on it having been */
 	/* inited under AmigaOS already, which seems to work just fine    */
-	/* (Klaus advised to do it this way)                              */
+	/* (Klaus advised to do it this way)			      */
 
 	if (cinfo->btype != BT_PICASSO4) {
-		WGen (cinfo, CL_VSSM, 0x10);	/* EGS: 0x16 */
-		WGen (cinfo, CL_POS102, 0x01);
-		WGen (cinfo, CL_VSSM, 0x08);	/* EGS: 0x0e */
+		WGen(cinfo, CL_VSSM, 0x10);	/* EGS: 0x16 */
+		WGen(cinfo, CL_POS102, 0x01);
+		WGen(cinfo, CL_VSSM, 0x08);	/* EGS: 0x0e */
 
 		if (cinfo->btype != BT_SD64)
-			WGen (cinfo, CL_VSSM2, 0x01);
+			WGen(cinfo, CL_VSSM2, 0x01);
 
-		vga_wseq (cinfo->regbase, CL_SEQR0, 0x03);	/* reset sequencer logic */
+		/* reset sequencer logic */
+		vga_wseq(cinfo->regbase, CL_SEQR0, 0x03);
 
-		vga_wseq (cinfo->regbase, VGA_SEQ_CLOCK_MODE, 0x21);	/* FullBandwidth (video off) and 8/9 dot clock */
-		WGen (cinfo, VGA_MIS_W, 0xc1);	/* polarity (-/-), disable access to display memory, VGA_CRTC_START_HI base address: color */
+		/* FullBandwidth (video off) and 8/9 dot clock */
+		vga_wseq(cinfo->regbase, VGA_SEQ_CLOCK_MODE, 0x21);
+		/* polarity (-/-), disable access to display memory,
+		 * VGA_CRTC_START_HI base address: color
+		 */
+		WGen(cinfo, VGA_MIS_W, 0xc1);
 
-/*      vga_wgfx (cinfo->regbase, CL_GRA, 0xce);    "magic cookie" - doesn't make any sense to me.. */
-		vga_wseq (cinfo->regbase, CL_SEQR6, 0x12);	/* unlock all extension registers */
+		/* "magic cookie" - doesn't make any sense to me.. */
+/*      vga_wgfx(cinfo->regbase, CL_GRA, 0xce);   */
+		/* unlock all extension registers */
+		vga_wseq(cinfo->regbase, CL_SEQR6, 0x12);
 
-		vga_wgfx (cinfo->regbase, CL_GR31, 0x04);	/* reset blitter */
+		/* reset blitter */
+		vga_wgfx(cinfo->regbase, CL_GR31, 0x04);
 
 		switch (cinfo->btype) {
 		case BT_GD5480:
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0x98);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0x98);
 			break;
 		case BT_ALPINE:
 			break;
 		case BT_SD64:
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0xb8);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0xb8);
 			break;
 		default:
-			vga_wseq (cinfo->regbase, CL_SEQR16, 0x0f);
-			vga_wseq (cinfo->regbase, CL_SEQRF, 0xb0);
+			vga_wseq(cinfo->regbase, CL_SEQR16, 0x0f);
+			vga_wseq(cinfo->regbase, CL_SEQRF, 0xb0);
 			break;
 		}
 	}
-	vga_wseq (cinfo->regbase, VGA_SEQ_PLANE_WRITE, 0xff);	/* plane mask: nothing */
-	vga_wseq (cinfo->regbase, VGA_SEQ_CHARACTER_MAP, 0x00);	/* character map select: doesn't even matter in gx mode */
-	vga_wseq (cinfo->regbase, VGA_SEQ_MEMORY_MODE, 0x0e);	/* memory mode: chain-4, no odd/even, ext. memory */
+	/* plane mask: nothing */
+	vga_wseq(cinfo->regbase, VGA_SEQ_PLANE_WRITE, 0xff);
+	/* character map select: doesn't even matter in gx mode */
+	vga_wseq(cinfo->regbase, VGA_SEQ_CHARACTER_MAP, 0x00);
+	/* memory mode: chain-4, no odd/even, ext. memory */
+	vga_wseq(cinfo->regbase, VGA_SEQ_MEMORY_MODE, 0x0e);
 
 	/* controller-internal base address of video memory */
 	if (bi->init_sr07)
-		vga_wseq (cinfo->regbase, CL_SEQR7, bi->sr07);
+		vga_wseq(cinfo->regbase, CL_SEQR7, bi->sr07);
 
-	/*  vga_wseq (cinfo->regbase, CL_SEQR8, 0x00); *//* EEPROM control: shouldn't be necessary to write to this at all.. */
+	/*  vga_wseq(cinfo->regbase, CL_SEQR8, 0x00); */
+	/* EEPROM control: shouldn't be necessary to write to this at all.. */
 
-	vga_wseq (cinfo->regbase, CL_SEQR10, 0x00);		/* graphics cursor X position (incomplete; position gives rem. 3 bits */
-	vga_wseq (cinfo->regbase, CL_SEQR11, 0x00);		/* graphics cursor Y position (..."... ) */
-	vga_wseq (cinfo->regbase, CL_SEQR12, 0x00);		/* graphics cursor attributes */
-	vga_wseq (cinfo->regbase, CL_SEQR13, 0x00);		/* graphics cursor pattern address */
+	/* graphics cursor X position (incomplete; position gives rem. 3 bits */
+	vga_wseq(cinfo->regbase, CL_SEQR10, 0x00);
+	/* graphics cursor Y position (..."... ) */
+	vga_wseq(cinfo->regbase, CL_SEQR11, 0x00);
+	/* graphics cursor attributes */
+	vga_wseq(cinfo->regbase, CL_SEQR12, 0x00);
+	/* graphics cursor pattern address */
+	vga_wseq(cinfo->regbase, CL_SEQR13, 0x00);
 
 	/* writing these on a P4 might give problems..  */
 	if (cinfo->btype != BT_PICASSO4) {
-		vga_wseq (cinfo->regbase, CL_SEQR17, 0x00);		/* configuration readback and ext. color */
-		vga_wseq (cinfo->regbase, CL_SEQR18, 0x02);		/* signature generator */
+		/* configuration readback and ext. color */
+		vga_wseq(cinfo->regbase, CL_SEQR17, 0x00);
+		/* signature generator */
+		vga_wseq(cinfo->regbase, CL_SEQR18, 0x02);
 	}
 
 	/* MCLK select etc. */
 	if (bi->init_sr1f)
-		vga_wseq (cinfo->regbase, CL_SEQR1F, bi->sr1f);
+		vga_wseq(cinfo->regbase, CL_SEQR1F, bi->sr1f);
 
-	vga_wcrt (cinfo->regbase, VGA_CRTC_PRESET_ROW, 0x00);	/* Screen A preset row scan: none */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_START, 0x20);	/* Text cursor start: disable text cursor */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_END, 0x00);	/* Text cursor end: - */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_HI, 0x00);	/* Screen start address high: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_START_LO, 0x00);	/* Screen start address low: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_HI, 0x00);	/* text cursor location high: 0 */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_CURSOR_LO, 0x00);	/* text cursor location low: 0 */
-
-	vga_wcrt (cinfo->regbase, VGA_CRTC_UNDERLINE, 0x00);	/* Underline Row scanline: - */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_MODE, 0xc3);	/* mode control: timing enable, byte mode, no compat modes */
-	vga_wcrt (cinfo->regbase, VGA_CRTC_LINE_COMPARE, 0x00);	/* Line Compare: not needed */
+	/* Screen A preset row scan: none */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_PRESET_ROW, 0x00);
+	/* Text cursor start: disable text cursor */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_START, 0x20);
+	/* Text cursor end: - */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_END, 0x00);
+	/* Screen start address high: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_HI, 0x00);
+	/* Screen start address low: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_START_LO, 0x00);
+	/* text cursor location high: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_HI, 0x00);
+	/* text cursor location low: 0 */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_CURSOR_LO, 0x00);
+
+	/* Underline Row scanline: - */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_UNDERLINE, 0x00);
+	/* mode control: timing enable, byte mode, no compat modes */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_MODE, 0xc3);
+	/* Line Compare: not needed */
+	vga_wcrt(cinfo->regbase, VGA_CRTC_LINE_COMPARE, 0x00);
 	/* ### add 0x40 for text modes with > 30 MHz pixclock */
-	vga_wcrt (cinfo->regbase, CL_CRT1B, 0x02);	/* ext. display controls: ext.adr. wrap */
+	/* ext. display controls: ext.adr. wrap */
+	vga_wcrt(cinfo->regbase, CL_CRT1B, 0x02);
 
-	vga_wgfx (cinfo->regbase, VGA_GFX_SR_VALUE, 0x00);	/* Set/Reset registes: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_SR_ENABLE, 0x00);	/* Set/Reset enable: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_COMPARE_VALUE, 0x00);	/* Color Compare: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_DATA_ROTATE, 0x00);	/* Data Rotate: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_PLANE_READ, 0x00);	/* Read Map Select: - */
-	vga_wgfx (cinfo->regbase, VGA_GFX_MODE, 0x00);	/* Mode: conf. for 16/4/2 color mode, no odd/even, read/write mode 0 */
-	vga_wgfx (cinfo->regbase, VGA_GFX_MISC, 0x01);	/* Miscellaneous: memory map base address, graphics mode */
-	vga_wgfx (cinfo->regbase, VGA_GFX_COMPARE_MASK, 0x0f);	/* Color Don't care: involve all planes */
-	vga_wgfx (cinfo->regbase, VGA_GFX_BIT_MASK, 0xff);	/* Bit Mask: no mask at all */
+	/* Set/Reset registes: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_SR_VALUE, 0x00);
+	/* Set/Reset enable: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_SR_ENABLE, 0x00);
+	/* Color Compare: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_COMPARE_VALUE, 0x00);
+	/* Data Rotate: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_DATA_ROTATE, 0x00);
+	/* Read Map Select: - */
+	vga_wgfx(cinfo->regbase, VGA_GFX_PLANE_READ, 0x00);
+	/* Mode: conf. for 16/4/2 color mode, no odd/even, read/write mode 0 */
+	vga_wgfx(cinfo->regbase, VGA_GFX_MODE, 0x00);
+	/* Miscellaneous: memory map base address, graphics mode */
+	vga_wgfx(cinfo->regbase, VGA_GFX_MISC, 0x01);
+	/* Color Don't care: involve all planes */
+	vga_wgfx(cinfo->regbase, VGA_GFX_COMPARE_MASK, 0x0f);
+	/* Bit Mask: no mask at all */
+	vga_wgfx(cinfo->regbase, VGA_GFX_BIT_MASK, 0xff);
 	if (cinfo->btype == BT_ALPINE)
-		vga_wgfx (cinfo->regbase, CL_GRB, 0x20);	/* (5434 can't have bit 3 set for bitblt) */
+		/* (5434 can't have bit 3 set for bitblt) */
+		vga_wgfx(cinfo->regbase, CL_GRB, 0x20);
 	else
-		vga_wgfx (cinfo->regbase, CL_GRB, 0x28);	/* Graphics controller mode extensions: finer granularity, 8byte data latches */
+	/* Graphics controller mode extensions: finer granularity,
+	 * 8byte data latches
+	 */
+		vga_wgfx(cinfo->regbase, CL_GRB, 0x28);
 
-	vga_wgfx (cinfo->regbase, CL_GRC, 0xff);	/* Color Key compare: - */
-	vga_wgfx (cinfo->regbase, CL_GRD, 0x00);	/* Color Key compare mask: - */
-	vga_wgfx (cinfo->regbase, CL_GRE, 0x00);	/* Miscellaneous control: - */
-	/*  vga_wgfx (cinfo->regbase, CL_GR10, 0x00); *//* Background color byte 1: - */
-/*  vga_wgfx (cinfo->regbase, CL_GR11, 0x00); */
-
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE0, 0x00);	/* Attribute Controller palette registers: "identity mapping" */
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE1, 0x01);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE2, 0x02);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE3, 0x03);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE4, 0x04);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE5, 0x05);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE6, 0x06);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE7, 0x07);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE8, 0x08);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTE9, 0x09);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEA, 0x0a);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEB, 0x0b);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEC, 0x0c);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTED, 0x0d);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEE, 0x0e);
-	vga_wattr (cinfo->regbase, VGA_ATC_PALETTEF, 0x0f);
-
-	vga_wattr (cinfo->regbase, VGA_ATC_MODE, 0x01);	/* Attribute Controller mode: graphics mode */
-	vga_wattr (cinfo->regbase, VGA_ATC_OVERSCAN, 0x00);	/* Overscan color reg.: reg. 0 */
-	vga_wattr (cinfo->regbase, VGA_ATC_PLANE_ENABLE, 0x0f);	/* Color Plane enable: Enable all 4 planes */
-/* ###  vga_wattr (cinfo->regbase, CL_AR33, 0x00); * Pixel Panning: - */
-	vga_wattr (cinfo->regbase, VGA_ATC_COLOR_PAGE, 0x00);	/* Color Select: - */
+	vga_wgfx(cinfo->regbase, CL_GRC, 0xff);	/* Color Key compare: - */
+	vga_wgfx(cinfo->regbase, CL_GRD, 0x00);	/* Color Key compare mask: - */
+	vga_wgfx(cinfo->regbase, CL_GRE, 0x00);	/* Miscellaneous control: - */
+	/* Background color byte 1: - */
+	/*  vga_wgfx (cinfo->regbase, CL_GR10, 0x00); */
+	/*  vga_wgfx (cinfo->regbase, CL_GR11, 0x00); */
+
+	/* Attribute Controller palette registers: "identity mapping" */
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE0, 0x00);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE1, 0x01);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE2, 0x02);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE3, 0x03);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE4, 0x04);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE5, 0x05);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE6, 0x06);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE7, 0x07);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE8, 0x08);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTE9, 0x09);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEA, 0x0a);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEB, 0x0b);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEC, 0x0c);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTED, 0x0d);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEE, 0x0e);
+	vga_wattr(cinfo->regbase, VGA_ATC_PALETTEF, 0x0f);
+
+	/* Attribute Controller mode: graphics mode */
+	vga_wattr(cinfo->regbase, VGA_ATC_MODE, 0x01);
+	/* Overscan color reg.: reg. 0 */
+	vga_wattr(cinfo->regbase, VGA_ATC_OVERSCAN, 0x00);
+	/* Color Plane enable: Enable all 4 planes */
+	vga_wattr(cinfo->regbase, VGA_ATC_PLANE_ENABLE, 0x0f);
+/* ###  vga_wattr(cinfo->regbase, CL_AR33, 0x00); * Pixel Panning: - */
+	/* Color Select: - */
+	vga_wattr(cinfo->regbase, VGA_ATC_COLOR_PAGE, 0x00);
 
-	WGen (cinfo, VGA_PEL_MSK, 0xff);	/* Pixel mask: no mask */
+	WGen(cinfo, VGA_PEL_MSK, 0xff);	/* Pixel mask: no mask */
 
 	if (cinfo->btype != BT_ALPINE && cinfo->btype != BT_GD5480)
-		WGen (cinfo, VGA_MIS_W, 0xc3);	/* polarity (-/-), enable display mem, VGA_CRTC_START_HI i/o base = color */
+	/* polarity (-/-), enable display mem,
+	 * VGA_CRTC_START_HI i/o base = color
+	 */
+		WGen(cinfo, VGA_MIS_W, 0xc3);
 
-	vga_wgfx (cinfo->regbase, CL_GR31, 0x04);	/* BLT Start/status: Blitter reset */
-	vga_wgfx (cinfo->regbase, CL_GR31, 0x00);	/* - " -           : "end-of-reset" */
+	/* BLT Start/status: Blitter reset */
+	vga_wgfx(cinfo->regbase, CL_GR31, 0x04);
+	/* - " -	   : "end-of-reset" */
+	vga_wgfx(cinfo->regbase, CL_GR31, 0x00);
 
 	/* misc... */
-	WHDR (cinfo, 0);	/* Hidden DAC register: - */
+	WHDR(cinfo, 0);	/* Hidden DAC register: - */
 
-	printk (KERN_DEBUG "cirrusfb: This board has %ld bytes of DRAM memory\n", cinfo->size);
-	DPRINTK ("EXIT\n");
+	printk(KERN_DEBUG "cirrusfb: This board has %ld bytes of DRAM memory\n",
+		cinfo->size);
+	DPRINTK("EXIT\n");
 	return;
 }
 
-static void switch_monitor (struct cirrusfb_info *cinfo, int on)
+static void switch_monitor(struct cirrusfb_info *cinfo, int on)
 {
 #ifdef CONFIG_ZORRO /* only works on Zorro boards */
 	static int IsOn = 0;	/* XXX not ok for multiple boards */
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (cinfo->btype == BT_PICASSO4)
 		return;		/* nothing to switch */
@@ -1963,44 +2109,43 @@ static void switch_monitor (struct cirru
 		return;		/* nothing to switch */
 	if (cinfo->btype == BT_PICASSO) {
 		if ((on && !IsOn) || (!on && IsOn))
-			WSFR (cinfo, 0xff);
+			WSFR(cinfo, 0xff);
 
-		DPRINTK ("EXIT\n");
+		DPRINTK("EXIT\n");
 		return;
 	}
 	if (on) {
 		switch (cinfo->btype) {
 		case BT_SD64:
-			WSFR (cinfo, cinfo->SFR | 0x21);
+			WSFR(cinfo, cinfo->SFR | 0x21);
 			break;
 		case BT_PICCOLO:
-			WSFR (cinfo, cinfo->SFR | 0x28);
+			WSFR(cinfo, cinfo->SFR | 0x28);
 			break;
 		case BT_SPECTRUM:
-			WSFR (cinfo, 0x6f);
+			WSFR(cinfo, 0x6f);
 			break;
 		default: /* do nothing */ break;
 		}
 	} else {
 		switch (cinfo->btype) {
 		case BT_SD64:
-			WSFR (cinfo, cinfo->SFR & 0xde);
+			WSFR(cinfo, cinfo->SFR & 0xde);
 			break;
 		case BT_PICCOLO:
-			WSFR (cinfo, cinfo->SFR & 0xd7);
+			WSFR(cinfo, cinfo->SFR & 0xd7);
 			break;
 		case BT_SPECTRUM:
-			WSFR (cinfo, 0x4f);
+			WSFR(cinfo, 0x4f);
 			break;
 		default: /* do nothing */ break;
 		}
 	}
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 #endif /* CONFIG_ZORRO */
 }
 
-
 /******************************************/
 /* Linux 2.6-style  accelerated functions */
 /******************************************/
@@ -2012,15 +2157,17 @@ static void cirrusfb_prim_fillrect(struc
 	u32 color = (cinfo->info->fix.visual == FB_VISUAL_TRUECOLOR) ?
 		cinfo->pseudo_palette[region->color] : region->color;
 
-	if(cinfo->info->var.bits_per_pixel == 1) {
-		cirrusfb_RectFill(cinfo->regbase, cinfo->info->var.bits_per_pixel,
+	if (cinfo->info->var.bits_per_pixel == 1) {
+		cirrusfb_RectFill(cinfo->regbase,
+				  cinfo->info->var.bits_per_pixel,
 				  region->dx / 8, region->dy,
 				  region->width / 8, region->height,
 				  color,
 				  cinfo->currentmode.line_length);
 	} else {
-		m = ( cinfo->info->var.bits_per_pixel + 7 ) / 8;
-		cirrusfb_RectFill(cinfo->regbase, cinfo->info->var.bits_per_pixel,
+		m = (cinfo->info->var.bits_per_pixel + 7) / 8;
+		cirrusfb_RectFill(cinfo->regbase,
+				  cinfo->info->var.bits_per_pixel,
 				  region->dx * m, region->dy,
 				  region->width * m, region->height,
 				  color,
@@ -2029,7 +2176,8 @@ static void cirrusfb_prim_fillrect(struc
 	return;
 }
 
-static void cirrusfb_fillrect (struct fb_info *info, const struct fb_fillrect *region)
+static void cirrusfb_fillrect(struct fb_info *info,
+			      const struct fb_fillrect *region)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_fillrect modded;
@@ -2047,12 +2195,14 @@ static void cirrusfb_fillrect (struct fb
 
 	memcpy(&modded, region, sizeof(struct fb_fillrect));
 
-	if(!modded.width || !modded.height ||
+	if (!modded.width || !modded.height ||
 	   modded.dx >= vxres || modded.dy >= vyres)
 		return;
 
-	if(modded.dx + modded.width  > vxres) modded.width  = vxres - modded.dx;
-	if(modded.dy + modded.height > vyres) modded.height = vyres - modded.dy;
+	if (modded.dx + modded.width  > vxres)
+		modded.width  = vxres - modded.dx;
+	if (modded.dy + modded.height > vyres)
+		modded.height = vyres - modded.dy;
 
 	cirrusfb_prim_fillrect(cinfo, &modded);
 }
@@ -2061,14 +2211,14 @@ static void cirrusfb_prim_copyarea(struc
 				   const struct fb_copyarea *area)
 {
 	int m; /* bytes per pixel */
-	if(cinfo->info->var.bits_per_pixel == 1) {
+	if (cinfo->info->var.bits_per_pixel == 1) {
 		cirrusfb_BitBLT(cinfo->regbase, cinfo->info->var.bits_per_pixel,
 				area->sx / 8, area->sy,
 				area->dx / 8, area->dy,
 				area->width / 8, area->height,
 				cinfo->currentmode.line_length);
 	} else {
-		m = ( cinfo->info->var.bits_per_pixel + 7 ) / 8;
+		m = (cinfo->info->var.bits_per_pixel + 7) / 8;
 		cirrusfb_BitBLT(cinfo->regbase, cinfo->info->var.bits_per_pixel,
 				area->sx * m, area->sy,
 				area->dx * m, area->dy,
@@ -2078,8 +2228,8 @@ static void cirrusfb_prim_copyarea(struc
 	return;
 }
 
-
-static void cirrusfb_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+static void cirrusfb_copyarea(struct fb_info *info,
+			      const struct fb_copyarea *area)
 {
 	struct cirrusfb_info *cinfo = info->par;
 	struct fb_copyarea modded;
@@ -2101,89 +2251,99 @@ static void cirrusfb_copyarea(struct fb_
 	vxres = info->var.xres_virtual;
 	vyres = info->var.yres_virtual;
 
-	if(!modded.width || !modded.height ||
+	if (!modded.width || !modded.height ||
 	   modded.sx >= vxres || modded.sy >= vyres ||
 	   modded.dx >= vxres || modded.dy >= vyres)
 		return;
 
-	if(modded.sx + modded.width > vxres)  modded.width = vxres - modded.sx;
-	if(modded.dx + modded.width > vxres)  modded.width = vxres - modded.dx;
-	if(modded.sy + modded.height > vyres) modded.height = vyres - modded.sy;
-	if(modded.dy + modded.height > vyres) modded.height = vyres - modded.dy;
+	if (modded.sx + modded.width > vxres)
+		modded.width = vxres - modded.sx;
+	if (modded.dx + modded.width > vxres)
+		modded.width = vxres - modded.dx;
+	if (modded.sy + modded.height > vyres)
+		modded.height = vyres - modded.sy;
+	if (modded.dy + modded.height > vyres)
+		modded.height = vyres - modded.dy;
 
 	cirrusfb_prim_copyarea(cinfo, &modded);
 }
 
-static void cirrusfb_imageblit(struct fb_info *info, const struct fb_image *image)
+static void cirrusfb_imageblit(struct fb_info *info,
+			       const struct fb_image *image)
 {
 	struct cirrusfb_info *cinfo = info->par;
 
-        cirrusfb_WaitBLT(cinfo->regbase);
+	cirrusfb_WaitBLT(cinfo->regbase);
 	cfb_imageblit(info, image);
 }
 
-
 #ifdef CONFIG_PPC_PREP
 #define PREP_VIDEO_BASE ((volatile unsigned long) 0xC0000000)
 #define PREP_IO_BASE    ((volatile unsigned char *) 0x80000000)
-static void get_prep_addrs (unsigned long *display, unsigned long *registers)
+static void get_prep_addrs(unsigned long *display, unsigned long *registers)
 {
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	*display = PREP_VIDEO_BASE;
 	*registers = (unsigned long) PREP_IO_BASE;
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 #endif				/* CONFIG_PPC_PREP */
 
-
 #ifdef CONFIG_PCI
-static int release_io_ports = 0;
+static int release_io_ports;
 
 /* Pulled the logic from XFree86 Cirrus driver to get the memory size,
  * based on the DRAM bandwidth bit and DRAM bank switching bit.  This
  * works with 1MB, 2MB and 4MB configurations (which the Motorola boards
  * seem to have. */
-static unsigned int cirrusfb_get_memsize (u8 __iomem *regbase)
+static unsigned int cirrusfb_get_memsize(u8 __iomem *regbase)
 {
 	unsigned long mem;
 	unsigned char SRF;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	SRF = vga_rseq (regbase, CL_SEQRF);
+	SRF = vga_rseq(regbase, CL_SEQRF);
 	switch ((SRF & 0x18)) {
-	    case 0x08: mem = 512 * 1024; break;
-	    case 0x10: mem = 1024 * 1024; break;
-		/* 64-bit DRAM data bus width; assume 2MB. Also indicates 2MB memory
-		   * on the 5430. */
-	    case 0x18: mem = 2048 * 1024; break;
-	    default: printk ("CLgenfb: Unknown memory size!\n");
+	case 0x08:
+		mem = 512 * 1024;
+		break;
+	case 0x10:
+		mem = 1024 * 1024;
+		break;
+	/* 64-bit DRAM data bus width; assume 2MB. Also indicates 2MB memory
+	 * on the 5430.
+	 */
+	case 0x18:
+		mem = 2048 * 1024;
+		break;
+	default:
+		printk(KERN_WARNING "CLgenfb: Unknown memory size!\n");
 		mem = 1024 * 1024;
 	}
-	if (SRF & 0x80) {
-		/* If DRAM bank switching is enabled, there must be twice as much
-		   * memory installed. (4MB on the 5434) */
+	if (SRF & 0x80)
+	/* If DRAM bank switching is enabled, there must be twice as much
+	 * memory installed. (4MB on the 5434)
+	 */
 		mem *= 2;
-	}
+
 	/* TODO: Handling of GD5446/5480 (see XF86 sources ...) */
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 	return mem;
 }
 
-
-
-static void get_pci_addrs (const struct pci_dev *pdev,
-			   unsigned long *display, unsigned long *registers)
+static void get_pci_addrs(const struct pci_dev *pdev,
+			  unsigned long *display, unsigned long *registers)
 {
-	assert (pdev != NULL);
-	assert (display != NULL);
-	assert (registers != NULL);
+	assert(pdev != NULL);
+	assert(display != NULL);
+	assert(registers != NULL);
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	*display = 0;
 	*registers = 0;
@@ -2198,13 +2358,12 @@ static void get_pci_addrs (const struct 
 		*registers = pci_resource_start(pdev, 1);
 	}
 
-	assert (*display != 0);
+	assert(*display != 0);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
-static void cirrusfb_pci_unmap (struct cirrusfb_info *cinfo)
+static void cirrusfb_pci_unmap(struct cirrusfb_info *cinfo)
 {
 	struct pci_dev *pdev = cinfo->pdev;
 
@@ -2219,19 +2378,18 @@ static void cirrusfb_pci_unmap (struct c
 }
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
-static void __devexit cirrusfb_zorro_unmap (struct cirrusfb_info *cinfo)
+static void __devexit cirrusfb_zorro_unmap(struct cirrusfb_info *cinfo)
 {
 	zorro_release_device(cinfo->zdev);
 
 	if (cinfo->btype == BT_PICASSO4) {
 		cinfo->regbase -= 0x600000;
-		iounmap ((void *)cinfo->regbase);
-		iounmap ((void *)cinfo->fbmem);
+		iounmap((void *)cinfo->regbase);
+		iounmap((void *)cinfo->fbmem);
 	} else {
 		if (zorro_resource_start(cinfo->zdev) > 0x01000000)
-			iounmap ((void *)cinfo->fbmem);
+			iounmap((void *)cinfo->fbmem);
 	}
 	framebuffer_release(cinfo->info);
 }
@@ -2267,7 +2425,8 @@ static int cirrusfb_set_fbinfo(struct ci
 	/* monochrome: only 1 memory plane */
 	/* 8 bit and above: Use whole memory area */
 	info->fix.smem_start = cinfo->fbmem_phys;
-	info->fix.smem_len   = (var->bits_per_pixel == 1) ? cinfo->size / 4 : cinfo->size;
+	info->fix.smem_len   =
+		(var->bits_per_pixel == 1) ? cinfo->size / 4 : cinfo->size;
 	info->fix.type       = cinfo->currentmode.type;
 	info->fix.type_aux   = 0;
 	info->fix.visual     = cinfo->currentmode.visual;
@@ -2292,17 +2451,18 @@ static int cirrusfb_register(struct cirr
 	int err;
 	cirrusfb_board_t btype;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	printk (KERN_INFO "cirrusfb: Driver for Cirrus Logic based graphic boards, v" CIRRUSFB_VERSION "\n");
+	printk(KERN_INFO "cirrusfb: Driver for Cirrus Logic based "
+		"graphic boards, v" CIRRUSFB_VERSION "\n");
 
 	info = cinfo->info;
 	btype = cinfo->btype;
 
 	/* sanity checks */
-	assert (btype != BT_NONE);
+	assert(btype != BT_NONE);
 
-	DPRINTK ("cirrusfb: (RAM start set to: 0x%p)\n", cinfo->fbmem);
+	DPRINTK("cirrusfb: (RAM start set to: 0x%p)\n", cinfo->fbmem);
 
 	/* Make pretend we've set the var so our structures are in a "good" */
 	/* state, even though we haven't written the mode to the hw yet...  */
@@ -2321,11 +2481,12 @@ static int cirrusfb_register(struct cirr
 
 	err = register_framebuffer(info);
 	if (err < 0) {
-		printk (KERN_ERR "cirrusfb: could not register fb device; err = %d!\n", err);
+		printk(KERN_ERR "cirrusfb: could not register "
+			"fb device; err = %d!\n", err);
 		goto err_dealloc_cmap;
 	}
 
-	DPRINTK ("EXIT, returning 0\n");
+	DPRINTK("EXIT, returning 0\n");
 	return 0;
 
 err_dealloc_cmap:
@@ -2335,24 +2496,23 @@ err_unmap_cirrusfb:
 	return err;
 }
 
-static void __devexit cirrusfb_cleanup (struct fb_info *info)
+static void __devexit cirrusfb_cleanup(struct fb_info *info)
 {
 	struct cirrusfb_info *cinfo = info->par;
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	switch_monitor (cinfo, 0);
+	switch_monitor(cinfo, 0);
 
-	unregister_framebuffer (info);
-	fb_dealloc_cmap (&info->cmap);
-	printk ("Framebuffer unregistered\n");
+	unregister_framebuffer(info);
+	fb_dealloc_cmap(&info->cmap);
+	printk("Framebuffer unregistered\n");
 	cinfo->unmap(cinfo);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 #ifdef CONFIG_PCI
-static int cirrusfb_pci_register (struct pci_dev *pdev,
+static int cirrusfb_pci_register(struct pci_dev *pdev,
 				  const struct pci_device_id *ent)
 {
 	struct cirrusfb_info *cinfo;
@@ -2379,31 +2539,34 @@ static int cirrusfb_pci_register (struct
 	cinfo->pdev = pdev;
 	cinfo->btype = btype = (cirrusfb_board_t) ent->driver_data;
 
-	DPRINTK (" Found PCI device, base address 0 is 0x%lx, btype set to %d\n",
+	DPRINTK(" Found PCI device, base address 0 is 0x%lx, btype set to %d\n",
 		pdev->resource[0].start, btype);
-	DPRINTK (" base address 1 is 0x%lx\n", pdev->resource[1].start);
+	DPRINTK(" base address 1 is 0x%lx\n", pdev->resource[1].start);
 
-	if(isPReP) {
-		pci_write_config_dword (pdev, PCI_BASE_ADDRESS_0, 0x00000000);
+	if (isPReP) {
+		pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, 0x00000000);
 #ifdef CONFIG_PPC_PREP
-		get_prep_addrs (&board_addr, &cinfo->fbregs_phys);
+		get_prep_addrs(&board_addr, &cinfo->fbregs_phys);
 #endif
-		/* PReP dies if we ioremap the IO registers, but it works w/out... */
+	/* PReP dies if we ioremap the IO registers, but it works w/out... */
 		cinfo->regbase = (char __iomem *) cinfo->fbregs_phys;
 	} else {
-		DPRINTK ("Attempt to get PCI info for Cirrus Graphics Card\n");
-		get_pci_addrs (pdev, &board_addr, &cinfo->fbregs_phys);
-		cinfo->regbase = NULL;		/* FIXME: this forces VGA.  alternatives? */
+		DPRINTK("Attempt to get PCI info for Cirrus Graphics Card\n");
+		get_pci_addrs(pdev, &board_addr, &cinfo->fbregs_phys);
+		/* FIXME: this forces VGA.  alternatives? */
+		cinfo->regbase = NULL;
 	}
 
-	DPRINTK ("Board address: 0x%lx, register address: 0x%lx\n", board_addr, cinfo->fbregs_phys);
+	DPRINTK("Board address: 0x%lx, register address: 0x%lx\n",
+		board_addr, cinfo->fbregs_phys);
 
 	board_size = (btype == BT_GD5480) ?
-		32 * MB_ : cirrusfb_get_memsize (cinfo->regbase);
+		32 * MB_ : cirrusfb_get_memsize(cinfo->regbase);
 
 	ret = pci_request_regions(pdev, "cirrusfb");
-	if (ret <0) {
-		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, abort\n",
+	if (ret < 0) {
+		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, "
+		       "abort\n",
 		       board_addr);
 		goto err_release_fb;
 	}
@@ -2429,8 +2592,9 @@ static int cirrusfb_pci_register (struct
 	cinfo->size = board_size;
 	cinfo->unmap = cirrusfb_pci_unmap;
 
-	printk (" RAM (%lu kB) at 0xx%lx, ", cinfo->size / KB_, board_addr);
-	printk ("Cirrus Logic chipset on PCI bus\n");
+	printk(KERN_INFO " RAM (%lu kB) at 0xx%lx, ",
+		cinfo->size / KB_, board_addr);
+	printk(KERN_INFO "Cirrus Logic chipset on PCI bus\n");
 	pci_set_drvdata(pdev, info);
 
 	ret = cirrusfb_register(cinfo);
@@ -2453,14 +2617,14 @@ err_out:
 	return ret;
 }
 
-static void __devexit cirrusfb_pci_unregister (struct pci_dev *pdev)
+static void __devexit cirrusfb_pci_unregister(struct pci_dev *pdev)
 {
 	struct fb_info *info = pci_get_drvdata(pdev);
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	cirrusfb_cleanup (info);
+	cirrusfb_cleanup(info);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 static struct pci_driver cirrusfb_pci_driver = {
@@ -2477,7 +2641,6 @@ static struct pci_driver cirrusfb_pci_dr
 };
 #endif /* CONFIG_PCI */
 
-
 #ifdef CONFIG_ZORRO
 static int cirrusfb_zorro_register(struct zorro_dev *z,
 				   const struct zorro_device_id *ent)
@@ -2498,7 +2661,7 @@ static int cirrusfb_zorro_register(struc
 
 	info = framebuffer_alloc(sizeof(struct cirrusfb_info), &z->dev);
 	if (!info) {
-		printk (KERN_ERR "cirrusfb: could not allocate memory\n");
+		printk(KERN_ERR "cirrusfb: could not allocate memory\n");
 		ret = -ENOMEM;
 		goto err_out;
 	}
@@ -2507,9 +2670,9 @@ static int cirrusfb_zorro_register(struc
 	cinfo->info = info;
 	cinfo->btype = btype;
 
-	assert (z > 0);
-	assert (z2 >= 0);
-	assert (btype != BT_NONE);
+	assert(z > 0);
+	assert(z2 >= 0);
+	assert(btype != BT_NONE);
 
 	cinfo->zdev = z;
 	board_addr = zorro_resource_start(z);
@@ -2517,55 +2680,59 @@ static int cirrusfb_zorro_register(struc
 	cinfo->size = size;
 
 	if (!zorro_request_device(z, "cirrusfb")) {
-		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, abort\n",
+		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, "
+		       "abort\n",
 		       board_addr);
 		ret = -EBUSY;
 		goto err_release_fb;
 	}
 
-	printk (" RAM (%lu MB) at $%lx, ", board_size / MB_, board_addr);
+	printk(" RAM (%lu MB) at $%lx, ", board_size / MB_, board_addr);
 
 	ret = -EIO;
 
 	if (btype == BT_PICASSO4) {
-		printk (" REG at $%lx\n", board_addr + 0x600000);
+		printk(KERN_INFO " REG at $%lx\n", board_addr + 0x600000);
 
 		/* To be precise, for the P4 this is not the */
 		/* begin of the board, but the begin of RAM. */
 		/* for P4, map in its address space in 2 chunks (### TEST! ) */
 		/* (note the ugly hardcoded 16M number) */
-		cinfo->regbase = ioremap (board_addr, 16777216);
+		cinfo->regbase = ioremap(board_addr, 16777216);
 		if (!cinfo->regbase)
 			goto err_release_region;
 
-		DPRINTK ("cirrusfb: Virtual address for board set to: $%p\n", cinfo->regbase);
+		DPRINTK("cirrusfb: Virtual address for board set to: $%p\n",
+			cinfo->regbase);
 		cinfo->regbase += 0x600000;
 		cinfo->fbregs_phys = board_addr + 0x600000;
 
 		cinfo->fbmem_phys = board_addr + 16777216;
-		cinfo->fbmem = ioremap (cinfo->fbmem_phys, 16777216);
+		cinfo->fbmem = ioremap(cinfo->fbmem_phys, 16777216);
 		if (!cinfo->fbmem)
 			goto err_unmap_regbase;
 	} else {
-		printk (" REG at $%lx\n", (unsigned long) z2->resource.start);
+		printk(KERN_INFO " REG at $%lx\n",
+			(unsigned long) z2->resource.start);
 
 		cinfo->fbmem_phys = board_addr;
 		if (board_addr > 0x01000000)
-			cinfo->fbmem = ioremap (board_addr, board_size);
+			cinfo->fbmem = ioremap(board_addr, board_size);
 		else
-			cinfo->fbmem = (caddr_t) ZTWO_VADDR (board_addr);
+			cinfo->fbmem = (caddr_t) ZTWO_VADDR(board_addr);
 		if (!cinfo->fbmem)
 			goto err_release_region;
 
 		/* set address for REG area of board */
-		cinfo->regbase = (caddr_t) ZTWO_VADDR (z2->resource.start);
+		cinfo->regbase = (caddr_t) ZTWO_VADDR(z2->resource.start);
 		cinfo->fbregs_phys = z2->resource.start;
 
-		DPRINTK ("cirrusfb: Virtual address for board set to: $%p\n", cinfo->regbase);
+		DPRINTK("cirrusfb: Virtual address for board set to: $%p\n",
+			cinfo->regbase);
 	}
 	cinfo->unmap = cirrusfb_zorro_unmap;
 
-	printk (KERN_INFO "Cirrus Logic chipset on Zorro bus\n");
+	printk(KERN_INFO "Cirrus Logic chipset on Zorro bus\n");
 	zorro_set_drvdata(z, info);
 
 	ret = cirrusfb_register(cinfo);
@@ -2592,11 +2759,11 @@ err_out:
 void __devexit cirrusfb_zorro_unregister(struct zorro_dev *z)
 {
 	struct fb_info *info = zorro_get_drvdata(z);
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	cirrusfb_cleanup (info);
+	cirrusfb_cleanup(info);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 static struct zorro_driver cirrusfb_zorro_driver = {
@@ -2628,26 +2795,24 @@ static int __init cirrusfb_init(void)
 	return error;
 }
 
-
-
 #ifndef MODULE
 static int __init cirrusfb_setup(char *options) {
 	char *this_opt, s[32];
 	int i;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (!options || !*options)
 		return 0;
 
-	while ((this_opt = strsep (&options, ",")) != NULL) {	
+	while ((this_opt = strsep(&options, ",")) != NULL) {
 		if (!*this_opt) continue;
 
 		DPRINTK("cirrusfb_setup: option '%s'\n", this_opt);
 
 		for (i = 0; i < NUM_TOTAL_MODES; i++) {
-			sprintf (s, "mode:%s", cirrusfb_predefined[i].name);
-			if (strcmp (this_opt, s) == 0)
+			sprintf(s, "mode:%s", cirrusfb_predefined[i].name);
+			if (strcmp(this_opt, s) == 0)
 				cirrusfb_def_mode = i;
 		}
 		if (!strcmp(this_opt, "noaccel"))
@@ -2657,7 +2822,6 @@ static int __init cirrusfb_setup(char *o
 }
 #endif
 
-
     /*
      *  Modularization
      */
@@ -2666,7 +2830,7 @@ MODULE_AUTHOR("Copyright 1999,2000 Jeff 
 MODULE_DESCRIPTION("Accelerated FBDev driver for Cirrus Logic chips");
 MODULE_LICENSE("GPL");
 
-static void __exit cirrusfb_exit (void)
+static void __exit cirrusfb_exit(void)
 {
 #ifdef CONFIG_PCI
 	pci_unregister_driver(&cirrusfb_pci_driver);
@@ -2682,66 +2846,67 @@ module_init(cirrusfb_init);
 module_exit(cirrusfb_exit);
 #endif
 
-
 /**********************************************************************/
 /* about the following functions - I have used the same names for the */
 /* functions as Markus Wild did in his Retina driver for NetBSD as    */
 /* they just made sense for this purpose. Apart from that, I wrote    */
-/* these functions myself.                                            */
+/* these functions myself.					    */
 /**********************************************************************/
 
 /*** WGen() - write into one of the external/general registers ***/
-static void WGen (const struct cirrusfb_info *cinfo,
+static void WGen(const struct cirrusfb_info *cinfo,
 		  int regnum, unsigned char val)
 {
 	unsigned long regofs = 0;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Picasso II specific hack */
-/*              if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D || regnum == CL_VSSM2) */
+/*	      if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D ||
+		  regnum == CL_VSSM2) */
 		if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D)
 			regofs = 0xfff;
 	}
 
-	vga_w (cinfo->regbase, regofs + regnum, val);
+	vga_w(cinfo->regbase, regofs + regnum, val);
 }
 
 /*** RGen() - read out one of the external/general registers ***/
-static unsigned char RGen (const struct cirrusfb_info *cinfo, int regnum)
+static unsigned char RGen(const struct cirrusfb_info *cinfo, int regnum)
 {
 	unsigned long regofs = 0;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Picasso II specific hack */
-/*              if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D || regnum == CL_VSSM2) */
+/*	      if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D ||
+		  regnum == CL_VSSM2) */
 		if (regnum == VGA_PEL_IR || regnum == VGA_PEL_D)
 			regofs = 0xfff;
 	}
 
-	return vga_r (cinfo->regbase, regofs + regnum);
+	return vga_r(cinfo->regbase, regofs + regnum);
 }
 
 /*** AttrOn() - turn on VideoEnable for Attribute controller ***/
-static void AttrOn (const struct cirrusfb_info *cinfo)
+static void AttrOn(const struct cirrusfb_info *cinfo)
 {
-	assert (cinfo != NULL);
+	assert(cinfo != NULL);
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
-	if (vga_rcrt (cinfo->regbase, CL_CRT24) & 0x80) {
+	if (vga_rcrt(cinfo->regbase, CL_CRT24) & 0x80) {
 		/* if we're just in "write value" mode, write back the */
 		/* same value as before to not modify anything */
-		vga_w (cinfo->regbase, VGA_ATT_IW,
-		       vga_r (cinfo->regbase, VGA_ATT_R));
+		vga_w(cinfo->regbase, VGA_ATT_IW,
+		      vga_r(cinfo->regbase, VGA_ATT_R));
 	}
 	/* turn on video bit */
-/*      vga_w (cinfo->regbase, VGA_ATT_IW, 0x20); */
-	vga_w (cinfo->regbase, VGA_ATT_IW, 0x33);
+/*      vga_w(cinfo->regbase, VGA_ATT_IW, 0x20); */
+	vga_w(cinfo->regbase, VGA_ATT_IW, 0x33);
 
 	/* dummy write on Reg0 to be on "write index" mode next time */
-	vga_w (cinfo->regbase, VGA_ATT_IW, 0x00);
+	vga_w(cinfo->regbase, VGA_ATT_IW, 0x00);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
 /*** WHDR() - write into the Hidden DAC register ***/
@@ -2750,119 +2915,115 @@ static void AttrOn (const struct cirrusf
  * registers of their functional group) here is a specialized routine for
  * accessing the HDR
  */
-static void WHDR (const struct cirrusfb_info *cinfo, unsigned char val)
+static void WHDR(const struct cirrusfb_info *cinfo, unsigned char val)
 {
 	unsigned char dummy;
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* Klaus' hint for correct access to HDR on some boards */
 		/* first write 0 to pixel mask (3c6) */
-		WGen (cinfo, VGA_PEL_MSK, 0x00);
-		udelay (200);
+		WGen(cinfo, VGA_PEL_MSK, 0x00);
+		udelay(200);
 		/* next read dummy from pixel address (3c8) */
-		dummy = RGen (cinfo, VGA_PEL_IW);
-		udelay (200);
+		dummy = RGen(cinfo, VGA_PEL_IW);
+		udelay(200);
 	}
 	/* now do the usual stuff to access the HDR */
 
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
-	dummy = RGen (cinfo, VGA_PEL_MSK);
-	udelay (200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
+	dummy = RGen(cinfo, VGA_PEL_MSK);
+	udelay(200);
 
-	WGen (cinfo, VGA_PEL_MSK, val);
-	udelay (200);
+	WGen(cinfo, VGA_PEL_MSK, val);
+	udelay(200);
 
 	if (cinfo->btype == BT_PICASSO) {
 		/* now first reset HDR access counter */
-		dummy = RGen (cinfo, VGA_PEL_IW);
-		udelay (200);
+		dummy = RGen(cinfo, VGA_PEL_IW);
+		udelay(200);
 
 		/* and at the end, restore the mask value */
 		/* ## is this mask always 0xff? */
-		WGen (cinfo, VGA_PEL_MSK, 0xff);
-		udelay (200);
+		WGen(cinfo, VGA_PEL_MSK, 0xff);
+		udelay(200);
 	}
 }
 
-
 /*** WSFR() - write to the "special function register" (SFR) ***/
-static void WSFR (struct cirrusfb_info *cinfo, unsigned char val)
+static void WSFR(struct cirrusfb_info *cinfo, unsigned char val)
 {
 #ifdef CONFIG_ZORRO
-	assert (cinfo->regbase != NULL);
+	assert(cinfo->regbase != NULL);
 	cinfo->SFR = val;
-	z_writeb (val, cinfo->regbase + 0x8000);
+	z_writeb(val, cinfo->regbase + 0x8000);
 #endif
 }
 
 /* The Picasso has a second register for switching the monitor bit */
-static void WSFR2 (struct cirrusfb_info *cinfo, unsigned char val)
+static void WSFR2(struct cirrusfb_info *cinfo, unsigned char val)
 {
 #ifdef CONFIG_ZORRO
 	/* writing an arbitrary value to this one causes the monitor switcher */
 	/* to flip to Amiga display */
-	assert (cinfo->regbase != NULL);
+	assert(cinfo->regbase != NULL);
 	cinfo->SFR = val;
-	z_writeb (val, cinfo->regbase + 0x9000);
+	z_writeb(val, cinfo->regbase + 0x9000);
 #endif
 }
 
-
 /*** WClut - set CLUT entry (range: 0..63) ***/
-static void WClut (struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char red,
+static void WClut(struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char red,
 	    unsigned char green, unsigned char blue)
 {
 	unsigned int data = VGA_PEL_D;
 
 	/* address write mode register is not translated.. */
-	vga_w (cinfo->regbase, VGA_PEL_IW, regnum);
+	vga_w(cinfo->regbase, VGA_PEL_IW, regnum);
 
 	if (cinfo->btype == BT_PICASSO || cinfo->btype == BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE || cinfo->btype == BT_GD5480) {
 		/* but DAC data register IS, at least for Picasso II */
 		if (cinfo->btype == BT_PICASSO)
 			data += 0xfff;
-		vga_w (cinfo->regbase, data, red);
-		vga_w (cinfo->regbase, data, green);
-		vga_w (cinfo->regbase, data, blue);
+		vga_w(cinfo->regbase, data, red);
+		vga_w(cinfo->regbase, data, green);
+		vga_w(cinfo->regbase, data, blue);
 	} else {
-		vga_w (cinfo->regbase, data, blue);
-		vga_w (cinfo->regbase, data, green);
-		vga_w (cinfo->regbase, data, red);
+		vga_w(cinfo->regbase, data, blue);
+		vga_w(cinfo->regbase, data, green);
+		vga_w(cinfo->regbase, data, red);
 	}
 }
 
-
 #if 0
 /*** RClut - read CLUT entry (range 0..63) ***/
-static void RClut (struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char *red,
+static void RClut(struct cirrusfb_info *cinfo, unsigned char regnum, unsigned char *red,
 	    unsigned char *green, unsigned char *blue)
 {
 	unsigned int data = VGA_PEL_D;
 
-	vga_w (cinfo->regbase, VGA_PEL_IR, regnum);
+	vga_w(cinfo->regbase, VGA_PEL_IR, regnum);
 
 	if (cinfo->btype == BT_PICASSO || cinfo->btype == BT_PICASSO4 ||
 	    cinfo->btype == BT_ALPINE || cinfo->btype == BT_GD5480) {
 		if (cinfo->btype == BT_PICASSO)
 			data += 0xfff;
-		*red = vga_r (cinfo->regbase, data);
-		*green = vga_r (cinfo->regbase, data);
-		*blue = vga_r (cinfo->regbase, data);
+		*red = vga_r(cinfo->regbase, data);
+		*green = vga_r(cinfo->regbase, data);
+		*blue = vga_r(cinfo->regbase, data);
 	} else {
-		*blue = vga_r (cinfo->regbase, data);
-		*green = vga_r (cinfo->regbase, data);
-		*red = vga_r (cinfo->regbase, data);
+		*blue = vga_r(cinfo->regbase, data);
+		*green = vga_r(cinfo->regbase, data);
+		*red = vga_r(cinfo->regbase, data);
 	}
 }
 #endif
 
-
 /*******************************************************************
 	cirrusfb_WaitBLT()
 
@@ -2870,10 +3031,10 @@ static void RClut (struct cirrusfb_info 
 *********************************************************************/
 
 /* FIXME: use interrupts instead */
-static void cirrusfb_WaitBLT (u8 __iomem *regbase)
+static void cirrusfb_WaitBLT(u8 __iomem *regbase)
 {
 	/* now busy-wait until we're done */
-	while (vga_rgfx (regbase, CL_GR31) & 0x08)
+	while (vga_rgfx(regbase, CL_GR31) & 0x08)
 		/* do nothing */ ;
 }
 
@@ -2883,15 +3044,17 @@ static void cirrusfb_WaitBLT (u8 __iomem
 	perform accelerated "scrolling"
 ********************************************************************/
 
-static void cirrusfb_BitBLT (u8 __iomem *regbase, int bits_per_pixel,
-			     u_short curx, u_short cury, u_short destx, u_short desty,
-			     u_short width, u_short height, u_short line_length)
+static void cirrusfb_BitBLT(u8 __iomem *regbase, int bits_per_pixel,
+			    u_short curx, u_short cury,
+			    u_short destx, u_short desty,
+			    u_short width, u_short height,
+			    u_short line_length)
 {
 	u_short nwidth, nheight;
 	u_long nsrc, ndest;
 	u_char bltmode;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	nwidth = width - 1;
 	nheight = height - 1;
@@ -2911,9 +3074,13 @@ static void cirrusfb_BitBLT (u8 __iomem 
 		nsrc = (cury * line_length) + curx;
 		ndest = (desty * line_length) + destx;
 	} else {
-		/* this means start addresses are at the end, counting backwards */
-		nsrc = cury * line_length + curx + nheight * line_length + nwidth;
-		ndest = desty * line_length + destx + nheight * line_length + nwidth;
+		/* this means start addresses are at the end,
+		 * counting backwards
+		 */
+		nsrc = cury * line_length + curx +
+			nheight * line_length + nwidth;
+		ndest = desty * line_length + destx +
+			nheight * line_length + nwidth;
 	}
 
 	/*
@@ -2929,52 +3096,65 @@ static void cirrusfb_BitBLT (u8 __iomem 
 	   start/stop
 	 */
 
-        cirrusfb_WaitBLT(regbase);
+	cirrusfb_WaitBLT(regbase);
 
 	/* pitch: set to line_length */
-	vga_wgfx (regbase, CL_GR24, line_length & 0xff);	/* dest pitch low */
-	vga_wgfx (regbase, CL_GR25, (line_length >> 8));	/* dest pitch hi */
-	vga_wgfx (regbase, CL_GR26, line_length & 0xff);	/* source pitch low */
-	vga_wgfx (regbase, CL_GR27, (line_length >> 8));	/* source pitch hi */
+	/* dest pitch low */
+	vga_wgfx(regbase, CL_GR24, line_length & 0xff);
+	/* dest pitch hi */
+	vga_wgfx(regbase, CL_GR25, line_length >> 8);
+	/* source pitch low */
+	vga_wgfx(regbase, CL_GR26, line_length & 0xff);
+	/* source pitch hi */
+	vga_wgfx(regbase, CL_GR27, line_length >> 8);
 
 	/* BLT width: actual number of pixels - 1 */
-	vga_wgfx (regbase, CL_GR20, nwidth & 0xff);	/* BLT width low */
-	vga_wgfx (regbase, CL_GR21, (nwidth >> 8));	/* BLT width hi */
+	/* BLT width low */
+	vga_wgfx(regbase, CL_GR20, nwidth & 0xff);
+	/* BLT width hi */
+	vga_wgfx(regbase, CL_GR21, nwidth >> 8);
 
 	/* BLT height: actual number of lines -1 */
-	vga_wgfx (regbase, CL_GR22, nheight & 0xff);	/* BLT height low */
-	vga_wgfx (regbase, CL_GR23, (nheight >> 8));	/* BLT width hi */
+	/* BLT height low */
+	vga_wgfx(regbase, CL_GR22, nheight & 0xff);
+	/* BLT width hi */
+	vga_wgfx(regbase, CL_GR23, nheight >> 8);
 
 	/* BLT destination */
-	vga_wgfx (regbase, CL_GR28, (u_char) (ndest & 0xff));	/* BLT dest low */
-	vga_wgfx (regbase, CL_GR29, (u_char) (ndest >> 8));	/* BLT dest mid */
-	vga_wgfx (regbase, CL_GR2A, (u_char) (ndest >> 16));	/* BLT dest hi */
+	/* BLT dest low */
+	vga_wgfx(regbase, CL_GR28, (u_char) (ndest & 0xff));
+	/* BLT dest mid */
+	vga_wgfx(regbase, CL_GR29, (u_char) (ndest >> 8));
+	/* BLT dest hi */
+	vga_wgfx(regbase, CL_GR2A, (u_char) (ndest >> 16));
 
 	/* BLT source */
-	vga_wgfx (regbase, CL_GR2C, (u_char) (nsrc & 0xff));	/* BLT src low */
-	vga_wgfx (regbase, CL_GR2D, (u_char) (nsrc >> 8));		/* BLT src mid */
-	vga_wgfx (regbase, CL_GR2E, (u_char) (nsrc >> 16));	/* BLT src hi */
+	/* BLT src low */
+	vga_wgfx(regbase, CL_GR2C, (u_char) (nsrc & 0xff));
+	/* BLT src mid */
+	vga_wgfx(regbase, CL_GR2D, (u_char) (nsrc >> 8));
+	/* BLT src hi */
+	vga_wgfx(regbase, CL_GR2E, (u_char) (nsrc >> 16));
 
 	/* BLT mode */
-	vga_wgfx (regbase, CL_GR30, bltmode);	/* BLT mode */
+	vga_wgfx(regbase, CL_GR30, bltmode);	/* BLT mode */
 
 	/* BLT ROP: SrcCopy */
-	vga_wgfx (regbase, CL_GR32, 0x0d);		/* BLT ROP */
+	vga_wgfx(regbase, CL_GR32, 0x0d);	/* BLT ROP */
 
 	/* and finally: GO! */
-	vga_wgfx (regbase, CL_GR31, 0x02);		/* BLT Start/status */
+	vga_wgfx(regbase, CL_GR31, 0x02);	/* BLT Start/status */
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 /*******************************************************************
 	cirrusfb_RectFill()
 
 	perform accelerated rectangle fill
 ********************************************************************/
 
-static void cirrusfb_RectFill (u8 __iomem *regbase, int bits_per_pixel,
+static void cirrusfb_RectFill(u8 __iomem *regbase, int bits_per_pixel,
 		     u_short x, u_short y, u_short width, u_short height,
 		     u_char color, u_short line_length)
 {
@@ -2982,93 +3162,95 @@ static void cirrusfb_RectFill (u8 __iome
 	u_long ndest;
 	u_char op;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	nwidth = width - 1;
 	nheight = height - 1;
 
 	ndest = (y * line_length) + x;
 
-        cirrusfb_WaitBLT(regbase);
+	cirrusfb_WaitBLT(regbase);
 
 	/* pitch: set to line_length */
-	vga_wgfx (regbase, CL_GR24, line_length & 0xff);	/* dest pitch low */
-	vga_wgfx (regbase, CL_GR25, (line_length >> 8));	/* dest pitch hi */
-	vga_wgfx (regbase, CL_GR26, line_length & 0xff);	/* source pitch low */
-	vga_wgfx (regbase, CL_GR27, (line_length >> 8));	/* source pitch hi */
+	vga_wgfx(regbase, CL_GR24, line_length & 0xff);	/* dest pitch low */
+	vga_wgfx(regbase, CL_GR25, line_length >> 8);	/* dest pitch hi */
+	vga_wgfx(regbase, CL_GR26, line_length & 0xff);	/* source pitch low */
+	vga_wgfx(regbase, CL_GR27, line_length >> 8);	/* source pitch hi */
 
 	/* BLT width: actual number of pixels - 1 */
-	vga_wgfx (regbase, CL_GR20, nwidth & 0xff);	/* BLT width low */
-	vga_wgfx (regbase, CL_GR21, (nwidth >> 8));	/* BLT width hi */
+	vga_wgfx(regbase, CL_GR20, nwidth & 0xff);	/* BLT width low */
+	vga_wgfx(regbase, CL_GR21, nwidth >> 8);	/* BLT width hi */
 
 	/* BLT height: actual number of lines -1 */
-	vga_wgfx (regbase, CL_GR22, nheight & 0xff);		/* BLT height low */
-	vga_wgfx (regbase, CL_GR23, (nheight >> 8));		/* BLT width hi */
+	vga_wgfx(regbase, CL_GR22, nheight & 0xff);	/* BLT height low */
+	vga_wgfx(regbase, CL_GR23, nheight >> 8);	/* BLT width hi */
 
 	/* BLT destination */
-	vga_wgfx (regbase, CL_GR28, (u_char) (ndest & 0xff));	/* BLT dest low */
-	vga_wgfx (regbase, CL_GR29, (u_char) (ndest >> 8));	/* BLT dest mid */
-	vga_wgfx (regbase, CL_GR2A, (u_char) (ndest >> 16));		/* BLT dest hi */
+	/* BLT dest low */
+	vga_wgfx(regbase, CL_GR28, (u_char) (ndest & 0xff));
+	/* BLT dest mid */
+	vga_wgfx(regbase, CL_GR29, (u_char) (ndest >> 8));
+	/* BLT dest hi */
+	vga_wgfx(regbase, CL_GR2A, (u_char) (ndest >> 16));
 
 	/* BLT source: set to 0 (is a dummy here anyway) */
-	vga_wgfx (regbase, CL_GR2C, 0x00);	/* BLT src low */
-	vga_wgfx (regbase, CL_GR2D, 0x00);	/* BLT src mid */
-	vga_wgfx (regbase, CL_GR2E, 0x00);	/* BLT src hi */
+	vga_wgfx(regbase, CL_GR2C, 0x00);	/* BLT src low */
+	vga_wgfx(regbase, CL_GR2D, 0x00);	/* BLT src mid */
+	vga_wgfx(regbase, CL_GR2E, 0x00);	/* BLT src hi */
 
 	/* This is a ColorExpand Blt, using the */
 	/* same color for foreground and background */
-	vga_wgfx (regbase, VGA_GFX_SR_VALUE, color);	/* foreground color */
-	vga_wgfx (regbase, VGA_GFX_SR_ENABLE, color);	/* background color */
+	vga_wgfx(regbase, VGA_GFX_SR_VALUE, color);	/* foreground color */
+	vga_wgfx(regbase, VGA_GFX_SR_ENABLE, color);	/* background color */
 
 	op = 0xc0;
 	if (bits_per_pixel == 16) {
-		vga_wgfx (regbase, CL_GR10, color);	/* foreground color */
-		vga_wgfx (regbase, CL_GR11, color);	/* background color */
+		vga_wgfx(regbase, CL_GR10, color);	/* foreground color */
+		vga_wgfx(regbase, CL_GR11, color);	/* background color */
 		op = 0x50;
 		op = 0xd0;
 	} else if (bits_per_pixel == 32) {
-		vga_wgfx (regbase, CL_GR10, color);	/* foreground color */
-		vga_wgfx (regbase, CL_GR11, color);	/* background color */
-		vga_wgfx (regbase, CL_GR12, color);	/* foreground color */
-		vga_wgfx (regbase, CL_GR13, color);	/* background color */
-		vga_wgfx (regbase, CL_GR14, 0);	/* foreground color */
-		vga_wgfx (regbase, CL_GR15, 0);	/* background color */
+		vga_wgfx(regbase, CL_GR10, color);	/* foreground color */
+		vga_wgfx(regbase, CL_GR11, color);	/* background color */
+		vga_wgfx(regbase, CL_GR12, color);	/* foreground color */
+		vga_wgfx(regbase, CL_GR13, color);	/* background color */
+		vga_wgfx(regbase, CL_GR14, 0);	/* foreground color */
+		vga_wgfx(regbase, CL_GR15, 0);	/* background color */
 		op = 0x50;
 		op = 0xf0;
 	}
 	/* BLT mode: color expand, Enable 8x8 copy (faster?) */
-	vga_wgfx (regbase, CL_GR30, op);	/* BLT mode */
+	vga_wgfx(regbase, CL_GR30, op);	/* BLT mode */
 
 	/* BLT ROP: SrcCopy */
-	vga_wgfx (regbase, CL_GR32, 0x0d);	/* BLT ROP */
+	vga_wgfx(regbase, CL_GR32, 0x0d);	/* BLT ROP */
 
 	/* and finally: GO! */
-	vga_wgfx (regbase, CL_GR31, 0x02);	/* BLT Start/status */
+	vga_wgfx(regbase, CL_GR31, 0x02);	/* BLT Start/status */
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 /**************************************************************************
  * bestclock() - determine closest possible clock lower(?) than the
  * desired pixel clock
  **************************************************************************/
-static void bestclock (long freq, long *best, long *nom,
+static void bestclock(long freq, long *best, long *nom,
 		       long *den, long *div, long maxfreq)
 {
 	long n, h, d, f;
 
-	assert (best != NULL);
-	assert (nom != NULL);
-	assert (den != NULL);
-	assert (div != NULL);
-	assert (maxfreq > 0);
+	assert(best != NULL);
+	assert(nom != NULL);
+	assert(den != NULL);
+	assert(div != NULL);
+	assert(maxfreq > 0);
 
 	*nom = 0;
 	*den = 0;
 	*div = 0;
 
-	DPRINTK ("ENTER\n");
+	DPRINTK("ENTER\n");
 
 	if (freq < 8000)
 		freq = 8000;
@@ -3085,7 +3267,7 @@ static void bestclock (long freq, long *
 			if (d > 31)
 				d = (d / 2) * 2;
 			h = (14318 * n) / d;
-			if (abs (h - freq) < abs (*best - freq)) {
+			if (abs(h - freq) < abs(*best - freq)) {
 				*best = h;
 				*nom = n;
 				if (d < 32) {
@@ -3102,7 +3284,7 @@ static void bestclock (long freq, long *
 			if (d > 31)
 				d = (d / 2) * 2;
 			h = (14318 * n) / d;
-			if (abs (h - freq) < abs (*best - freq)) {
+			if (abs(h - freq) < abs(*best - freq)) {
 				*best = h;
 				*nom = n;
 				if (d < 32) {
@@ -3116,14 +3298,13 @@ static void bestclock (long freq, long *
 		}
 	}
 
-	DPRINTK ("Best possible values for given frequency:\n");
-	DPRINTK ("        best: %ld kHz  nom: %ld  den: %ld  div: %ld\n",
-		 freq, *nom, *den, *div);
+	DPRINTK("Best possible values for given frequency:\n");
+	DPRINTK("	best: %ld kHz  nom: %ld  den: %ld  div: %ld\n",
+		freq, *nom, *den, *div);
 
-	DPRINTK ("EXIT\n");
+	DPRINTK("EXIT\n");
 }
 
-
 /* -------------------------------------------------------------------------
  *
  * debugging functions
@@ -3145,21 +3326,20 @@ static void bestclock (long freq, long *
  */
 
 static
-void cirrusfb_dbg_print_byte (const char *name, unsigned char val)
+void cirrusfb_dbg_print_byte(const char *name, unsigned char val)
 {
-	DPRINTK ("%8s = 0x%02X (bits 7-0: %c%c%c%c%c%c%c%c)\n",
-		 name, val,
-		 val & 0x80 ? '1' : '0',
-		 val & 0x40 ? '1' : '0',
-		 val & 0x20 ? '1' : '0',
-		 val & 0x10 ? '1' : '0',
-		 val & 0x08 ? '1' : '0',
-		 val & 0x04 ? '1' : '0',
-		 val & 0x02 ? '1' : '0',
-		 val & 0x01 ? '1' : '0');
+	DPRINTK("%8s = 0x%02X (bits 7-0: %c%c%c%c%c%c%c%c)\n",
+		name, val,
+		val & 0x80 ? '1' : '0',
+		val & 0x40 ? '1' : '0',
+		val & 0x20 ? '1' : '0',
+		val & 0x10 ? '1' : '0',
+		val & 0x08 ? '1' : '0',
+		val & 0x04 ? '1' : '0',
+		val & 0x02 ? '1' : '0',
+		val & 0x01 ? '1' : '0');
 }
 
-
 /**
  * cirrusfb_dbg_print_regs
  * @base: If using newmmio, the newmmio base address, otherwise %NULL
@@ -3172,25 +3352,26 @@ void cirrusfb_dbg_print_byte (const char
  */
 
 static
-void cirrusfb_dbg_print_regs (caddr_t regbase, cirrusfb_dbg_reg_class_t reg_class,...)
+void cirrusfb_dbg_print_regs(caddr_t regbase,
+			     cirrusfb_dbg_reg_class_t reg_class, ...)
 {
 	va_list list;
 	unsigned char val = 0;
 	unsigned reg;
 	char *name;
 
-	va_start (list, reg_class);
+	va_start(list, reg_class);
 
-	name = va_arg (list, char *);
+	name = va_arg(list, char *);
 	while (name != NULL) {
-		reg = va_arg (list, int);
+		reg = va_arg(list, int);
 
 		switch (reg_class) {
 		case CRT:
-			val = vga_rcrt (regbase, (unsigned char) reg);
+			val = vga_rcrt(regbase, (unsigned char) reg);
 			break;
 		case SEQ:
-			val = vga_rseq (regbase, (unsigned char) reg);
+			val = vga_rseq(regbase, (unsigned char) reg);
 			break;
 		default:
 			/* should never occur */
@@ -3198,15 +3379,14 @@ void cirrusfb_dbg_print_regs (caddr_t re
 			break;
 		}
 
-		cirrusfb_dbg_print_byte (name, val);
+		cirrusfb_dbg_print_byte(name, val);
 
-		name = va_arg (list, char *);
+		name = va_arg(list, char *);
 	}
 
-	va_end (list);
+	va_end(list);
 }
 
-
 /**
  * cirrusfb_dump
  * @cirrusfbinfo:
@@ -3214,13 +3394,11 @@ void cirrusfb_dbg_print_regs (caddr_t re
  * DESCRIPTION:
  */
 
-static
-void cirrusfb_dump (void)
+static void cirrusfb_dump(void)
 {
-	cirrusfb_dbg_reg_dump (NULL);
+	cirrusfb_dbg_reg_dump(NULL);
 }
 
-
 /**
  * cirrusfb_dbg_reg_dump
  * @base: If using newmmio, the newmmio base address, otherwise %NULL
@@ -3232,11 +3410,11 @@ void cirrusfb_dump (void)
  */
 
 static
-void cirrusfb_dbg_reg_dump (caddr_t regbase)
+void cirrusfb_dbg_reg_dump(caddr_t regbase)
 {
-	DPRINTK ("CIRRUSFB VGA CRTC register dump:\n");
+	DPRINTK("CIRRUSFB VGA CRTC register dump:\n");
 
-	cirrusfb_dbg_print_regs (regbase, CRT,
+	cirrusfb_dbg_print_regs(regbase, CRT,
 			   "CR00", 0x00,
 			   "CR01", 0x01,
 			   "CR02", 0x02,
@@ -3286,11 +3464,11 @@ void cirrusfb_dbg_reg_dump (caddr_t regb
 			   "CR3F", 0x3F,
 			   NULL);
 
-	DPRINTK ("\n");
+	DPRINTK("\n");
 
-	DPRINTK ("CIRRUSFB VGA SEQ register dump:\n");
+	DPRINTK("CIRRUSFB VGA SEQ register dump:\n");
 
-	cirrusfb_dbg_print_regs (regbase, SEQ,
+	cirrusfb_dbg_print_regs(regbase, SEQ,
 			   "SR00", 0x00,
 			   "SR01", 0x01,
 			   "SR02", 0x02,
@@ -3319,7 +3497,7 @@ void cirrusfb_dbg_reg_dump (caddr_t regb
 			   "SR1F", 0x1F,
 			   NULL);
 
-	DPRINTK ("\n");
+	DPRINTK("\n");
 }
 
 #endif				/* CIRRUSFB_DEBUG */

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

(no subject)

[Tony Lindgren]

As the musb/tusb code now mostly works for host and peripheral,
I'm planning to push a series of search and replace patches
to start converting the musb/tusb driver into something that
follows CodingStyle.

Following is a list of changes I've done. I haven't gone through
DaVinci or 2430 specific code, as I cannot test them right now.
No functional changes should be included. Code has been tested
with tusb6010.

Regards,

Tony

[PATCH 1/52] musb_hdrc: Search and replace pThis with musb
[PATCH 2/52] musb_hdrc: Search and replace pEndPt with hw_ep
[PATCH 3/52] musb_hdrc: Search and replace pEnd with musb_ep when struct musb_ep
[PATCH 4/52] musb_hdrc: Search and replace pEnd with musb_ep when struct musb_hw_ep
[PATCH 5/52] musb_hdrc: Search and replace pRegs with mregs
[PATCH 6/52] musb_hdrc: Search and replace pBase with mbase
[PATCH 7/52] musb_hdrc: Search and replace pSource with src
[PATCH 8/52] musb_hdrc: Search and replace pDest with dst
[PATCH 9/52] musb_hdrc: Search and replace dwCount with len
[PATCH 10/52] musb_hdrc: Search and replace wFifoCount with fifo_count
[PATCH 11/52] musb_hdrc: Search and replace wCount with len
[PATCH 12/52] musb_hdrc: Search and replace bLocalEnd with epnum
[PATCH 13/52] musb_hdrc: Search and replace aLocalEnd with endpoints
[PATCH 14/52] musb_hdrc: Search and replace bEndCount with nr_endpoints
[PATCH 15/52] musb_hdrc: Search and replace bEndNumber with current_epnum
[PATCH 16/52] musb_hdrc: Search and replace bEnd0Stage with ep0_stage
[PATCH 17/52] musb_hdrc: Search and replace bEnd with epnum
[PATCH 18/52] musb_hdrc: Search and replace Lock with lock
[PATCH 19/52] musb_hdrc: Search and replace MGC_SelectEnd with musb_ep_select
[PATCH 20/52] musb_hdrc: Search and replace _pthis with _musb
[PATCH 21/52] musb_hdrc: Search and replace bIsHost with is_host
[PATCH 22/52] musb_hdrc: Get rid of old unused MUSB_EpFifoDescriptor
[PATCH 23/52] musb_hdrc: Search and replace bIsSharedFifo with is_shared_fifo
[PATCH 24/52] musb_hdrc: Search and replace wMaxPacketSizeTx with max_packet_sz_tx
[PATCH 25/52] musb_hdrc: Search and replace wMaxPacketSizeRx with max_packet_sz_rx
[PATCH 26/52] musb_hdrc: Search and replace pDmaController with dma_controller
[PATCH 27/52] musb_hdrc: Search and replace bIsMultipoint with is_multipoint
[PATCH 28/52] musb_hdrc: Search and replace bIgnoreDisconnect with ignore_disconnect
[PATCH 29/52] musb_hdrc: Search and replace bBulkSplit with bulk_split
[PATCH 30/52] musb_hdrc: Search and replace bBulkCombine with bulk_combine
[PATCH 31/52] musb_hdrc: Search and replace bAddress with address
[PATCH 32/52] musb_hdrc: Search and replace bTestModeValue with test_mode_nr
[PATCH 33/52] musb_hdrc: Search and replace bTestMode with test_mode
[PATCH 34/52] musb_hdrc: Search and replace pGadgetDriver with gadget_driver
[PATCH 35/52] musb_hdrc: Search and replace bDelayPortPowerOff with delay_port_power_off
[PATCH 36/52] musb_hdrc: Search and replace pProcEntry with proc_entry
[PATCH 37/52] musb_hdrc: Search and replace pPrivateData with private_data
[PATCH 38/52] musb_hdrc: Search and replace dwMaxLength with max_len
[PATCH 39/52] musb_hdrc: Search and replace dwActualLength with actual_len
[PATCH 40/52] musb_hdrc: Search and replace bStatus with status
[PATCH 41/52] musb_hdrc: Search and replace bDesiredMode with desired_mode
[PATCH 42/52] musb_hdrc: Search and replace bMode with mode
[PATCH 43/52] musb_hdrc: Search and replace MGC_pfDmaProgramChannel with dma_program_channel
[PATCH 44/52] musb_hdrc: Search and replace pControlRequest with ctrlrequest
[PATCH 45/52] musb_hdrc: Search and replace bResult with result
[PATCH 46/52] musb_hdrc: Search and replace bSetAddress with set_address
[PATCH 47/52] musb_hdrc: Search and replace bRecip with recip
[PATCH 48/52] musb_hdrc: Search and replace pRequest with request
[PATCH 49/52] musb_hdrc: Search and replace wCsrVal with csr
[PATCH 50/52] musb_hdrc: Search and replace bTx with tx
[PATCH 51/52] musb_hdrc: Search and replace wPacketSize with packet_sz
[PATCH 52/52] musb_hdrc: Search and replace channelNum with chnum

Re: (no subject)

[Felipe Balbi]

Hi Tony,

On 8/13/07, Tony Lindgren <tony@atomide.com> wrote:
> As the musb/tusb code now mostly works for host and peripheral,
> I'm planning to push a series of search and replace patches
> to start converting the musb/tusb driver into something that
> follows CodingStyle.
>
> Following is a list of changes I've done. I haven't gone through
> DaVinci or 2430 specific code, as I cannot test them right now.
> No functional changes should be included. Code has been tested
> with tusb6010.

Thanks a lot for your patch series... I was planning to do such
cleanup a while ago but got stuck on some activities and this has gone
to less priority queue.

Anyway, I'll try to get a time to test this patches and I'll report
you any trouble I find. :-)

>
> Regards,
>
> Tony
>
> [PATCH 1/52] musb_hdrc: Search and replace pThis with musb
> [PATCH 2/52] musb_hdrc: Search and replace pEndPt with hw_ep
> [PATCH 3/52] musb_hdrc: Search and replace pEnd with musb_ep when struct musb_ep
> [PATCH 4/52] musb_hdrc: Search and replace pEnd with musb_ep when struct musb_hw_ep
> [PATCH 5/52] musb_hdrc: Search and replace pRegs with mregs
> [PATCH 6/52] musb_hdrc: Search and replace pBase with mbase
> [PATCH 7/52] musb_hdrc: Search and replace pSource with src
> [PATCH 8/52] musb_hdrc: Search and replace pDest with dst
> [PATCH 9/52] musb_hdrc: Search and replace dwCount with len
> [PATCH 10/52] musb_hdrc: Search and replace wFifoCount with fifo_count
> [PATCH 11/52] musb_hdrc: Search and replace wCount with len
> [PATCH 12/52] musb_hdrc: Search and replace bLocalEnd with epnum
> [PATCH 13/52] musb_hdrc: Search and replace aLocalEnd with endpoints
> [PATCH 14/52] musb_hdrc: Search and replace bEndCount with nr_endpoints
> [PATCH 15/52] musb_hdrc: Search and replace bEndNumber with current_epnum
> [PATCH 16/52] musb_hdrc: Search and replace bEnd0Stage with ep0_stage
> [PATCH 17/52] musb_hdrc: Search and replace bEnd with epnum
> [PATCH 18/52] musb_hdrc: Search and replace Lock with lock
> [PATCH 19/52] musb_hdrc: Search and replace MGC_SelectEnd with musb_ep_select
> [PATCH 20/52] musb_hdrc: Search and replace _pthis with _musb
> [PATCH 21/52] musb_hdrc: Search and replace bIsHost with is_host
> [PATCH 22/52] musb_hdrc: Get rid of old unused MUSB_EpFifoDescriptor
> [PATCH 23/52] musb_hdrc: Search and replace bIsSharedFifo with is_shared_fifo
> [PATCH 24/52] musb_hdrc: Search and replace wMaxPacketSizeTx with max_packet_sz_tx
> [PATCH 25/52] musb_hdrc: Search and replace wMaxPacketSizeRx with max_packet_sz_rx
> [PATCH 26/52] musb_hdrc: Search and replace pDmaController with dma_controller
> [PATCH 27/52] musb_hdrc: Search and replace bIsMultipoint with is_multipoint
> [PATCH 28/52] musb_hdrc: Search and replace bIgnoreDisconnect with ignore_disconnect
> [PATCH 29/52] musb_hdrc: Search and replace bBulkSplit with bulk_split
> [PATCH 30/52] musb_hdrc: Search and replace bBulkCombine with bulk_combine
> [PATCH 31/52] musb_hdrc: Search and replace bAddress with address
> [PATCH 32/52] musb_hdrc: Search and replace bTestModeValue with test_mode_nr
> [PATCH 33/52] musb_hdrc: Search and replace bTestMode with test_mode
> [PATCH 34/52] musb_hdrc: Search and replace pGadgetDriver with gadget_driver
> [PATCH 35/52] musb_hdrc: Search and replace bDelayPortPowerOff with delay_port_power_off
> [PATCH 36/52] musb_hdrc: Search and replace pProcEntry with proc_entry
> [PATCH 37/52] musb_hdrc: Search and replace pPrivateData with private_data
> [PATCH 38/52] musb_hdrc: Search and replace dwMaxLength with max_len
> [PATCH 39/52] musb_hdrc: Search and replace dwActualLength with actual_len
> [PATCH 40/52] musb_hdrc: Search and replace bStatus with status
> [PATCH 41/52] musb_hdrc: Search and replace bDesiredMode with desired_mode
> [PATCH 42/52] musb_hdrc: Search and replace bMode with mode
> [PATCH 43/52] musb_hdrc: Search and replace MGC_pfDmaProgramChannel with dma_program_channel
> [PATCH 44/52] musb_hdrc: Search and replace pControlRequest with ctrlrequest
> [PATCH 45/52] musb_hdrc: Search and replace bResult with result
> [PATCH 46/52] musb_hdrc: Search and replace bSetAddress with set_address
> [PATCH 47/52] musb_hdrc: Search and replace bRecip with recip
> [PATCH 48/52] musb_hdrc: Search and replace pRequest with request
> [PATCH 49/52] musb_hdrc: Search and replace wCsrVal with csr
> [PATCH 50/52] musb_hdrc: Search and replace bTx with tx
> [PATCH 51/52] musb_hdrc: Search and replace wPacketSize with packet_sz
> [PATCH 52/52] musb_hdrc: Search and replace channelNum with chnum
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>


-- 
Best Regards,

Felipe Balbi
felipebalbi@users.sourceforge.net

(no subject)

[Izik Eidus]

[-- Attachment #1.1: Type: text/plain, Size: 422 bytes --]

we are working on swapping support for the guests in kvm.
we want to allow management of the memory swapping of the guests from kvm.

i wrote this patch that move the guest allocated memory from the kernel to the userspace for better management.
plus in this way it will share more code for such soultion with s390 and other archs.

this is request for comment, so any idea you have please write to me.

thanks


[-- Attachment #1.2: Type: text/html, Size: 807 bytes --]

[-- Attachment #2: kvmctl_patch --]
[-- Type: application/octet-stream, Size: 3666 bytes --]

diff --git a/user/kvmctl.c b/user/kvmctl.c
index 43b374d..887cb63 100644
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -239,12 +239,13 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 	int fd = kvm->fd;
 	int zfd;
 	int r;
-	struct kvm_memory_region low_memory = {
+
+	struct kvm_host_memory_region low_memory = {
 		.slot = 3,
 		.memory_size = memory  < dosmem ? memory : dosmem,
 		.guest_phys_addr = 0,
 	};
-	struct kvm_memory_region extended_memory = {
+	struct kvm_host_memory_region extended_memory = {
 		.slot = 0,
 		.memory_size = memory < exmem ? 0 : memory - exmem,
 		.guest_phys_addr = exmem,
@@ -259,14 +260,41 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 	}
 	kvm->vm_fd = fd;
 
+	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+	if (*vm_mem == MAP_FAILED) {
+		fprintf(stderr, "kvm_create: %s", strerror(errno));
+		return -1;
+	}
+
+	r = munmap(memory + dosmem, exmem - dosmem);
+	if (r == -1) {
+		fprintf(stderr, "kvm_create: %s", strerror(errno));
+		return -1;
+	}
+
+	memset(*vm_mem, 0, dosmem);
+	memset(*vm_mem + exmem, 0, memory - exmem);
+
 	/* 640K should be enough. */
-	r = ioctl(fd, KVM_SET_MEMORY_REGION, &low_memory);
+	low_memory.guest_host_addr = *vm_mem;
+	if (!low_memory.guest_host_addr) {
+		fprintf(stderr, "kvm_create: %s", strerror(errno));
+		return -1;
+	}
+
+	r = ioctl(fd, KVM_SET_USER_MEMORY_REGION, &low_memory);
 	if (r == -1) {
 		fprintf(stderr, "kvm_create_memory_region: %m\n");
 		return -1;
 	}
 	if (extended_memory.memory_size) {
-		r = ioctl(fd, KVM_SET_MEMORY_REGION, &extended_memory);
+		extended_memory.guest_host_addr = *vm_mem + exmem;
+		if (!extended_memory.guest_host_addr) {
+			fprintf(stderr, "kvm_create: %s", strerror(errno));
+			return -1;
+		}
+
+		r = ioctl(fd, KVM_SET_USER_MEMORY_REGION, &extended_memory);
 		if (r == -1) {
 			fprintf(stderr, "kvm_create_memory_region: %m\n");
 			return -1;
@@ -276,11 +304,6 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 	kvm_memory_region_save_params(kvm, &low_memory);
 	kvm_memory_region_save_params(kvm, &extended_memory);
 
-	*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
-	if (*vm_mem == MAP_FAILED) {
-		fprintf(stderr, "mmap: %m\n");
-		return -1;
-	}
 	kvm->physical_memory = *vm_mem;
 
 	zfd = open("/dev/zero", O_RDONLY);
@@ -291,7 +314,7 @@ int kvm_create(kvm_context_t kvm, unsigned long memory, void **vm_mem)
 	r = kvm_create_vcpu(kvm, 0);
 	if (r < 0)
 		return r;
-
+	
 	return 0;
 }
 
@@ -302,25 +325,36 @@ void *kvm_create_phys_mem(kvm_context_t kvm, unsigned long phys_start,
 	int r;
 	int fd = kvm->vm_fd;
 	int prot = PROT_READ;
-	struct kvm_memory_region memory = {
+	struct kvm_host_memory_region memory = {
 		.slot = slot,
 		.memory_size = len,
 		.guest_phys_addr = phys_start,
 		.flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
 	};
-
-	r = ioctl(fd, KVM_SET_MEMORY_REGION, &memory);
+	
+	if (writable)
+		prot |= PROT_WRITE;
+	
+	ptr = mmap(NULL, len, prot, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+	if (ptr == MAP_FAILED) {
+		fprintf(stderr, "kvm_create_phys_mem: %s", strerror(errno));
+		return -1;
+	}
+	
+	memset(ptr, 0, len);
+	
+	memory.guest_host_addr = ptr;
+	if (!memory.guest_host_addr) {
+		fprintf(stderr, "kvm_create_phys_mem: %s", strerror(errno));
+		return 0;
+	}
+	
+	r = ioctl(fd, KVM_SET_USER_MEMORY_REGION, &memory);
 	if (r == -1)
 	    return 0;
 
 	kvm_memory_region_save_params(kvm, &memory);
 
-	if (writable)
-		prot |= PROT_WRITE;
-
-	ptr = mmap(NULL, len, prot, MAP_SHARED, fd, phys_start);
-	if (ptr == MAP_FAILED)
-		return 0;
 	return ptr;
 }
 

[-- Attachment #3: kvm_kernel_patch --]
[-- Type: application/octet-stream, Size: 8168 bytes --]

diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index fc27c2f..a94714f 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -415,6 +415,7 @@ struct kvm_memory_slot {
 	unsigned long flags;
 	struct page **phys_mem;
 	unsigned long *dirty_bitmap;
+	int user_alloc; /* user allocated memory */
 };
 
 struct kvm {
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bc11c2d..1e6fa58 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -37,6 +37,7 @@
 #include <linux/cpumask.h>
 #include <linux/smp.h>
 #include <linux/anon_inodes.h>
+#include <linux/pagemap.h>
 
 #include <asm/processor.h>
 #include <asm/msr.h>
@@ -322,19 +323,40 @@ static int kvm_dev_open(struct inode *inode, struct file *filp)
 	return 0;
 }
 
+static void kvm_free_userspace_physmem(struct kvm_memory_slot *free)
+{
+	int i;
+	
+	for (i = 0; i < free->npages; ++i) {
+		if (free->phys_mem[i]) {
+			if (!PageReserved(free->phys_mem[i]))
+				SetPageDirty(free->phys_mem[i]);
+			page_cache_release(free->phys_mem[i]);
+		}
+	}
+}
+
+static void kvm_free_kernel_physmem(struct kvm_memory_slot *free)
+{
+	int i;
+	
+	for (i = 0; i < free->npages; ++i)
+		if (free->phys_mem[i])
+			__free_page(free->phys_mem[i]);
+}
+
 /*
  * Free any memory in @free but not in @dont.
  */
 static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
 				  struct kvm_memory_slot *dont)
 {
-	int i;
-
 	if (!dont || free->phys_mem != dont->phys_mem)
 		if (free->phys_mem) {
-			for (i = 0; i < free->npages; ++i)
-				if (free->phys_mem[i])
-					__free_page(free->phys_mem[i]);
+			if (free->user_alloc)
+				kvm_free_userspace_physmem(free);
+			else
+				kvm_free_kernel_physmem(free);
 			vfree(free->phys_mem);
 		}
 
@@ -670,7 +692,8 @@ EXPORT_SYMBOL_GPL(fx_init);
  * Discontiguous memory is allowed, mostly for framebuffers.
  */
 static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
-					  struct kvm_memory_region *mem)
+					  struct kvm_memory_region *mem,
+						unsigned long guest_host_addr)
 {
 	int r;
 	gfn_t base_gfn;
@@ -748,12 +771,26 @@ raced:
 			goto out_free;
 
 		memset(new.phys_mem, 0, npages * sizeof(struct page *));
-		for (i = 0; i < npages; ++i) {
-			new.phys_mem[i] = alloc_page(GFP_HIGHUSER
-						     | __GFP_ZERO);
-			if (!new.phys_mem[i])
+		
+		if (guest_host_addr) {
+			unsigned long pages_num;
+			
+			new.user_alloc = 1;
+			down_read(&current->mm->mmap_sem);
+			pages_num = get_user_pages(current, current->mm, guest_host_addr,
+								npages, 1, 0, new.phys_mem, NULL);
+			up_read(&current->mm->mmap_sem);
+			if (pages_num != npages)
 				goto out_free;
-			set_page_private(new.phys_mem[i],0);
+		} else {
+			new.user_alloc = 0;
+			for (i = 0; i < npages; ++i) {
+				new.phys_mem[i] = alloc_page(GFP_HIGHUSER
+							     | __GFP_ZERO);
+				if (!new.phys_mem[i])
+					goto out_free;
+				set_page_private(new.phys_mem[i],0);
+			}
 		}
 	}
 
@@ -2772,10 +2809,32 @@ static long kvm_vm_ioctl(struct file *filp,
 		r = -EFAULT;
 		if (copy_from_user(&kvm_mem, argp, sizeof kvm_mem))
 			goto out;
-		r = kvm_vm_ioctl_set_memory_region(kvm, &kvm_mem);
+		r = kvm_vm_ioctl_set_memory_region(kvm, &kvm_mem, 0);
+		if (r)
+			goto out;
+		break;
+	}
+	case KVM_SET_USER_MEMORY_REGION: {
+		struct kvm_memory_region kvm_mem;
+		struct kvm_host_memory_region kvm_host_mem;
+		r = -EFAULT;
+		if (copy_from_user(&kvm_host_mem, argp, sizeof kvm_host_mem))
+			goto out;
+
+		if (!kvm_host_mem.guest_host_addr)
+			goto out;		
+
+		kvm_mem.slot = kvm_host_mem.slot;
+		kvm_mem.flags = kvm_host_mem.flags;
+		kvm_mem.guest_phys_addr = kvm_host_mem.guest_phys_addr;
+		kvm_mem.memory_size = kvm_host_mem.memory_size;
+		
+		r = kvm_vm_ioctl_set_memory_region(kvm, &kvm_mem,
+					kvm_host_mem.guest_host_addr);
 		if (r)
 			goto out;
 		break;
+
 	}
 	case KVM_GET_DIRTY_LOG: {
 		struct kvm_dirty_log log;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 91a446f..e53e70e 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -23,6 +23,15 @@ struct kvm_memory_region {
 	__u64 memory_size; /* bytes */
 };
 
+/* for KVM_SET_USER_MEMORY_REGION */
+struct kvm_host_memory_region {
+	__u32 slot;
+	__u32 flags;
+	__u64 guest_phys_addr;
+	__u64 memory_size; /* bytes */
+	__u64 guest_host_addr; /* host userspace allocated memory address */
+};
+
 /* for kvm_memory_region::flags */
 #define KVM_MEM_LOG_DIRTY_PAGES  1UL
 
@@ -254,47 +263,50 @@ struct kvm_signal_mask {
 /*
  * ioctls for /dev/kvm fds:
  */
-#define KVM_GET_API_VERSION       _IO(KVMIO,   0x00)
-#define KVM_CREATE_VM             _IO(KVMIO,   0x01) /* returns a VM fd */
-#define KVM_GET_MSR_INDEX_LIST    _IOWR(KVMIO, 0x02, struct kvm_msr_list)
+#define KVM_GET_API_VERSION        _IO(KVMIO,   0x00)
+#define KVM_CREATE_VM              _IO(KVMIO,   0x01) /* returns a VM fd */
+#define KVM_GET_MSR_INDEX_LIST     _IOWR(KVMIO, 0x02, struct kvm_msr_list)
 /*
  * Check if a kvm extension is available.  Argument is extension number,
  * return is 1 (yes) or 0 (no, sorry).
  */
-#define KVM_CHECK_EXTENSION       _IO(KVMIO,   0x03)
+#define KVM_CHECK_EXTENSION        _IO(KVMIO,   0x03)
 /*
  * Get size for mmap(vcpu_fd)
  */
-#define KVM_GET_VCPU_MMAP_SIZE    _IO(KVMIO,   0x04) /* in bytes */
+#define KVM_GET_VCPU_MMAP_SIZE     _IO(KVMIO,   0x04) /* in bytes */
 
 /*
  * ioctls for VM fds
  */
-#define KVM_SET_MEMORY_REGION     _IOW(KVMIO, 0x40, struct kvm_memory_region)
+#define KVM_SET_MEMORY_REGION      _IOW(KVMIO, 0x40, struct kvm_memory_region)
+#define KVM_SET_USER_MEMORY_REGION _IOW(KVMIO, 0x44,\
+					 struct kvm_host_memory_region)
+
 /*
  * KVM_CREATE_VCPU receives as a parameter the vcpu slot, and returns
  * a vcpu fd.
  */
-#define KVM_CREATE_VCPU           _IO(KVMIO,  0x41)
-#define KVM_GET_DIRTY_LOG         _IOW(KVMIO, 0x42, struct kvm_dirty_log)
-#define KVM_SET_MEMORY_ALIAS      _IOW(KVMIO, 0x43, struct kvm_memory_alias)
+#define KVM_CREATE_VCPU            _IO(KVMIO,  0x41)
+#define KVM_GET_DIRTY_LOG          _IOW(KVMIO, 0x42, struct kvm_dirty_log)
+#define KVM_SET_MEMORY_ALIAS       _IOW(KVMIO, 0x43, struct kvm_memory_alias)
 
 /*
  * ioctls for vcpu fds
  */
-#define KVM_RUN                   _IO(KVMIO,   0x80)
-#define KVM_GET_REGS              _IOR(KVMIO,  0x81, struct kvm_regs)
-#define KVM_SET_REGS              _IOW(KVMIO,  0x82, struct kvm_regs)
-#define KVM_GET_SREGS             _IOR(KVMIO,  0x83, struct kvm_sregs)
-#define KVM_SET_SREGS             _IOW(KVMIO,  0x84, struct kvm_sregs)
-#define KVM_TRANSLATE             _IOWR(KVMIO, 0x85, struct kvm_translation)
-#define KVM_INTERRUPT             _IOW(KVMIO,  0x86, struct kvm_interrupt)
-#define KVM_DEBUG_GUEST           _IOW(KVMIO,  0x87, struct kvm_debug_guest)
-#define KVM_GET_MSRS              _IOWR(KVMIO, 0x88, struct kvm_msrs)
-#define KVM_SET_MSRS              _IOW(KVMIO,  0x89, struct kvm_msrs)
-#define KVM_SET_CPUID             _IOW(KVMIO,  0x8a, struct kvm_cpuid)
-#define KVM_SET_SIGNAL_MASK       _IOW(KVMIO,  0x8b, struct kvm_signal_mask)
-#define KVM_GET_FPU               _IOR(KVMIO,  0x8c, struct kvm_fpu)
-#define KVM_SET_FPU               _IOW(KVMIO,  0x8d, struct kvm_fpu)
+#define KVM_RUN                    _IO(KVMIO,   0x80)
+#define KVM_GET_REGS               _IOR(KVMIO,  0x81, struct kvm_regs)
+#define KVM_SET_REGS               _IOW(KVMIO,  0x82, struct kvm_regs)
+#define KVM_GET_SREGS              _IOR(KVMIO,  0x83, struct kvm_sregs)
+#define KVM_SET_SREGS              _IOW(KVMIO,  0x84, struct kvm_sregs)
+#define KVM_TRANSLATE              _IOWR(KVMIO, 0x85, struct kvm_translation)
+#define KVM_INTERRUPT              _IOW(KVMIO,  0x86, struct kvm_interrupt)
+#define KVM_DEBUG_GUEST            _IOW(KVMIO,  0x87, struct kvm_debug_guest)
+#define KVM_GET_MSRS               _IOWR(KVMIO, 0x88, struct kvm_msrs)
+#define KVM_SET_MSRS               _IOW(KVMIO,  0x89, struct kvm_msrs)
+#define KVM_SET_CPUID              _IOW(KVMIO,  0x8a, struct kvm_cpuid)
+#define KVM_SET_SIGNAL_MASK        _IOW(KVMIO,  0x8b, struct kvm_signal_mask)
+#define KVM_GET_FPU                _IOR(KVMIO,  0x8c, struct kvm_fpu)
+#define KVM_SET_FPU                _IOW(KVMIO,  0x8d, struct kvm_fpu)
 
 #endif

[-- Attachment #4: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #5: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: (no subject)

[Anthony Liguori]

Hi Izik,

On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote:
> we are working on swapping support for the guests in kvm.
> we want to allow management of the memory swapping of the guests from
> kvm.
> 
> i wrote this patch that move the guest allocated memory from the
> kernel to the userspace for better management.
> plus in this way it will share more code for such soultion with s390
> and other archs.

Do we care much about maintaining the kvmctl API?  I ask because I think
it would be nice to provide a pointer to kvmctl instead of having it
allocate the memory.  I think there are a few advantages to this.

It simplifies the QEMU patch and it allows for the logic for choosing
how memory is allocated to be done in QEMU.  I'm thinking about things
like allocating memory from hugetlbfs.  Since large pages are a sparse
commodity, I don't think we want to use large pages unless the user asks
us to.  Seems like this logic is best suited to be in QEMU to me.

Otherwise, this page seems pretty good to me.

There's some whitespace damage in this patch to btw.

Regards,

Anthony Liguori


> this is request for comment, so any idea you have please write to me.
> 
> thanks
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: (no subject)

[Avi Kivity]

Anthony Liguori wrote:
> Hi Izik,
>
> On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote:
>   
>> we are working on swapping support for the guests in kvm.
>> we want to allow management of the memory swapping of the guests from
>> kvm.
>>
>> i wrote this patch that move the guest allocated memory from the
>> kernel to the userspace for better management.
>> plus in this way it will share more code for such soultion with s390
>> and other archs.
>>     
>
> Do we care much about maintaining the kvmctl API?  

Not so much at this time.  We will later on (it will also be a dynamic 
library at that time).

> I ask because I think
> it would be nice to provide a pointer to kvmctl instead of having it
> allocate the memory.  I think there are a few advantages to this.
>
> It simplifies the QEMU patch and it allows for the logic for choosing
> how memory is allocated to be done in QEMU.  I'm thinking about things
> like allocating memory from hugetlbfs.  Since large pages are a sparse
> commodity, I don't think we want to use large pages unless the user asks
> us to.  Seems like this logic is best suited to be in QEMU to me.
>   

Yes, that is one of the motivations for this patch.  Indeed it is a lot 
closer than guest paging.

However this can be modified later, let's keep this patchset small for now.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: (no subject)

[Carsten Otte]

Izik Eidus wrote:
> we are working on swapping support for the guests in kvm.
> we want to allow management of the memory swapping of the guests from kvm.
This is excellent, thank you!

> this is request for comment, so any idea you have please write to me.
I ran into a few while reading the code:

+static void kvm_free_userspace_physmem(struct kvm_memory_slot *free)
+{
+	int i;
+	
+	for (i = 0; i < free->npages; ++i) {
+		if (free->phys_mem[i]) {
+			if (!PageReserved(free->phys_mem[i]))
+				SetPageDirty(free->phys_mem[i]);
+			page_cache_release(free->phys_mem[i]);
+		}
+	}
+}
I don't see why we would want to dirty a page we release in general. 
We do only need to dirty it, if the corresponding page table entry 
indicates so (dirty bit). Did I miss something?



@@ -670,7 +692,8 @@ EXPORT_SYMBOL_GPL(fx_init);
   * Discontiguous memory is allowed, mostly for framebuffers.
   */
  static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
-					  struct kvm_memory_region *mem)
+					  struct kvm_memory_region *mem,
+						unsigned long guest_host_addr)
  {
  	int r;
  	gfn_t base_gfn;
@@ -748,12 +771,26 @@ raced:
  			goto out_free;

  		memset(new.phys_mem, 0, npages * sizeof(struct page *));
-		for (i = 0; i < npages; ++i) {
-			new.phys_mem[i] = alloc_page(GFP_HIGHUSER
-						     | __GFP_ZERO);
-			if (!new.phys_mem[i])
+		
+		if (guest_host_addr) {
+			unsigned long pages_num;
+			
+			new.user_alloc = 1;
+			down_read(&current->mm->mmap_sem);
+			pages_num = get_user_pages(current, current->mm, guest_host_addr,
+								npages, 1, 0, new.phys_mem, NULL);
+			up_read(&current->mm->mmap_sem);
+			if (pages_num != npages)
  				goto out_free;
-			set_page_private(new.phys_mem[i],0);
+		} else {
+			new.user_alloc = 0;
+			for (i = 0; i < npages; ++i) {
+				new.phys_mem[i] = alloc_page(GFP_HIGHUSER
+							     | __GFP_ZERO);
+				if (!new.phys_mem[i])
+					goto out_free;
+				set_page_private(new.phys_mem[i],0);
+			}
  		}
  	}
Do we intend to maintain both pathes in the long run, or wait until we 
don't care about ancient userland anymore that does'nt do the 
allocation on its own?


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[Reza schutter]

B,U,L,L MARKET R_E_PORT!!!
Insider B_u_ying A-l-e-r-t!!!

Tr Date: Friday, Aug 10, 2007
Com: P-R-I_M_E T.I.M.E GROUP INC
Symbol: (P)(R)(T)(H)
Cur Pr: $0.105
Thur Close: Gain (19.32%)
Recomm: S!trong B.u.y/H.o.l.d

DO YOU LOVE T_R-A-D-I-N_G P*ENNY S,T.O,C.K,S?
[P][R][T][H] WILL MOVE LIKE A COMET AND ITS
ONLY GOING TO GET BETTER!
Wat ch this S-U.P-E.RNOVA closely FRIDAY!

(no subject)

[grikxd]

[-- Attachment #1.1: Type: text/plain, Size: 23 bytes --]






grikxd
2007-08-10

[-- Attachment #1.2: Type: text/html, Size: 524 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Harlan Kellis]

LIVE FROM THE STREET!

Sym: (P R T H)
Price: .088

Announces the Opening of Two New Stores by
(P.I.NKSH.E.ETS: P R T H) is pleased to announce that Puerto Rico 7, Inc. has
opened two new stores. The stores are recorded as Pinero II and Borinquen
Towers. Both locations were researched demographically to deliver above
average sales due to high traffic streets and communities directly
surrounding the stores. The Management team believes that the stores will
each quickly reach an annualized run rate of 1.2 Million dollars of sales.

IMAGINE IF YOU HAD THE CHANCE TO BUY A WAL-MART FRANCHISE IN MEXICO
RIGHT WHEN IT FIRST OPENED ITS DOORS THERE  AND ALL YOU NEEDED WAS A
SMALL STAKE TO GET IN.

Hurry, we see this stock starting to make the turn NOW.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[采购成本降低技巧及供应商管理]

[-- Attachment #1.1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.1.2: Type: text/html, Size: 483 bytes --]

[-- Attachment #1.2: "供应商001.gif" --]
[-- Type: image/gif, Size: 22189 bytes --]

[-- Attachment #1.3: "供应商002.gif" --]
[-- Type: image/gif, Size: 13326 bytes --]

[-- Attachment #1.4: "供应商003.gif" --]
[-- Type: image/gif, Size: 15047 bytes --]

[-- Attachment #1.5: "供应商004.gif" --]
[-- Type: image/gif, Size: 25558 bytes --]

[-- Attachment #1.6: "供应商005.gif" --]
[-- Type: image/gif, Size: 8659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Jean]

[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.2: Type: text/html, Size: 319 bytes --]

[-- Attachment #2: Mailbody.pdf --]
[-- Type: application/pdf, Size: 20498 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Piotr Kandziora]

Dear All,

Hi, I have some issue with NFS exporting. I am using Debian with 2.6.17-13 kernel, NFS 1.0.9, portmap 5-9 and LVM2 as NFS server. I have also a share which is exported via NFS. When I extend Logical Volume where the share is located on my clients I have to re-mount the share, but not on all.
Debian and Gentoo distribution can handle with this, but on Mandriva, Ubuntu and Solaris systems I get "NFS file handle", when I tro to access to it.
According to my investigation it is not related to kernel or portmap versions of clients.

-work good(without remounting):
    -Debian with portmap 6-0 and 2.6.21 kernel
    -Gentoo with portmap 5-0 and 2.6.16 kernel
-did not work - remount was needed:
    -Mandriva with portmap 4-0 and 6-0 and 2.6.17 kernel
    -Ubuntu with portmap 5-0 2.6.20 kernel

Did I miss something? What is this related to? Please help - in my environment we have many Linux clients different distribution and it is not desired to remount. I must also mention that the same behaviour I get after restarting the server.

Best Regards

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Piotr Kandziora]

Server NFS: 192.168.0.166
client 1: 192.168.0.169
client 2: 192.168.0.183

showmount output on server:
# showmount -a
All mount points on hostname:
*:/aa
*:/bb
192.168.0.169:*
192.168.0.183:*

# cat /var/lib/nfs/rmtab
192.168.0.183:*:0x00000001
*:/aa:0x00000002
192.168.0.169:*:0x00000002
*:/bb:0x00000002

client 1:
# mount|grep 166
192.168.0.166:/aa on /mnt/tmp0 type nfs (rw,addr=192.168.0.166)
192.168.0.166:/bb on /mnt/tmp1 type nfs (rw,addr=192.168.0.166)

client 2:
# mount|grep 166
192.168.0.166:/aa on /mnt/tmp0 type nfs
(rw,vers=3,rsize=32768,wsize=32768,hard,proto=udp,timeo=7,retrans=3,addr=192.168.0.166)

On client 1 there are mounted two shares (aa and bb), on client 2 only one share (aa).

My questions are:

How to get information about mounted shares on concrete clients from showmount or other command?

What is meaning of asterisks in showmount output?




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Jeff Layton]

On Thu, 02 Aug 2007 09:24:28 +0200
Piotr Kandziora <raveen@tlen.pl> wrote:

> Server NFS: 192.168.0.166
> client 1: 192.168.0.169
> client 2: 192.168.0.183
> 
> showmount output on server:
> # showmount -a
> All mount points on hostname:
> *:/aa
> *:/bb
> 192.168.0.169:*
> 192.168.0.183:*
> 
> # cat /var/lib/nfs/rmtab
> 192.168.0.183:*:0x00000001
> *:/aa:0x00000002
> 192.168.0.169:*:0x00000002
> *:/bb:0x00000002
> 
> client 1:
> # mount|grep 166
> 192.168.0.166:/aa on /mnt/tmp0 type nfs (rw,addr=192.168.0.166)
> 192.168.0.166:/bb on /mnt/tmp1 type nfs (rw,addr=192.168.0.166)
> 
> client 2:
> # mount|grep 166
> 192.168.0.166:/aa on /mnt/tmp0 type nfs
> (rw,vers=3,rsize=32768,wsize=32768,hard,proto=udp,timeo=7,retrans=3,addr=192.168.0.166)
> 
> On client 1 there are mounted two shares (aa and bb), on client 2 only one share (aa).
> 
> My questions are:
> 
> How to get information about mounted shares on concrete clients from showmount or other command?
> 

This info will never be reliable -- see the notes on rmtab in
rpc.mountd(8).

> What is meaning of asterisks in showmount output?

The nfs-utils rmtab handling code was recently fixed a few months ago.
You're likely running older code that's inserting these bogus entries
into the rmtab for each mount.

-- 
Jeff Layton <jlayton@redhat.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Mahoney O.Becky]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: facts.pdf --]
[-- Type: application/pdf, Size: 6345 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Trujillo]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: advertisement.pdf --]
[-- Type: application/pdf, Size: 5682 bytes --]

[-- Attachment #3: SpamAssassinReport.txt --]
[-- Type: text/plain, Size: 780 bytes --]

Spam detection software, running on the system "daredevil.linux-foundation.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  [...] 

Content analysis details:   (6.8 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.0 BAYES_95               BODY: Bayesian spam probability is 95 to 99%
                            [score: 0.9658]
 2.0 MISSING_SUBJECT        Missing Subject: header
 1.7 EMPTY_MESSAGE          Message appears to be empty with no Subject: text



[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

(no subject)

[Hooper]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Invitation.pdf --]
[-- Type: application/pdf, Size: 2039 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

(no subject)

[Vivien Gilmore]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Readme.pdf --]
[-- Type: application/pdf, Size: 9187 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

(no subject)

[Neville]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: e-mail.pdf --]
[-- Type: application/pdf, Size: 15361 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

(no subject)

[Smartschan]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: bull_report-4223823117.zip --]
[-- Type: application/octet-stream, Size: 5933 bytes --]

[-- Attachment #3: SpamAssassinReport.txt --]
[-- Type: text/plain, Size: 777 bytes --]

Spam detection software, running on the system "daredevil.linux-foundation.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  [...] 

Content analysis details:   (5.1 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.0 BAYES_60               BODY: Bayesian spam probability is 60 to 80%
                            [score: 0.6020]
 2.0 MISSING_SUBJECT        Missing Subject: header
 2.1 INVALID_MSGID          Message-Id is not valid, according to RFC 2822



[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

(no subject)

[Hendrickson L. Maggie]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: article.pdf --]
[-- Type: application/pdf, Size: 10748 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Watkins S. Valentine]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: article.pdf --]
[-- Type: application/pdf, Size: 10748 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[White]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: cashed.pdf --]
[-- Type: application/pdf, Size: 11242 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Agatha C. Walter]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Readme.pdf --]
[-- Type: application/pdf, Size: 12601 bytes --]

[-- Attachment #3: SpamAssassinReport.txt --]
[-- Type: text/plain, Size: 780 bytes --]

Spam detection software, running on the system "daredevil.linux-foundation.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  [...] 

Content analysis details:   (6.8 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.0 BAYES_95               BODY: Bayesian spam probability is 95 to 99%
                            [score: 0.9827]
 2.0 MISSING_SUBJECT        Missing Subject: header
 1.7 EMPTY_MESSAGE          Message appears to be empty with no Subject: text



[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Stacy Lilly]

Try Penis Enlarge Patch  you will be happy with the results.

http://www.libiorn.net/

Dont forget that shipping is free for on-line orders of Penis Enlarge Patch. 














------------------------
Storks away. But  when  the  bytheraging,  firesurrounded Nest ITSELF caught
   He went away blindly into the darkest part of the cellar. It was very black there, but his eyes stared wide before him. It was very cold, but drops of sweat stood on his forehead as if he were in the hayfield. He was alone, but his lips moved from time to time, and once he called out in some loud, stifled exclamation which resounded hollowly in the vault-like place. He was there a long time. 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[Blanchard R. Tim]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: request.pdf --]
[-- Type: application/pdf, Size: 20845 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Frederick]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: request.pdf --]
[-- Type: application/pdf, Size: 22591 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: (no subject)

[Olive Crosby]

Penis Enlarge Patch - the formula is proven.

http://www.pafrac.com/

Going on a date - than improve your shape with Penis Enlarge Patch.














------------------------
   Where should he go? He was dazed by the unlimited possibilities before him. To Boston first, as the nearest seaport. He had taken the trip in his mind so many times that he knew the exact minute when the train would cross the state line and he would be really escaped from the net which had bound him all his life. From Boston to Jamaica as the nearest place that was quite, quite different from Vermont. He had no desire to see Europe or England. Life there was too much like what he had known. He wanted to be in a country where nothing should remind him of his past. From Jamaica where? His stiff old fingers painfully traced out a steamship line to the Isthmus and thence to Colombia. He knew nothing about that country. All the better. It would be the more foreign. Only this he knew, that nobody in that tropical country farmed it, and that was where he wanted to go. From Colombia around th
 e Cape to Argentina. He was aghast at the cost, but instantly decided that he would go ste
 erage. There would be more 
I  went often to  look at the collection of curiosities  in  HeidelbergCastle, and one day  I surprised the  keeper of it with  my German. I  spokeentirely in that language. He was greatly interested; and after I had talked


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Carlton]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Cheque.pdf --]
[-- Type: application/pdf, Size: 7158 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Eldridge]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Text.pdf --]
[-- Type: application/pdf, Size: 25637 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Dennis]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: message.pdf --]
[-- Type: application/pdf, Size: 8159 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Bella]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: message.pdf --]
[-- Type: application/pdf, Size: 8159 bytes --]

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Shaohua Li]

> From: "Avi Kivity" <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
> To: "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Tue, 24 Jul 2007 13:42:29 +0800
> Subject: Re: [RFC 0/8]KVM: swap out guest pages
>
>
> Shaohua Li wrote:
> > On Mon, 2007-07-23 at 18:27 +0800, Avi Kivity wrote:
> >
> >> Shaohua Li wrote:
> >>
> >>> This patch series make kvm guest pages be able to be swapped out and
> >>> dynamically allocated. Without it, all guest memory is allocated at
> >>> guest start time.
> >>>
> >>> patches are against latest git, and you need first patch Avi's
> >>>
> >> kvm-sch
> >>
> >>> integration patch
> >>>
> >>>
> >>
> (http://sourceforge.net/mailarchive/forum.php?thread_name=11841693332609-git-send-email-avi%40qumranet.com&forum_name=kvm-devel
> ).
> >>
> >>> Patch is quite stable in my test. With the patch, I can run a 256M
> >>> memory guest in a 300M memory host.
> >>>
> >> What about the opposite?
> >>
> >>
> >>> If guest is idle, the memory it used
> >>> can be less than 10M. I did a simple performance test (measure
> >>>
> >> kernel
> >>
> >>> build time in guest), if there is few swap, the performance w/wo the
> >>> patch difference isn't significent. If you have better measurement
> >>> approach, please let me try.
> >>>
> >>> Unresolved issue:
> >>> 1. swapoff doesn't work, we need a hook.
> >>> 2. SMP guest might not work, as kvm doesn't support smp till now.
> >>> 3. better algorithm to select swaped out guest pages according to
> >>> guest's memory usage.
> >>> Maybe more.
> >>>
> >>> Any suggests and comments are appreciated.
> >>>
> >>>
> >> The big question is whether to have kvm's own address_space or not.
> >>
> >> Having an address_space (like your patch does) is remarkably simple,
> >> and
> >> requires few hooks from the current vm.  However using existing vmas
> >> mapped by the user has many advantages:
> >>
> >> - compatible with s390 requirements
> >> - allows the user to use hugetlbfs pages, which have a performance
> >> advantage using ept/npt (but which are unswappable)
> >> - allows the user to map a file (which can be regarded as way to
> >> specify
> >> the swap device)
> >> - better ingration with the rest of the vm
> >>
> >> I am quite torn between the simplicity of your approach and the
> >> advantages of using generic vmas.  However, s390 pretty much forces
> >> our
> >> hand.
> >>
> >> What is your opinion of extending generic vmas to back kvm guest
> >> memory?
> >>
> > several issues:
> > 1. vma is to manage usersapce address, kvm guest uses full address
> > space.
> > 2. qemu itself must use some address space.
> >
>
> My idea is to keep the current slot concept, but instead of having kvm
> allocate pages for a slot, it would call get_user_pages() for a virtual
> address range.  Userspace doesn't directly talk about vmas, just virtual
> address ranges.
all the APIs need vma/page table handling. swap also needs vma for
rmap for generic file.

Thanks,
Shaohua

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

(no subject)

[Walter]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: File.pdf --]
[-- Type: application/pdf, Size: 12484 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Riley]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Suggestion.pdf --]
[-- Type: application/pdf, Size: 10841 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Santiago]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Suggestion.pdf --]
[-- Type: application/pdf, Size: 10841 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Mathilda S. Corbett]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: info.pdf --]
[-- Type: application/pdf, Size: 14536 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

(no subject)

[Joachim B.Byrne]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: paid.pdf --]
[-- Type: application/pdf, Size: 18730 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 210 bytes --]

_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

(no subject)

[Sandy Holloway]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Log.pdf --]
[-- Type: application/pdf, Size: 8933 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Cohen Micky]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: cancelled.pdf --]
[-- Type: application/pdf, Size: 10145 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Dong, Eddie]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

(no subject)

[Dong, Eddie]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

(no subject)

[Palmer]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: unpaid.pdf --]
[-- Type: application/pdf, Size: 26335 bytes --]

[-- Attachment #3: SpamAssassinReport.txt --]
[-- Type: text/plain, Size: 887 bytes --]

Spam detection software, running on the system "daredevil.linux-foundation.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  [...] 

Content analysis details:   (7.7 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.9 HELO_DYNAMIC_IPADDR    Relay HELO'd using suspicious hostname (IP addr
                            1)
 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%
                            [score: 0.4825]
 2.0 MISSING_SUBJECT        Missing Subject: header
 1.7 EMPTY_MESSAGE          Message appears to be empty with no Subject: text



[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

(no subject)

[Persy]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Check.pdf --]
[-- Type: application/pdf, Size: 20947 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Gwendolyn]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: report.pdf --]
[-- Type: application/pdf, Size: 20947 bytes --]

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

(no subject)

[Glenn]

subscribe linux-wireless

(no subject)

[Mark Levedahl]

 From 567906ddb2fbbcf07325acc2808346ad6a472df1 Mon Sep 17 00:00:00 2001
From: Mark Levedahl <mdl123@verizon.net>
Date: Tue, 17 Jul 2007 18:35:46 -0400
Subject: [PATCH] gitk - Ignore ctrl-z as EOF on windows
To:        mlevedahl@verizon.net
-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
Cygwin's Tcl is configured to honor any occurence of ctrl-z as an
end-of-file marker, while some commits in the git repository and possibly
elsewhere include that character in the commit comment. This causes gitk
ignore commit history following such a comment and incorrect graphs. This
change affects only Windows as Tcl on other platforms already has
eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and
the fix was suggested by Shawn Pierce.

Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
 gitk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitk b/gitk
index 39e452a..238607e 100755
--- a/gitk
+++ b/gitk
@@ -101,7 +101,7 @@ proc start_rev_list {view} {
     set commfd($view) $fd
     set leftover($view) {}
     set lookingforhead $showlocalchanges
-    fconfigure $fd -blocking 0 -translation lf
+    fconfigure $fd -blocking 0 -translation lf -eofchar {}
     if {$tclencoding != {}} {
     fconfigure $fd -encoding $tclencoding
     }
--
1.5.3.rc2.5.g66bbd

Re: (no subject)

[Marshall]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: mail.pdf --]
[-- Type: application/pdf, Size: 14445 bytes --]

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

(no subject)

[Riccardo Bini]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Hull N.Flossie]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: unpaid.pdf --]
[-- Type: application/pdf, Size: 12647 bytes --]

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: (no subject)

[Cummings]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Check.pdf --]
[-- Type: application/pdf, Size: 13263 bytes --]

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[sun lu]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

I am a Chinese linux developer and now working on the ARM9 board EP9315 
development based on linux system. I have downloaded the 
nfs-utils-1.0.6-ptx4 package and attempted to build the nfs service module 
into the ARM linux system so that the ARM board can funtion as a nfs server 
which can be mounted by other boards.
However, some problems confused me :in the package, I have modified the 
file "configure.sh" aiming to let the package's compiling directory link to 
the cross-compiling enviroment 2.95.3( it exists in /usr/local/arm) ,but it 
doesn't work. The package cannot install the nfs modules which work in the 
ARM linux system.
So,I hope if you can give me some advices or offer me some help, I'll be 
appreciated for that very much!!

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  



[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Gautham Kampalapur Shankar, TLS, Chennai]

[-- Attachment #1: Type: text/html, Size: 420 bytes --]

[-- Attachment #2: Type: text/plain, Size: 984 bytes --]

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[pradeep singh rautela]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 6/11/07, Gautham Kampalapur Shankar, TLS, Chennai  wrote:
>
>
>
>
>  How xen bus and xen store works ? How they related to each other ?
Gautham you are supposed to use a proper subject for a prompt reply.

thanks

- --
- ---
pradeep singh rautela

"Genius is 1% inspiration, and 99% perspiration" - not me :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://firegpg.tuxfamily.org

iD8DBQFGbSmLky6Gd9lpXlERAu12AJ4kdzmyofihA5fmShaCuNbQv5z+ZQCePElh
JA4gh+llY+9GVInFabWvVHw=
=UC9B
-----END PGP SIGNATURE-----

(no subject)

[Nicklas Bondesson]

unsubscribe linux-kernel

Re: [PATCH] locks: provide a file lease method enabling cluster-coherent leases

[J. Bruce Fields]

On Thu, Jun 07, 2007 at 10:43:51AM -0400, Robert Rappaport wrote:
> My interpretation of the preceeding is  that there is agreement that
> the functionality currently implemented in __setlease() should be
> exported, even though the exported name may not be __setlease().  Is
> this correct?

Yes.

> If so, that is just fine with me.

OK, good.  I'll revise and post a new series.  (Do people prefer another
mailbomb or a git url?)

> The question that I have now is when do you think it likely that these
> changes get into the released code?  I hope that the plan is to get it
> there fairly soon.

It would seem reasonable to me to put off the question of how to do proper
distributed lease-breaking for now, in which case the remaining patches
seem straightforward enough to me that they could go in now.

My main question is whether the partial disabling of leases looks to the
GFS2 people like reasonable behavior.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[J. Bruce Fields]

J. Bruce Fields <bfields@fieldses.org> wrote:
> OK, good.  I'll revise and post a new series.  (Do people prefer
> another mailbomb or a git url?)

OK, I went for the former; if you'd rather get this out of git, you can

	git clone http://www.linux-nfs.org/~bfields/linux.git
	git checkout server-cluster-lease-api

The changes from the last version seem pretty trivial, but I've
compile-tested this only for now.

I'm ignoring the problem of breaking leases on unlink and rename.  I
think we should go ahead and do this part now--it's adequate for the
current lease semantics, and even more so for our current application
(just turning off leases selectively on some filesystems)--but I'd
really like to solve that problem eventually.

That's probably not going to happen until we get a cluster filesystem
with real lease support into the kernel....

Changes:
	- do away with the break_lease method.
	- rename __setlease to setlease, setlease to vfs_setlease, and
	  make sure it's setlease (the one that doesn't call into the
	  filesystem) that's exported.
	- rename ->set_lease to ->setlease.  (I don't really care which
	  we go with, it just seemed confusing when everything else was
	  already named without the underscore.)
	- Add a trivial patch that disables leases on nfs (as suggested
	  by a patch elsewhere from Peter Staubach)

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Xyber Blue]

Hello Guys,

I just want to know what are the requirements aside from the storage
subsystems hardware in creating device mapper multipath DSM or
Hardware Handler. I have just read from the linux symposium document
about the implementation of the Linux Multipathing solution that the
Device Specific Module allows the ff:

   a) Specification of kernel resident storage system specific path
group initialization
   b) IO completion filtering
   c) Message handling

Is there any document available on how to implement these specific components?

Another Question:

   How do I test these Hardware Handler in userspace?

Thanks and Best Regards,
xyber

(no subject)

[Kirkwood, David A.]

[-- Attachment #1.1: Type: text/plain, Size: 276 bytes --]

How do I place a watch on files that are being rotated? For example: I
want to audit the audit logs themselves , and when they are rotated I
need to watch the new audit log that is created as well as the rotated
logs. 

 

Thanks,

 

David A. Kirkwood



 


[-- Attachment #1.2: Type: text/html, Size: 2124 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[ashok.shanmugam]

[-- Attachment #1.1: Type: text/plain, Size: 177 bytes --]



hi all
  i am a kernel newbie,
  I wanted to know is there any way to create our own fileoperations on a particular disk partition. Please let me know..

Thanks
Ashok

[-- Attachment #1.2: Type: text/html, Size: 556 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Fabio Olive Leite]

Hi nfs@,

This patch solves an issue found on 32bit architectures, where jiffies
wrap every 50 days. Since many NFS structures are very long lived and
the code uses jiffies everywhere for timestamp comparisons, there are
many places where old data can be considered newer than something
fresh from the server. This one deals with negative dentries, and I'd
like to have it discussed in the list for sanity checking.

    In 32bit architectures the NFS code uses 32bit jiffies for structures
    that can very easily remain allocated for several u32 jiffy wraps,
    fooling tests made only with time_after[_eq]. One such case is for
    negative dentries, that given the correct timing can be considered valid
    even after changing their parent dir's attributes.
    =

    This patch addresses that by using another unused struct dentry field to
    store the higher part of the u64 jiffies. It has more comments than code
    because the issue is subtle, and is made conditional on long being a
    32bit quantity (64bit arches won't exhibit this behavior).

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index cd34697..a21fb87 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -644,11 +644,26 @@ static int nfs_check_verifier(struct inode *dir, stru=
ct dentry *dentry)
 	if ((NFS_I(dir)->cache_validity & NFS_INO_INVALID_ATTR) !=3D 0
 			|| nfs_attribute_timeout(dir))
 		return 0;
+#if (BITS_PER_LONG < 64)
+	/* In 32bit architectures, also check the cached higher bits of
+	 * jiffies64. NFS dentries can sit idle across two sign flips of
+	 * 32bit jiffies and fool time_after[_eq].
+	 */
+	if ((u32)(dentry->d_cookie) !=3D (u32)(get_jiffies_64() >> 32))
+		return 0;
+#endif
 	return nfs_verify_change_attribute(dir, (unsigned long)dentry->d_fsdata);
 }
 =

 static inline void nfs_set_verifier(struct dentry * dentry, unsigned long =
verf)
 {
+#if (BITS_PER_LONG < 64)
+	/* In 32bit architectures we can have problems with dentries that sit
+	 * idle during two flips of the MSB of the u32 jiffies, so we keep
+	 * track of the higher bits in d_cookie.
+	 */
+	(u32)(dentry->d_cookie) =3D (u32)(get_jiffies_64() >> 32);
+#endif
 	dentry->d_fsdata =3D (void *)verf;
 }
 =

@@ -755,8 +770,17 @@ static int nfs_lookup_revalidate(struct dentry * dentr=
y, struct nameidata *nd)
 	inode =3D dentry->d_inode;
 =

 	if (!inode) {
-		if (nfs_neg_need_reval(dir, dentry, nd))
+		if (nfs_neg_need_reval(dir, dentry, nd)) {
+#if (BITS_PER_LONG < 64)
+			dfprintk(VFS, "nfs_lookup_revalidate: expiring neg dentry for %s\n",
+				dentry->d_name.name);
+			dfprintk(VFS, "  d_cookie %08x high_jiffies %08x\n",
+				dentry->d_cookie, (u32)(get_jiffies_64() >> 32));
+			dfprintk(VFS, "  d_fsdata %08x cache_change_attribute %08x\n",
+				dentry->d_fsdata, NFS_I(dir)->cache_change_attribute);
+#endif
 			goto out_bad;
+		}
 		goto out_valid;
 	}
 =


Cheers,
F=E1bio
-- =

ex sed lex awk yacc, e pluribus unix, amem

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[paul moore]

My understanding is that the auid/loginid process property is to allow the
audit system to *really* know who did things In particular it seems to be
for tracking who did things when they run su or sudo 

But it seems to be trivial to spoof it

login as: paul
paul@192.168.111.40's password:
Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
[paul@rhes5-wa-1 ~]$ sudo bash
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
600[root@rhes5-wa-1 ~]# exit
[paul@rhes5-wa-1 ~]$ cat /proc/self/loginuid
556[paul@rhes5-wa-1 ~]$

I was 556 at login, after sudo i am still 556 but then as root I can now
change it to 600 and the audit log for my actions has auid=600 in it
doesnt that undermine the whole point of the login id?
Surely once it has been set it should not be possible to change it again.

I see a debate in the thread "proc_loginuid_write() checks wrong capability"
about who should be able to do this but it misses the point. It should only
be writtable if its -1 at the moment.
Otherwise it must be unconditionally rejected.

The argument for it being like it is is that root is all powerfull so they
should be allowed to do anything. But the beauty of auid is that it lets me
see who the root sudoer really is. 

(BTW - my 10$ says its should be a new capability since it doesn't match
either CONTROL or WRITE, But if that's not possible then it should be
CONTROL)

Any insights gratefully received

Paul Moore

(no subject)

[paul moore]

My understanding is that the auid/loginid process property is to allow the
audit system to *really* know who did things In particular it seems to be
for tracking who did things when they run su or sudo 

But it seems to be trivial to spoof it

login as: paul
paul@192.168.111.40's password:
Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
[paul@rhes5-wa-1 ~]$ sudo bash
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
600[root@rhes5-wa-1 ~]# exit
[paul@rhes5-wa-1 ~]$ cat /proc/self/loginuid
556[paul@rhes5-wa-1 ~]$

I was 556 at login, after sudo i am still 556 but then as root I can now
change it to 600 and the audit log for my actions has auid=600 in it
doesnt that undermine the whole point of the login id?
Surely once it has been set it should not be possible to change it again.

I see a debate in the thread "proc_loginuid_write() checks wrong capability"
about who should be able to do this but it misses the point. It should only
be writtable if its -1 at the moment.
Otherwise it must be unconditionally rejected.

The argument for it being like it is is that root is all powerfull so they
should be allowed to do anything. But the beauty of auid is that it lets me
see who the root sudoer really is. 

(BTW - my 10$ says its should be a new capability since it doesn't match
either CONTROL or WRITE, But if that's not possible then it should be
CONTROL)

Any insights gratefully received

Paul Moore

Re: (no subject)

[Steve Grubb]

On Friday 20 April 2007 18:13:17 paul moore wrote:
> My understanding is that the auid/loginid process property is to allow the
> audit system to *really* know who did things In particular it seems to be
> for tracking who did things when they run su or sudo

Yep.

> But it seems to be trivial to spoof it
>
> login as: paul
> paul@192.168.111.40's password:
> Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
> [paul@rhes5-wa-1 ~]$ sudo bash
> [root@rhes5-wa-1 ~]# cat /proc/self/loginuid
> 556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid

But you will generate an audit message right here saying that you changed the 
loginuid. While its not protection, it doesn't quietly let that occur.

> I was 556 at login, after sudo i am still 556 but then as root I can now
> change it to 600 and the audit log for my actions has auid=600 in it
> doesnt that undermine the whole point of the login id?

There should still be a trail showing that you changed it.

> Surely once it has been set it should not be possible to change it again.

I think there are 1 or 2 daemons that count on that.

> I see a debate in the thread "proc_loginuid_write() checks wrong
> capability" about who should be able to do this but it misses the point. It
> should only be writtable if its -1 at the moment. Otherwise it must be
> unconditionally rejected.

Except in the case where daemons are changing loginuid temporarily to record 
the fact that its doing something on behalf of a user. For example, I think 
postfix may do this when delivering email and reading the dot files.

> The argument for it being like it is is that root is all powerfull so they
> should be allowed to do anything. But the beauty of auid is that it lets me
> see who the root sudoer really is.

But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and 
admin does a restart of sshd, sshd will not be able to set it either. If you 
only allow setting auid if its non-zero, how do you restart a service like 
sshd since it will inherit the loginuid? The only option is to reboot the 
machine, so forget about rpm upgrades.

I really think the answer is to protect this with SE Linux policy...but there 
is a problem. I think that by setting loginuid by the proc filesystem we 
won't be able to have a SE Linux type that is distinct for loginuid without 
changing things in the kernel. Then you also have to worry about descriptors 
being held open across forks. Not to mention, you have to do a open(), 
write(), close() for each setting of loginuid.

So I think the best solution is to make a syscall for setting the loginuid 
that SE Linux can protect with a distinct type. Then we can say things like 
local_login_t is allowed setloginuid_t.

> (BTW - my 10$ says its should be a new capability since it doesn't match
> either CONTROL or WRITE,

I've been saying that for a while too. I think it is distinct in the same way 
that chown is different than unlink. Changing the loginuid is only 1 
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to 
delete rules. So you change whether or not the event even was recorded as 
opposed to who to blame.

But one thing that does help is deleting the rules is done via netlink 
interface, which SE Linux does control. So, policy can be written that 
disallows anything except auditctl_t from writing to netlink, and policy can 
be written saying who can run auditctl.

-Steve

RE: (no subject)

[paul moore]

Aha - I see that there is an audit event for the auid change. Thats good
enough for me - thanks

I still have a couple of questions

A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?
There is no error message
B) always if I echo to /proc... as non root it is ignored (as it should be)
but no message is generated; shouldn't it say EPERM?
C) I put pam_loginuid in my gdm pam config but my xterm windows still have
-1 in loginuid (I have rebooted)

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, April 20, 2007 4:32 PM
To: linux-audit@redhat.com
Cc: paul moore
Subject: Re: (no subject)

On Friday 20 April 2007 18:13:17 paul moore wrote:
> My understanding is that the auid/loginid process property is to allow 
> the audit system to *really* know who did things In particular it 
> seems to be for tracking who did things when they run su or sudo

Yep.

> But it seems to be trivial to spoof it
>
> login as: paul
> paul@192.168.111.40's password:
> Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
> [paul@rhes5-wa-1 ~]$ sudo bash
> [root@rhes5-wa-1 ~]# cat /proc/self/loginuid
> 556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid

But you will generate an audit message right here saying that you changed
the loginuid. While its not protection, it doesn't quietly let that occur.

> I was 556 at login, after sudo i am still 556 but then as root I can 
> now change it to 600 and the audit log for my actions has auid=600 in 
> it doesnt that undermine the whole point of the login id?

There should still be a trail showing that you changed it.

> Surely once it has been set it should not be possible to change it again.

I think there are 1 or 2 daemons that count on that.

> I see a debate in the thread "proc_loginuid_write() checks wrong 
> capability" about who should be able to do this but it misses the 
> point. It should only be writtable if its -1 at the moment. Otherwise 
> it must be unconditionally rejected.

Except in the case where daemons are changing loginuid temporarily to record
the fact that its doing something on behalf of a user. For example, I think
postfix may do this when delivering email and reading the dot files.

> The argument for it being like it is is that root is all powerfull so 
> they should be allowed to do anything. But the beauty of auid is that 
> it lets me see who the root sudoer really is.

But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and
admin does a restart of sshd, sshd will not be able to set it either. If you
only allow setting auid if its non-zero, how do you restart a service like
sshd since it will inherit the loginuid? The only option is to reboot the
machine, so forget about rpm upgrades.

I really think the answer is to protect this with SE Linux policy...but
there is a problem. I think that by setting loginuid by the proc filesystem
we won't be able to have a SE Linux type that is distinct for loginuid
without changing things in the kernel. Then you also have to worry about
descriptors being held open across forks. Not to mention, you have to do a
open(), write(), close() for each setting of loginuid.

So I think the best solution is to make a syscall for setting the loginuid
that SE Linux can protect with a distinct type. Then we can say things like
local_login_t is allowed setloginuid_t.

> (BTW - my 10$ says its should be a new capability since it doesn't 
> match either CONTROL or WRITE,

I've been saying that for a while too. I think it is distinct in the same
way that chown is different than unlink. Changing the loginuid is only 1
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to
delete rules. So you change whether or not the event even was recorded as
opposed to who to blame.

But one thing that does help is deleting the rules is done via netlink
interface, which SE Linux does control. So, policy can be written that
disallows anything except auditctl_t from writing to netlink, and policy can
be written saying who can run auditctl.

-Steve

RE: (no subject)

[paul moore]

Aha - I see that there is an audit event for the auid change. Thats good
enough for me - thanks

I still have a couple of questions

A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?
There is no error message
B) always if I echo to /proc... as non root it is ignored (as it should be)
but no message is generated; shouldn't it say EPERM?
C) I put pam_loginuid in my gdm pam config but my xterm windows still have
-1 in loginuid (I have rebooted)

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, April 20, 2007 4:32 PM
To: linux-audit@redhat.com
Cc: paul moore
Subject: Re: (no subject)

On Friday 20 April 2007 18:13:17 paul moore wrote:
> My understanding is that the auid/loginid process property is to allow 
> the audit system to *really* know who did things In particular it 
> seems to be for tracking who did things when they run su or sudo

Yep.

> But it seems to be trivial to spoof it
>
> login as: paul
> paul@192.168.111.40's password:
> Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
> [paul@rhes5-wa-1 ~]$ sudo bash
> [root@rhes5-wa-1 ~]# cat /proc/self/loginuid
> 556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid

But you will generate an audit message right here saying that you changed
the loginuid. While its not protection, it doesn't quietly let that occur.

> I was 556 at login, after sudo i am still 556 but then as root I can 
> now change it to 600 and the audit log for my actions has auid=600 in 
> it doesnt that undermine the whole point of the login id?

There should still be a trail showing that you changed it.

> Surely once it has been set it should not be possible to change it again.

I think there are 1 or 2 daemons that count on that.

> I see a debate in the thread "proc_loginuid_write() checks wrong 
> capability" about who should be able to do this but it misses the 
> point. It should only be writtable if its -1 at the moment. Otherwise 
> it must be unconditionally rejected.

Except in the case where daemons are changing loginuid temporarily to record
the fact that its doing something on behalf of a user. For example, I think
postfix may do this when delivering email and reading the dot files.

> The argument for it being like it is is that root is all powerfull so 
> they should be allowed to do anything. But the beauty of auid is that 
> it lets me see who the root sudoer really is.

But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and
admin does a restart of sshd, sshd will not be able to set it either. If you
only allow setting auid if its non-zero, how do you restart a service like
sshd since it will inherit the loginuid? The only option is to reboot the
machine, so forget about rpm upgrades.

I really think the answer is to protect this with SE Linux policy...but
there is a problem. I think that by setting loginuid by the proc filesystem
we won't be able to have a SE Linux type that is distinct for loginuid
without changing things in the kernel. Then you also have to worry about
descriptors being held open across forks. Not to mention, you have to do a
open(), write(), close() for each setting of loginuid.

So I think the best solution is to make a syscall for setting the loginuid
that SE Linux can protect with a distinct type. Then we can say things like
local_login_t is allowed setloginuid_t.

> (BTW - my 10$ says its should be a new capability since it doesn't 
> match either CONTROL or WRITE,

I've been saying that for a while too. I think it is distinct in the same
way that chown is different than unlink. Changing the loginuid is only 1
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to
delete rules. So you change whether or not the event even was recorded as
opposed to who to blame.

But one thing that does help is deleting the rules is done via netlink
interface, which SE Linux does control. So, policy can be written that
disallows anything except auditctl_t from writing to netlink, and policy can
be written saying who can run auditctl.

-Steve

Re: (no subject)

[Steve Grubb]

On Friday 20 April 2007 20:24, paul moore wrote:
> A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?

Show me an example.

> There is no error message

Not sure if '>' outputs error messages.

> B) always if I echo to /proc... as non root it is ignored (as it should be)
> but no message is generated; shouldn't it say EPERM?

Not sure the '>' outputs errors. You could strace it and see that the errno 
was returned and the shell did nothing with it.

> C) I put pam_loginuid in my gdm pam config but my xterm windows still have
> -1 in loginuid (I have rebooted)

How are you starting your xterm windows? If I use gnome terminal all is well. 
Even if I start an xterm window from it everything is still OK.

-Steve

(no subject)

[xfwolf]

Re: (no subject)

[Jojo Keiser]

Have you seen how these sub-one-cent companies take off on 
Good News?  For the past two months, every one we have 
brought you has shown Amazing Appreciation. 

At such a low price even the smallest Gain means a 
Significant Percentage Return.

We called (P)(P)(T)(L) as one to watch on Friday because of a 
Highly Anticipated Report from the Field.  It moved up 13% 
on Friday and the news isn't even out yet.  Just wait till 
word hits the street!

On second thought, Don't Wait!

Company (P)remium (P)e(T)ro(L)eum (P)(P)(T)(L)

Current  $0.0085 (+13%)
Target    $0.0450 (a FIVE bagger!)

At this time (P)(P)(T)(L)  has a number of Surveys and Drilling 
projects in progress.  We have heard that a Major Discovery 
has been made, and recommend our readers capitalize on this 
Opportunity right away!

HEADLINES
---------------------
Coyote jumps in Quiznos drink cooler 
CNN Wire: Latest updates on world's top stories 
Congress bypassed to appoint Swift Boat donor
Woman charged with faking HIV, taking money Video
Records: Smith drugs all prescribed by 1 doctor
Collins: Why this scientist believes in God 

---------------------

Re: (no subject)

[Maung Nadir Ali]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Have you seen how these sub-one-cent companies take off on 
Good News?  For the past two months, every one we have 
brought you has shown Amazing Appreciation. 

At such a low price even the smallest Gain means a 
Significant Percentage Return.

We called (P)(P)(T)(L) as one to watch on Friday because of a 
Highly Anticipated Report from the Field.  It moved up 13% 
on Friday and the news isn't even out yet.  Just wait till 
word hits the street!

On second thought, Don't Wait!

Company (P)remium (P)e(T)ro(L)eum (P)(P)(T)(L)

Current  $0.0085 (+13%)
Target    $0.0450 (a FIVE bagger!)

At this time (P)(P)(T)(L)  has a number of Surveys and Drilling 
projects in progress.  We have heard that a Major Discovery 
has been made, and recommend our readers capitalize on this 
Opportunity right away!

HEADLINES
---------------------
Records: Smith drugs all prescribed by 1 doctor
Bush appoints ambassador
Ahmadinejad: Pardon for UK sailors
Texans want Hold 'Em games legal ... and taxed 
Woman charged with faking HIV, taking money Video

---------------------





[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Kirkwood, David A.]

[-- Attachment #1.1: Type: text/plain, Size: 380 bytes --]

When I view the events related to xscreensaver for a locked screen  I
get 2 separate audit entries, one for a failure and 1 as a success. Both
have the same uid, euid, etc. Actually, the entries are exactly the same
except for the event number and the success outcome. I  have the
xscreensaver executable set -rwsr-xr-x. 

 

Thanks,

 

David A. Kirkwood



 


[-- Attachment #1.2: Type: text/html, Size: 2237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Bill Tangren]

Kirkwood, David A. wrote:
> When I view the events related to xscreensaver for a locked screen  I 
> get 2 separate audit entries, one for a failure and 1 as a success. Both 
> have the same uid, euid, etc. Actually, the entries are exactly the same 
> except for the event number and the success outcome. I  have the 
> xscreensaver executable set -rwsr-xr-x.
> 
>  
> 
>

The failure may be due to xscreensaver not being able to write to the faillog, 
if you are using pam_tally (to implement three strikes and you are locked out), 
but I'm just guessing.

Re: (no subject)

[Sutton O. Javelin]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3512 bytes --]

[-- Attachment #1.2: barrelling.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Empty V. Crock]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4117 bytes --]

[-- Attachment #1.2: meaning.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Giggler S. Defeatist]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3278 bytes --]

[-- Attachment #1.2: Donaldson.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Arjuna H. Settlement]

[-- Attachment #1: Type: text/plain, Size: 3884 bytes --]

Spam detection software, running on the system "alsa0.alsa-project.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  Read more Bojcy fehtovali na ravnyh, odinakovo ne ustupaia
   drug drugu i odinakovo ne Obrashchaia ni malejshego vnimaniia ni na podbadrivaiushchie
   kriki poklonnikov, ni na Vozmushchennyj ropot teh, kto zakliuchil na nih
  pari i uzhe ustal j zhdat Kakogo-libo rezultata. Nkot. 15. No, s drugoj Storony,
   vyhodit, ona ponimala, chto ee rukami shefir delaet so mnoj, i nichego Ne
   mogla podelat s etim. Proch s dorogi, Ocenol, ugrozhaiushche prorokotal lovchij
   mag. Nubesov liudskie dela ne interesovali. Pravda, Uzhin rasslabil menia
   kuda bolshe, chem ia ozhidal, i bolshogo zhelaniia boltat na Otvlechennye
   temy chto-to ia ne oshchushchal. Tak silno, chto Inoj raz ot etoj nenavisti
   u menia temnelo v glazah. Imenno ob etom prednaznachenii ia i tolkoval tem
   vecherom, a ne o bitve s Prokoldom, kak ty reshil na svoj lad. Veroiatno,
   eta mestnost sluzhila im privychnymi ohotnichimi ugodiami, i oni ne Zhelali
   tak prosto sdavatsia. Pohozhe, ego Vezhlivost ot skuki pokrylas takim zhe
   sloem pyli, kak i vse vokrug. Sedousyj v moment udara nabliudal za Delovitoj
   rabotoj voznic, liho rabotavshih toporami. Fizicheskoe iscelenie obekta,
  s Kotorym ia rabotaiu, iavliaetsia lish pobochnym effektom. Ia Okazalsia na
   spine, pridavlennyj tiazheloj tushej. Esli ponravishsia emu, to vnaklade
  ne Ostaneshsia, ia etogo tipa davno znaiu. Nedolgo dumaia, ia prygnul priamo
   s mesta tri metra ne rasstoianie i bez Leshu. 4. I ia speshilsia. Ego Merzkaia
   lovushka edva ne pogubila tebia. Kakoe vse-taki mrachnoe mesto. A kak zhe
   naschet materialnogo voznagrazhdeniia, obeshchannogo Nkotom? Pozhav plechami,
   ia povernulsia na slabyj shum sleva po koridoru iz lifta Vyshel Alani so
  svitoj iz piaterki podchinennyh i neznakomym mne parnem let Tridcati. V tom
   zhe parke Tirtiniuma, v pristupe holodnoj Iarosti napav pervym, ia ispolzoval
   protiv Velsajta vse, chto dano mne bylo Prirodoj i trenirovkami po Mobra,
   i vyigral poedinok. Silno. Bankos zdes samaia vazhnaia Cennost posle zhizni.
   A dlia Nori iz obshchej grudy vyudil chto-to ti pa osy legkij, iziashchnyj
   Pistolet-izluchatel, [...] 

Content analysis details:   (9.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 2.0 DATE_IN_FUTURE_03_06   Date: is 3 to 6 hours after Received: date
 0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
 0.6 HTML_00_10             BODY: Message is 0% to 10% HTML
 0.7 MIME_HTML_MOSTLY       BODY: Multipart message mostly text/html MIME
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.3 HTML_FONT_BIG          BODY: HTML tag for a big font size
 0.1 MPART_ALT_DIFF         BODY: HTML and text parts are different
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
               [Blocked - see <http://www.spamcop.net/bl.shtml?201.75.142.27>]
 3.1 RCVD_IN_XBL            RBL: Received via a relay in Spamhaus XBL
                            [201.75.142.27 listed in sbl-xbl.spamhaus.org]
 1.1 URIBL_SBL              Contains an URL listed in the SBL blocklist
                            [URIs: uniqa.hk]

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Size: 12759 bytes --]

[-- Attachment #2.1.1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #2.1.1.1.2: Type: text/html, Size: 3792 bytes --]

[-- Attachment #2.1.1.2: emus.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Cutlasses M. Greek]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3710 bytes --]

[-- Attachment #1.2: Gospels.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Flickering E. Sharps]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4175 bytes --]

[-- Attachment #1.2: periscopes.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Rational K. Haggard]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3256 bytes --]

[-- Attachment #1.2: unadvised.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Redeeming T. Angus]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3331 bytes --]

[-- Attachment #1.2: servo.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Orient K. Underpinnings]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3118 bytes --]

[-- Attachment #1.2: gynecologist.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Depreciates F. Sum]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3668 bytes --]

[-- Attachment #1.2: torquing.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Whispers F. Charlie]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4431 bytes --]

[-- Attachment #1.2: allot.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Dr.Friedrick Conway]

Gexnexric Viagxrxa 10 pxills - $59.58
Gexnxeric Viagrxxa 30 pills - $119.85
Vxixagra Professional 10 pills - $69.87
Vixxagra Professional 30 pills - $139.25
Ciaxlxis 20 pilxls - $199.6
Cxixalis 30 pills - $239.89
Cxxialis 100 pills - $566.82
Viagxrxa Sofxt Tabs 10 pills - $69.36
Viaxgxra Soft Tabs 30 pills - $139.89
Cxiaxlis + Vxixagra (10 pills + 10 pxills) - $129.21
Cixaxlis + Vixagxra (20 pills + 20 pillxs) - $249.34
Ciaxlxis + Viagxrxa (30 pills + 30 pills) - $319.23 
Cxialxis Sxoft Txabs 10 pills - $89.77
Cialxixs Soft Tabs 30 pills - $236.8
Cxialxis Soft Tabs 60 pixlls - $377.53
Amxxbien 30 pixlls - $124.59
Ambiexxn 60 pills - $190.3
Amxbixen 90 pills - $260
Amoxicixlxlin 30 pills (500 mg) - $99.07
Meridxixa 60 pills - $219.1
Proxpecxia 180 pixlls - $186.6
Soma 90 pills (350mg) - $124.5
Vaxlxium 30 pills (10mg) - $124.98
Vaxlxium 60 pixlls (10mg) - $190.1
Vaxlixum 90 pills (10mg) - $260

http:// mumrq.h k (remoxve thxe spaces fxrom txhe link)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Dr.Hank Miles]

Genxerxic Vixxagra 10 pills - $59.85
Gexnerxic Vxiagxra 30 pills - $119.97
Vxiagrxa Professional 10 pills - $69.71
Vixagxra Professional 30 pixlls - $139.70
Cialxixs 20 pilxls - $199.4
Cialixxs 30 pilxls - $239.71
Cixaxlis 100 pilxls - $566.88
Viagxrxa Sxoft Tabs 10 pills - $69.38
Viagxrxa Soft Taxbs 30 pills - $139.29
Cxixalis + Vixagxra (10 pills + 10 pills) - $129.42
Ciaxlixs + Vixxagra (20 pills + 20 pills) - $249.40
Ciaxlxis + Vxiaxgra (30 pills + 30 pills) - $319.58 
Cixaxlis Soft Tabs 10 pixlls - $89.40
Ciaxlxis Soxft Tabs 30 pills - $236.2
Cxiaxlis Soft Tabs 60 pilxls - $377.56
Ambxixen 30 pixlls - $124.29
Ambixexn 60 pills - $190.9
Axmbixen 90 pixlls - $260
Amoxxixcillin 30 pills (500 mg) - $99.04
Merxidxia 60 pilxls - $219.8
Proxpxecia 180 pxills - $186.7
Soma 90 pills (350mg) - $124.1
Vxxalium 30 pxills (10mg) - $124.04
Valxxium 60 pills (10mg) - $190.2
Valixuxm 90 pills (10mg) - $260

http:// mu mrq.hk (remxove txhe spxaces from thxe link)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Dr.Aaron Barrera]

Gexnerixc Viagxrxa 10 pills - $59.20
Gxenerixc Viaxgrxa 30 pills - $119.91
Viaxgxra Professional 10 pills - $69.20
Viaxgrxa Professional 30 pills - $139.30
Cxialixs 20 pills - $199.0
Cialxxis 30 pills - $239.41
Cixalxis 100 pxills - $566.91
Vixxagra Soft Tabs 10 pills - $69.66
Vxiagrxa Soft Taxbs 30 pills - $139.82
Ciaxxlis + Viaxgrxa (10 pills + 10 pills) - $129.30
Cixalxis + Vixxagra (20 pills + 20 pills) - $249.19
Cxiaxlis + Viaxxgra (30 pxills + 30 pills) - $319.08 
Cixaxlis Soft Tabs 10 pixlls - $89.07
Cxialxis Soft Tabs 30 pills - $236.2
Cixxalis Soft Tabs 60 pills - $377.33
Ambxiexn 30 pxills - $124.64
Axmbiexn 60 pills - $190.8
Ambxixen 90 pillxs - $260
Axxmoxicillin 30 pxills (500 mg) - $99.84
Mexrixdia 60 pills - $219.7
Pxropecixa 180 pills - $186.9
Soma 90 pills (350mg) - $124.7
Vaxlxium 30 pills (10mg) - $124.73
Valiuxxm 60 pills (10mg) - $190.7
Vxalxium 90 pilxls (10mg) - $260

http:// mumr q.hk (remoxve txhe spacexs from the linxk)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Nautilus S. Womb]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3138 bytes --]

[-- Attachment #1.2: populated.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

(no subject)

[ddup1]

unsubscribe linux-kernel

(no subject)

[Dear Sir Madam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1513 bytes --]

Government Accredited Licensed lottery promoters.
The online Lotto - Zo werkt Lotto draws was conducted from an exclusive
list of 25,000,000 e-mail addresses of individuals and corporate
institutions,picked by an advanced automated random computer search from the
internet. No tickets were sold 
International emails  held on the Febuary 2nd  December , 2006.all winnings
must
be claim not later than Febuary  24th, 2007,Your email won the lottery.For
a total pay out of €1,000,000.
Please remember to quote your reference number and batch numbers: 
1, Batch 9484-9006-0076,2, Ref: 637409467-Nll.3, lucky numbers
1-0960-31-444
To file for your claim, please contact 
**************************
CALL NOW TO CLAIM YOUR WINNING PRIZE 
Advocate Faber  Dutchs
Tel: +31 -614 318476
Fax: +31-84-728-9686
email- lawclaimsection@aol.com
law & Associates
In other to claim your €1,000,000.00  prize winning, fill the form below
and send it to Advocate Faber  Dutchs for verification and then you will be
directed how to get a ticket in your name.send the fill form to email-
lawclaimsection@aol.com
NAME:.....................................AGE:.............................
..........
SEX:........................................ADDRESS:.......................
.......
EMAIL:....................................PHONE:...........................
.......
OCCUPATION:.........................:COUNTRY..............................
Yours faithfully,
Mrs Eava Van Boer
Online coordinator 
Sweepstakes International Program.




[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

(no subject)

[ddup1]

unsubscribe linux-kernel

Re: (no subject)

[COM CYCL]

[-- Attachment #1.1.1: Type: text/plain, Size: 150 bytes --]



Ronald Conflict Everyone concerned conflict. ethnic trade wars labour

Navy Steaks CouponOne Fredrick Bike Shack CouponRei Camera Authority Marine


[-- Attachment #1.1.2: Type: text/html, Size: 2300 bytes --]

[-- Attachment #1.2: pic01.gif --]
[-- Type: image/gif, Size: 2559 bytes --]

[-- Attachment #2: Type: text/plain, Size: 374 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

(no subject)

[operators country]

[-- Attachment #1: Type: text/html, Size: 1747 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Karsten Wiese]

Hi Takashi,

some oopses here running -rt kernels vanished after applying this.

      Karsten
------------------------------------------------------------------- 
snd_hwdep_release() racefix


snd_card_file_remove() can free the snd_card.
Touch hw->* only before calling snd_card_file_remove().

Unrelated: Allow hwdep devices not to have own ops.release();


Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>


--- /alsa-kernel/core/hwdep.c_	2007-01-30 20:32:01.000000000 +0100
+++ /alsa-kernel/core/hwdep.c	2007-01-30 20:32:01.000000000 +0100
@@ -156,15 +156,16 @@
 	int err = -ENXIO;
 	struct snd_hwdep *hw = file->private_data;
 	struct module *mod = hw->card->module;
+
 	mutex_lock(&hw->open_mutex);
-	if (hw->ops.release) {
+	if (hw->ops.release)
 		err = hw->ops.release(hw, file);
-		wake_up(&hw->open_wait);
-	}
 	if (hw->used > 0)
 		hw->used--;
-	snd_card_file_remove(hw->card, file);
 	mutex_unlock(&hw->open_mutex);
+	wake_up(&hw->open_wait);
+
+	snd_card_file_remove(hw->card, file);
 	module_put(mod);
 	return err;
 }

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Takashi Iwai]

At Tue, 30 Jan 2007 20:51:47 +0100,
Karsten Wiese wrote:
> 
> Hi Takashi,
> 
> some oopses here running -rt kernels vanished after applying this.
> 
>       Karsten
> ------------------------------------------------------------------- 
> snd_hwdep_release() racefix
> 
> 
> snd_card_file_remove() can free the snd_card.
> Touch hw->* only before calling snd_card_file_remove().
> 
> Unrelated: Allow hwdep devices not to have own ops.release();
> 
> 
> Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>


Thanks, applied to HG tree.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

(no subject)

[orig]

subscribe linux-kernel

(no subject)

[Craig Van Tassle]

subscribe linux-kernel

Re: (no subject)

[Establishes S. Adoption]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3557 bytes --]

[-- Attachment #1.2: regiment.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Maisie T. Deathblow]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3992 bytes --]

[-- Attachment #1.2: holidayed.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Barracuda K. Bobbi]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3535 bytes --]

[-- Attachment #1.2: Natalie.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Acid P. Hank]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3198 bytes --]

[-- Attachment #1.2: altruists.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Timezone D. Authenticity]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3869 bytes --]

[-- Attachment #1.2: blinker.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Lintel E. Late]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4114 bytes --]

[-- Attachment #1.2: Lear.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Princeton F. Aligns]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3539 bytes --]

[-- Attachment #1.2: flamboyant.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Wot V. Armband]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3579 bytes --]

[-- Attachment #1.2: archangel.gif --]
[-- Type: image/gif, Size: 5490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Clemens Ladisch]

tardo2002@libero.it wrote:
> > What is the output of "amixer contents"?
>
> ...

Your mixer controls look OK.

The noise is probably just interference from other components on
the motherboard.


Regards,
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

(no subject)

[Niyanth, Venkata]

Hi,
     I am working on OMAP5912, i am planning to develop some multimedia applications.
Presently i am working on linux platform and planning to port Windows mobile on the board.
Is it possible to have windows mobile on the board ?
 

Re: (no subject)

[Tony Lindgren]

* Niyanth, Venkata <VNiyanth@ciber.com> [061219 01:27]:
> Hi,
>      I am working on OMAP5912, i am planning to develop some multimedia applications.
> Presently i am working on linux platform and planning to port Windows mobile on the board.
> Is it possible to have windows mobile on the board ?

This is a Linux mailing list, it's unlikely that you find an answer here.

Tony

(no subject)

[tardo2002]

Hi, I am an italian linux user. I have a serious noise problem with my integrated sound card (VIA8237, 5.1 channels AC'97 audio) on my Asrock motherboard (P4VT8). 

Follow my lspci -nv:

00:00.0 0600: 1106:3168 (rev 82)
	Subsystem: 1849:3168
	Flags: bus master, 66MHz, medium devsel, latency 8
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Capabilities: [80] AGP version 3.5
	Capabilities: [c0] Power Management version 2

00:01.0 0604: 1106:b198
	Flags: bus master, 66MHz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000a000-0000afff
	Memory behind bridge: dfe00000-dfefffff
	Prefetchable memory behind bridge: bfd00000-dfcfffff
	Capabilities: [80] Power Management version 2

00:0b.0 0780: 14f1:2f00 (rev 01)
	Subsystem: 14f1:2004
	Flags: bus master, medium devsel, latency 32, IRQ 5
	Memory at dffe0000 (32-bit, non-prefetchable) [size=64K]
	I/O ports at d400 [size=8]
	Capabilities: [40] Power Management version 2

00:0f.0 0104: 1106:3149 (rev 80)
	Subsystem: 1849:3149
	Flags: bus master, medium devsel, latency 32, IRQ 16
	I/O ports at ec00 [size=8]
	I/O ports at e800 [size=4]
	I/O ports at e400 [size=8]
	I/O ports at e000 [size=4]
	I/O ports at dc00 [size=16]
	I/O ports at d800 [size=256]
	Capabilities: [c0] Power Management version 2

00:0f.1 0101: 1106:0571 (rev 06) (prog-if 8a)
	Subsystem: 1849:0571
	Flags: bus master, medium devsel, latency 32, IRQ 16
	I/O ports at fc00 [size=16]
	Capabilities: [c0] Power Management version 2

00:10.0 0c03: 1106:3038 (rev 81)
	Subsystem: 1849:3038
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at c400 [size=32]
	Capabilities: [80] Power Management version 2

00:10.1 0c03: 1106:3038 (rev 81)
	Subsystem: 1849:3038
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at c800 [size=32]
	Capabilities: [80] Power Management version 2

00:10.2 0c03: 1106:3038 (rev 81)
	Subsystem: 1849:3038
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at cc00 [size=32]
	Capabilities: [80] Power Management version 2

00:10.3 0c03: 1106:3038 (rev 81)
	Subsystem: 1849:3038
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at d000 [size=32]
	Capabilities: [80] Power Management version 2

00:10.4 0c03: 1106:3104 (rev 86) (prog-if 20)
	Subsystem: 1849:3104
	Flags: bus master, medium devsel, latency 32, IRQ 17
	Memory at dfffbe00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2

00:11.0 0601: 1106:3227
	Subsystem: 1849:3227
	Flags: bus master, stepping, medium devsel, latency 0
	Capabilities: [c0] Power Management version 2

00:11.5 0401: 1106:3059 (rev 60)
	Subsystem: 1849:9739
	Flags: medium devsel, IRQ 19
	I/O ports at c000 [size=256]
	Capabilities: [c0] Power Management version 2

00:12.0 0200: 1106:3065 (rev 78)
	Subsystem: 1849:3065
	Flags: bus master, medium devsel, latency 32, IRQ 18
	I/O ports at bc00 [size=256]
	Memory at dfffbd00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2

01:00.0 0300: 1002:5964 (rev 01)
	Subsystem: 174b:7c26
	Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 20
	Memory at d0000000 (32-bit, prefetchable) [size=128M]
	I/O ports at a800 [size=256]
	Memory at dfef0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at dfec0000 [disabled] [size=128K]
	Capabilities: [58] AGP version 3.0
	Capabilities: [50] Power Management version 2

01:00.1 0380: 1002:5d44 (rev 01)
	Subsystem: 174b:7c27
	Flags: bus master, 66MHz, medium devsel, latency 32
	Memory at c8000000 (32-bit, prefetchable) [size=128M]
	Memory at dfee0000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2


My problem is: when I am listening to some audio file, sound stream is disturbed by a strong noise component. This noise component, in my opinion, is strange becouse it follow rhythm of sound stream and there is both when PCM volume is 0 (but turned on) even PCM volume is high! I red documentation about alsa module snd-via82xx (chosen and loaded automatically by alsaconfig script) and I tried to change dxs_support option from 0 to 5 and other options. I tried to change any volumes, set 'on' just PCM and other tests in alsamixer. I did not found any solution in some forums. I tried different alsa versions, kernel versions, linux distributions, multimedia programs, OSS emulation, output jack of sound card and headphones, but my result is been always the same: NOISE!
I think it is not a hardware problem, becouse card work fine in Windows OS. It is possible to manage channels (sometimes usefull) and other enviroment effects (useless).
You are my last hope, before to buy the simplest pci sound card that work in linux.

Can you list me any kind of tests and tricks to solve my problem, most stupid too? (it is probable I forget to do something else or I don't know some deep tests or tricks)

Thanks for your good work


------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada16dic06



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Clemens Ladisch]

tardo2002@libero.it wrote:
> My problem is: when I am listening to some audio file, sound stream is
> disturbed by a strong noise component. This noise component, in my
> opinion, is strange becouse it follow rhythm of sound stream and there is
> both when PCM volume is 0 (but turned on) even PCM volume is high!

What codec does your motherboard use? (see /proc/asound/cards)
What is the output of "amixer contents"?


Regards,
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[miki]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/04
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/04

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/04

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/04
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/04

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.bz/pc/04

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.bz/pc/04


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/04

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/04

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?04
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/04
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892







-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[Glenn K. Transporting]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3942 bytes --]

[-- Attachment #1.2: drearier.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Generality O. Lifeblood]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4027 bytes --]

[-- Attachment #1.2: lumber.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Proponent V. Stepbrother]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3693 bytes --]

[-- Attachment #1.2: parsimony.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Scrounger D. Aboded]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3481 bytes --]

[-- Attachment #1.2: tern.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Profanation R. Meandering]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3861 bytes --]

[-- Attachment #1.2: anticipation.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Groins O. Animation]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3386 bytes --]

[-- Attachment #1.2: miscalculate.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Variance P. Whirled]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4261 bytes --]

[-- Attachment #1.2: urging.gif --]
[-- Type: image/gif, Size: 3260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

RE: (no subject)

[Tim Edwards]

> -----Original Message-----
> From: Bernd Petrovitsch [mailto:bernd@firmix.at]
> Sent: 21 November 2006 10:54
> To: Tim Edwards
> Cc: netfilter@lists.netfilter.org
> Subject: RE: (no subject)
> 
> On Tue, 2006-11-21 at 10:44 +0000, Tim Edwards wrote:
> >
> > -----Original Message-----
> > From: Bernd Petrovitsch [mailto:bernd@firmix.at]
> > Sent: 21 November 2006 10:13
> > To: Tim Edwards
> > Cc: netfilter@lists.netfilter.org
> > Subject: Re: (no subject)
> >
> > > Yes. Just insert such a rule into the OUTPUT chain.
> >
> > Ok I have the following rules but it still isn't cutting off
existing
> > connections:
> 
> Yup.
> 
> > #!/bin/bash
> >
> > # First clear all rules (and set the policy to DROP on the default
> > chains)
> > iptables -F
> > # Second delete all the extra (user-defined) chains
> > iptables -X
> > # Set polcy on the default chains
> > iptables -P INPUT DROP
> > iptables -P OUTPUT DROP
> > iptables -P FORWARD DROP
> > # allow anything over loopback
> > iptables -A INPUT -i lo -j ACCEPT
> > iptables -A OUTPUT -o lo -j ACCEPT
> > # Allow incoming ssh and http/s connections
> > iptables -A INPUT -p tcp -m tcp -m multiport --dports 22,80,443 -j
> > ACCEPT
> > iptables -A INPUT -j LOG --log-prefix="INPUT REJECT"
--log-level=info
> > iptables -A INPUT -j REJECT
> > # Allow already established ssh and http/s connections back out
through
> > the firewall
> > iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT
> 
> This allows all existing connections. If the above comment should be
> correct, you probably forgot here something.
> 
> > iptables -A OUTPUT -j LOG --log-prefix="OUTPUT REJECT"
--log-level=info
> > iptables -A OUTPUT -j REJECT
> > iptables -A FORWARD -j LOG --log-prefix="FORWARD REJECT"
> > --log-level=info
> > iptables -A FORWARD -j REJECT

Good point, that line was definitely wrong. What I'm trying to do this
block all traffic, including active connections, except incoming ssh and
http/s connections. From testing I've found the above does block all
traffic while allowing ssh and http/s in, but doesn't cutoff existing
connections.

I've tried this line instead of the one above but now all traffic,
including incoming ssh and http/s, seems to be blocked:
iptables -A OUTPUT -m tcp -m multiport --sports 22,80,443 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT

Any suggestions?

Thanks

Tim
This email and any attachment may contain confidential, privileged information for the sole use of the intended recipient. If you are not the intended recipient, do not disclose, reproduce, disseminate or otherwise use this communication. If you received this communication in error, please immediately notify the sender via email and delete the communication from your system.

RE: (no subject)

[Tim Edwards]

-----Original Message-----
From: Bernd Petrovitsch [mailto:bernd@firmix.at] 
Sent: 21 November 2006 10:13
To: Tim Edwards
Cc: netfilter@lists.netfilter.org
Subject: Re: (no subject)

> Yes. Just insert such a rule into the OUTPUT chain.

Ok I have the following rules but it still isn't cutting off existing
connections:

#!/bin/bash

# First clear all rules (and set the policy to DROP on the default
chains)
iptables -F
# Second delete all the extra (user-defined) chains
iptables -X
# Set polcy on the default chains
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# allow anything over loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow incoming ssh and http/s connections
iptables -A INPUT -p tcp -m tcp -m multiport --dports 22,80,443 -j
ACCEPT
iptables -A INPUT -j LOG --log-prefix="INPUT REJECT" --log-level=info
iptables -A INPUT -j REJECT
# Allow already established ssh and http/s connections back out through
the firewall
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix="OUTPUT REJECT" --log-level=info
iptables -A OUTPUT -j REJECT
iptables -A FORWARD -j LOG --log-prefix="FORWARD REJECT"
--log-level=info
iptables -A FORWARD -j REJECT


This email and any attachment may contain confidential, privileged information for the sole use of the intended recipient. If you are not the intended recipient, do not disclose, reproduce, disseminate or otherwise use this communication. If you received this communication in error, please immediately notify the sender via email and delete the communication from your system.

RE: (no subject)

[Bernd Petrovitsch]

On Tue, 2006-11-21 at 10:44 +0000, Tim Edwards wrote:
> 
> -----Original Message-----
> From: Bernd Petrovitsch [mailto:bernd@firmix.at] 
> Sent: 21 November 2006 10:13
> To: Tim Edwards
> Cc: netfilter@lists.netfilter.org
> Subject: Re: (no subject)
> 
> > Yes. Just insert such a rule into the OUTPUT chain.
> 
> Ok I have the following rules but it still isn't cutting off existing
> connections:

Yup.

> #!/bin/bash
> 
> # First clear all rules (and set the policy to DROP on the default
> chains)
> iptables -F
> # Second delete all the extra (user-defined) chains
> iptables -X
> # Set polcy on the default chains
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> # allow anything over loopback
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
> # Allow incoming ssh and http/s connections
> iptables -A INPUT -p tcp -m tcp -m multiport --dports 22,80,443 -j
> ACCEPT
> iptables -A INPUT -j LOG --log-prefix="INPUT REJECT" --log-level=info
> iptables -A INPUT -j REJECT
> # Allow already established ssh and http/s connections back out through
> the firewall
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

This allows all existing connections. If the above comment should be
correct, you probably forgot here something.

> iptables -A OUTPUT -j LOG --log-prefix="OUTPUT REJECT" --log-level=info
> iptables -A OUTPUT -j REJECT
> iptables -A FORWARD -j LOG --log-prefix="FORWARD REJECT"
> --log-level=info
> iptables -A FORWARD -j REJECT

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

(no subject)

[Tim Edwards]

Hi,

I don't know if this makes much sense with the way iptables works.
Anyway I'm trying to instantly stop all outgoing traffic from a machine,
even from processes that are currently running and may have connections
active.

Is this possible with iptables? 

Thanks 

Tim Edwards

This email and any attachment may contain confidential, privileged information for the sole use of the intended recipient. If you are not the intended recipient, do not disclose, reproduce, disseminate or otherwise use this communication. If you received this communication in error, please immediately notify the sender via email and delete the communication from your system.

Re: (no subject)

[Bernd Petrovitsch]

On Tue, 2006-11-21 at 09:25 +0000, Tim Edwards wrote:
> Hi,
> 
> I don't know if this makes much sense with the way iptables works.
> Anyway I'm trying to instantly stop all outgoing traffic from a machine,
> even from processes that are currently running and may have connections
> active.
> 
> Is this possible with iptables? 

Yes. Just insert such a rule into the OUTPUT chain.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: (no subject)

[Tamil E. Turnoffs]

[-- Attachment #1.1: Type: text/html, Size: 1310 bytes --]

[-- Attachment #1.2: nutshell.gif --]
[-- Type: image/gif, Size: 1377 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Doctor]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4165 bytes --]

[-- Attachment #1.2: Jarred.gif --]
[-- Type: image/gif, Size: 4830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Doctor]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3831 bytes --]

[-- Attachment #1.2: exemplar.gif --]
[-- Type: image/gif, Size: 4830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Rectums C. Palate]

welc ome to the best pharmacy http://<html>/?IJESRKUF5AVRhVV0VRWXFTX0dUHEJBW19UUUcaWkNV


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[Antonio Sampayo]

-- 
 --------------
< Debian Rules >
 --------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (no subject)

[Isabel Decker]

[-- Attachment #1.1.1: Type: text/plain, Size: 2636 bytes --]

just do their  and parents alike.  The efforts often children are plopped in  one day a week.  
kids: The American  academy report says.for creating  resists  says the report,   neighborhoods  It says enrichment tools  old-fashioned playtime.  of free play time,  
It can help children   the report says. stressed-out  lose school recess  overscheduled  
instead allowing  Atlanta, Georgia.  begin as early as infancy. these things, will  Social pressures  things you can do  
of Philadelphia, Pennsylvania. 
just do their  
become creative,   with get-smart   activities  Numerous studies  
would worry if  prepared by two  "I hope it will have some effect," "I truly believe  is more good,  really need for  super parents, I believe this message  skills,  videos, enrichment Noted pediatrician and author  
discover  weekly, plus T-ball  
love to do. 
"I truly believe  
lose school recess  instead allowing  Here's some soothing  and parents alike.  and organized  one day a week.  

is more good,  super parents, I believe this message  develop problem-solving  she says, she  become creative,  has a  
such as blocks and dolls,  classes in a  Noted pediatrician and author  it's chasing butterflies, playing with 
 contribute to depression  adjust to school settings, the  
help them excel.  
relate to others and  It says enrichment tools   with get-smart  If it occurs  and lots of 
 "true toys"  she says, she  
for looking for  
super parents, I believe this message  
academy report says. "Perhaps above all,  
"Perhaps above all,  for some of  plenty of time  stressed-out  playtime can create  
stressed-out  as a requirement  relate to others and  
her kids   "true toys"  time, it can increase risks for  help them excel.  drive to  in preschool  It says enrichment tools  
they must be  beneficial but should not be viewed  because young  
medicine for  
trouble finding buddies  annual meeting in  
Numerous studies  
one day a week.  A lack of spontaneous   activities   a lack of playtime  with the other kids." 
she says, she  playtime can create  part of childhood,"  play is a simple  
and 3-year-old   activities  and other play  "I truly believe   contribute to depression  
of free play time,  trouble finding buddies  
relate to others and   classes in a  in the shuffle,  If it occurs  one day a week.  
would worry if  these things, will  release Monday  
huge variety of  "I hope it will have some effect," a pediatrician at The Children's Hospital  beneficial but should not be viewed  the academy's report. own thing,"  
joy that is a cherished  have shown that  
"Perhaps above all,  
they must be  sp1 


[-- Attachment #1.1.2: Type: text/html, Size: 3634 bytes --]

[-- Attachment #1.2: ljmsr.{PIC_TYPE} --]
[-- Type: image/gif, Size: 8246 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Doctor]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 4203 bytes --]

[-- Attachment #1.2: disproportion.gif --]
[-- Type: image/gif, Size: 12294 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

(no subject)

[Kaleb D. Tuimala]

I am new to Linux. I am using Open Suse 10.0. Currently iptables 1.3.3 is
installed. I want to patch that up to 1.3.6. The problem I am having is
that I have no idea how to install the incremental patches from iptables
1.3.3 - 1.3.6. How do I successfully do this? If anyone could give me
detailed instructions on how to use the patches I would greatly appreciate
it.

-- Kaleb

Re: (no subject)

[Doctor]

[-- Attachment #1.1.1: Type: text/plain, Size: 1 bytes --]

 

[-- Attachment #1.1.2: Type: text/html, Size: 3521 bytes --]

[-- Attachment #1.2: emancipating.gif --]
[-- Type: image/gif, Size: 12294 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: (no subject)

[Garbs H. Pecan]

welco me to the best pharmacy http:///


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[ATA YAZILIM A.Þ.]

ARTIK PERSONEL TAKİBİ ÇOK KOLAY!!!

PARMAK İZLİ DEVAM KONTROL SİSTEMLERİ
"ŞİMDİ GEÇ KALANLAR DÜŞÜNSÜN"

UYGUN FİYAT-KOLAY KURULUM,KULLANIM-TÜRKÇE PROGRAM

30.10.2006 TARİHİNE KADAR VERİLEN SİPARİŞLERDE 200$ DEĞERİNDEKİ OTOMATİK
MAAŞ HESAPLAYISI BEDAVA!!!

BAYİLİKLER VERİLECEKTİR.

PDKS TÜRKİYE DİSTRİBÜTÖRÜ
ATA YAZILIM DONANIM A.Ş
MUSTAFA ALTINKILIÇ
TEL: 0462 223 4005
FAX: 0462 223 4017
mustafa@ataas.com
BEŞİRLİ MAH. OSA APT. KAT 1 TRABZON
www.ataas.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[Skelhorn.RJC]

Any update on this problem?
http://www.spinics.net/lists/alsa-devel/msg01148.html

Thanks
Richard

Please CC your reply to rskelhorn@eastlink.ca


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (Was Re: [Alsa-user] Poorly supported HDA intel)

[Ricardo Cerqueira]

On Fri, 20 Oct 2006 18:48:13 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 20 Oct 2006 18:35:43 +0200,
> Ricardo Cerqueira wrote:
>>
>>
>>
>> On Fri, 20 Oct 2006 18:18:09 +0200, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Fri, 20 Oct 2006 17:55:23 +0200,
>> > Ricardo Cerqueira wrote:
>> >>
>> >> On Fri, 20 Oct 2006 17:52:56 +0200, Takashi Iwai <tiwai@suse.de>
> wrote:
>> >> > At Fri, 20 Oct 2006 17:48:00 +0200,
>> >>
>> >> >>
>> >> >> Hmmm. I was trying to look into codec#0 to check the pin
> assignments,
>> >> > and I
>> >> >> realized it's being cut off at byte 4096, and I'm missing
>> > information.
>> >> > Looks
>> >> >> like something is limiting that proc entry's size to 4k, do you
> have
>> > any
>> >> > idea
>> >> >> where?
>> >> >
>> >> > Are your using HG version of driver?
>> >> > This bug should have been fixed recently.
>> >> >
>> >> >
>> >>
>> >> Yes, pulled about 14 hours ago...
>> >
>> > Strange, it works for me.  I tested to print extra data up to 32k
>> > bytes on my i386 machine, and it looks OK.
>> >
>> > Check alsa-kernel hg tree whether you have a changeset 4658
>> > "Fix re-use of va_list" (although it should work even without this
>> > patch on i386).
>>
>> Yes, I'm at changeset 4662... I checked core/info.c by hand, and the
> va_list
>> change is there... I just tried cloning fresh copies of alsa-kernel and
>> alsa-driver, and the result is the same.
> 
> Weird.  Could you check whether really it's 4k boundary problem?

Looks like it is:

> For example, try the patch below to see whether you get 500 dummy
> lines in codec#0 proc file.
> 

[root@frolic ~]# cat /proc/asound/card0/codec#0 | tail
[76] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[77] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[78] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[79] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[80] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[81] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[82] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[83] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[84] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[85] XXXXX DUMMY LINE XXX[root@frolic ~]#
[root@frolic ~]#
[root@frolic ~]# wc  /proc/asound/card0/codec#0
85 770 4095 /proc/asound/card0/codec#0

--
RC


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (Was Re: [Alsa-user] Poorly supported HDA intel)

[Ricardo Cerqueira]

On Fri, 20 Oct 2006 18:55:56 +0200, Ricardo Cerqueira <alsa-users@cerqueira.org> wrote:
> 
> On Fri, 20 Oct 2006 18:48:13 +0200, Takashi Iwai <tiwai@suse.de> wrote:
>> At Fri, 20 Oct 2006 18:35:43 +0200,
>> Ricardo Cerqueira wrote:
>>>
>>>
>>>
>>> On Fri, 20 Oct 2006 18:18:09 +0200, Takashi Iwai <tiwai@suse.de> wrote:
>>> > At Fri, 20 Oct 2006 17:55:23 +0200,
>>> > Ricardo Cerqueira wrote:
>>> >>
>>> >> On Fri, 20 Oct 2006 17:52:56 +0200, Takashi Iwai <tiwai@suse.de>
>> wrote:
>>> >> > At Fri, 20 Oct 2006 17:48:00 +0200,
>>> >>
>>> >> >>
>>> >> >> Hmmm. I was trying to look into codec#0 to check the pin
>> assignments,
>>> >> > and I
>>> >> >> realized it's being cut off at byte 4096, and I'm missing
>>> > information.
>>> >> > Looks
>>> >> >> like something is limiting that proc entry's size to 4k, do you
>> have
>>> > any
>>> >> > idea
>>> >> >> where?
>>> >> >
>>> >> > Are your using HG version of driver?
>>> >> > This bug should have been fixed recently.
>>> >> >
>>> >> >
>>> >>
>>> >> Yes, pulled about 14 hours ago...
>>> >
>>> > Strange, it works for me.  I tested to print extra data up to 32k
>>> > bytes on my i386 machine, and it looks OK.
>>> >
>>> > Check alsa-kernel hg tree whether you have a changeset 4658
>>> > "Fix re-use of va_list" (although it should work even without this
>>> > patch on i386).
>>>
>>> Yes, I'm at changeset 4662... I checked core/info.c by hand, and the
>> va_list
>>> change is there... I just tried cloning fresh copies of alsa-kernel and
>>> alsa-driver, and the result is the same.
>>
>> Weird.  Could you check whether really it's 4k boundary problem?
> 
> Looks like it is:

OK... The resize call is never reached (the break clause is always true).
I added a small printk before the size test, and got:

DEBUG - res=48 and len=74
DEBUG - res=25 and len=26
DEBUG - res=0 and len=1
DEBUG - res=0 and len=1
DEBUG - res=0 and len=1

And from here on, vsnprintf always returns 0. From my understanding of
the documentation, it shouldn't happen, but... (maybe a glibc bug?)

Changing the "if (res < len)" to "if (res && res < len)" solves it, but I
don't know if there'll be other side effects.




> 
>> For example, try the patch below to see whether you get 500 dummy
>> lines in codec#0 proc file.
>>
> 
> [root@frolic ~]# cat /proc/asound/card0/codec#0 | tail
> [76] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [77] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [78] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [79] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [80] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [81] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [82] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [83] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [84] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [85] XXXXX DUMMY LINE XXX[root@frolic ~]#
> [root@frolic ~]#
> [root@frolic ~]# wc  /proc/asound/card0/codec#0
> 85 770 4095 /proc/asound/card0/codec#0
> 
> --
> RC
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (no subject)

[Thierry Vignaud]

Ricardo Cerqueira <ricardo@cerqueira.org> writes:

> >>> > Check alsa-kernel hg tree whether you have a changeset 4658
> >>> > "Fix re-use of va_list" (although it should work even without
> >>> > this patch on i386).
> >>>
> >>> Yes, I'm at changeset 4662... I checked core/info.c by hand, and
> >>> the va_list change is there... I just tried cloning fresh copies
> >>> of alsa-kernel and alsa-driver, and the result is the same.
> >>
> >> Weird.  Could you check whether really it's 4k boundary problem?
> > 
> > Looks like it is:
> 
> OK... The resize call is never reached (the break clause is always
> true).  I added a small printk before the size test, and got:
> 
> DEBUG - res=48 and len=74
> DEBUG - res=25 and len=26
> DEBUG - res=0 and len=1
> DEBUG - res=0 and len=1
> DEBUG - res=0 and len=1
> 
> And from here on, vsnprintf always returns 0. From my understanding
> of the documentation, it shouldn't happen, but... (maybe a glibc
> bug?)

core/info.c is kernel land, no glibc code is used there

> Changing the "if (res < len)" to "if (res && res < len)" solves it,
> but I don't know if there'll be other side effects.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (no subject)

[misato]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/?06
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*

お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?03
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/?06

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/?06

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/?06
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/?06

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.bz/pc/?06

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.bz/pc/?06


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/?06

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/?06

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?06
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/?06
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[Thomas Sandquist]

Hello,

I'm trying to find out if the ipt_random module can be compiled in to the
2.6 kernels? A few years ago (back in the day of kernel 2.4) I patched and
compiled this module in to the kernel and used it in a load balancing
script (shotgunning cable modems). I'm interested in doing this with a new
box running FC5 (currently kernel 2.6.18) but have found very little
information on it. I finally figured out how to get POM again (I think I
got the right version anyways... it's now POM-NG however the release date
was in 2004) and found the random source there but the info note says it
only works on kernels below 2.6.0. Do I just have too old of a version of
the POM package or is the random module really only available in the 2.4
kernel? If it's not available in the 2.6 kernel are their any alternative
modules that I should be looking in to (perhaps the nth module although I
haven't really read up on it yet)? Any help would be appreciated. It was
great shotgunning cable modems with this setup a few years ago and it
would be even cooler if I could get this working on a more modern distro
(I am open to other distro's other than Fedora if someone knows of one
that might be better for my routing purposes).

Thanks,
Thomas Sandquist

Re: (no subject)

[James Templeton]

Good day,

Accoring to your prior applications, we can 
offer you anywhere from 217K at 6.32% to 672K at 5.95%

http://contrum.com/16r

Please fill in your info and instantly get your FICO score.
Poor scores are NOT a problem. 

Thanks,
James Templeton



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[albox]

It doesn't work for me either (at least, I can load the driver after using the
patch from Takashi).

Here are some details :

lspci -nv says:
0000:00:1b.0 0403: 8086:27d8 (rev 02)
        Subsystem: 161f:2054
        Flags: bus master, fast devsel, latency 0, IRQ 82
        Memory at d5300000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable+
        Capabilities: [70] #10 [0091]

$ dmesg | grep ALSA
[17179588.696000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:680:
codec_mask = 0x3
[17179588.876000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:1741:
hda_codec: model 'medion' is selected
[17179589.604000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:245:
si3054: cannot initialize. EXT MID = 0000
[17179589.612000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/patch_si3054.c:257:
Link Frame Detect(FDT) is not ready (line status: 0000)
[17179635.900000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1142:
azx_pcm_prepare: bufsize=0x10000, fragsize=0x1000, format=0x11
[17179635.900000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
[17179635.908000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
hda_codec_setup_stream: NID=0x4, stream=0x5, channel=0, format=0x11
[17179635.916000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
hda_codec_setup_stream: NID=0x3, stream=0x5, channel=0, format=0x11
[17179635.924000] ALSA
/home/albuntu/install/realtek-linux-audiopack-4.05b/alsa-driver-1.0.13/pci/hda/hda_codec.c:630:
hda_codec_setup_stream: NID=0x5, stream=0x5, channel=0, format=0x11

$ cat /proc/asound/card0/codec#0
Codec: Realtek ALC883
Address: 0
Vendor Id: 0x10ec0883
Subsystem Id: 0x161fd82b
Revision Id: 0x100002
Default PCM: rates 0x560, bits 0x0e, types 0x1
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
Node 0x02 [Audio Output] wcaps 0x11: Stereo
  PCM: rates 0x560, bits 0x0e, types 0x1
Node 0x03 [Audio Output] wcaps 0x11: Stereo
  PCM: rates 0x560, bits 0x0e, types 0x1
Node 0x04 [Audio Output] wcaps 0x11: Stereo
  PCM: rates 0x560, bits 0x0e, types 0x1
Node 0x05 [Audio Output] wcaps 0x11: Stereo
  PCM: rates 0x560, bits 0x0e, types 0x1
Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital
  PCM: rates 0x560, bits 0x1e, types 0x1
Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x08 [Audio Input] wcaps 0x10011b: Stereo Amp-In
  Amp-In caps: ofs=0x08, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x80 0x80]
  PCM: rates 0x160, bits 0x06, types 0x1
  Connection: 1
     0x23
Node 0x09 [Audio Input] wcaps 0x10011b: Stereo Amp-In
  Amp-In caps: ofs=0x08, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x80 0x80]
  PCM: rates 0x160, bits 0x06, types 0x1
  Connection: 1
     0x22
Node 0x0a [Audio Input] wcaps 0x100391: Stereo Digital
  PCM: rates 0x560, bits 0x1e, types 0x1
  Connection: 1
     0x1f
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x00 0x00] [0x1f 0x1f] [0x00 0x00] [0x00 0x00] [0x00 0x00]
[0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 10
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17
Node 0x0c [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
  Amp-Out vals:  [0x1f 0x1f]
  Connection: 2
     0x02 0x0b
Node 0x0d [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
  Amp-Out vals:  [0x06 0x06]
  Connection: 2
     0x03 0x0b
Node 0x0e [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
  Amp-Out vals:  [0x0b 0x07]
  Connection: 2
     0x04 0x0b
Node 0x0f [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
  Amp-Out vals:  [0x06 0x06]
  Connection: 2
     0x05 0x0b
Node 0x10 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x12 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x14 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x083e: IN OUT HP Detect
  Pin Default 0x01011110: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x15 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x083e: IN OUT HP Detect
  Pin Default 0x01011112: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x0c 0x0d* 0x0e 0x0f 0x26
Node 0x16 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x083e: IN OUT HP Detect
  Pin Default 0x01011111: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x0c 0x0d 0x0e* 0x0f 0x26
Node 0x17 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x083e: IN OUT HP Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x40: OUT
  Connection: 5
     0x0c 0x0d 0x0e 0x0f* 0x26
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x08173e: IN OUT HP Detect
  Pin Default 0x02a11c3f: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Black
  Pin-ctls: 0x24: IN
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x19 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x08173e: IN OUT HP Detect
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x24: IN
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x08173e: IN OUT HP Detect
  Pin Default 0x99830130: [Fixed] Line In at Int ATAPI
    Conn = ATAPI, Color = Unknown
  Pin-ctls: 0x20: IN
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x1b [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x08173e: IN OUT HP Detect
  Pin Default 0x0221111f: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Black
  Pin-ctls: 0xc0: OUT HP
  Connection: 5
     0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x0820: IN
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
  Pin-ctls: 0x00:
Node 0x1d [Pin Complex] wcaps 0x400000: Mono
  Pincap 0x0820: IN
  Pin Default 0x99830131: [Fixed] Line In at Int ATAPI
    Conn = ATAPI, Color = Unknown
  Pin-ctls: 0x00:
Node 0x1e [Pin Complex] wcaps 0x400300: Mono Digital
  Pincap 0x0810: OUT
  Pin Default 0x01451120: [Jack] SPDIF Out at Ext Rear
    Conn = Optical, Color = Black
  Pin-ctls: 0x00:
  Connection: 1
     0x06
Node 0x1f [Pin Complex] wcaps 0x400200: Mono Digital
  Pincap 0x0820: IN
  Pin Default 0x01c46160: [Jack] SPDIF In at Ext Rear
    Conn = RCA, Color = Orange
  Pin-ctls: 0x00:
Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x22 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x80 0x80] [0x00 0x00]
[0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Amp-Out caps: N/A
  Amp-Out vals:  [0x00 0x00]
  Connection: 11
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
Node 0x23 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
[0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Amp-Out caps: N/A
  Amp-Out vals:  [0x00 0x00]
  Connection: 11
     0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x14 0x15 0x16 0x17 0x0b
Node 0x24 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x25 [Audio Output] wcaps 0x11: Stereo
  PCM: rates 0x560, bits 0x0e, types 0x1
Node 0x26 [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
  Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-In vals:  [0x00 0x00] [0x80 0x80]
  Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=0
  Amp-Out vals:  [0x00 0x00]
  Connection: 2
     0x25 0x0b


I also tried speaker-test but nothing happened. I'll now try the tarball that
Remy posted last weekend and I'll let you know if it works...

Cheers,
AL

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

(no subject)

[Timo Benk]

Hi,

i am using two domains, which are internally connected by one virtual interface.

xendom1: Backend Domain without a physical interface
xendom2: normal Domain-U using xendom1 as a vif-Backend-Domain

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
 ---------      ---------

Then i add another virtual interface to xendom2.

 ---------      ---------
| xendom1 |    | xendom2 |
|         |    |         |
|  vif2.0--------eth0    |
|         |    |         |
|  vif2.1--------eth1    |
|         |    |         |
 ---------      ---------

Domain-0:~ # xm network-attach xendom2 backend=xendom1
                script=vif-nothing

---<snip>---
# /etc/xen/script/vif-nothing in Domain xendom1
dir=$(dirname "$0")
. "$dir/vif-common.sh"

success
---<snap>---

Then i save both domains:

Domain-0:~ # xm save xendom2
Domain-0:~ # xm save xendom1
Error: /usr/lib/xen/bin/xc_save 17 4 0 0 0 failed
Usage: xm save <Domain> <CheckpointFile>

Save a domain state to restore later.

Domain-0:~ # xm list
Name                       ID Mem(MiB) VCPUs State   Time(s)
Domain-0                   0      985     2 r-----     62.5
Zombie-migrating-xendom2   5      512     1 ---s-d     18.0
xendom1                    4      128     1 ---s--     19.6

Both domains are not reachable anymore, i need to destroy xendom1 and xendom2 lives another life as a zombie domain :-(

Greetings,
-timo
-- 
Timo Benk - B1 Systems GmbH (http://www.b1-systems.de)
Jabber ID: fry@jabber.org - ICQ ID: #241877854
PGP Public Key: http://m28s01.vlinux.de/b1_gpg_key.asc

Re: (no subject)

[yuki]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/01
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/01

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/01
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.bz/pc/01


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.jp/pc/?1
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/01
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[miyuki]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/?02
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/?02

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/?02
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.jp/pc/?06

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.jp/pc/?06


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

お問い合わせ先はこちら↓
広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892






-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: (no subject)

[lucke]

On Tuesday 26 September 2006 00:11, lucke wrote:
> http://zeniv.linux.org.uk/~telsa/boom/

Oops, please disregard. Apparently whole day studying doesn't help my ability 
to send mails to correct recipients.

Pardon,

Luke

Re: (no subject)

[yukihana]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/?02
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/?02

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/?02
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/?02

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.jp/pc/?06

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.jp/pc/?06


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/?02

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/?02
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

お問い合わせ先はこちら↓
広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892






-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[Laurent CARON]

unsubscribe linux-kernel

(no subject)

[Laurent CARON]

unsubscribe linux-kernel

(no subject)

[Tim Kirk]

Hi,

Not certain if this is where I should post this, but I've not been  
able to find anything or anywhere else that seems able to help me  
with this.

I have a PC with an A8V Deluxe motherboard using all 4 SATA channels  
for 4 drives. This machine worked how I needed it to under Fedora  
Core 4, and I have just reinstalled it with FC5 only to find that it  
will not let me run the 4 SATA drives as four separate drives.

After booting I find that the third and fourth drives are taken over  
by dm, and have a /dev/dm-0 and /dev/dm-1 that are not usable due to  
invalid partition tables and assorted other errors (not valid block  
devices etc...).

Using 'dmsetup remove_all' and then 'fdisk /dev/sdc', 'fdisk /dev/ 
sdd' (to give me a single partition on each drive), 'mke2fs -j /dev/ 
sdc1', 'mke2fs -j /dev/sdd1' gives me two mountable, usable, drives.

When I reboot the machine though these drives are remapped as /dev/dm- 
o and /dev/dm-1 and are now unmountable. If I use 'dmsetup  
remove_all' again the drives are now available to be reformatted  
again, but I have reformat them to make use of them.

Surely there is some way to tell device-mapper to leave things alone?  
I simply need four drives that I can use as four separate units - no  
RAIDing, nothing fancy, but this it seems impossible to tell the OS  
that...

Cheers,

Tim Kirk

More Detailed Information Below -

kudzu -ps

class: HD
bus: SCSI
detached: 0
device: sda
desc: "ATA HDS722525VLSA80"
host: 1
id: 0
channel: 0
lun: 0
-
class: HD
bus: SCSI
detached: 0
device: sdb
desc: "ATA HDS722525VLSA80"
host: 2
id: 0
channel: 0
lun: 0
-
class: HD
bus: SCSI
detached: 0
device: sdc
desc: "ATA HDS722525VLSA80"
host: 3
id: 0
channel: 0
lun: 0
-
class: HD
bus: SCSI
detached: 0
device: sdd
desc: "ATA HDS722525VLSA80"
host: 4
id: 0
channel: 0
lun: 0
-
class: RAID
bus: PCI
detached: 0
driver: sata_via
desc: "VIA Technologies, Inc. VIA VT6420 SATA RAID Controller"
vendorId: 1106
deviceId: 3149
subVendorId: 1043
subDeviceId: 80ed
pciType: 1
pcidom:    0
pcibus:  0
pcidev:  f
pcifn:  0
-
class: RAID
bus: PCI
detached: 0
driver: sata_promise
desc: "Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378)"
vendorId: 105a
deviceId: 3373
subVendorId: 1043
subDeviceId: 80f5
pciType: 1
pcidom:    0
pcibus:  0
pcidev:  8
pcifn:  0
-

Straight after reboot  (snipped out /dev/sda & /dev/sdb) :

[root@bragg1 ~]# fdisk -l

Disk /dev/sdc: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       30401   244196001   83  Linux

Disk /dev/sdd: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1       30401   244196001   83  Linux

Disk /dev/dm-0: 250.0 GB, 250059292672 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/dm-0p1               1       30401   244196001   83  Linux

Disk /dev/dm-1: 250.0 GB, 250056705024 bytes
255 heads, 63 sectors/track, 30400 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-1 doesn't contain a valid partition table

Then :

[root@bragg1 ~]# fdisk /dev/dm1

Unable to open /dev/dm1

[root@bragg1 ~]# fdisk /dev/dm-0

The number of cylinders for this disk is set to 30401.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
    (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/dm-0: 250.0 GB, 250059292672 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/dm-0p1               1       30401   244196001   83  Linux

Command (m for help): q

So I have 1 disk I can use.

I then go through the dmsetup remove_all, fdisk, mke2fs rigmarole and  
then have two discs I can mount (I only have to fdisk /dev/sdc, then  
use 'p' to check that the partition table is what I want, and 'w' to  
write it and exit and the disk is fine for writing a filesystem onto  
- so the partition table is there as far as fdisk is concerned, but  
is not being read properly at some over level in the OS):

[root@bragg1 ~]# df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
<snipped other drives>
/dev/sdc1            240362656    192672 237728024   1% /xray/bragg1c
/dev/sdd1            240362656    192672 237728024   1% /xray/bragg1d

This seems fine - exactly what I want. Then I try to reboot (I've had  
to make the drives 'noauto' and not to be fsck'd in /etc/fstab to get  
through the boot process without a 'cannot find /dev/sdc1' error).

And I get this :

[root@bragg1 ~]# mount -t ext3 /dev/sdc1 /xray/bragg1c
mount: /dev/sdc1 is not a valid block device
[root@bragg1 ~]# mount -t ext3 /dev/sdd1 /xray/bragg1d
mount: /dev/sdd1 is not a valid block device

What do I have to do to get the boot process to leave my hard drives  
formatted how they were before the reboot?

Re: (no subject)

[Dave Wysochanski]

> Surely there is some way to tell device-mapper to leave things alone?  
> I simply need four drives that I can use as four separate units - no  
> RAIDing, nothing fancy, but this it seems impossible to tell the OS  
> that...
> 
Did you try blacklisting in /etc/multipath.conf?

I don't know which keyword for your setup - either blacklist or
devnode_blacklist.

Something like this should work:

devnode_blacklist {
       devnode "^sd[a-d]$"
}

_or_

blacklist {
       devnode "^sd[a-d]$"
}

To blacklist everything use devnode "*".

To verify the blacklist use the multipath command:
# multipath -d -v3 | grep sd
sda: blacklisted

Re: (no subject)

[Darrick J. Wong]

Mr. Kirk,

> Sounds like dmraid is grabbing them.  I'm not sure where the configuration for
> dmraid is, but that's a starting point.

I think FC5 runs "dmraid -ay" automatically, which probes disks and sets
up device-mapper configurations.  However, to ensure that this is really
dmraid's fault, could you post the output of "dmsetup table" after you
boot the system (and before you blow away the dm devices, obviously)?

If it _is_ dmraid, then you'll want to clean out any RAID configurations
in the SATA BIOS, and/or run dmraid -E /dev/sdX to remove the dmraid
configuration data.

Thanks,

--Darrick

RE: (no subject)

[ted creedon]

For what its worth, using SuSE 10.1

1. Set up e Nvidia SATA raids in the bios slots 2 and 3 in the controller,
slot 1 is linux
2. Devices look like /dev/sdb1 /dev/sdc1 on boot
3. run YaST it detects /dev/sdb and sdc as raid
4. use YaST partitioner to make /dev/md0 a mirror raid for sdb and sdc
5. /dev/sdb1 and /dev/sdc1 disappear and are replaced with /dev/md0

tedc

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On
Behalf Of Darrick J. Wong
Sent: Thursday, September 14, 2006 3:06 PM
To: device-mapper development
Subject: Re: [dm-devel] (no subject)

Mr. Kirk,

> Sounds like dmraid is grabbing them.  I'm not sure where the configuration
for
> dmraid is, but that's a starting point.

I think FC5 runs "dmraid -ay" automatically, which probes disks and sets
up device-mapper configurations.  However, to ensure that this is really
dmraid's fault, could you post the output of "dmsetup table" after you
boot the system (and before you blow away the dm devices, obviously)?

If it _is_ dmraid, then you'll want to clean out any RAID configurations
in the SATA BIOS, and/or run dmraid -E /dev/sdX to remove the dmraid
configuration data.

Thanks,

--Darrick


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

(no subject)

[qinping]

[-- Attachment #1: Type: text/plain, Size: 4 bytes --]






[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[yukaridayo]

:―― INFORMATION  ―――――――――――――――――――――――――:
 不正・悪質なサイトを一切排除しておりますので
 安心してご利用ください。   http://love-match.bz/pc/01
:――――――――――――――――――――――――――――――――――:

*・゜゜・*:.。. .。.:*・゜゜・*:.。..。:*・゜゜・*:.。..。:**・゜゜・*


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 不倫・ワリキリ専門の無料出会いサイト『Love☆Match』
　-----------------------------------------------------------------
　　登録料・利用料　・・・・・・・・・【無料】
　　メールの送受信　・・・・・・・・・【無料】
　　ユーザーの検索　・・・・・・・・・【無料】
　　掲示板の閲覧・書込み　・・・・・・【無料】
　　画像交換・アップロード　・・・・・【無料】
　　アドレス交換・電話番号交換　・・・【無料】
　-----------------------------------------------------------------
　　どれだけ使っても全て無料！　http://love-match.bz/pc/01

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ いつでも女性ユーザーがいっぱい。その理由は？

　-----------------------------------------------------------------
　ＰＣ＆モバイルに対応！いつでもどこでも気軽に楽しめる！
　-----------------------------------------------------------------
　仕事中は携帯電話から、プライベートは自宅からのんびりと。
　気になる相手といつでも繋がっているから、新密度も急速にＵＰ。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　ＰＣから簡単プロフィール作成。ネット初心者でもラクラク参加ＯＫ
　-----------------------------------------------------------------
　面倒な登録は一切不要。パソコンから簡単なプロフィールを作成して
　初心者の方や女性でもすぐに参加できます。
　http://love-match.bz/pc/01
　-----------------------------------------------------------------
　自由恋愛対応！直電・直メ交換支援ツール
　-----------------------------------------------------------------
　基本的にメールアドレスや電話番号は非公開ですが
　仲良くなった人だけにメールアドレスや電話番号を教える事ができます。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　写真アップロードに対応！好みの相手を素早くＣＨＥＣＫ！
　-----------------------------------------------------------------
　待ち合わせ場所にイメージとまったく違う人が来たら…。
　ピュアックスなら会う前に写真交換ができるから、そんな不安も解消。
　http://love-match.bz/pc/01

　-----------------------------------------------------------------
　スレッド掲示板で秘密のパートナー検索も効率ＵＰ！
　-----------------------------------------------------------------
　メインの掲示板のほかにスレッド型の掲示板を設置。
　メル友から秘密のパートナーまで目的別のユーザーが集う掲示板です。
　http://love-match.bz/pc/01


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　□■ 毎日500人近くのユーザーが続々参加中！！

□-----------------------------------------------------------------

　リエ（２１歳/会社員）
　いつも１人でエッチなことを考えてます。
　メールだといろいろ話せるんだけど、実際に会うとあまりしゃべれなく
　なっちゃうので、盛り上げてくれるような楽しい男の人いないかな？
　引っ込み思案のせいか、男性経験はあまり無いんです。
　優しく＆楽しくリードしてくれる男性からのメール待ってます。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　真菜（２４歳/フリーター）
　彼氏が浮気してて超アタマきたっ！まなだって遊びたい盛りだし、ずっと
　ガマンしてたのにさ！かっこいい人見つけて思いっきりふってやるつもりで
　登録してみた（笑）
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　みさ（３４歳/専業主婦）
　殆ど家に帰ってこない仕事人間のだんなさまと二人きりの毎日で、ほんと
　寂しい思いをしています。年下の男の子がいれば仲良くなりたいな。
　年下の人とは付き合ったことがないので興味津々です(^^)
　[写真無し] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　恭子（２８歳/会社員）
　彼氏とはいつも同じようなセックスばかりでかなり冷め気味です。
　誰かあたしと熱いセックスを楽しみませんか？めんどくさい事は
　言いません。ただ、いつもと違うドキドキするような事がしたい
　だけなんです。
　[写真無し] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　ななこ（２８歳/主婦）
　半年前にだんなと別れて今は×1です。
　夜のお仕事なので、昼間まったりと過ごしませんか？
　心身ともに疲れ気味で、今、激しく癒されたいです。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　祥子（３１歳/クリエイター）
　平日は18時くらいまでは大体仕事してるので、その後に食事したり
　楽しく飲んだりできるパートナー希望です。年上でも年下でも
　かまいませんので気軽にメールを送って頂けると嬉しいです。
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------

　ゅヵ`（２０歳/学生）
　まずゎ会ってみないとはじまらなぃょね？！
　横浜近辺の人で、いろんな意味でオトナな人は
　プロフ付きでめぇる送って☆
　[写真有り] http://love-match.bz/pc/01

□-----------------------------------------------------------------


   出会いサイトのサクラに騙されないように↓
　┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　【裏】無料の出会い情報
　　-------------------------------------------------------------
　　お金と時間を持て余している人妻の間で、噂になってるあのサイト
　　[登録・利用料全て無料]　http://love-match.jp/pc/?1
　　-------------------------------------------------------------
　　彼女達が求めているのはこんな男性です。
　　?年上女性にリードしてもらいたい、経験少なめの男性
　　?体力・テクニックに自信が有る男性
　　男性会員が不足しています。我こそは、と思う方は今すぐ参加！
　　[登録・利用料全て無料]　http://love-match.bz/pc/01
　┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

広東省茂名市人民大街3-6-4-533
友誼網絡公司
139-3668-7892




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[ashish gawarikar]

subscribe netdev

(no subject)

[richard]

Hi. 

 Recently I'm developing a firewall router with linux 2.4(and I can only
use 2.4 for some reasons). But there are more resources about the linux 2.6
netfilter. Do you think I should port the netfilter frameworke from linux
2.6 to linux 2.4 to have more support? :) (I think it's a bad idea). 

richard

(no subject)

[Franck Bui-Huu]

subscribe

--

Franck BUI-HUU
Software Engineer

INNOVA CARD
ZI Athelia IV - Le Forum, Batiment A
2 avenue de la Tramontane
13705 La Ciotat Cedex - France
Phone  : +33 (0)4 42 98 15 35
Fax    : +33 (0)4 42 08 33 19
Email  : franck.bui-huu@innova-card.com
Web    : www.innova-card.com

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
Innova Card will not therefore be liable for the message if modified.

(no subject)

[Bernd Schubert]

Hi,

I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 =

and the client is 2.6.16. I need some help regarding the nfs protocol.

Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I als=
o =

guess the inode was recycled.

A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
A 'cat /etc/mozilla/mozillarc' gave i/o errors.

Ethereal shows that the getattr gives the correct results, but the read cal=
l =

gives an NFS3ERR_STALE. =

Should the client in this case drop its filehandle cache and entirely =

re-request the file from the server, or is the given i/o error ok?

>From the point of the server, I guess, it already should return the =

NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the =

sources to see why it didn't. (unfs3 was compiled with inode generation =

number support).

After an 'echo 3 > /proc/sys/vm/drop_caches' the problem was solved for now=
, =

of course.


Thanks in advance,
	Bernd



-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> Hi,
> 
> I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 
> and the client is 2.6.16. I need some help regarding the nfs protocol.
> 
> Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I also 
> guess the inode was recycled.
> 
> A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
> A 'cat /etc/mozilla/mozillarc' gave i/o errors.
> 
> Ethereal shows that the getattr gives the correct results, but the read call 
> gives an NFS3ERR_STALE. 
> Should the client in this case drop its filehandle cache and entirely 
> re-request the file from the server, or is the given i/o error ok?

The ESTALE error is usually correct. The client should not be reopening
the file unless it can guarantee that the file is the same as the one
that was originally open()ed.

> From the point of the server, I guess, it already should return the 
> NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the 
> sources to see why it didn't. (unfs3 was compiled with inode generation 
> number support).

Yes. Under the close-to-open caching model, the expectation is that the
filehandle will remain valid from the moment the successful GETATTR call
is sent in the first open() request until the last call to close(). If
unfs3 is caching filehandles, then it needs to use something like
inotify in order to figure out when to invalidate its cache.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Li, Xin B]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

on x86_64, when guest has more than 2G memory, "startx" will cause qemu
dm die, this patch fixes it.

Signed-off-by: Xin Li <xin.b.li@intel.com>

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c  Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c  Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start,
double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1,
bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- Attachment #2: vga.patch --]
[-- Type: application/octet-stream, Size: 621 bytes --]

diff -r ecb8ff1fcf1f tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c	Fri Jul 14 18:53:27 2006 +0100
+++ b/tools/ioemu/hw/vga.c	Mon Jul 17 22:35:54 2006 +0800
@@ -1392,7 +1392,8 @@ static void vga_draw_graphic(VGAState *s
 static void vga_draw_graphic(VGAState *s, int full_update)
 {
     int y1, y, update, page_min, page_max, linesize, y_start, double_scan, mask;
-    int width, height, shift_control, line_offset, page0, page1, bwidth;
+    int width, height, shift_control, line_offset, bwidth;
+    ram_addr_t page0, page1;
     int disp_width, multi_scan, multi_run;
     uint8_t *d;
     uint32_t v, addr1, addr;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[gary douglas]

Try to build a clean box with Fedora Core 4 and IPTables with  
connlimits. I keep running into errors.

I clean install Fedora Core 4. Download iptables 1.3.5, patch-o-matic  
20060710, and linux kernel 2.6.17.3. Create a link from /usr/src/ 
linux to the linux kernel directory.

cd into patch o matic and enter the following:
export KERNEL_DIR=/usr/src/linux

export IPTABLES_DIR=~/iptables-1.3.5

./runme connlimit


I have to force this as connlimit, if I do a y I get the following  
error:

unable to find ladd slot in src /tmp/pom-29493/net/ipv4/netfilter/ 
Makefile (./patchlets/connlimit/linux-2.6.11/./net/ipv4/netfilter/ 
Makefile.ladd)

than I cd over to iptables folder and run the make command. I get the  
following error at this time:

cc -O2 -Wall -Wunused -I/usr/src/linux/include -Iinclude/ - 
DIPTABLES_VERSION=\"1.3.5\"  -D_UNKNOWN_KERNEL_POINTER_SIZE -fPIC -o  
extensions/libipt_CLUSTERIP_sh.o -c extensions/libipt_CLUSTERIP.c
In file included from /usr/src/linux/include/linux/config.h:6,
                  from /usr/src/linux/include/linux/netfilter_ipv4.h:8,
                  from /usr/src/linux/include/linux/netfilter_ipv4/ 
ip_tables.h:26,
                  from include/libiptc/libiptc.h:6,
                  from include/iptables.h:5,
                  from extensions/libipt_CLUSTERIP.c:18:
/usr/include/linux/autoconf.h:1:2: error: #error Invalid kernel  
header included in userspace
make: *** [extensions/libipt_CLUSTERIP_sh.o] Error 1


Any suggestion on correcting this problem are welcome.

Thank you
Gary Douglas

RE: (no subject)

[Rob Sterenborg]

> Try to build a clean box with Fedora Core 4 and IPTables with 
> connlimits. I keep running into errors.
> 
> I clean install Fedora Core 4. Download iptables 1.3.5, 
> patch-o-matic 20060710, and linux kernel 2.6.17.3. Create a 
> link from /usr/src/ linux to the linux kernel directory.
> 
> cd into patch o matic and enter the following:
> export KERNEL_DIR=/usr/src/linux
> 
> export IPTABLES_DIR=~/iptables-1.3.5
> 
> ./runme connlimit
> 
> 
> I have to force this as connlimit, if I do a y I get the following
> error:
> 
> unable to find ladd slot in src /tmp/pom-29493/net/ipv4/netfilter/
> Makefile (./patchlets/connlimit/linux-2.6.11/./net/ipv4/netfilter/
> Makefile.ladd)

And thus your kernel-/iptables-source isn't patched.

I had the same error and patched the kernel manually.
Look in POM in patchlets/connlimit directory and you'll find what you
need. The directory layout is just like you find it in the kernel
source.
Add the content of Makefile.ladd to the appropriate Makefile and that of
Kconfig.ladd to the appropriate Kconfig. Copy the .c and .h files into
the appropriate directories.
Start "make menuconfig" and the new options should show up and compile.


Gr,
Rob

(no subject)

[潘思广]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

贵公司领导、财务：
    
        我公司是深圳市宏溢诚贸易有限公司（注册号：4403012161790）。
    成立于2002年6月，经过几年的发展我公司不断壮大，在国内多处大中
    城市设有分公司，是一家集机电设备、电子产品、化工原料、建材、办
    公设备，国内商业、物资供销业等于一体的大型企业。 并与国内上百家  
    公司有着密切的联系。我公司业务量大、进项大、业务范围广，信誉好。
    现我公司特开设代理代开发票业务，代开范围：全国各地运输发票、商
    品销售票、建筑安装票、广告票、其他服务、餐饮、增值票、海关代征
    票等……本公司郑重承诺所有票据均为各单位在税务部门申领，可在网
    上查询或到税务部门抵扣验证。贵厂家、贵公司若有需要请向我公司人
    员联系！
    

    联系电话：0755-21006449或13728960698  范先生
    

    顺祝：生意兴隆，合作愉快！

                                   宏溢诚贸易有限公司财务部


[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Jochen Maes]

(no subject)

[Petronenko Denis]

subscribe

(no subject)

[Paulo Cordeiro]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[legwpjv]

(no subject)

[Abimanyu G]

(no subject)

[cycrypxz]

(no subject)

[icjoqtc]

Re: (no subject)

[Rita Bruce]

-S''ensationall r'evoolution in m''edicine!

-En  large your p''e'n'i's up to 10 cm or up to 4 i'nches!

-It's h'e'r'b'a'l solution what hasn't side e'ffect, but has 100% g'uaranted results!

-Don't lose your chance and but know wihtout d'oubts, you will be i'mpressed with results!

 Clisk here: http://gift-samsung.com










dark disputant eclogue impure lethe haberman fringe gum permit furry
laboratory cried tributary ada malady revenue attenuate tugging railroad
dignity castle symbol dignify drumhead potatoes echo emerald vega stare came
expiration loot montmartre tuscarora testimony shirk dominion deface
midas barrington commonweal duet quickie painful cheek falstaff
stagy kafkaesque psychotic atop taut diagnoses bass coalesce

(no subject)

[vineet chadha]

Hi,

Compiling xen-3.0.2.2 on host redhat 2.4.18 kernel I am getting following error:


make[2]: Entering directory `/root/software/xen-3.0.2-2'
if grep "^CONFIG_MODULES=" linux-2.6.16-xen/.config ; then \
    make -C linux-2.6.16-xen ARCH=i386 modules ; \
    make -C linux-2.6.16-xen ARCH=i386
INSTALL_MOD_PATH=/root/software/xen-3.0.2-2/dist/install
modules_install ; \
fi
CONFIG_MODULES=y
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
  CHK     include/linux/version.h
  Building modules, stage 2.
  MODPOST
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[3]: Entering directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt
rm: invalid option -- x
Try `rm --help' for more information.
make[3]: *** [_modinst_] Error 1
make[3]: Leaving directory `/root/software/xen-3.0.2-2/linux-2.6.16-xen'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/root/software/xen-3.0.2-2'
make[1]: *** [linux-2.6-xen-install] Error 2
make[1]: Leaving directory `/root/software/xen-3.0.2-2'
make: *** [install-kernels] Error 1

Please help
-John

process starvation with 2.6 scheduler

[Kallol Biswas]

Hello,
       We have a process starvation problem with our 2.6.11 kernel running on a ppc-440 based system.

We have a storage SOC based on PPC-440. The SOC is emulated on a system emulator called Palladium. It is from Cadence. The system runs at 400KHz speed. It has three Ethernet ports; they are connected to outside lab network with a speed bridge.

The netperf server netserver runs on the emulated system (2.6.11 kernel on Palladium). There are netperf linux clients running on a x86 box.

If netperf request response (TCP_RR) traffic is run on all three ports; after sometime only one port remains active, the application (netperf client) on other two ports wait for a long time and eventually time out.

The netserver code has been instrumented. For one of the starved netserver processes it has been found that the TCP_RR request from the netperf client on linux x86 box has been received by the server, it has issued send() call to send back reply but send() never returns.

With an ICE connected to the Palladium (emulator) I have dumped the kernel data structures of the starved process and the active process. 


For Active  Process:
  Time_slice 84
  Policy : SCHED_NORMAL
  Dynamic priority: 118
  Static priority: 120
  Preempt_count: 0x20100
  Flags = 0
  State = 0 (TASK_RUNNING)

For Starved Process:
  Time slice: 77
  Policy: SCHED_NORMAL
  Dynamic priority: 120
  Static priority: 120
  Preempt_count: 0x10000000 (PREEMPT_ACTIVE is set)
  Flags = 0 
  State = 0 (TASK_RUNNING)

Any help to debug the problem is welcome. 

Kallol

(no subject)

[Hack Sung Lee]

unsubscribe linux-kernel

(no subject)

[Kevin Tronkowski]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Attached is a patch which extends vmxassist to handle two cases 
related to mode switching found while experimenting with different 
boot loaders.

The first case is use of the JMP instruction with memory location 
operands to complete a switch to protected mode. This patch adds 
emulation for this form of the JMP instruction to vmxassist.

The second case is where boot loader code does not save/restore a 
non-zero SS register across a protected mode traversal. 
Zeroing the SS register in vmxassist results in all sorts of problems 
in the domU after returning back to real mode. This patch stores 
segment register values before entering protected mode and correctly 
restores the old values (instead of an incorrect zero value) when 
reentering real mode. 

Signed-off-by Kevin Tronkowski <ktronkowski@virtualiron.com>

Kevin


[-- Attachment #2: vm86.patch --]
[-- Type: application/octet-stream, Size: 4282 bytes --]

diff -r 6993a0f91efc tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Thu Jun  1 18:10:00 2006 +0100
+++ b/tools/firmware/vmxassist/vm86.c	Thu Jun  1 16:40:28 2006 -0400
@@ -36,6 +36,8 @@
 
 static unsigned prev_eip = 0;
 enum vm86_mode mode = 0;
+
+static struct regs saved_rm_regs;
 
 #ifdef DEBUG
 int traceset = 0;
@@ -795,6 +797,8 @@ protected_mode(struct regs *regs)
 	oldctx.esp = regs->uesp;
 	oldctx.eflags = regs->eflags;
 
+	memset(&saved_rm_regs, 0, sizeof(struct regs));
+
 	/* reload all segment registers */
 	if (!load_seg(regs->cs, &oldctx.cs_base,
 				&oldctx.cs_limit, &oldctx.cs_arbytes))
@@ -808,6 +812,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.es_base,
 			    &oldctx.es_limit, &oldctx.es_arbytes);
 		oldctx.es_sel = 0;
+		saved_rm_regs.ves = regs->ves;
 	}
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
@@ -817,6 +822,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ss_base,
 			    &oldctx.ss_limit, &oldctx.ss_arbytes);
 		oldctx.ss_sel = 0;
+		saved_rm_regs.uss = regs->uss;
 	}
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
@@ -826,6 +832,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.ds_base,
 			    &oldctx.ds_limit, &oldctx.ds_arbytes);
 		oldctx.ds_sel = 0;
+		saved_rm_regs.vds = regs->vds;
 	}
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
@@ -835,6 +842,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.fs_base,
 			    &oldctx.fs_limit, &oldctx.fs_arbytes);
 		oldctx.fs_sel = 0;
+		saved_rm_regs.vfs = regs->vfs;
 	}
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
@@ -844,6 +852,7 @@ protected_mode(struct regs *regs)
 		load_seg(0, &oldctx.gs_base,
 			    &oldctx.gs_limit, &oldctx.gs_arbytes);
 		oldctx.gs_sel = 0;
+		saved_rm_regs.vgs = regs->vgs;
 	}
 
 	/* initialize jump environment to warp back to protected mode */
@@ -880,16 +889,22 @@ real_mode(struct regs *regs)
 		if (regs->uss >= HIGHMEM)
 			panic("%%ss 0x%lx higher than 1MB", regs->uss);
 		regs->uss = address(regs, regs->uss, 0) >> 4;
+	} else {
+	  regs->uss = saved_rm_regs.uss;
 	}
 	if (regs->vds != 0) {
 		if (regs->vds >= HIGHMEM)
 			panic("%%ds 0x%lx higher than 1MB", regs->vds);
 		regs->vds = address(regs, regs->vds, 0) >> 4;
+	} else {
+	  regs->vds = saved_rm_regs.vds;
 	}
 	if (regs->ves != 0) {
 		if (regs->ves >= HIGHMEM)
 			panic("%%es 0x%lx higher than 1MB", regs->ves);
 		regs->ves = address(regs, regs->ves, 0) >> 4;
+	} else {
+	  regs->ves = saved_rm_regs.ves;
 	}
 
 	/* this should get us into 16-bit mode */
@@ -971,6 +986,39 @@ jmpl(struct regs *regs, int prefix)
 	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
 		eip = (prefix & DATA32) ? fetch32(regs) : fetch16(regs);
 		cs = fetch16(regs);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_REAL);
+	} else
+		panic("jmpl");
+}
+
+static void
+jmpl_indirect(struct regs *regs, int prefix, unsigned modrm)
+{
+	unsigned n = regs->eip;
+	unsigned cs, eip;
+	unsigned addr;
+
+	addr  = operand(prefix, regs, modrm);
+
+	if (mode == VM86_REAL_TO_PROTECTED) { /* jump to protected mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
+
+		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
+
+                regs->cs = cs;
+                regs->eip = eip;
+		set_mode(regs, VM86_PROTECTED);
+	} else if (mode == VM86_PROTECTED_TO_REAL) { /* jump to real mode */
+		eip = (prefix & DATA32) ? read32(addr) : read16(addr);
+		addr += (prefix & DATA32) ? 4 : 2;
+		cs = read16(addr);
 
 		TRACE((regs, (regs->eip - n) + 1, "jmpl 0x%x:0x%x", cs, eip));
 
@@ -1306,6 +1354,23 @@ opcode(struct regs *regs)
 			}
 			goto invalid;
 
+		case 0xFF: /* jmpl (indirect) */
+			if ((mode == VM86_REAL_TO_PROTECTED) ||
+			    (mode == VM86_PROTECTED_TO_REAL)) {
+			 	unsigned modrm = fetch8(regs);
+				
+				switch((modrm >> 3) & 7) {
+				case 5:
+				  jmpl_indirect(regs, prefix, modrm);
+				  return OPC_INVALID;
+
+				default:
+				  break;
+				}
+
+			}
+			goto invalid;
+
 		case 0xEB: /* short jump */
 			if ((mode == VM86_REAL_TO_PROTECTED) ||
 			    (mode == VM86_PROTECTED_TO_REAL)) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [No Subject]

[Arnulfo Titor]

Hello,

If you want PROMPT assets to utilize ANY
way you feel like, or sincerely feel like to LOWER 
your premiums by 25% or more; 

Here are the offers We have ASAP : 

lNTEREST-OnIy : $ 564K @ UNDER  477 a month
VARlABLE : $ 556K at BELOW 453 each month

http://foigbil.com/9r

Rush, these proposals will end in 24 hours

Thanks Alot,
Arnulfo Titor

(no subject)

[OcHe]

Hi all =)

I'm working for my final thesis project, it's something about MIDI over
IP, i'm planning to use aseqnet for the demonstration purpose, my main
focus is about performance, how to calculate elapsed time (event data
traveled between Yamaha PSRA to Host A to Host B to Yamaha PSRB) (vice
versa). I'm running Fedora Core 4 (ALSA seems to work great with my
device) and C as the programming language.

Host A - Local LAN - Host B
  |                  |
Yamaha             Yamaha
Keyboard           Keyboard

My questions are:

1. How to calculate elapsed time data traverse from Yamaha to Computer ?
2. How to calculate elapsed time  data traverse from Host A to Host B (i'm
just guessing maybe i could use ping to show RTT?? is this the correct
answer?)
3. is there any other processes i should calculate ?
4. What realtime kernel patch should i use?
5. How long (in millisecond / second ??) should the total elapsed time be,
to make the realtime playing feasible?

Thanks =)



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: (no subject)

[Eric Shattow]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

Have you looked into Open Sound Control (OSC) ?

 E

On 5/4/06, OcHe <oche@mumufarm.com> wrote:
>
> Hi all =)
>
> I'm working for my final thesis project, it's something about MIDI over
> IP, i'm planning to use aseqnet for the demonstration purpose, my main
> focus is about performance, how to calculate elapsed time (event data
> traveled between Yamaha PSRA to Host A to Host B to Yamaha PSRB) (vice
> versa). I'm running Fedora Core 4 (ALSA seems to work great with my
> device) and C as the programming language.
>
> Host A - Local LAN - Host B
>   |                  |
> Yamaha             Yamaha
> Keyboard           Keyboard
>
> My questions are:
>
> 1. How to calculate elapsed time data traverse from Yamaha to Computer ?
> 2. How to calculate elapsed time  data traverse from Host A to Host B (i'm
> just guessing maybe i could use ping to show RTT?? is this the correct
> answer?)
> 3. is there any other processes i should calculate ?
> 4. What realtime kernel patch should i use?
> 5. How long (in millisecond / second ??) should the total elapsed time be,
> to make the realtime playing feasible?
>
> Thanks =)
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>

[-- Attachment #2: Type: text/html, Size: 2460 bytes --]

Re: (no subject)

[Clemens Ladisch]

OcHe wrote:
> I'm working for my final thesis project, it's something about MIDI over
> IP, i'm planning to use aseqnet for the demonstration purpose, my main
> focus is about performance, how to calculate elapsed time (event data
> traveled between Yamaha PSRA to Host A to Host B to Yamaha PSRB) (vice
> versa). I'm running Fedora Core 4 (ALSA seems to work great with my
> device) and C as the programming language.
> 
> Host A - Local LAN - Host B
>   |                  |
> Yamaha             Yamaha
> Keyboard           Keyboard
> 
> My questions are:
> 
> 1. How to calculate elapsed time data traverse from Yamaha to Computer ?

The time for the actual transmission of MIDI commands is easily
calculated, knowing that the bit rate is 31250 Hz and each byte (plus
start and stop bits) needs 10 bits.

More interesting might be the times from the key press to the actual
transmission of the command, and from the arrival of the command at the
computer until the software actually deals with it.  But these are not
related to the IP transmission.

> 2. How to calculate elapsed time  data traverse from Host A to Host B (i'm
> just guessing maybe i could use ping to show RTT?? is this the correct
> answer?)

Different network protocols might have different latencies (ping uses
ICMP, aseqnet uses TCP).

You might want to send the data back to host A and divide the time by
two.

Another approach would be to run some soft synth (or better some
hardware synth) on both computers, and record the output of both on the
left/right channels of a stereo sound card, so that the delay between
them can easily be measured.

> 5. How long (in millisecond / second ??) should the total elapsed time be,
> to make the realtime playing feasible?

A value usually mentioned is ten milliseconds.
(Real organists deal with latencies of about one second.)


HTH
Clemens


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

(no subject)

[Kirkwood, David A]

[-- Attachment #1.1: Type: text/plain, Size: 101 bytes --]

I don't see any timestamps on audit events. How can I bracket events between
to dates /times?

 

 


[-- Attachment #1.2: Type: text/html, Size: 1610 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: (no subject)

[Steve Grubb]

On Wednesday 03 May 2006 13:21, Kirkwood, David A wrote:
> I don't see any timestamps on audit events. How can I bracket events
> between to dates /times?

The ausearch utility was created to view the audit records. It extracts that 
information from the event. Can you give that a try?

ausearch -ts 1:00:00 -i

(This also assumes you have the audit daemon running.)

-Steve

(no subject)

[Nichole]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]

(no subject)

[Javier Ruano]

hi.
i have this problem.
kernel 2.6.16.2

intelfb: Framebuffer driver for Intel(R)
830M/845G/852GM/855GM/865G/915G/915GM chipsets
intelfb: Version 0.9.2
intelfb: 00:02.0: Intel(R) 855GME, aperture size 128MB, stolen memory 892kB
intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
intelfb: Video mode must be programmed at boot time.


the driver (*) is inside kernel.
Thanks 





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: (no subject)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Fri, 2006-04-14 15:02:56 +0000, Javier Ruano <javier.ruano@estudiante.uam.es> wrote:
> i have this problem.
> kernel 2.6.16.2
> 
> intelfb: Framebuffer driver for Intel(R)
> 830M/845G/852GM/855GM/865G/915G/915GM chipsets
> intelfb: Version 0.9.2
> intelfb: 00:02.0: Intel(R) 855GME, aperture size 128MB, stolen memory 892kB
> intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
> intelfb: Video mode must be programmed at boot time.

So where is the problem?

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: (no subject)

[Knut Petersen]

>intelfb: Framebuffer driver for Intel(R)
>830M/845G/852GM/855GM/865G/915G/915GM chipsets
>intelfb: Version 0.9.2
>intelfb: 00:02.0: Intel(R) 855GME, aperture size 128MB, stolen memory 892kB
>intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
>intelfb: Video mode must be programmed at boot time.
>
>
>the driver (*) is inside kernel.
>  
>
Yes - of course, why not? It should be possible to compile a framebuffer
driver into the kernel without problems, and it should be possible to
load it as a module ... even from within xterm ;-)

Why do you believe that this is related to any of the problems?

cu,
 knut


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

(no subject)

[Nivedita Singhvi]

[-- Attachment #1.1: Type: text/plain, Size: 913 bytes --]





Hello!

Just wanted to let everyone know Jiuxing  has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:

http://xenbits.xensource.com/ext/xen-smartio.hg

This contains the current source code for a xen infiniband frontend
and backend driver. The source code is in very preliminary stages
of development, just a proof of concept for now (works). We have
a long way to go.  We'd like to invite interested folks to take a look
and get involved in the continuing design and development as an
open-source community.

We will be putting up a Wiki page for this shortly on the Xen Wiki.
Stay tuned...

There is also a mailing list we set up for discussion on
virtualization of smart I/O in Xen at:

http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-smartio

However, at Ian's request we're going to contain most discussion
to xen-devel itself.


thanks,
Nivedita

[-- Attachment #1.2: Type: text/html, Size: 1194 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[汇嘉宏]

贵公司(经理/财务)您好:

    机会与竞争并存.因本公司进项较多,为要冲减进项,
降低经营成本,现有部分外省市普通发票(商品销售,广告
,建筑,服务).公路内河运输,国际运输等发票可优惠代开
 或合作,助您切实解决,理顺企业的财税,工商事宜.而且
本公司郑重承诺所用票据均可以上网查询或税务局验证.
自本公司成立以来,一直坚持以:诚信:立足于市场中,我们
本着:互惠互利.共同发展的原则,来建立长期良好的经贸合
作关系,多年来我司在入世贸后,开扩创新的精神和政治优势
,积极发展都市交流贸易平台,此信息长期有效,欢迎来电!
(注:税率的多少按金额大小而定!)

　　　　　　　　　　　电话：

　　　　　　　　　　　传真：

　　　　　　　　　　　手机：13631323086

　　　　　　　　　　联系人：林风(财务经理)　　　 　　　　　　　                            









                                        顺祝商祺



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

(no subject)

[Nick Dvoeglazov]

subscribe

(no subject)

[Selmeci, Tamas]

> Yes it possible,
> You can use cmdpartion if it is present in the kernel, or static
partion.

Maybe this will be a silly question, but how can I create those
partitions on my SMC using PC-based Linux if I have a card reader? Is
cmdpartition for this purpose? (using vivi on the developer board I can
create partitions, but vivi is in close relationship with BonFS and it
keeps on creating BonFS for me - probably I should modify the
sources...)

And does anybody know why should BonFS be used if partitioning can be
solved without that too?

Bye
--
Tamas Selmeci
Siemens PSE HU
Tel.:    +36-1-471-3861
Email:   tamas.selmeci@siemens.com
Address: H-1143 Budapest, Gizella ut 51-59 

(no subject)

[rasmit.ranjan]

[-- Attachment #1.1: Type: text/plain, Size: 1055 bytes --]

Hi all,
   I have a PCMCIA card which has a usb Host Controller (HC) on it. I am
writing Host Controller Driver (HCD) for this. I have pcmcia client
driver which is registering HC as a platform device.i.e. my HCD is a
platform driver. The device representation in linux-2.6.15.4 is given
below.
 
 
/sys/class/pcmcia-socket/pcmcia-socket1/device/1.0/myhcd/usb5/5-0:1.0
 
In my pcmcia client driver i get suspend event when i do selective
suspend of the card (pcmcia-socket1/device in device tree ) .  Platform
driver`s suspend entry point is getting called when i do selective
suspend of myhcd. Now if i do global suspend will Power Management
sub-system follow the device tree to suspend the card ? Which means PM
sub-system will suspend 5-0:1.0 , then it will suspend usb5, then myhcd
and then the pcmcia-socket1/device. So does it mean that in global
suspend platform driver`s suspend entry point will be getting called
before the pcmcia client driver`s suspend event ?
Please suggest.
 
Thanks and regards,
Rasmit Ranjan swain.

[-- Attachment #1.2: Type: text/html, Size: 2543 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

(no subject)

[Mark L. Wise]

Hello all!

I am struggling with what I think is an iptables issue...

I have the following Net-to-Net VPN set up between to FC4 boxes:

192.168.20.0/24-->192.168.20.2(gw)-->$PUBLICIP1 ...
$PUBLICIP2<--192.168.30.100(gw)<--192.168.30.0/24

With no firewall rules (iptables) entered, I can ping from 192.168.20.70 to
192.168.30.33 without any problem.  However, I cannot get to outside
internet addresses.  If I add:

iptables -t nat -A POSTROUTING --dst ! 192.168.30.0/24 -j SNAT --to-source
$PUBLICIP1

to the 192.168.20.2(gw) machine's iptables, I can get out of the firewall to
the internet from the 192.168.20.0/24 net, BUT MY VPN TRAFFIC DOES NOT REACH
THE OTHER SIDE.

So it seems that I can either have my VPN traffic between the nets OR be
able to get to the internet (WWW, etc.) but I cannot have both.

Anyone have any ideas???

Mark L. Wise, President
Alpha II Service, Inc.
1312 Epworth Ave
Reynoldsburg, Ohio 43068-2116
614 868-5033 (Phone)
614 868-1060 (Fax)

(no subject)

[Li, Xin B]

Leendert, when I'm reading the vmxassist code, I think we need this
patch, can you take a look for me?
Thanks
-Xin

diff -r 47013962e411 tools/firmware/vmxassist/setup.c
--- a/tools/firmware/vmxassist/setup.c  Fri Feb 10 02:23:36 2006
+++ b/tools/firmware/vmxassist/setup.c  Fri Feb 10 15:28:17 2006
@@ -363,7 +363,7 @@

        initialize_real_mode = 1;
        cr0 = get_cr0();
-#ifndef TEST
+#ifdef TEST
        set_cr0(cr0 | CR0_PE);
 #endif
        set_cr0(cr0 & ~CR0_PE);

RE: (no subject)

[Yu, Luming]

http://vger.kernel.org/vger-lists.html#linux-acpi 

>-----Original Message-----
>From: linux-acpi-owner@vger.kernel.org 
>[mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Pedro Venda
>Sent: 2006年1月6日 0:17
>To: linux-acpi@vger.kernel.org
>Subject: (no subject)
>
>subscribe
>-
>To unsubscribe from this list: send the line "unsubscribe 
>linux-acpi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[Ian Kent]

Whitespace and formating changes to waitq code.

Signed-off-by: Ian Kent <raven@themaw.net>


--- linux-2.6.15-rc5-mm3/fs/autofs4/waitq.c.waitq-cleanup	2006-01-02 13:28:54.000000000 +0800
+++ linux-2.6.15-rc5-mm3/fs/autofs4/waitq.c	2006-01-02 13:28:35.000000000 +0800
@@ -33,7 +33,7 @@ void autofs4_catatonic_mode(struct autof
 	sbi->catatonic = 1;
 	wq = sbi->queues;
 	sbi->queues = NULL;	/* Erase all wait queues */
-	while ( wq ) {
+	while (wq) {
 		nwq = wq->next;
 		wq->status = -ENOENT; /* Magic is gone - report failure */
 		kfree(wq->name);
@@ -45,7 +45,6 @@ void autofs4_catatonic_mode(struct autof
 		fput(sbi->pipe);	/* Close the pipe */
 		sbi->pipe = NULL;
 	}
-
 	shrink_dcache_sb(sbi->sb);
 }
 
@@ -165,7 +164,7 @@ int autofs4_wait(struct autofs_sb_info *
 	int len, status;
 
 	/* In catatonic mode, we don't wait for nobody */
-	if ( sbi->catatonic )
+	if (sbi->catatonic)
 		return -ENOENT;
 	
 	name = kmalloc(NAME_MAX + 1, GFP_KERNEL);
@@ -190,7 +189,7 @@ int autofs4_wait(struct autofs_sb_info *
 			break;
 	}
 
-	if ( !wq ) {
+	if (!wq) {
 		/* Can't wait for an expire if there's no mount */
 		if (notify == NFY_NONE && !d_mountpoint(dentry)) {
 			kfree(name);
@@ -200,7 +199,7 @@ int autofs4_wait(struct autofs_sb_info *
 
 		/* Create a new wait queue */
 		wq = kmalloc(sizeof(struct autofs_wait_queue),GFP_KERNEL);
-		if ( !wq ) {
+		if (!wq) {
 			kfree(name);
 			up(&sbi->wq_sem);
 			return -ENOMEM;
@@ -240,14 +239,14 @@ int autofs4_wait(struct autofs_sb_info *
 
 	/* wq->name is NULL if and only if the lock is already released */
 
-	if ( sbi->catatonic ) {
+	if (sbi->catatonic) {
 		/* We might have slept, so check again for catatonic mode */
 		wq->status = -ENOENT;
 		kfree(wq->name);
 		wq->name = NULL;
 	}
 
-	if ( wq->name ) {
+	if (wq->name) {
 		/* Block all but "shutdown" signals while waiting */
 		sigset_t oldset;
 		unsigned long irqflags;
@@ -283,12 +282,12 @@ int autofs4_wait_release(struct autofs_s
 	struct autofs_wait_queue *wq, **wql;
 
 	down(&sbi->wq_sem);
-	for ( wql = &sbi->queues ; (wq = *wql) != 0 ; wql = &wq->next ) {
-		if ( wq->wait_queue_token == wait_queue_token )
+	for (wql = &sbi->queues ; (wq = *wql) != 0 ; wql = &wq->next) {
+		if (wq->wait_queue_token == wait_queue_token)
 			break;
 	}
 
-	if ( !wq ) {
+	if (!wq) {
 		up(&sbi->wq_sem);
 		return -EINVAL;
 	}

(no subject)

[Ian Kent]

This patch removes the update of i_atime from autofs4 in favour of
having VFS update it. i_atime is never used for expire in autofs4.

Signed-off-by: Ian Kent <raven@themaw.net>


--- linux-2.6.15-mm3/fs/autofs4/root.c.remove-update_atime	2006-01-13 16:21:05.000000000 +0800
+++ linux-2.6.15-mm3/fs/autofs4/root.c	2006-01-13 16:27:09.000000000 +0800
@@ -84,24 +84,6 @@ static int autofs4_root_readdir(struct f
 	return dcache_readdir(file, dirent, filldir);
 }
 
-/* Update usage from here to top of tree, so that scan of
-   top-level directories will give a useful result */
-static void autofs4_update_usage(struct vfsmount *mnt, struct dentry *dentry)
-{
-	struct dentry *top = dentry->d_sb->s_root;
-
-	spin_lock(&dcache_lock);
-	for(; dentry != top; dentry = dentry->d_parent) {
-		struct autofs_info *ino = autofs4_dentry_ino(dentry);
-
-		if (ino) {
-			touch_atime(mnt, dentry);
-			ino->last_used = jiffies;
-		}
-	}
-	spin_unlock(&dcache_lock);
-}
-
 static int autofs4_dir_open(struct inode *inode, struct file *file)
 {
 	struct dentry *dentry = file->f_dentry;
@@ -246,10 +228,9 @@ out:
 	return dcache_readdir(file, dirent, filldir);
 }
 
-static int try_to_fill_dentry(struct vfsmount *mnt, struct dentry *dentry, int flags)
+static int try_to_fill_dentry(struct dentry *dentry, int flags)
 {
-	struct super_block *sb = mnt->mnt_sb;
-	struct autofs_sb_info *sbi = autofs4_sbi(sb);
+	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
 	struct autofs_info *ino = autofs4_dentry_ino(dentry);
 	int status = 0;
 
@@ -323,13 +304,6 @@ static int try_to_fill_dentry(struct vfs
 		}
 	}
 
-	/*
-	 * We don't update the usages for the autofs daemon itself, this
-	 * is necessary for recursive autofs mounts
-	 */
-	if (!autofs4_oz_mode(sbi))
-		autofs4_update_usage(mnt, dentry);
-
 	/* Initialize expiry counter after successful mount */
 	if (ino)
 		ino->last_used = jiffies;
@@ -357,7 +331,7 @@ static int autofs4_revalidate(struct den
 	/* Pending dentry */
 	if (autofs4_ispending(dentry)) {
 		if (!oz_mode)
-			status = try_to_fill_dentry(nd->mnt, dentry, flags);
+			status = try_to_fill_dentry(dentry, flags);
 		return status;
 	}
 
@@ -374,15 +348,11 @@ static int autofs4_revalidate(struct den
 			 dentry, dentry->d_name.len, dentry->d_name.name);
 		spin_unlock(&dcache_lock);
 		if (!oz_mode)
-			status = try_to_fill_dentry(nd->mnt, dentry, flags);
+			status = try_to_fill_dentry(dentry, flags);
 		return status;
 	}
 	spin_unlock(&dcache_lock);
 
-	/* Update the usage list */
-	if (!oz_mode)
-		autofs4_update_usage(nd->mnt, dentry);
-
 	return 1;
 }

(no subject)

[Ian Kent]

This patch changes the names of the boolean functions autofs4_check_mount
and autofs4_check_tree to autofs4_mount_busy and autofs4_tree_busy
respectively and alters their return codes to suit in order to aid
code readabilty.

A couple of white space cleanups are included as well.

Signed-off-by: Ian Kent <raven@themaw.net>


--- linux-2.6.15-mm2/fs/autofs4/expire.c.expire-cleanup	2006-01-12 15:06:52.000000000 +0800
+++ linux-2.6.15-mm2/fs/autofs4/expire.c	2006-01-12 15:11:55.000000000 +0800
@@ -16,7 +16,7 @@
 
 static unsigned long now;
 
-/* Check if a dentry can be expired return 1 if it can else return 0 */
+/* Check if a dentry can be expired */
 static inline int autofs4_can_expire(struct dentry *dentry,
 					unsigned long timeout, int do_now)
 {
@@ -41,14 +41,13 @@ static inline int autofs4_can_expire(str
 		     attempts if expire fails the first time */
 		ino->last_used = now;
 	}
-
 	return 1;
 }
 
-/* Check a mount point for busyness return 1 if not busy, otherwise */
-static int autofs4_check_mount(struct vfsmount *mnt, struct dentry *dentry)
+/* Check a mount point for busyness */
+static int autofs4_mount_busy(struct vfsmount *mnt, struct dentry *dentry)
 {
-	int status = 0;
+	int status = 1;
 
 	DPRINTK("dentry %p %.*s",
 		dentry, (int)dentry->d_name.len, dentry->d_name.name);
@@ -65,7 +64,7 @@ static int autofs4_check_mount(struct vf
 
 	/* The big question */
 	if (may_umount_tree(mnt) == 0)
-		status = 1;
+		status = 0;
 done:
 	DPRINTK("returning = %d", status);
 	mntput(mnt);
@@ -75,30 +74,29 @@ done:
 
 /* Check a directory tree of mount points for busyness
  * The tree is not busy iff no mountpoints are busy
- * Return 1 if the tree is busy or 0 otherwise
  */
-static int autofs4_check_tree(struct vfsmount *mnt,
-	       		      struct dentry *top,
-			      unsigned long timeout,
-			      int do_now)
+static int autofs4_tree_busy(struct vfsmount *mnt,
+	       		     struct dentry *top,
+			     unsigned long timeout,
+			     int do_now)
 {
 	struct dentry *this_parent = top;
 	struct list_head *next;
 
-	DPRINTK("parent %p %.*s",
+	DPRINTK("top %p %.*s",
 		top, (int)top->d_name.len, top->d_name.name);
 
 	/* Negative dentry - give up */
 	if (!simple_positive(top))
-		return 0;
+		return 1;
 
 	/* Timeout of a tree mount is determined by its top dentry */
 	if (!autofs4_can_expire(top, timeout, do_now))
-		return 0;
+		return 1;
 
 	/* Is someone visiting anywhere in the tree ? */
 	if (may_umount_tree(mnt))
-		return 0;
+		return 1;
 
 	spin_lock(&dcache_lock);
 repeat:
@@ -126,9 +124,9 @@ resume:
 
 		if (d_mountpoint(dentry)) {
 			/* First busy => tree busy */
-			if (!autofs4_check_mount(mnt, dentry)) {
+			if (autofs4_mount_busy(mnt, dentry)) {
 				dput(dentry);
-				return 0;
+				return 1;
 			}
 		}
 
@@ -144,7 +142,7 @@ resume:
 	}
 	spin_unlock(&dcache_lock);
 
-	return 1;
+	return 0;
 }
 
 static struct dentry *autofs4_check_leaves(struct vfsmount *mnt,
@@ -188,7 +186,7 @@ resume:
 				goto cont;
 
 			/* Can we umount this guy */
-			if (autofs4_check_mount(mnt, dentry))
+			if (!autofs4_mount_busy(mnt, dentry))
 				return dentry;
 
 		}
@@ -241,7 +239,7 @@ static struct dentry *autofs4_expire(str
 		struct dentry *dentry = list_entry(next, struct dentry, d_u.d_child);
 
 		/* Negative dentry - give up */
-		if ( !simple_positive(dentry) ) {
+		if (!simple_positive(dentry)) {
 			next = next->next;
 			continue;
 		}
@@ -259,21 +257,21 @@ static struct dentry *autofs4_expire(str
 				goto next;
 
 			/* Can we umount this guy */
-			if (autofs4_check_mount(mnt, dentry)) {
+			if (!autofs4_mount_busy(mnt, dentry)) {
 				expired = dentry;
 				break;
 			}
 			goto next;
 		}
 
-		if ( simple_empty(dentry) )
+		if (simple_empty(dentry))
 			goto next;
 
 		/* Case 2: tree mount, expire iff entire tree is not busy */
 		if (!exp_leaves) {
 			/* Lock the tree as we must expire as a whole */
 			spin_lock(&sbi->fs_lock);
-			if (autofs4_check_tree(mnt, dentry, timeout, do_now)) {
+			if (!autofs4_tree_busy(mnt, dentry, timeout, do_now)) {
 				struct autofs_info *inf = autofs4_dentry_ino(dentry);
 
 				/* Set this flag early to catch sys_chdir and the like */
@@ -297,7 +295,7 @@ next:
 		next = next->next;
 	}
 
-	if ( expired ) {
+	if (expired) {
 		DPRINTK("returning %p %.*s",
 			expired, (int)expired->d_name.len, expired->d_name.name);
 		spin_lock(&dcache_lock);
@@ -352,16 +350,16 @@ int autofs4_expire_multi(struct super_bl
 		return -EFAULT;
 
 	if ((dentry = autofs4_expire(sb, mnt, sbi, do_now)) != NULL) {
-		struct autofs_info *de_info = autofs4_dentry_ino(dentry);
+		struct autofs_info *ino = autofs4_dentry_ino(dentry);
 
 		/* This is synchronous because it makes the daemon a
                    little easier */
-		de_info->flags |= AUTOFS_INF_EXPIRING;
+		ino->flags |= AUTOFS_INF_EXPIRING;
 		ret = autofs4_wait(sbi, dentry, NFY_EXPIRE);
-		de_info->flags &= ~AUTOFS_INF_EXPIRING;
+		ino->flags &= ~AUTOFS_INF_EXPIRING;
 		dput(dentry);
 	}
-		
+
 	return ret;
 }

(no subject)

[Ian Kent]

This patch addresses a problem where stale dentrys stop mounts
from happening.

When a mount point directory is pre-created and a non-existent
entry within it is requested a dentry ends up being created within
the mount point directory which stops future mounts. The problem
is solved by ignoring negative, unhashed dentrys in the mount point 
d_subdirs list.

Additionally the apparent cacheing of -ENOENT returns from requests
is removed. The test on d_time is a tautology and d_time is not
initialised and has an unexpected value. In short it doesn't do
what it's meant to.

The cacheing of failed requests to the daemon is important and will
be followed up later.

Signed-off-by: Ian Kent <raven@themaw.net>


--- linux-2.6.15-mm3/fs/autofs4/root.c.failed-lookup	2006-01-13 16:12:20.000000000 +0800
+++ linux-2.6.15-mm3/fs/autofs4/root.c	2006-01-13 16:13:33.000000000 +0800
@@ -294,14 +294,13 @@ static int try_to_fill_dentry(struct vfs
 
 		/* Turn this into a real negative dentry? */
 		if (status == -ENOENT) {
-			dentry->d_time = jiffies + AUTOFS_NEGATIVE_TIMEOUT;
 			spin_lock(&dentry->d_lock);
 			dentry->d_flags &= ~DCACHE_AUTOFS_PENDING;
 			spin_unlock(&dentry->d_lock);
-			return 1;
+			return 0;
 		} else if (status) {
 			/* Return a negative dentry, but leave it "pending" */
-			return 1;
+			return 0;
 		}
 	/* Trigger mount for path component or follow link */
 	} else if (flags & (LOOKUP_CONTINUE | LOOKUP_DIRECTORY) ||
@@ -360,13 +359,13 @@ static int autofs4_revalidate(struct den
 
 	/* Negative dentry.. invalidate if "old" */
 	if (dentry->d_inode == NULL)
-		return (dentry->d_time - jiffies <= AUTOFS_NEGATIVE_TIMEOUT);
+		return 0;
 
 	/* Check for a non-mountpoint directory with no contents */
 	spin_lock(&dcache_lock);
 	if (S_ISDIR(dentry->d_inode->i_mode) &&
 	    !d_mountpoint(dentry) && 
-	    list_empty(&dentry->d_subdirs)) {
+	    simple_empty_nolock(dentry)) {
 		DPRINTK("dentry=%p %.*s, emptydir",
 			 dentry, dentry->d_name.len, dentry->d_name.name);
 		spin_unlock(&dcache_lock);
--- linux-2.6.15-mm3/fs/autofs4/autofs_i.h.failed-lookup	2006-01-13 16:05:10.000000000 +0800
+++ linux-2.6.15-mm3/fs/autofs4/autofs_i.h	2006-01-13 16:13:33.000000000 +0800
@@ -40,14 +40,6 @@
 
 #define AUTOFS_SUPER_MAGIC 0x0187
 
-/*
- * If the daemon returns a negative response (AUTOFS_IOC_FAIL) then the
- * kernel will keep the negative response cached for up to the time given
- * here, although the time can be shorter if the kernel throws the dcache
- * entry away.  This probably should be settable from user space.
- */
-#define AUTOFS_NEGATIVE_TIMEOUT (60*HZ)	/* 1 minute */
-
 /* Unified info structure.  This is pointed to by both the dentry and
    inode structures.  Each file in the filesystem has an instance of this
    structure.  It holds a reference to the dentry, so dentries are never

(no subject)

[Ian Kent]

This patch changes readdir routines to use the cursor based routines
in libfs.c. This removes reliance on old readdir code from 2.4 and
should improve efficiency of readdir in autofs4.

Signed-off-by: Ian Kent <raven@themaw.net>


--- linux-2.6.16-rc1/fs/autofs4/root.c.readdir-cleanup	2006-01-18 09:24:03.000000000 +0800
+++ linux-2.6.16-rc1/fs/autofs4/root.c	2006-01-18 09:25:15.000000000 +0800
@@ -30,7 +30,6 @@ static int autofs4_dir_close(struct inod
 static int autofs4_dir_readdir(struct file * filp, void * dirent, filldir_t filldir);
 static int autofs4_root_readdir(struct file * filp, void * dirent, filldir_t filldir);
 static struct dentry *autofs4_lookup(struct inode *,struct dentry *, struct nameidata *);
-static int autofs4_dcache_readdir(struct file *, void *, filldir_t);
 
 struct file_operations autofs4_root_operations = {
 	.open		= dcache_dir_open,
@@ -82,7 +81,7 @@ static int autofs4_root_readdir(struct f
 
 	DPRINTK("needs_reghost = %d", sbi->needs_reghost);
 
-	return autofs4_dcache_readdir(file, dirent, filldir);
+	return dcache_readdir(file, dirent, filldir);
 }
 
 /* Update usage from here to top of tree, so that scan of
@@ -103,75 +102,21 @@ static void autofs4_update_usage(struct 
 	spin_unlock(&dcache_lock);
 }
 
-/*
- * From 2.4 kernel readdir.c
- */
-static int autofs4_dcache_readdir(struct file * filp, void * dirent, filldir_t filldir)
-{
-	int i;
-	struct dentry *dentry = filp->f_dentry;
-
-	i = filp->f_pos;
-	switch (i) {
-		case 0:
-			if (filldir(dirent, ".", 1, i, dentry->d_inode->i_ino, DT_DIR) < 0)
-				break;
-			i++;
-			filp->f_pos++;
-			/* fallthrough */
-		case 1:
-			if (filldir(dirent, "..", 2, i, dentry->d_parent->d_inode->i_ino, DT_DIR) < 0)
-				break;
-			i++;
-			filp->f_pos++;
-			/* fallthrough */
-		default: {
-			struct list_head *list;
-			int j = i-2;
-
-			spin_lock(&dcache_lock);
-			list = dentry->d_subdirs.next;
-
-			for (;;) {
-				if (list == &dentry->d_subdirs) {
-					spin_unlock(&dcache_lock);
-					return 0;
-				}
-				if (!j)
-					break;
-				j--;
-				list = list->next;
-			}
-
-			while(1) {
-				struct dentry *de = list_entry(list,
-						struct dentry, d_u.d_child);
-
-				if (!d_unhashed(de) && de->d_inode) {
-					spin_unlock(&dcache_lock);
-					if (filldir(dirent, de->d_name.name, de->d_name.len, filp->f_pos, de->d_inode->i_ino, DT_UNKNOWN) < 0)
-						break;
-					spin_lock(&dcache_lock);
-				}
-				filp->f_pos++;
-				list = list->next;
-				if (list != &dentry->d_subdirs)
-					continue;
-				spin_unlock(&dcache_lock);
-				break;
-			}
-		}
-	}
-	return 0;
-}
-
 static int autofs4_dir_open(struct inode *inode, struct file *file)
 {
 	struct dentry *dentry = file->f_dentry;
 	struct vfsmount *mnt = file->f_vfsmnt;
 	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
+	struct dentry *cursor;
 	int status;
 
+	status = dcache_dir_open(inode, file);
+	if (status)
+		goto out;
+
+	cursor = file->private_data;
+	cursor->d_fsdata = NULL;
+
 	DPRINTK("file=%p dentry=%p %.*s",
 		file, dentry, dentry->d_name.len, dentry->d_name.name);
 
@@ -180,12 +125,15 @@ static int autofs4_dir_open(struct inode
 
 	if (autofs4_ispending(dentry)) {
 		DPRINTK("dentry busy");
-		return -EBUSY;
+		dcache_dir_close(inode, file);
+		status = -EBUSY;
+		goto out;
 	}
 
+	status = -ENOENT;
 	if (!d_mountpoint(dentry) && dentry->d_op && dentry->d_op->d_revalidate) {
 		struct nameidata nd;
-		int empty;
+		int empty, ret;
 
 		/* In case there are stale directory dentrys from a failed mount */
 		spin_lock(&dcache_lock);
@@ -195,13 +143,13 @@ static int autofs4_dir_open(struct inode
 		if (!empty)
 			d_invalidate(dentry);
 
-		nd.dentry = dentry;
-		nd.mnt = mnt;
 		nd.flags = LOOKUP_DIRECTORY;
-		status = (dentry->d_op->d_revalidate)(dentry, &nd);
+		ret = (dentry->d_op->d_revalidate)(dentry, &nd);
 
-		if (!status)
-			return -ENOENT;
+		if (!ret) {
+			dcache_dir_close(inode, file);
+			goto out;
+		}
 	}
 
 	if (d_mountpoint(dentry)) {
@@ -212,25 +160,29 @@ static int autofs4_dir_open(struct inode
 		if (!autofs4_follow_mount(&fp_mnt, &fp_dentry)) {
 			dput(fp_dentry);
 			mntput(fp_mnt);
-			return -ENOENT;
+			dcache_dir_close(inode, file);
+			goto out;
 		}
 
 		fp = dentry_open(fp_dentry, fp_mnt, file->f_flags);
 		status = PTR_ERR(fp);
 		if (IS_ERR(fp)) {
-			file->private_data = NULL;
-			return status;
+			dcache_dir_close(inode, file);
+			goto out;
 		}
-		file->private_data = fp;
+		cursor->d_fsdata = fp;
 	}
-out:
 	return 0;
+out:
+	return status;
 }
 
 static int autofs4_dir_close(struct inode *inode, struct file *file)
 {
 	struct dentry *dentry = file->f_dentry;
 	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
+	struct dentry *cursor = file->private_data;
+	int status = 0;
 
 	DPRINTK("file=%p dentry=%p %.*s",
 		file, dentry, dentry->d_name.len, dentry->d_name.name);
@@ -240,26 +192,28 @@ static int autofs4_dir_close(struct inod
 
 	if (autofs4_ispending(dentry)) {
 		DPRINTK("dentry busy");
-		return -EBUSY;
+		status = -EBUSY;
+		goto out;
 	}
 
 	if (d_mountpoint(dentry)) {
-		struct file *fp = file->private_data;
-
-		if (!fp)
-			return -ENOENT;
-
+		struct file *fp = cursor->d_fsdata;
+		if (!fp) {
+			status = -ENOENT;
+			goto out;
+		}
 		filp_close(fp, current->files);
-		file->private_data = NULL;
 	}
 out:
-	return 0;
+	dcache_dir_close(inode, file);
+	return status;
 }
 
 static int autofs4_dir_readdir(struct file *file, void *dirent, filldir_t filldir)
 {
 	struct dentry *dentry = file->f_dentry;
 	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
+	struct dentry *cursor = file->private_data;
 	int status;
 
 	DPRINTK("file=%p dentry=%p %.*s",
@@ -274,7 +228,7 @@ static int autofs4_dir_readdir(struct fi
 	}
 
 	if (d_mountpoint(dentry)) {
-		struct file *fp = file->private_data;
+		struct file *fp = cursor->d_fsdata;
 
 		if (!fp)
 			return -ENOENT;
@@ -289,7 +243,7 @@ static int autofs4_dir_readdir(struct fi
 		return status;
 	}
 out:
-	return autofs4_dcache_readdir(file, dirent, filldir);
+	return dcache_readdir(file, dirent, filldir);
 }
 
 static int try_to_fill_dentry(struct vfsmount *mnt, struct dentry *dentry, int flags)

(no subject)

[Jonas Lihnell]

Hi there fellow nfs'ers (or whatever I'm supposed to call you :)

I got some issues with my root-on-nfs installation and after an hour of 
googling, reading forums and mailinglist (none in particular, just 
whatever google turned up) and trying a bunch of stuff I thought it was 
time to resort to this mailing list.

I am capable of booting and mounting the rootfs, as well as any other 
nfs shares but it goes slow and from time to time becomes unresponsive 
for some moments. When measuring speed of downloading files to nfs 
share I get decent speed and every few minutes it halts for some 
seconds, sometime just a few, sometimes many.

According to what I've come to know I should set a few options to get 
rid of this situation, namely tcp, rsync, wsync and nfsvers3. 
Unfortunately the booting kernel refuses to use the options I specify 
with append as stated in nfsroot.txt in the documentation folder from 
my kernel.

I can mount the share with the specified options when booted from a 
live-cd (ubuntu 5.10) so as far as I can see it's just a stubborn 
kernel which don't listen to what I say. :D

Some information about my setup and config files:
pxelinux.cfg/default:
"DEFAULT /bzImage
APPEND ip=dhcp root=/dev/nfs 
nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"

Some information I am supposed to give when mailing this list:
nfs-utils version: net-fs/nfs-utils-1.0.6-r6
kernel version: sys-kernel/gentoo-sources-2.6.14-r5
operating system: Gentoo Linux

network layout:
Servers "eth1: DGE-530T Gigabit Ethernet Adapter" connected to a dlink 
gigabit switch which in turn is connected to the clients "eth0: VIA 
Rhine II"

Good to know: "eth0: link up, 100Mbps, full-duplex"

/etc/exports snippet:
"# Netboot
/mnt/storage/network-nodes/     192.168.0.0/24(rw,sync,no_root_squash)"

rcpinfo -p localhost run on the server:
"   100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33543  status
    100024    1   tcp  47866  status
    100011    1   udp   4002  rquotad
    100011    2   udp   4002  rquotad
    100011    1   tcp   4002  rquotad
    100011    2   tcp   4002  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  33544  nlockmgr
    100021    3   udp  33544  nlockmgr
    100021    4   udp  33544  nlockmgr
    100021    1   tcp  47867  nlockmgr
    100021    3   tcp  47867  nlockmgr
    100021    4   tcp  47867  nlockmgr
    100005    1   udp    834  mountd
    100005    1   tcp    837  mountd
    100005    2   udp    834  mountd
    100005    2   tcp    837  mountd
    100005    3   udp    834  mountd
    100005    3   tcp    837  mountd"

rpcinfo -p 192.168.0.64 run on the client:
"    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33543  status
    100024    1   tcp  47866  status
    100011    1   udp   4002  rquotad
    100011    2   udp   4002  rquotad
    100011    1   tcp   4002  rquotad
    100011    2   tcp   4002  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  33544  nlockmgr
    100021    3   udp  33544  nlockmgr
    100021    4   udp  33544  nlockmgr
    100021    1   tcp  47867  nlockmgr
    100021    3   tcp  47867  nlockmgr
    100021    4   tcp  47867  nlockmgr
    100005    1   udp    834  mountd
    100005    1   tcp    837  mountd
    100005    2   udp    834  mountd
    100005    2   tcp    837  mountd
    100005    3   udp    834  mountd
    100005    3   tcp    837  mountd"



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Trond Myklebust]

On Tue, 2006-01-17 at 22:37 +0100, Jonas Lihnell wrote:

> Some information about my setup and config files:
> pxelinux.cfg/default:
> "DEFAULT /bzImage
> APPEND ip=dhcp root=/dev/nfs 
> nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"

Hmm... "sync" and "rw" are not listed in the nfsroot options (though I
agree that they probably should be).

What happens if you take those two out of the list?

Cheers,
  Trond



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: (no subject)

[Jonas Lihnell]

Thanks, that did the trick!
Have a nice day trond, and thanks for not only a quick, but also 
accurate reply :)

-- Jonas Lihnell

Quoting Trond Myklebust <trond.myklebust@fys.uio.no>:

> On Tue, 2006-01-17 at 22:37 +0100, Jonas Lihnell wrote:
>
>> Some information about my setup and config files:
>> pxelinux.cfg/default:
>> "DEFAULT /bzImage
>> APPEND ip=dhcp root=/dev/nfs
>> nfsroot=192.168.0.64:/mnt/storage/network-nodes/default,sync,hard,intr,rw,nolock,rsize=8192,wsize=8192,nfsvers=3,tcp"
>
> Hmm... "sync" and "rw" are not listed in the nfsroot options (though I
> agree that they probably should be).
>
> What happens if you take those two out of the list?
>
> Cheers,
>  Trond
>
>





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Nicolas Turro]

Hi, I am trying to patch my Fedora core 4 kernel/iptable in order to include the 'random' filter (I am trying to implement 
http://linux.com.lb/wiki/index.pl?node=Load%20Balancing%20Across%20Multiple%20Links )


However I encounter some difficulties:

Patch-o-matic works against my kernel source tree, but won't recognize linux-libc-headers as a valid KERNEL_DIR.

 Iptable won't compile against the kernel source tree: I get a bunch of 
#error including kernel header in userspace; use the glibc headers instead!
(However in this case, make print-extensions finds IPv4:random )

And if I use the unpatched linux-libc-headers, it won't compile libipt_random.so (make print-extensions only shows: IPv4:recent)


So I don't know how to proceed.
Any tips?

Please respond to me explicitly since I'm not subscribed to this mail list. Thx in advance

N. Turro

Re: (no subject)

[Amitabh Kant]

Try instaling glic kernel headers. If you have yum working on your
system, "yum install glibc-kernheaders.i386" should install the
required headers.

Amitabh

(no subject)

[Daniel Mack]

Dear ALSA people,

I'm about to write an ALSA driver for a sound hardware we developed
and I'm wondering about how to tackle it. It's a USB2.0 hardware
which has sound input and output but also some controller elements
and MIDI jacks. I'd like to make the controllers accessible by linux'
input device interface.

The audio part is - for good reasons - not USB class compliant,
and assuming that the usb folder in the driver tree only addresses
such devices, I pretty much guess this is not the point to start,
right?

I'm asking since I don't want to do the whole thing twice
because I started it the wrong way around.

Could anyone point me in the right direction?

Please Cc: me personally in replies since I'm not (yet) subscribed
to the list.

Best regards,
Daniel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: (no subject)

[Takashi Iwai]

At Tue, 10 Jan 2006 14:24:52 +0100,
Daniel Mack wrote:
> 
> Dear ALSA people,
> 
> I'm about to write an ALSA driver for a sound hardware we developed
> and I'm wondering about how to tackle it. It's a USB2.0 hardware
> which has sound input and output but also some controller elements
> and MIDI jacks. I'd like to make the controllers accessible by linux'
> input device interface.
> 
> The audio part is - for good reasons - not USB class compliant,
> and assuming that the usb folder in the driver tree only addresses
> such devices, I pretty much guess this is not the point to start,
> right?

If it's not USB class compliant, you'll likely need to write a driver
from scratch.  But, unless the protocol detail is informed, I cannot
tell what should be done... :)

One troublesome stuff in USB audio is the data transfer.  The
usb-audio driver has a double-buffer to behave as a pseudo DMA.
A similar trick would be required in your case, too.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: (no subject)

[Clemens Ladisch]

Takashi Iwai wrote:
> Daniel Mack wrote:
> > I'm about to write an ALSA driver for a sound hardware we developed
> > and I'm wondering about how to tackle it. It's a USB2.0 hardware
> > which has sound input and output but also some controller elements
> > and MIDI jacks. I'd like to make the controllers accessible by linux'
> > input device interface.
> >
> > The audio part is - for good reasons - not USB class compliant,
> > and assuming that the usb folder in the driver tree only addresses
> > such devices, I pretty much guess this is not the point to start,
> > right?
>
> If it's not USB class compliant, you'll likely need to write a driver
> from scratch.

All PCM devices have to use isochronous transfers, so it might work if you
just hard code the sample format, like, e.g., for the UA-1000.

The synchronization of the PCM output sample rate might be a problem -- if the
device doesn't use a standard USB synchronization mechanism (synchronous/
asynchronous/adaptive), the driver would have to be hacked some more.
(Playback on the UA-1000 doesn't work because the driver doesn't (yet) support
synchronizing the output PCM stream to the input PCM stream.)

The driver currently assumes that each (output/input) PCM endpoint has its
own interface (where it can select alternate settings independently).
Is this the case?


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: (no subject)

[Daniel Mack]

Hi,

On Jan 10, 2006, at 8:12 PM, Clemens Ladisch wrote:
> The synchronization of the PCM output sample rate might be a  
> problem -- if the
> device doesn't use a standard USB synchronization mechanism  
> (synchronous/
> asynchronous/adaptive), the driver would have to be hacked some more.
> (Playback on the UA-1000 doesn't work because the driver doesn't  
> (yet) support
> synchronizing the output PCM stream to the input PCM stream.)

I wrote a driver stack for this device for MacOSX already and attended
the development for the Windows version. They both work fine and so I
have some code to orientate on.

> The driver currently assumes that each (output/input) PCM endpoint  
> has its
> own interface (where it can select alternate settings independently).
> Is this the case?

No. All audio data is muxed and sent over one single endpoint and  
receviced
from another.

I think I have to write it from scratch to keep it straight forward.

Thanks for your suggestions, let's see how far I get.

Daniel





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

(no subject)

[Chaitanya Vinay Hazarey]

subscribe linux-kernel

(no subject)

[Pedro Venda]

subscribe
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(no subject)

[siman]

Hi All:
I want port Linux system to the MVME6100, I found moto has this kind of
patch for the MOTO SBC, just like patch-2.6.6-mcg.rm01.gz file.
Any know how and where can I download it? 
Thank you very much.

(no subject)

[093u2y8y83yg3]

(no subject)

[VJlm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

§K¶Oºâ©R³á
From: jOIEJ@iris.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[YjXXXulPAVpSHgx]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

§K¶Oºâ©R³á
From: yXtexJq@mx.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[8pvs2I]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

§K¶Oºâ©R³á
From: ozxKNraBEOJyRBL@saturn.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[Ramani Karuppiah]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Respected Sir,

                      I want devolope a good project in linux . My idea is
about the Audio System in linux.Please give me any

information about it.





                         Thanking
You.
-K.Ramani

[-- Attachment #2: Type: text/html, Size: 1152 bytes --]

(no subject)

[polpolkim6677]

(no subject)

[Otavio Salvador]

---

 arch/ppc/platforms/chrp_setup.c |    1 -
 arch/ppc/platforms/prep_setup.c |    1 -
 2 files changed, 0 insertions(+), 2 deletions(-)

applies-to: 8622c40782404c8fb13aa2a4dd4a7b0ebc44e896
66697dfc757179883127a3ae53bc486320b38374
diff --git a/arch/ppc/platforms/chrp_setup.c b/arch/ppc/platforms/chrp_setup.c
index f1b70ab..056ac2a 100644
--- a/arch/ppc/platforms/chrp_setup.c
+++ b/arch/ppc/platforms/chrp_setup.c
@@ -404,7 +404,6 @@ static struct irqaction xmon_irqaction =
 void __init chrp_init_IRQ(void)
 {
 	struct device_node *np;
-	int i;
 	unsigned long chrp_int_ack = 0;
 	unsigned char init_senses[NR_IRQS - NUM_8259_INTERRUPTS];
 #if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
index 4415748..f4ef267 100644
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -954,7 +954,6 @@ prep_calibrate_decr(void)
 static void __init
 prep_init_IRQ(void)
 {
-	int i;
 	unsigned int pci_viddid, pci_did;
 
 	if (OpenPIC_Addr != NULL) {
---
0.99.9k

(no subject)

[ikoey8y36vihioyt]

[GIT PATCH] USB patches for 2.6.15-rc3

[Greg KH]

Here are six small patches for 2.6.15-rc3 against your git tree that fix
some reported problems.  The biggest is the ehci boot issue, and the usb
suspend issue that the ppc people are seeing.  There's also a
documentation fix, a hwmon driver bugfix, and a pci_ids.h duplication
fix in here.

I did this as a git tree to make it easier to apply :)

Please pull from:
	rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
or if master.kernel.org hasn't synced up yet:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/

The full patches will be sent to the linux-usb-devel and linux-kernel
mailing lists, if anyone wants to see them.

thanks,

greg k-h


 Documentation/usb/error-codes.txt |    5 ++--
 drivers/hwmon/w83792d.c           |   25 ++++++++++++++------
 drivers/usb/atm/cxacru.c          |    3 ++
 drivers/usb/core/hcd-pci.c        |    3 +-
 drivers/usb/core/hcd.c            |   15 ++++++++----
 drivers/usb/core/hcd.h            |    7 ++++-
 drivers/usb/host/ehci-pci.c       |   46 +++++++++++++++++++++++++++++++-------
 drivers/usb/host/ehci-q.c         |   24 +++++++++++++------
 drivers/usb/host/ehci-sched.c     |   18 +++++++++++++-
 drivers/usb/host/ohci-hcd.c       |    6 ++++
 drivers/usb/host/ohci-hub.c       |   24 ++++++++++++++++---
 drivers/usb/host/ohci-pci.c       |   27 ++++++++++++++++++++--
 drivers/usb/host/uhci-hcd.c       |    6 ++++
 include/linux/pci_ids.h           |    3 --
 14 files changed, 168 insertions(+), 44 deletions(-)


Alan Stern:
      USB: documentation update

Benjamin Herrenschmidt:
      USB: Fix USB suspend/resume crasher (#2)

Dave Jones:
      Additional device ID for Conexant AccessRunner USB driver

David Brownell:
      USB: ehci fixups

Grant Coady:
      pci_ids.h: remove duplicate entries

Jean Delvare:
      hwmon: w83792d fix unused fan pins

Re: [GIT PATCH] USB patches for 2.6.15-rc3

[Linus Torvalds]

On Tue, 29 Nov 2005, Greg KH wrote:
>
>  include/linux/pci_ids.h           |    3 --
> 
> Grant Coady:
>       pci_ids.h: remove duplicate entries

Why is this in the USB tree, and WHY THE HELL DOES IT EXIST IN THE FIRST 
PLACE?

Not only does it have absolutely nothing to do with USB, it's totally 
bogus and incorrect. The commit log is also non-sensical, since it points 
to a commit that doesn't even exist in that tree.

It causes

	drivers/ide/pci/amd74xx.c:77: error: PCI_DEVICE_ID_AMD_CS5536_IDE undeclared here (not in a function)

Grr.

That hwmon thing didn't seem to have anything to do with usb either.

		Linus

Re: [GIT PATCH] USB patches for 2.6.15-rc3

[Greg KH]

On Wed, Nov 30, 2005 at 10:23:34AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 29 Nov 2005, Greg KH wrote:
> >
> >  include/linux/pci_ids.h           |    3 --
> > 
> > Grant Coady:
> >       pci_ids.h: remove duplicate entries
> 
> Why is this in the USB tree, and WHY THE HELL DOES IT EXIST IN THE FIRST 
> PLACE?

Sorry, in the body of the message I stated that I had a pci and a hwmon
driver patch too.  I should have corrected the Subject: too.

> Not only does it have absolutely nothing to do with USB, it's totally 
> bogus and incorrect. The commit log is also non-sensical, since it points 
> to a commit that doesn't even exist in that tree.
> 
> It causes
> 
> 	drivers/ide/pci/amd74xx.c:77: error: PCI_DEVICE_ID_AMD_CS5536_IDE undeclared here (not in a function)
> 
> Grr.

Ugh, I thought Grant wanted this in for the main kernel tree, sorry.

Grant, what git tree were you referring to?

I think I'll go back to sending individual patches late in the -rc
series from now on :)

Sorry for the trouble, and thanks for reverting the pci id patch in your
tree.

greg k-h

(no subject)

[Glenn L Shurson]

unsubscribe linux-kernel

(no subject)

[declarator]

(no subject)

[Purav Saraiya]

I am facing problems with debugging DomU.

I have made changes in the gdt table in the file head.S for Dom U. Because
of that the domain is crashing.

For debugging, I followed the steps mentioned in the file
/xen-unstable/tools/debugger/gdb/README. I also made changes in the
/xen/Rules.mk file and compiled domU with -g C flag.

However, as mentioned in the README file no
/var/xen/dump/<Domain-name>.<DomainID>.core file is generated.

Rules.mk file :
verbose     ?= y
debug       ?= y
perfc       ?= n
perfc_arrays?= n
domu_debug  ?= y
crash_debug ?= y

Am I missing something?

Thanks for replies.
-Purav

(no subject)

[Andi Kleen]

Sender: ak@brahms.suse.de
To: Adrian Bunk <bunk@stusta.de>
Cc: linux-kernel@vger.kernel.org, virtualization@lists.osdl.org
Subject: Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386
References: <20051118014055.GK11494@stusta.de>
From: Andi Kleen <ak@suse.de>
Date: 18 Nov 2005 17:05:07 +0100
In-Reply-To: <20051118014055.GK11494@stusta.de>
Message-ID: <p73lkzmhrgs.fsf@brahms.suse.de>
Lines: 17
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Adrian Bunk <bunk@stusta.de> writes:

> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> on i386.

I don't think you can do that. We still need these functions in low 
level architecture code at least.

Using __pa/__va doesn't cut it because it won't work on Xen guests
which have different views on bus vs physical addresses. The Xen
code is (hopefully) in the process of being merged, so intentionally
breaking them isn't a good idea.

So if anything there would need to be replacement functions for it
first that do the same thing. But why not just keep the old ones?

-Andi

Re: (no subject)

[Keir Fraser]

On 18 Nov 2005, at 16:05, Andi Kleen wrote:

> I don't think you can do that. We still need these functions in low
> level architecture code at least.
>
> Using __pa/__va doesn't cut it because it won't work on Xen guests
> which have different views on bus vs physical addresses. The Xen
> code is (hopefully) in the process of being merged, so intentionally
> breaking them isn't a good idea.
>
> So if anything there would need to be replacement functions for it
> first that do the same thing. But why not just keep the old ones?

We could make use of virt_to_machine/machine_to_virt instead, which 
arguably better describe the intent of those functions. Currently we 
only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
modified dma_map code. In those files I think the existing function 
names make some sense, but we can easily change if that's preferred.

  -- Keir

Re: (no subject)

[Russell King]

On Mon, Nov 21, 2005 at 10:06:03AM +0000, Keir Fraser wrote:
> On 18 Nov 2005, at 16:05, Andi Kleen wrote:
> >I don't think you can do that. We still need these functions in low
> >level architecture code at least.
> >
> >Using __pa/__va doesn't cut it because it won't work on Xen guests
> >which have different views on bus vs physical addresses. The Xen
> >code is (hopefully) in the process of being merged, so intentionally
> >breaking them isn't a good idea.
> >
> >So if anything there would need to be replacement functions for it
> >first that do the same thing. But why not just keep the old ones?
> 
> We could make use of virt_to_machine/machine_to_virt instead, which 
> arguably better describe the intent of those functions. Currently we 
> only use virt_to_bus/bus_to_virt in our swiotlb implementation, and our 
> modified dma_map code. In those files I think the existing function 
> names make some sense, but we can easily change if that's preferred.

If you're thinking of replacing bus_to_virt/virt_to_bus, you might want
to think about virt_to_dma(dev, virt) and dma_to_virt(dev, dma) as a
replacement, where "dev" is the device actually performing the DMA
(which obviously may not be the device asking for the mapping to be set
up.)  ARM already has these for use in the architecture code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: (no subject)

[Andi Kleen]

> We could make use of virt_to_machine/machine_to_virt instead, which 

I don't like it because "machine" is quite meaningless outside
Xen. 

-Andi

(no subject)

[Kyle Perkins]

[-- Attachment #1: Type: text/plain, Size: 11 bytes --]

subscribe

[-- Attachment #2: Type: text/html, Size: 11 bytes --]

RE: (no subject)

[Zhao Yu,SCNB R&D NNA(BJ)]

Ok. Thank you.
Sorry, I not pay attention to the comment. I just rushed into the code.

Thank for your help.

-----Original Message-----
From: Yoshinori K. Okuji [mailto:okuji@enbug.org] 
Sent: 2005年11月1日 20:18
To: The development of GRUB 2
Subject: Re: (no subject)


On Tuesday 01 November 2005 08:21 am, Zhao Yu,SCNB R&D NNA(BJ) wrote:
> I just begin to read some code in GRUB2, I met a question. Could you 
> help me out?

Sure.

> In function
> void
> grub_rescue_cmd_multiboot (int argc, char *argv[])
> {
>      ...
>     if (grub_multiboot_load_elf (file, buffer) != GRUB_ERR_NONE)
>     goto fail;
>     ...
> }
> Do that mean the OS image must be elf format?
> Or there are some miunderstand.

Please look at the comment in the beginning of that file. Since a.out kludge 
is not implemented yet, only ELF can be loaded correctly. This is in my TODO 
list.

Okuji


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel

(no subject)

[Zhao Yu,SCNB R&D NNA(BJ)]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

I just begin to read some code in GRUB2, I met a question.
Could you help me out?

In function
void
grub_rescue_cmd_multiboot (int argc, char *argv[])
{
     ... 
    if (grub_multiboot_load_elf (file, buffer) != GRUB_ERR_NONE)
    goto fail;
    ...
}
Do that mean the OS image must be elf format?
Or there are some miunderstand.

Thank you

[-- Attachment #2: Type: text/html, Size: 1193 bytes --]

Re: (no subject)

[Yoshinori K. Okuji]

On Tuesday 01 November 2005 08:21 am, Zhao Yu,SCNB R&D NNA(BJ) wrote:
> I just begin to read some code in GRUB2, I met a question.
> Could you help me out?

Sure.

> In function
> void
> grub_rescue_cmd_multiboot (int argc, char *argv[])
> {
>      ...
>     if (grub_multiboot_load_elf (file, buffer) != GRUB_ERR_NONE)
>     goto fail;
>     ...
> }
> Do that mean the OS image must be elf format?
> Or there are some miunderstand.

Please look at the comment in the beginning of that file. Since a.out kludge 
is not implemented yet, only ELF can be loaded correctly. This is in my TODO 
list.

Okuji

(no subject)

[Yasuyuki KOZAKAI]

[-- Attachment #1: Type: Text/Plain, Size: 1862 bytes --]

Subject: Re: nf_conntrack comments
From: Yasuyuki KOZAKAI <kozakai@isl.rdc.toshiba.co.jp>
Fcc: +backup
In-Reply-To: <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
References: <20051018084924.GD20338@sunbeam.de.gnumonks.org>
	<39e6f6c70510282108i60d78df6w9728f40641dccf80@mail.gmail.com>
	<20051029135524.GQ4479@sunbeam.de.gnumonks.org>
X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
----

Hi, Acme and all,

Acme, thank you for reviewing of nf_conntrack.

From: Harald Welte <laforge@netfilter.org>
Date: Sat, 29 Oct 2005 15:55:24 +0200

> > +       if (!h) {
> > +               DEBUGP("icmpv6_error: no match\n");
> > +               return NF_ACCEPT;
> > +       } else {
> > +               if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
> > +                       *ctinfo += IP_CT_IS_REPLY;
> > +       }
> > +
> > +       /* Update skb to refer to this connection */
> > +       skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
> > +       skb->nfctinfo = *ctinfo;
> > +       return -NF_ACCEPT;
> > +}
> > 
> > I noticed that some of the returns are NF_ACCEPT while at leat this last one
> > returns -NF_ACCEPT, is this a special convention or should all be negative? or
> > positive?
>
> I'll check that, looks like a bug to me, too.

If we don't change, the result is same. If this function return NF_ACCEPT,
connection tracking handles packet as normal packet. But it cannot find invert
tuple for it and stop processing after all. Then no problem.

But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
stop processing early.

BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
necessary to both of them if we want.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

Netfilter folks, do you have any problem if I change these return value ?

Regards,

--- Yasuyuki Kozakai

[-- Attachment #2: ct-icmp-error.patch --]
[-- Type: Text/Plain, Size: 6212 bytes --]

[NETFILTER] stop tracking ICMP(v6) error at early point

Currently connection tracking handles ICMP(v6) error like normal packets
if it failed to get related connection. But it fails that after all.

This makes connection tracking stop tracking ICMP(v6) error at early point.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

---
commit 45d0380701e4980f1276d3d7d83285e1c4a2e4c9
tree e2ae86189f6c961b1a8db032a2b11b814219e5f5
parent 296d553d2cf7856d37e613ab20b4290dbfe38afa
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Mon, 31 Oct 2005 20:00:31 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Mon, 31 Oct 2005 20:00:31 +0900

 net/ipv4/netfilter/ip_conntrack_proto_icmp.c   |   10 +++++-----
 net/ipv4/netfilter/nf_conntrack_proto_icmp.c   |   10 +++++-----
 net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c |   12 ++++++------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
--- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
@@ -151,13 +151,13 @@ icmp_error_message(struct sk_buff *skb,
 	/* Not enough header? */
 	inside = skb_header_pointer(skb, skb->nh.iph->ihl*4, sizeof(_in), &_in);
 	if (inside == NULL)
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 
 	/* Ignore ICMP's containing fragments (shouldn't happen) */
 	if (inside->ip.frag_off & htons(IP_OFFSET)) {
 		DEBUGP("icmp_error_track: fragment of proto %u\n",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	innerproto = ip_conntrack_proto_find_get(inside->ip.protocol);
@@ -166,7 +166,7 @@ icmp_error_message(struct sk_buff *skb,
 	if (!ip_ct_get_tuple(&inside->ip, skb, dataoff, &origtuple, innerproto)) {
 		DEBUGP("icmp_error: ! get_tuple p=%u", inside->ip.protocol);
 		ip_conntrack_proto_put(innerproto);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	/* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -174,7 +174,7 @@ icmp_error_message(struct sk_buff *skb,
 	if (!ip_ct_invert_tuple(&innertuple, &origtuple, innerproto)) {
 		DEBUGP("icmp_error_track: Can't invert tuple\n");
 		ip_conntrack_proto_put(innerproto);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 	ip_conntrack_proto_put(innerproto);
 
@@ -190,7 +190,7 @@ icmp_error_message(struct sk_buff *skb,
 
 		if (!h) {
 			DEBUGP("icmp_error_track: no match\n");
-			return NF_ACCEPT;
+			return -NF_ACCEPT;
 		}
 		/* Reverse direction from that found */
 		if (DIRECTION(h) != IP_CT_DIR_REPLY)
diff --git a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
--- a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
+++ b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
@@ -159,13 +159,13 @@ icmp_error_message(struct sk_buff *skb,
 	/* Not enough header? */
 	inside = skb_header_pointer(skb, skb->nh.iph->ihl*4, sizeof(_in), &_in);
 	if (inside == NULL)
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 
 	/* Ignore ICMP's containing fragments (shouldn't happen) */
 	if (inside->ip.frag_off & htons(IP_OFFSET)) {
 		DEBUGP("icmp_error_message: fragment of proto %u\n",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	innerproto = nf_ct_find_proto(PF_INET, inside->ip.protocol);
@@ -176,7 +176,7 @@ icmp_error_message(struct sk_buff *skb,
 			     &nf_conntrack_l3proto_ipv4, innerproto)) {
 		DEBUGP("icmp_error_message: ! get_tuple p=%u",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
         /* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -184,7 +184,7 @@ icmp_error_message(struct sk_buff *skb,
         if (!nf_ct_invert_tuple(&innertuple, &origtuple,
 				&nf_conntrack_l3proto_ipv4, innerproto)) {
 		DEBUGP("icmp_error_message: no match\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	*ctinfo = IP_CT_RELATED;
@@ -199,7 +199,7 @@ icmp_error_message(struct sk_buff *skb,
 
 		if (!h) {
 			DEBUGP("icmp_error_message: no match\n");
-			return NF_ACCEPT;
+			return -NF_ACCEPT;
 		}
 
 		/* Reverse direction from that found */
diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
--- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
@@ -164,14 +164,14 @@ icmpv6_error_message(struct sk_buff *skb
 	hp = skb_header_pointer(skb, icmp6off, sizeof(_hdr), &_hdr);
 	if (hp == NULL) {
 		DEBUGP("icmpv6_error: Can't get ICMPv6 hdr.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	inip6off = icmp6off + sizeof(_hdr);
 	if (skb_copy_bits(skb, inip6off+offsetof(struct ipv6hdr, nexthdr),
 			  &inprotonum, sizeof(inprotonum)) != 0) {
 		DEBUGP("icmpv6_error: Can't get nexthdr in inner IPv6 header.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 	inprotoff = nf_ct_ipv6_skip_exthdr(skb,
 					   inip6off + sizeof(struct ipv6hdr),
@@ -182,7 +182,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if ((inprotoff < 0) || (inprotoff > skb->len) ||
 	    (inprotonum == NEXTHDR_FRAGMENT)) {
 		DEBUGP("icmpv6_error: Can't get protocol header in ICMPv6 payload.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	inproto = nf_ct_find_proto(PF_INET6, inprotonum);
@@ -191,7 +191,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if (!nf_ct_get_tuple(skb, inip6off, inprotoff, PF_INET6, inprotonum,
 			     &origtuple, &nf_conntrack_l3proto_ipv6, inproto)) {
 		DEBUGP("icmpv6_error: Can't get tuple\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	/* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -199,7 +199,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if (!nf_ct_invert_tuple(&intuple, &origtuple,
 				&nf_conntrack_l3proto_ipv6, inproto)) {
 		DEBUGP("icmpv6_error: Can't invert tuple\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	*ctinfo = IP_CT_RELATED;
@@ -207,7 +207,7 @@ icmpv6_error_message(struct sk_buff *skb
 	h = nf_conntrack_find_get(&intuple, NULL);
 	if (!h) {
 		DEBUGP("icmpv6_error: no match\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	} else {
 		if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
 			*ctinfo += IP_CT_IS_REPLY;

Re: (no subject)

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> Subject: Re: nf_conntrack comments
> From: Yasuyuki KOZAKAI <kozakai@isl.rdc.toshiba.co.jp>
> Fcc: +backup
> In-Reply-To: <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> References: <20051018084924.GD20338@sunbeam.de.gnumonks.org>
> 	<39e6f6c70510282108i60d78df6w9728f40641dccf80@mail.gmail.com>
> 	<20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
> ----
> 
> Hi, Acme and all,
> 
> Acme, thank you for reviewing of nf_conntrack.
> 
> From: Harald Welte <laforge@netfilter.org>
> Date: Sat, 29 Oct 2005 15:55:24 +0200
> 
> 
>>>+       if (!h) {
>>>+               DEBUGP("icmpv6_error: no match\n");
>>>+               return NF_ACCEPT;
>>>+       } else {
>>>+               if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>>>+                       *ctinfo += IP_CT_IS_REPLY;
>>>+       }
>>>+
>>>+       /* Update skb to refer to this connection */
>>>+       skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
>>>+       skb->nfctinfo = *ctinfo;
>>>+       return -NF_ACCEPT;
>>>+}
>>>
>>>I noticed that some of the returns are NF_ACCEPT while at leat this last one
>>>returns -NF_ACCEPT, is this a special convention or should all be negative? or
>>>positive?
>>
>>I'll check that, looks like a bug to me, too.
> 
> 
> If we don't change, the result is same. If this function return NF_ACCEPT,
> connection tracking handles packet as normal packet. But it cannot find invert
> tuple for it and stop processing after all. Then no problem.
> 
> But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
> stop processing early.
> 
> BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
> necessary to both of them if we want.
> 
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
> 
> Netfilter folks, do you have any problem if I change these return value ?

I think its a good idea, there is no point in continuing to process
these packets.

(no subject)

[Korolev, Alexey]

Nicolas,

Selecting of only one CFI buswidth and chip interleave helped to resolve
the halting issue.
cfi_cmdset001.o doesn't contain any reference to __udivsi3 __divsi3 and
__ashrdi3 in data segment.
I made several tests no halts or kernel panics got appeared. 

P/S 
1. I also tried to relocate some /arch/arm/lib code into RAM. It was
very bad move because it caused kernel Data abort at the very beginning
of kernel bootup process. Looks some code uses __divsi3 operations
before memory got initialized.
2. I have a question about XIP and icache 
	a. Execute kernel instructions from FLASH. Start filling of
icache pages by instructions from FLASH.
	b. Do_write_buffer call. Switching to READ_STATUS. 
	c. Finish filling of icache pages by instructions from FLASH.
(Part of icache is corrupted).
	d. Return from Do_write_buffer 
	e. Execute instruction from FLASH which is presorted in icache.
-> Data abort or kernel panic.

Is it possible to face the following scenario? 

Thanks,
Alexey

(no subject)

[Amresh Kumar]

Hi
I am new to iptables i have a problem in adding iptable rule i am adding ip 
table rule

  iptables -A OUTPUT -p tcp -m iprange --src-range 10.0.0.1-10.0.0.20 -m 
iprange  --dst-range 61.12.43.1-61.12.43.20 -j ACCEPT
But i am getting following error
Bad argument `61.12.43.1-61.12.43.20'
Try `iptables -h' or 'iptables --help' for more information.
Actuall i am trying to drop  destination iprange 61.12.43.1-61.12.43.20 to 
source ip range 10.0.0.1-10.0.0.20 .

Is their any other rule  that i can add. plz help me

Thanks and regard..

_________________________________________________________________
Register with e-bay. 
http://pages.ebay.in/msnindia/msn_quad_shopwingold_sept.html Win gold, 
watches and more!

Re: (no subject)

[Vinod Chandran]

Remove the second instance of -m iprange.

Regards,
Vinod C

Amresh Kumar wrote:

> Hi
> I am new to iptables i have a problem in adding iptable rule i am 
> adding ip table rule
>
>  iptables -A OUTPUT -p tcp -m iprange --src-range 10.0.0.1-10.0.0.20 
> -m iprange  --dst-range 61.12.43.1-61.12.43.20 -j ACCEPT
> But i am getting following error
> Bad argument `61.12.43.1-61.12.43.20'
> Try `iptables -h' or 'iptables --help' for more information.
> Actuall i am trying to drop  destination iprange 
> 61.12.43.1-61.12.43.20 to source ip range 10.0.0.1-10.0.0.20 .
>
> Is their any other rule  that i can add. plz help me
>
> Thanks and regard..
>
> _________________________________________________________________
> Register with e-bay. 
> http://pages.ebay.in/msnindia/msn_quad_shopwingold_sept.html Win gold, 
> watches and more!
>
>

Re: (no subject)

[Rob Sterenborg]

On Thu, October 6, 2005 10:11, Amresh Kumar wrote:
> Hi
> I am new to iptables i have a problem in adding iptable rule i am
> adding ip
> table rule
>
>   iptables -A OUTPUT -p tcp -m iprange --src-range 10.0.0.1-10.0.0.20
> -m
> iprange  --dst-range 61.12.43.1-61.12.43.20 -j ACCEPT
> But i am getting following error
> Bad argument `61.12.43.1-61.12.43.20'
> Try `iptables -h' or 'iptables --help' for more information.
> Actuall i am trying to drop  destination iprange
> 61.12.43.1-61.12.43.20 to
> source ip range 10.0.0.1-10.0.0.20 .

You probably don't have Netfilter "range" support in/for your kernel
or the modules is not loaded (osmething like ipt_range ?). If you
don't have it, you may have to patch (Patch-O-Matic) and compile a new
kernel.


Gr,
Rob

(no subject)

[Doug McLain]

unsubscribe

(no subject)

[Bob Brose]

I'm trying to fix some of the AX25 code in the 2.6 kernel and traced down
a problem to the use of a char var which was being assigned
the value of -1. On x86 when the var was compared to -1 it succeded but
on PPC it failed. So I tried a simple test:

main()
{
char atest;
atest=-1;
printf("%i,%X\n",atest,atest);
}

With GCC 3.3.5 on 2.6.14-rc1 x86 I get:
./atest
-1,FFFFFFFF

With GCC 3.3.5 on 2.6.14-rc1 PPC I get:
./atest
255,FF

If I change the declaration of atest to a signed char on PPC I get the
same result as x86.

Does this mean the char in x86 is signed and in PPC it's unsigned?
Has it always been thus?
 

Re: (no subject)

[Andreas Schwab]

Bob Brose <linuxppcdev@qbjnet.com> writes:

> Does this mean the char in x86 is signed and in PPC it's unsigned?

Yes.

> Has it always been thus?

Yes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

(no subject)

[Prashanth Radhakrishnan]

> Yes, I'm still working on it.  The focus of that work was copy-on-write
> sharing of memory for the purposes of building a (virtual) network of
> honeypot systems.  We have a paper in SOSP this year, talking about that
> work and the copy-on-write memory implementation.  See
>     http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin.pdf
> for some information.
>
> I'm presently working on updating and cleaning that work up.
>
> --Michael Vrable

Thanks for the info, Michael. Just wondering if this code has been checked 
into the Xen-unstable branch, or around when it would be checked in.
(I din't find any related checkin by searching at 
http://lists.xensource.com/archives/html/xen-changelog/)

thanks again,
prashanth

(no subject)

[Li, Chengyuan]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]


Set guest selectors to be null if it's not valid when switch to
protected-mode in the guest firmware.

Signed-off-by: Chengyuan Li <chengyuan.li@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>


Thanks,
Chengyuan


[-- Attachment #2: vmxassist_selector.patch --]
[-- Type: application/octet-stream, Size: 2097 bytes --]

diff -r f069a06e650f tools/firmware/vmxassist/vm86.c
--- a/tools/firmware/vmxassist/vm86.c	Wed Sep 28 21:18:30 2005
+++ b/tools/firmware/vmxassist/vm86.c	Thu Sep 29 12:59:36 2005
@@ -470,10 +470,21 @@
 	unsigned long long entry;
 
 	/* protected mode: use seg as index into gdt */
-	if (sel == 0 || sel > oldctx.gdtr_limit)
+	if (sel > oldctx.gdtr_limit)
 		return 0;
 
+    if (sel == 0) {
+        arbytes->fields.null_bit = 1;
+        return 1;
+    }
+
 	entry =  ((unsigned long long *) oldctx.gdtr_base)[sel >> 3];
+
+    /* Check the P bit fisrt*/
+    if (!((entry >> (15+32)) & 0x1) && sel != 0) {
+        return 0;
+    }
+
 	*base =  (((entry >> (56-24)) & 0xFF000000) |
 		  ((entry >> (32-16)) & 0x00FF0000) |
 		  ((entry >> (   16)) & 0x0000FFFF));
@@ -519,22 +530,42 @@
 	if (load_seg(regs->ves, &oldctx.es_base,
 				&oldctx.es_limit, &oldctx.es_arbytes))
 		oldctx.es_sel = regs->ves;
+    else {
+        load_seg(0, &oldctx.es_base,&oldctx.es_limit, &oldctx.es_arbytes);
+        oldctx.es_sel = 0;
+    }
 
 	if (load_seg(regs->uss, &oldctx.ss_base,
 				&oldctx.ss_limit, &oldctx.ss_arbytes))
 		oldctx.ss_sel = regs->uss;
+    else {
+        load_seg(0, &oldctx.ss_base, &oldctx.ss_limit, &oldctx.ss_arbytes);
+        oldctx.ss_sel = 0;
+    }
 
 	if (load_seg(regs->vds, &oldctx.ds_base,
 				&oldctx.ds_limit, &oldctx.ds_arbytes))
 		oldctx.ds_sel = regs->vds;
+    else {
+        load_seg(0, &oldctx.ds_base, &oldctx.ds_limit, &oldctx.ds_arbytes);
+        oldctx.ds_sel = 0;
+    }
 
 	if (load_seg(regs->vfs, &oldctx.fs_base,
 				&oldctx.fs_limit, &oldctx.fs_arbytes))
 		oldctx.fs_sel = regs->vfs;
+    else {
+        load_seg(0, &oldctx.fs_base, &oldctx.fs_limit, &oldctx.fs_arbytes);
+        oldctx.fs_sel = 0;
+    }
 
 	if (load_seg(regs->vgs, &oldctx.gs_base,
 				&oldctx.gs_limit, &oldctx.gs_arbytes))
 		oldctx.gs_sel = regs->vgs;
+    else {
+        load_seg(0, &oldctx.gs_base, &oldctx.gs_limit, &oldctx.gs_arbytes);
+        oldctx.gs_sel = 0;
+    }
 
 	/* initialize jump environment to warp back to protected mode */
 	regs->cs = CODE_SELECTOR;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

(no subject)

[ÏÄÓê]

I have plugged a PCI net card (i82559)on the ICECUBE board (mpc5200), but could not make it work .Which environment should i config in U-BOOT?

Re: (no subject)

[Wolfgang Denk]

In message <200509272153.AA292552812@NARI-RELAYS.COM> you wrote:
> I have plugged a PCI net card (i82559)on the ICECUBE board (mpc5200), but could not make it work .Which environment should i config in U-BOOT?

What are you talking about? Make it work in U-Boot?  In  Linux?  What
exactly  did you try, and what did not work? What was the exact error
messages?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Der Horizont vieler Menschen ist ein Kreis mit Radius Null --
und das nennen sie ihren Standpunkt.

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> -----Original Message-----
> From: Magenheimer, Dan (HP Labs Fort Collins) 
> Sent: Wednesday, September 21, 2005 2:50 PM
> To: 'Christian Limpach'
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] (no subject)
> 
> > > I suppose it would be nice if on ia64 just 'make' did the
> > > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > > specify it on the command line.  In that case, adding it
> > > to all the calls to mkbuildtree is necessary.  How do
> > > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > > if x86 (or x86_64) and the architecture it is running on
> > > (e.g. ia64) otherwise?
> > 
> > I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> > dependent on ARCH, like you did in your original patch...
> 
> Thanks very much!  I tried it and it works great!  Using
> this, I have started committing files into the ia64 subdirs
> of -sparse in xen-ia64-unstable.hg which will be pulled
> into the xen-unstable tree at the next sync.  I have already
> built and tested a "driver-less" domain0 from -sparse.

Oops, I tried it only using a cross-compiler.  When I compiled
natively on ia64, it is still necessary to specify
LINUX_ARCH=ia64 on the make-line, else I get x86 configs.

I think the fix is to change in buildconfig/Rules.mk from

ifneq ($(ARCH),ia64)
  to
ifneq ($(XEN_TARGET_ARCH),ia64)

I'll roll this fix in at the next merge with xen-ia64-unstable.

Thanks,
Dan

Re: (no subject)

[Christian Limpach]

On 9/23/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> Oops, I tried it only using a cross-compiler.  When I compiled
> natively on ia64, it is still necessary to specify
> LINUX_ARCH=ia64 on the make-line, else I get x86 configs.
>
> I think the fix is to change in buildconfig/Rules.mk from
>
> ifneq ($(ARCH),ia64)
>  to
> ifneq ($(XEN_TARGET_ARCH),ia64)
>
> I'll roll this fix in at the next merge with xen-ia64-unstable.

Yes, thanks!

    christian

RE: (no subject)

[Heyman, Michael]

> From: Henrik Nordstrom [mailto:hno@marasystems.com] 
> Sent: Thursday, September 22, 2005 4:01 AM
> 
> > I found what apears to be a bug in the 
> > "net/ipv4/netfilter/ip_tables.c" code. The issue 
> > arose when I had a mangle table target that could 
> > return NF_STOLEN. The ipt_do_table() routine uses 
> > the contents of the sk_buff to calculate "datalen" 
> > even though the sk_buff, upon return from the 
> > "target()" call with NF_STOLEN, should be assumed 
> > invalid (in my case, I had set the returned 
> > sk_buff to NULL).
> >
> > --- foo.c	2005-09-21 07:00:35.000000000 -0400
> > +++ net/ipv4/netfilter/ip_tables.c	2005-06-17 15:48:29.000000000
> > -0400
> > @@ -378,15 +378,16 @@
> > 				((struct ipt_entry
> > *)table_base)->comefrom
> > 					= 0x57acc001;
> > #endif
> > -				/* Target might have changed stuff. */
> > -				ip = (*pskb)->nh.iph;
> > -				datalen = (*pskb)->len - ip->ihl * 4;
> > -
> > 				if (verdict == IPT_CONTINUE)
> > 					e = (void *)e + e->next_offset;
> > 				else
> > 					/* Verdict */
> > 					break;
> > +
> > +				/* Target might have changed stuff. */
> > +				ip = (*pskb)->nh.iph;
> > +				datalen = (*pskb)->len - ip->ihl * 4;
> > +
> 
> 
> This patch on the other hand fails in the perhaps more common 
> situation where a target mangles the payload and returns NF_ACCEPT.
> 
Again, I haven't tested it but I also didn't see where "ip" or "datalen"
were used in the case where the target did not return IPT_CONTINUE.

-Michael Heyman

RE: (no subject)

[Henrik Nordstrom]

On Thu, 22 Sep 2005, Heyman, Michael wrote:

> Again, I haven't tested it but I also didn't see where "ip" or "datalen"
> were used in the case where the target did not return IPT_CONTINUE.

You are right. On a second look your patch looks much better.

Regards
Henrik

difference between syn and NEW

[Subramanian]

hi,

I read in the iptables manual [in the Appendix B.
Common problems and questions ]that the NEW state
match may accept any packet marked as NEW whether it
has syn bit set or not.

 it says "If you use state NEW, packets with the SYN
bit unset will get through your firewall"

so in short it means anything marked NEW is passed
thru irrespective of whether syn is set or not OR
maybe any other bit is set

My question is if i am having a single firewall with
deny all policy and wanting to accept only new
connections for ip's or services like ssh,smtp etc
what shld be my rule -

a) iptables with --syn   OR
b) iptables with --syn + NEW OR ONLY
c) iptables with NEW

what is the recommended rule for a restrictive
firewall?

I guess option a) is the best one. But it shld not
lead to a lot of connection drops as NEW allows timed
out connections if the connection is not closed.

Please suggest the best practice.

Secondly if i want to limit ssh connections for syn
flood protection what is the recomended limit and
limit-burst values.

thirdly if i want to limit ping for ping flood
protection what is the recomended limit and
limit-burst values.

Please suggest the best practice.

Thanks & Regards,
sub  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

(no subject)

[Bernd Lippert]

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > I suppose it would be nice if on ia64 just 'make' did the
> > right thing, e.g. set LINUX_ARCH=ia64 without the need to
> > specify it on the command line.  In that case, adding it
> > to all the calls to mkbuildtree is necessary.  How do
> > I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> > if x86 (or x86_64) and the architecture it is running on
> > (e.g. ia64) otherwise?
> 
> I'll check it in tomorrow, and I'll make it set LINUX_ARCH
> dependent on ARCH, like you did in your original patch...

Thanks very much!  I tried it and it works great!  Using
this, I have started committing files into the ia64 subdirs
of -sparse in xen-ia64-unstable.hg which will be pulled
into the xen-unstable tree at the next sync.  I have already
built and tested a "driver-less" domain0 from -sparse.

Dan

(no subject)

[Ryan Olejnik]

[-- Attachment #1: Type: text/plain, Size: 29 bytes --]

unsubscribe <ryno@audio.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]

(no subject)

[Heyman, Michael]

I found what apears to be a bug in the "net/ipv4/netfilter/ip_tables.c"
code. The issue arose when I had a mangle table target that could return
NF_STOLEN. The ipt_do_table() routine uses the contents of the sk_buff
to calculate "datalen" even though the sk_buff, upon return from the
"target()" call with NF_STOLEN, should be assumed invalid (in my case, I
had set the returned sk_buff to NULL).

I cannot change the kernel my target must run on. This led me to simply
set the sk_buff returned to a static with the required values,
"skb->len" and "skb->nh.iph->ihl", set to zero. Doing this doesn't seem
to break anything.

I have included a possible patch to fix the issue, I haven't tested the
patch but the idea is to simply move the sk_buff access to a point where
the sk_buff should be valid.

A quick grep shows a similar construct in
"net/ipv4/netfilter/arp_tables.c:arpt_do_table()" that may need a
similar fix.

-Michael Heyman


--- foo.c	2005-09-21 07:00:35.000000000 -0400
+++ net/ipv4/netfilter/ip_tables.c	2005-06-17 15:48:29.000000000
-0400
@@ -378,15 +378,16 @@
 				((struct ipt_entry
*)table_base)->comefrom
 					= 0x57acc001;
 #endif
-				/* Target might have changed stuff. */
-				ip = (*pskb)->nh.iph;
-				datalen = (*pskb)->len - ip->ihl * 4;
-
 				if (verdict == IPT_CONTINUE)
 					e = (void *)e + e->next_offset;
 				else
 					/* Verdict */
 					break;
+
+				/* Target might have changed stuff. */
+				ip = (*pskb)->nh.iph;
+				datalen = (*pskb)->len - ip->ihl * 4;
+
 			}
 		} else 

Re: (no subject)

[Henrik Nordstrom]

On Wed, 21 Sep 2005, Heyman, Michael wrote:

> I found what apears to be a bug in the "net/ipv4/netfilter/ip_tables.c"
> code. The issue arose when I had a mangle table target that could return
> NF_STOLEN. The ipt_do_table() routine uses the contents of the sk_buff
> to calculate "datalen" even though the sk_buff, upon return from the
> "target()" call with NF_STOLEN, should be assumed invalid (in my case, I
> had set the returned sk_buff to NULL).
>
> --- foo.c	2005-09-21 07:00:35.000000000 -0400
> +++ net/ipv4/netfilter/ip_tables.c	2005-06-17 15:48:29.000000000
> -0400
> @@ -378,15 +378,16 @@
> 				((struct ipt_entry
> *)table_base)->comefrom
> 					= 0x57acc001;
> #endif
> -				/* Target might have changed stuff. */
> -				ip = (*pskb)->nh.iph;
> -				datalen = (*pskb)->len - ip->ihl * 4;
> -
> 				if (verdict == IPT_CONTINUE)
> 					e = (void *)e + e->next_offset;
> 				else
> 					/* Verdict */
> 					break;
> +
> +				/* Target might have changed stuff. */
> +				ip = (*pskb)->nh.iph;
> +				datalen = (*pskb)->len - ip->ihl * 4;
> +


This patch on the other hand fails in the perhaps more common situation 
where a target mangles the payload and returns NF_ACCEPT.

Regards
Henrik

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > You have to export LINUX_ARCH to the script.  We don't want to
> > > unconditionally polute the environment of all the commands we
> > > run, so you'll have to add it to all the calls to mkbuildtree.
> > 
> > I'm not sure I follow... I don't know exactly how make or bash
> > work wrt to exporting... I didn't explicitly export LINUX_ARCH
> > but it seems to be known by mkbuildtree and all the mk.linux's
> > anyway.  (I successfully built for x86 and ia64 with the
> > patch.)
> > 
> > Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> > so as to avoid polluting the environment?
> 
> Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> passed to mkbuildtree unless you add it to its environment.
> I confirmed this now by adding this to mkbuildtree:
> echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> you have LINUX_ARCH set in your shell environment where you ran
> make?  Odd...

No, it's not in my shell environment.  However, when I run make
to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
I'm guessing make must export it to subshells.  If I add the
'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
do get run.

But if I build (for xen/x86) with just 'make', nothing gets
echoed to the file and, as you pointed out, no hook script
gets run.  But that's the default behavior we want, correct?

I suppose it would be nice if on ia64 just 'make' did the
right thing, e.g. set LINUX_ARCH=ia64 without the need to
specify it on the command line.  In that case, adding it
to all the calls to mkbuildtree is necessary.  How do
I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
if x86 (or x86_64) and the architecture it is running on
(e.g. ia64) otherwise?

So I think the patch is OK as is... I've built successfully
for both x86 and ia64... but I can still change it and
resubmit if you prefer the other way.

Thanks,
Dan

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 01:52:36PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
> > passed to mkbuildtree unless you add it to its environment.
> > I confirmed this now by adding this to mkbuildtree:
> > echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
> > LINUX_ARCH is empty and thus your hook script won't run.  Maybe
> > you have LINUX_ARCH set in your shell environment where you ran
> > make?  Odd...
> 
> No, it's not in my shell environment.  However, when I run make
> to build for ia64 I run it as: 'make LINUX_ARCH=ia64 ...' and
> I'm guessing make must export it to subshells.  If I add the
> 'echo', I do get ia64 in /tmp/xxxxxx and the ia64 hook scripts
> do get run.

Yes, that explains it.

> I suppose it would be nice if on ia64 just 'make' did the
> right thing, e.g. set LINUX_ARCH=ia64 without the need to
> specify it on the command line.  In that case, adding it
> to all the calls to mkbuildtree is necessary.  How do
> I set LINUX_ARCH in Rules.mk so that it is set to 'xen'
> if x86 (or x86_64) and the architecture it is running on
> (e.g. ia64) otherwise?

I'll check it in tomorrow, and I'll make it set LINUX_ARCH
dependent on ARCH, like you did in your original patch...

Thanks!

    christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > Please define LINUX_ARCH in buildconfigs/Rules.mk and use 
> that where
> > > we run make ARCH=xen.
> > > If you can name your config file xen0_defconfig_ia64 and use
> > > LINUX_ARCH for the path, then you won't need to duplicate 
> the config
> > > file code.
> > 
> > OK, I see.  This cleans it up nicely. New patch attached.
> 
> You have to export LINUX_ARCH to the script.  We don't want to
> unconditionally polute the environment of all the commands we
> run, so you'll have to add it to all the calls to mkbuildtree.

I'm not sure I follow... I don't know exactly how make or bash
work wrt to exporting... I didn't explicitly export LINUX_ARCH
but it seems to be known by mkbuildtree and all the mk.linux's
anyway.  (I successfully built for x86 and ia64 with the
patch.)

Or are you suggesting I *not* define it in buildconfigs/Rules.mk
so as to avoid polluting the environment?
 
> I think I'd prefer xen-mkbuildtree-{pre,post} as the name of 
> the scripts
> to run, but not too fussed about that...

That's OK with me.  If enlightenment (is that a bad word in
Xen land now?) from the above requires me to re-generate
the patch, I will change the names.

Thanks!
Dan

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 12:20:41PM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > > OK, I see.  This cleans it up nicely. New patch attached.
> > 
> > You have to export LINUX_ARCH to the script.  We don't want to
> > unconditionally polute the environment of all the commands we
> > run, so you'll have to add it to all the calls to mkbuildtree.
> 
> I'm not sure I follow... I don't know exactly how make or bash
> work wrt to exporting... I didn't explicitly export LINUX_ARCH
> but it seems to be known by mkbuildtree and all the mk.linux's
> anyway.  (I successfully built for x86 and ia64 with the
> patch.)
> 
> Or are you suggesting I *not* define it in buildconfigs/Rules.mk
> so as to avoid polluting the environment?

Rules.mk is fine.  What I meant is that LINUX_ARCH won't get
passed to mkbuildtree unless you add it to its environment.
I confirmed this now by adding this to mkbuildtree:
echo ${LINUX_ARCH} >>/tmp/xxxxxxxx
LINUX_ARCH is empty and thus your hook script won't run.  Maybe
you have LINUX_ARCH set in your shell environment where you ran
make?  Odd...

> That's OK with me.  If enlightenment (is that a bad word in
> Xen land now?) from the above requires me to re-generate
> the patch, I will change the names.

Cheers!

   christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> > > Why are you piping in tons of nothing into Make here 
> using the "yes"
> > > command?
> > 
> > This mechanically does the same as manually hitting
> > "enter" at every prompt from "make oldconfig", thus it
> > applies the default response for every unconfigured
> > option without manual intervention.
> 
> I think it's preferable to have default config files which don't cause
> any prompting.
> 
> Also if people upgrade, they probably want to be prompted on any new
> options.  If not, then let's get the default behaviour for "make
> oldconfig" changed upstream...

I've just used this for convenience.  The defconfigs in
Linux/ia64 cause prompting and the config change required for
Xen/ia64 support (because it is transparently paravirtualized)
is adding "CONFIG_XEN=y".  But I can easily put the output
of make oldconfig in the xen defconfig file if the
preference is to have no prompting (thus the "yes" pipe
is removed from the previously posted patch).

Thanks,
Dan

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

(Sorry about the "no subject" in the original message...
fat fingers on my part.)

> Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> we run make ARCH=xen.
> If you can name your config file xen0_defconfig_ia64 and use
> LINUX_ARCH for the path, then you won't need to duplicate the config
> file code.

OK, I see.  This cleans it up nicely. New patch attached.

> Please also change all mk.linux files.

Done.

> > 2) A sequence of mkbuildtree "massage" commands need to
> >   be executed before mkbuildtree does its linking thing.
> >   Perhaps this could be done as:
> >    if -e mkbuildtree.prelink.$XENARCH
> >        mkbuildtree.prelink.$XENARCH
> >   Though ia64 doesn't need it, maybe also add a "postlink"
> >   equivalent?
> 
> Why do you need to move these out of the way in the first place?  If
> any of the changes we've made break ia64, then we should cleanup our
> changes.

Do the changes have no impact to non-Xen non-x86 kernels?
Since xenlinux/ia64 is transparently paravirtualized,
the changes looked like they might be xen-specific, and
xenlinux/ia64 has been running out-of-tree without any
of those changes, the script moves them aside.  If there's
no impact, I can move them back in (but will probably
do so slowly for testing purposes).

In any case, drivers/xen definitely is not yet fully
archdep, so I need to use the pre- or post-mkbuildtree
to do some patching in the short term.  Agree in the longer
term, these files should be empty but if you don't mind
greatly, having the archdep hooks there will probably
make things easier for arch's for now.

> > Could someone with the necessary build knowledge make
> > the improvements and commit this please? Let me know if/when
> > it goes in and I will populate the ia64 -sparse branches.
> 
> Please give creating a patch another try, taking the suggestions above
> into consideration.  Thanks!

OK, let me know if this is better.

Thanks,
Dan

[-- Attachment #2: xenia64sparse2 --]
[-- Type: application/octet-stream, Size: 7395 bytes --]

diff -r ec01850d0ee9 buildconfigs/Rules.mk
--- a/buildconfigs/Rules.mk	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/Rules.mk	Mon Sep 19 10:45:52 2005
@@ -14,6 +14,9 @@
 # Setup pristine search path
 PRISTINE_SRC_PATH	?= .:..
 vpath pristine-% $(PRISTINE_SRC_PATH)
+
+# By default, build Linux with ARCH=xen (overridden by some non arch's)
+LINUX_ARCH	?= xen
 
 # Expand Linux series to Linux version
 LINUX_SERIES	?= 2.6
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.4-xenU
--- a/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.4-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -36,16 +36,16 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	make -C $(LINUX_DIR) ARCH=xen oldconfig
-	make -C $(LINUX_DIR) ARCH=xen dep
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
+	make -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen dep
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) dep
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen
--- a/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 buildconfigs/mk.linux-2.6-xenU
--- a/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 15:21:09 2005
+++ b/buildconfigs/mk.linux-2.6-xenU	Mon Sep 19 10:45:52 2005
@@ -15,10 +15,10 @@
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
-	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) INSTALL_PATH=$(DESTDIR) install
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -38,14 +38,14 @@
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) oldconfig
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) $(CONFIGMODE)
 
 clean::
-	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+	$(MAKE) -C $(LINUX_DIR) ARCH=$(LINUX_ARCH) clean
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r ec01850d0ee9 linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 15:21:09 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Mon Sep 19 10:45:52 2005
@@ -89,6 +89,11 @@
 abs_to_rel ${AD} ${AS}
 RS=$DESTPATH
 
+# Arch-specific pre-processing
+if [ -x arch/${LINUX_ARCH}/xen-pre-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-pre-mkbuildtree
+fi
+
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
@@ -110,3 +115,10 @@
 
 cd ${AD}/include/asm-xen/linux-public
 ln -sf ../../../${RS}/../tools/xenstore/xenstored.h
+
+# Arch-specific post-processing
+cd ${AD}
+if [ -x arch/${LINUX_ARCH}/xen-post-mkbuildtree ]; then
+	arch/${LINUX_ARCH}/xen-post-mkbuildtree
+fi
+

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Christian Limpach]

On Mon, Sep 19, 2005 at 09:49:05AM -0700, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
> > we run make ARCH=xen.
> > If you can name your config file xen0_defconfig_ia64 and use
> > LINUX_ARCH for the path, then you won't need to duplicate the config
> > file code.
> 
> OK, I see.  This cleans it up nicely. New patch attached.

You have to export LINUX_ARCH to the script.  We don't want to
unconditionally polute the environment of all the commands we
run, so you'll have to add it to all the calls to mkbuildtree.

I think I'd prefer xen-mkbuildtree-{pre,post} as the name of the scripts
to run, but not too fussed about that...

> Do the changes have no impact to non-Xen non-x86 kernels?
> Since xenlinux/ia64 is transparently paravirtualized,
> the changes looked like they might be xen-specific, and
> xenlinux/ia64 has been running out-of-tree without any
> of those changes, the script moves them aside.  If there's
> no impact, I can move them back in (but will probably
> do so slowly for testing purposes).
> 
> In any case, drivers/xen definitely is not yet fully
> archdep, so I need to use the pre- or post-mkbuildtree
> to do some patching in the short term.  Agree in the longer
> term, these files should be empty but if you don't mind
> greatly, having the archdep hooks there will probably
> make things easier for arch's for now.

Ok, let's go with the pre/post link scripts for now, but I think
it would be good to make our changes work when building non-x86/non-xen.

    christian

RE: (no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

> On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
> 
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
> 
> Why are you piping in tons of nothing into Make here using the "yes"
> command? 

This mechanically does the same as manually hitting
"enter" at every prompt from "make oldconfig", thus it
applies the default response for every unconfigured
option without manual intervention.

Dan

Re: (no subject)

[Christian Limpach]

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> > On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
> > Collins) wrote:
> >
> > > +ifeq ($(ARCH),ia64)
> > > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > > +else
> >
> > Why are you piping in tons of nothing into Make here using the "yes"
> > command?
> 
> This mechanically does the same as manually hitting
> "enter" at every prompt from "make oldconfig", thus it
> applies the default response for every unconfigured
> option without manual intervention.

I think it's preferable to have default config files which don't cause
any prompting.

Also if people upgrade, they probably want to be prompted on any new
options.  If not, then let's get the default behaviour for "make
oldconfig" changed upstream...

    christian

(no subject)

[Magenheimer, Dan (HP Labs Fort Collins)]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Attached is an (ugly but relatively simple) patch that allows
Xenlinux/ia64 to be built using the linux "-sparse" tree
methodology (once I populate some files in the -sparse tree).

The changes are not dramatic and I think they can be done
much more cleanly, but I'm not a build expert so would
appreciate improvements from those more comfortable with
the Xen build environment... and perhaps it can be
made more generic so the ppc guys can benefit too.

The primary changes are:
1) wherever a make is done with ARCH=xen, this needs
   to be converted to ARCH=ia64.  (This can probably
   be done as ARCH=$(XENARCH) or something like that
   but I'm not sure how to do it without requiring x86
   and x86_64 builds to specify XENARCH= at build time.)
2) A sequence of mkbuildtree "massage" commands need to
   be executed before mkbuildtree does its linking thing.
   Perhaps this could be done as:
    if -e mkbuildtree.prelink.$XENARCH
        mkbuildtree.prelink.$XENARCH
   Though ia64 doesn't need it, maybe also add a "postlink"
   equivalent?

There is also one change because the ia64 defconfig filename
is different.  I can change this filename to conform with
the existing convention but perhaps the defconfig pathname
could be set as part of the prelink file?

Could someone with the necessary build knowledge make
the improvements and commit this please? Let me know if/when
it goes in and I will populate the ia64 -sparse branches.

Thanks,
Dan

[-- Attachment #2: xenia64sparse --]
[-- Type: application/octet-stream, Size: 3406 bytes --]

diff -r 8d133d172bfd buildconfigs/mk.linux-2.6-xen0
--- a/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 18:18:57 2005
+++ b/buildconfigs/mk.linux-2.6-xen0	Sun Sep 18 14:31:47 2005
@@ -14,11 +14,19 @@
 
 # The real action starts here!
 build: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_PATH=$(DESTDIR) install
+	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 modules ; \
+	    $(MAKE) -C $(LINUX_DIR) ARCH=ia64 INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
+	fi
+else
 	if grep "^CONFIG_MODULES=" $(LINUX_DIR)/.config ; then \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen modules ; \
 	    $(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_MOD_PATH=$(DESTDIR) modules_install ; \
 	fi
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(DESTDIR) install
+endif
 
 $(LINUX_DIR)/include/linux/autoconf.h: ref-$(OS)-$(LINUX_VER)/.valid-ref
 	rm -rf $(LINUX_DIR)
@@ -27,25 +35,45 @@
 	( cd linux-$(LINUX_SERIES)-xen-sparse ; \
           ./mkbuildtree ../$(LINUX_DIR) )
 	# Re-use config from install dir if one exits else use default config
+ifeq ($(ARCH),ia64)
+	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
+	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
+	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
+	  || cp $(LINUX_DIR)/arch/ia64/configs/xen_zx1_defconfig \
+		$(LINUX_DIR)/.config
+else
 	CONFIG_VERSION=$$(sed -ne 's/^EXTRAVERSION = //p' $(LINUX_DIR)/Makefile); \
 	[ -r $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) ] && \
 	  cp $(DESTDIR)/boot/config-$(LINUX_VER)$$CONFIG_VERSION-$(EXTRAVERSION) $(LINUX_DIR)/.config \
 	  || cp $(LINUX_DIR)/arch/xen/configs/$(EXTRAVERSION)_defconfig_$(XEN_TARGET_ARCH) \
 		$(LINUX_DIR)/.config
+endif
 	# See if we need to munge config to enable PAE
 	$(MAKE) CONFIG_FILE=$(LINUX_DIR)/.config -f buildconfigs/Rules.mk config-update-pae
 	# Patch kernel Makefile to set EXTRAVERSION
 	( cd $(LINUX_DIR) ; \
 	  sed -e 's/^EXTRAVERSION.*/&$$(XENGUEST)\nXENGUEST = -$(EXTRAVERSION)/' Makefile >Mk.tmp ; \
 	  rm -f Makefile ; mv Mk.tmp Makefile )
+ifeq ($(ARCH),ia64)
+	yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen oldconfig
+endif
 
 config: CONFIGMODE = menuconfig
 config: $(LINUX_DIR)/include/linux/autoconf.h
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) $(CONFIGMODE)
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen $(CONFIGMODE)
+endif
 
 clean::
+ifeq ($(ARCH),ia64)
+	$(MAKE) -C $(LINUX_DIR) ARCH=ia64 clean
+else
 	$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
+endif
 
 delete: 
 	rm -rf tmp-$(OS)-$(LINUX_VER) $(LINUX_DIR) 
diff -r 8d133d172bfd linux-2.6-xen-sparse/mkbuildtree
--- a/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 18:18:57 2005
+++ b/linux-2.6-xen-sparse/mkbuildtree	Sun Sep 18 14:31:47 2005
@@ -92,6 +92,16 @@
 # Remove old copies of files and directories at the destination
 for i in `find . -type f -o -type l` ; do rm -f ${AD}/${i#./} ; done
 
+if [ "$ARCH" = "ia64" ]; then
+mv arch/xen/kernel drivers/xen/core
+mv mm mm.x86
+mv net net.x86
+mv kernel kernel.x86
+mv arch/xen arch/xen.x86
+mv include/asm-generic include/asm-generic.x86
+mv include/linux include/linux.x86
+fi
+
 # We now work from the destination directory
 cd ${AD} || { echo "cannot cd to ${AD}"; exit 1; }
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: (no subject)

[Christian Limpach]

On 9/19/05, Magenheimer, Dan (HP Labs Fort Collins)
<dan.magenheimer@hp.com> wrote:
> The primary changes are:
> 1) wherever a make is done with ARCH=xen, this needs
>   to be converted to ARCH=ia64.  (This can probably
>   be done as ARCH=$(XENARCH) or something like that
>   but I'm not sure how to do it without requiring x86
>   and x86_64 builds to specify XENARCH= at build time.)

Please define LINUX_ARCH in buildconfigs/Rules.mk and use that where
we run make ARCH=xen.
If you can name your config file xen0_defconfig_ia64 and use
LINUX_ARCH for the path, then you won't need to duplicate the config
file code.
Please also change all mk.linux files.

> 2) A sequence of mkbuildtree "massage" commands need to
>   be executed before mkbuildtree does its linking thing.
>   Perhaps this could be done as:
>    if -e mkbuildtree.prelink.$XENARCH
>        mkbuildtree.prelink.$XENARCH
>   Though ia64 doesn't need it, maybe also add a "postlink"
>   equivalent?

Why do you need to move these out of the way in the first place?  If
any of the changes we've made break ia64, then we should cleanup our
changes.

> Could someone with the necessary build knowledge make
> the improvements and commit this please? Let me know if/when
> it goes in and I will populate the ia64 -sparse branches.

Please give creating a patch another try, taking the suggestions above
into consideration.  Thanks!

    christian

Re: (no subject)

[Jerone Young]

On Mon, 2005-09-19 at 06:43 -0700, Magenheimer, Dan (HP Labs Fort
Collins) wrote:

> +ifeq ($(ARCH),ia64)
> +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> +else

Why are you piping in tons of nothing into Make here using the "yes"
command? 

-- 
Jerone Young
IBM Linux Technology Center
jyoung5@us.ibm.com
512-838-1157 (T/L: 678-1157)

Re: (no subject)

[Mark Williamson]

> Collins) wrote:
> > +ifeq ($(ARCH),ia64)
> > +       yes "" | $(MAKE) -C $(LINUX_DIR) oldconfig
> > +else
>
> Why are you piping in tons of nothing into Make here using the "yes"
> command?

I guess, to answer <ret> (choose default) to any questions oldconfig throws 
up.

Cheers,
Mark

(no subject)

[Konstantin Kletschke]

Hi Folks!

I realize actuall on 2.6.13 flash_unlock is not functional anymore,
have I missed something? I use it with cfi_cmdset_0001.c quite often
on 2.6.12. Version of flash_unlock is current cvs...

# strace flash_unlock /dev/mtd3
execve("/usr/sbin/flash_unlock", ["flash_unlock", "/dev/mtd3"], [/* 16 vars */]) = 0
old_mmap(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000
readlink("/lib/ld-uClibc.so.0", "ld-uClibc-0.9.27.so", 1024) = 19
stat("/etc/ld.so.cache", 0xbeb236a0)    = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\22\0\000"..., 4096) = 4096
old_mmap(NULL, 61440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000d000
old_mmap(0x4000d000, 25188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4000d000
old_mmap(0x4001b000, 1032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x6000) = 0x4001b000
close(4)                                = 0
munmap(0x40006000, 4096)                = 0
open("/lib/libc.so.0", O_RDONLY)        = 4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40006000
read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\220\356\0"..., 4096) = 4096
old_mmap(NULL, 368640, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001c000
old_mmap(0x4001c000, 309464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4001c000
old_mmap(0x40070000, 5568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x4c000) = 0x40070000
old_mmap(0x40072000, 15824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40072000
close(4)                                = 0
mprotect(0x4001c000, 309464, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x40006000, 4096)                = 0
mprotect(0x4001c000, 309464, PROT_READ|PROT_EXEC) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
brk(0)                                  = 0x11000
brk(0x12000)                            = 0x12000
open("/dev/mtd3", O_RDWR)               = 4
ioctl(4, MTRRIOC_SET_ENTRY, 0xbeb23cfc) = 0
ioctl(4, MTRRIOC_SET_PAGE_ENTRY, 0xbeb23cf4) = -1071198208
write(2, "Could not unlock MTD device: ", 29Could not unlock MTD device: ) = 29
write(2, "/dev/mtd3", 9/dev/mtd3)                = 9
write(2, "\n", 1
)                       = 1
close(4)                                = 0
_exit(1)                                = ?

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

(no subject)

[James Strickland]

testing account

(no subject)

[Yasuyuki KOZAKAI]

Hi,

If CONFIG_NF_IP_CONNTRACK=y, CONFIG_NETFILTER_NETLINK=m, and
CONFIG_NF_CONNTRACK_NETLINK=m, it's failed to build kernel
of netfilter-2.6.14 git tree. Because __nfa_fill() in nfnetlink
called from ip_conntrack isn't built into kernel image in this case.
It's necessary to fix Kconfig or change source code to make dependencies
more simple.

BTW, the current relation between ip_conntrack, nfnetlink, and nfctnetlink
is complex. The following table is the patterns user can select.

ip_conntrack   | n n n n n n n n n m m m m m m m m m y y y y y y y y y
nfnetlink      | n n n m m m y y y n n n m m m y y y n n n m m m y y y
nfctnetlink    | n m y n m y n m y n m y n m y n m y n m y n m y n m y
-----------------------------------------------------------------------------
               | o x x o x x o x x o x x o o x o o x o x x o * x o o o

o: user can select and no error.
x: user can select.
*: user can select, but error.


Sorry, it's too difficult for me to fix Kconfig without complexity.
I think it's preferable that ip_conntrack doesn't depend on nfctnetlink.

Regars,

-----------------------------------------------------------------
Yasuyuki Kozakai @ USAGI Project <yasuyuki.kozakai@toshiba.co.jp>

(no subject)

[netfilter]

Hi,

I've been trying to apply Patrick McHardy's netfilter+ipsec patches to
my 
2.6.12-5 (from kernel.org) using patch-o-matic.  When I try to apply any
of 
the four patches I receive the following message:

patchlets/ipsec-01-output-hooks has dependency on nf_reset, but nf_reset
is 
not known

I've probably missed something obvious, but I've hit a dead end, any
help 
would be appreciated.  

Cheers,
Chris
-- 
  Chris Notley
  chris@notley.org

Re: (no subject)

[Daniel Lopes]

netfilter@notleyc.fastmail.fm schrieb:
> Hi,
> 
> I've been trying to apply Patrick McHardy's netfilter+ipsec patches to
> my 
> 2.6.12-5 (from kernel.org) using patch-o-matic.  When I try to apply any
> of 
> the four patches I receive the following message:
> 
> patchlets/ipsec-01-output-hooks has dependency on nf_reset, but nf_reset
> is 
> not known
> 
> I've probably missed something obvious, but I've hit a dead end, any
> help 
> would be appreciated.  
> 
> Cheers,
> Chris

I've read somewhere deleting the dependency in the info file should let 
apply the patch cleanly. The other hooks for example hook number x 
depend on the hook x-1. So if the 01 hook applies cleanly the others 
should do aswell.

Re: (no subject)

[Chris Notley]

On Thu, 25 Aug 2005 00:40:26 +0200, "Daniel Lopes" <lopsch@lopsch.com>
said:
> netfilter@notleyc.fastmail.fm schrieb:
> > Hi,
> > 
> > I've been trying to apply Patrick McHardy's netfilter+ipsec patches to
> > my 
> > 2.6.12-5 (from kernel.org) using patch-o-matic.  When I try to apply any
> > of 
> > the four patches I receive the following message:
> > 
> > patchlets/ipsec-01-output-hooks has dependency on nf_reset, but nf_reset
> > is 
> > not known
> > 
> > I've probably missed something obvious, but I've hit a dead end, any
> > help 
> > would be appreciated.  
> > 
> > Cheers,
> > Chris
> 
> I've read somewhere deleting the dependency in the info file should let 
> apply the patch cleanly. The other hooks for example hook number x 
> depend on the hook x-1. So if the 01 hook applies cleanly the others 
> should do aswell.
> 
Thanks Daniel, that did the trick!

Cheers,
Chris

(no subject)

[d1187e7720r]

(no subject)

[d1187e7720r]

(no subject)

[q0960m0638o]

(no subject)

[d1187e7720r]

(no subject)

[y5834i4926v]

(no subject)

[d1187e7720r]

(no subject)

[seohai]

(no subject)

[Armil]

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

(no subject)

[Mr.Derrick Tanner.]

(no subject)

[murasfdg sjhfsd]

 dear my friend
    i want details about ultrix file system and how optimizing unix file operations

thanks my friend bye-bye


-- 
India.com free e-mail - www.india.com. 
Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes!

Re: (no subject)

[Kaupo Arulo]

Ühel kenal päeval (pühapäev, 10. juuli 2005 15:40) kirjutas 樊亮:
> netfilter-devel:
>
> 	Our demand is like this now, a linux gateway, two network cards, one(eth0)
> is Intranet's  address 192. 168. 85. 1, the other
>
> (eth1) is extranet's address 202. 116. 93. 66, has tied 202 . 116. 83.
> 80-93 so many real address, Intranet is 192.168. 85.
>
> 10-23 so many timid address, require oneself write one netfilter module,
> make sure timid address and real address one-to-one
>
> correspondence. because in future  we will use ip address pool(about 4096
> ipaddresses) to assign real ip for user dynamicly,
>
> so we can't use systematic nat function.

I'm not sure, if I understood you correctly, but it seems that netmap patch 
from POM should help you.

-- 
Kaupo Arulo

(no subject)

[樊亮]

netfilter-devel:

	Our demand is like this now, a linux gateway, two network cards, one(eth0) is Intranet's  address 192. 168. 85. 1, the other

(eth1) is extranet's address 202. 116. 93. 66, has tied 202 . 116. 83. 80-93 so many real address, Intranet is 192.168. 85. 

10-23 so many timid address, require oneself write one netfilter module, make sure timid address and real address one-to-one 

correspondence. because in future  we will use ip address pool(about 4096 ipaddresses) to assign real ip for user dynamicly,  

so we can't use systematic nat function.

My method is that , at postroute hook ,if eth0,convert source ip to 202.116.93.*.at preroute hook,if eth1,convert des ip to 

192.168.85.*. I think it finish nat function  in theory like this , but  when i test this module ,it seems there is no 

forward packet, the checksum of tcp udp and ip has done .i whatto know  what is wrong with my idea, any idea will be 

appreciate.
　　　　　　　　
　　　　　　　　sendtofl@yahoo.com.cn
　　　　　　　　　　2005-07-10

(no subject)

[Igor Feoktistov]

Hi,

has anybody tried linux-iscsi-4.0.2 with linux-2.6.11-xen0?
scsi-transport-iscsi failed to compile due to different structure
definitions in scsi_transport_iscsi.h
Using scsi-transport-iscsi from linux-2.6.11-xen0 distro I was able
to open iscsi session. However, there is tons of kernel errors like below.
Any ideas how to cure it?
--
Jul  5 15:18:31 iscsi-rh4u1 kernel: SCSI device sdc: 73400320 512-byte hdwr sectors (375
Jul  5 15:18:31 iscsi-rh4u1 kernel: Badness in local_bh_enable at kernel/softirq.c:140  
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c011e495>] local_bh_enable+0x68/0x89             
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c896a742>] iscsi_queuecommand+0x173/0x1e3 [iscsi_
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c2f8>] scsi_dispatch_cmd+0x140/0x22e         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029c53a>] scsi_done+0x0/0x26                    
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029ebdb>] scsi_times_out+0x0/0xa0               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a19de>] scsi_request_fn+0x234/0x452           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0227bda>] __elv_add_request+0x84/0xb1           
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c022a708>] blk_insert_request+0xd7/0x104         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a05aa>] scsi_insert_special_req+0x3a/0x40     
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a07f2>] scsi_wait_req+0x69/0x9b               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a06ef>] scsi_wait_done+0x0/0x9a               
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c02a1e1d>] __scsi_mode_sense+0xc7/0x286          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0119be3>] vprintk+0x140/0x1b7                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fc98>] sd_read_cache_type+0x5f/0x216         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c029bce8>] scsi_allocate_request+0x28/0x62       
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ff48>] sd_revalidate_disk+0xf9/0x131         
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030fe4f>] sd_revalidate_disk+0x0/0x131          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c0185201>] rescan_partitions+0xdd/0x103          
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c030ea83>] sd_open+0x0/0xf0                      
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b05c>] do_open+0x2a7/0x390                   
Jul  5 15:18:31 iscsi-rh4u1 kernel:  [<c015b1c8>] blkdev_get+0x83/0x8e                  

(no subject)

[Brent Clark]

Hi List

I seem to have a problem whereby if I type the following commonds, I get 
the following output


gate:~# netstat-nat
Proto NATed Address                  Foreign Address                State
gate:~#

or when I use conntrack-viewer.pl

gate:~# conntrack-viewer.pl
Active Connections according to /proc/net/ip_conntrack
Proto   Source Address           Remote Address           Service 
State       Masq  Name Resolution
Use of uninitialized value in getservbyport at 
/usr/sbin/conntrack-viewer.pl line 114.
Use of uninitialized value in getservbyport at 
/usr/sbin/conntrack-viewer.pl line 115.
Use of uninitialized value in length at /usr/sbin/conntrack-viewer.pl 
line 128.


if I use  iptstate (this seems to work)
                                                              IPTables - 
State Top
Version: 1.3          Sort: SrcIP           s to change sorting
Source                                                 Destination 
                                       Proto   State        TTL
192.168.111.10,1114                                    192.168.111.11,53 
                                      udp                    0:01:33
192.168.111.10,1118                                    192.168.111.11,53 
                                      udp                    0:01:06
192.168.111.11,51146 
213.133.106.29,35520                                   tcp 
ESTABLISHED   98:43:17

I had a brief look at the /dev/net/ip_conntrack, and all seems fine there.

If anyone has any tips or advice, it would be most appreciated.

Kind Regards
Brent Clark

(no subject)

[Amit Sharma]

Hi 
I have problem in MTD driver with jFFS2 mounting on NAND device.During 
Cp -f /tmp/jffs2.image /dev/mtd/o
I get error
"page not aligned "

can any one help me in this problem

Thanks
Amit

Re: (no subject)

[Artem B. Bityuckiy]

On Sun, 2005-07-03 at 11:47 +0900, Amit Sharma wrote:
> Hi 
> I have problem in MTD driver with jFFS2 mounting on NAND device.During 
> Cp -f /tmp/jffs2.image /dev/mtd/o
> I get error
> "page not aligned "
> 
Don't use cp with NAND flash. Read the FAQ for more details.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

(no subject)

[董晓凡]

[-- Attachment #1.1: Type: text/plain, Size: 321 bytes --]

 

Hi，everybody.Recently,I focus on kernel 2.6.10,I want to migrate it to
mpc8260.

But,I can not compile it successfully when I choose fcc .And it seems some
wrong with cpm2_immap.h.

Would you like to tell me if it need a patch.

Thankyou very much!

**********************************************

 


[-- Attachment #1.2: Type: text/html, Size: 4265 bytes --]

[-- Attachment #2: image001.jpg --]
[-- Type: image/jpeg, Size: 4389 bytes --]

[-- Attachment #3: image002.gif --]
[-- Type: image/gif, Size: 7830 bytes --]

Re: (no subject)

[evilninja]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

董晓凡 schrieb:
>  
> 
> Hi，everybody.Recently,I focus on kernel 2.6.10,I want to migrate it to
> mpc8260.
> 
> But,I can not compile it successfully when I choose fcc .And it seems some
> wrong with cpm2_immap.h.

mind to show us the compile errors?

Christian.
PS: and *please* don't send HTML only messages.
- --
BOFH excuse #147:

Party-bug in the Aloha protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwsrXC/PVm5+NVoYRApx4AKDmCtqASeh3uRzoC1nO94k4LFlTmgCeKOc2
vbEH4lwXt/zZV+JhA0zwOxc=
=pk9/
-----END PGP SIGNATURE-----

(no subject)

[FLAMENT David]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

hello, 
 
I use a EP8248 and I search a Kernel 2.6 for this board because I use a kernel 2.4.26 of arabella and the usb isn't supported in this version.
When I compile with USB option ( uhci, scsi + usb mastorage), there is this message "usb-ohci currently requires PCI-based controllers".
If you have a sugget, thank you.
 
 
--------------------------------
Flament David
d.flament@sofrel.com
Lacroix Sofrel, 1 rue plessis, 35770 Vern sur seiche (France)
(+33)2.99.04.84.23
 
 

[-- Attachment #2: Type: text/html, Size: 1677 bytes --]

(no subject)

[Reiner Sailer]

> Message: 4
> Date: Sat, 25 Jun 2005 19:21:21 -0500
> From: Anthony Liguori <aliguori@us.ibm.com>
> Subject: Re: [Xen-devel] [PATCH] 1 of 2: default ssid to 0
> To: Stefan Berger <stefanb@us.ibm.com>
> Cc: xen-devel@lists.xensource.com
> Message-ID: <42BDF501.4090502@us.ibm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Please make sure to increment the DOM0_INTERFACE_VERSION when this is 
> committed.

Correct. The DOM0 interface treats "non-existing" ssidref configurations 
now
differently (sets them to 0 instead of ffffffff).

> 
> Anthony Liguori
> 
> Stefan Berger wrote:

Thanks
Reiner

(no subject)

[David L]

Hi,

I'm using a Nand flash driver on a Compulab board with a proprietary driver 
provided by Compulab.  I'd like to switch to a non-proprietary driver like 
MTD for a few reasons.  But having read through the MTD documentation, I'm 
not sure we can maintain our current boot strategy if we migrate to MTD.  
Right now, we boot to DOS that comes with the board and then use loadlin to 
boot a kernel/initial ramdisk that reside on a partition of the Nand flash 
that has a DOS filesystem on it.  On the rare event that we need to change 
the kernel or initial ramdisk, we mount the DOS filesystem from Linux and 
change the file.

Is there a way to maintain this strategy if we use MTD?  I saw in the NAND 
API document that only jffs2 and YAFFS filesystems can be used with MTD.  Is 
there any way around this? (I don't care how efficient it is).  And even if 
there is a workaround that would allow us to modify files in a DOS 
filesystem from Linux, will MTD partitions be visible from DOS so that we 
can boot in the first place?

Thanks...

                    David

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

(no subject)

[dierbro]

unsubscribe git

(no subject)

[faton kurteshi]

Hi
Does anybody know, why I'm getting this warning error or whatever
ip_conntrack_rtsp.c: help_out: ip_conntrack_expect_related failed (-17)
and what can be the consequences, should I use any patch or something else
I'm using gentoo with kernel version 2.4.26-gentoo-r13.

(no subject)

[colui77]

Hi guys, 
any of you knows a version of JVM running on Montavista linux for ML300
(PPC405)
I tried the Blackdown 1.3.1 for PPC but it doesn't seem to work...
Any suggestion?
Thanks,
Luigi

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id CE413FA1F

	for <buffer@sniffo.org>; Tue, 24 May 2005 03:30:17 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1QmF3031979;

	Mon, 23 May 2005 18:26:48 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:25:08 -0700 (PDT)

Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1P4F3031331

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:25:04 -0700

Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom

 SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:24:08 -0700

X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA

Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by

 mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID#

 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:24:07

 -0700

Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com

 [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP

 id AZY37732; Mon, 23 May 2005 18:24:07 -0700 (PDT)

Received: from nt-irva-0741.brcm.ad.broadcom.com (

 nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by

 mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16376; Mon, 23

 May 2005 18:24:06 -0700 (PDT)

Received: from 10.7.17.55 ([10.7.17.55]) by

 NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft

 Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:24:06 +0000

Received: from rh4 by nt-irva-0741; 23 May 2005 17:26:23 -0700

Subject: [PATCH 2/6] bnx2: Fix rx checksum

From: "Michael Chan" <mchan@broadcom.com>
To: davem@davemloft.net
Cc: jgarzik@pobox.com, netdev@oss.sgi.com
In-Reply-To: <1116892439.4908.1.camel@rh4>

References: <1116892439.4908.1.camel@rh4>

Date: Mon, 23 May 2005 17:26:23 -0700

Message-ID: <1116894383.4908.29.camel@rh4>

MIME-Version: 1.0

X-Mailer: Evolution 2.0.2 (2.0.2-3)

X-WSS-ID: 6E8C5DB21VO1443376-01-01

Content-Type: multipart/mixed;

 boundary="=-MjP9kNbfLluHpwDwIMre"

X-archive-position: 1531

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: mchan@broadcom.com

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean




--=-MjP9kNbfLluHpwDwIMre
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Fix bug in rx checksum by indicating CHECKSUM_UNNECESSARY only when the
hw calculated checksum is 0xffff.

Spotted by Jeff Garzik.

Signed-off-by: Michael Chan <mchan@broadcom.com>


--=-MjP9kNbfLluHpwDwIMre
Content-Disposition: attachment;
 filename=bnx2-12.patch
Content-Type: text/x-patch;
 charset=utf-8;
 name=bnx2-12.patch
Content-Transfer-Encoding: base64

ZGlmZiAtTnJ1IDExL2RyaXZlcnMvbmV0L2JueDIuYyAxMi9kcml2ZXJzL25ldC9ibngyLmMNCi0t
LSAxMS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyMDoyMC4wMDAwMDAwMDAgLTA3
MDANCisrKyAxMi9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyOTowMi4wMDAwMDAw
MDAgLTA3MDANCkBAIC0xNDcwLDkgKzE0NzAsOCBAQA0KIA0KIAkJCXUxNiBja3N1bSA9IHJ4X2hk
ci0+bDJfZmhkcl90Y3BfdWRwX3hzdW07DQogDQotCQkJaWYgKChja3N1bSA9PSAweGZmZmYpIHx8
IChja3N1bSA9PSAwKSkgew0KKwkJCWlmIChja3N1bSA9PSAweGZmZmYpDQogCQkJCXNrYi0+aXBf
c3VtbWVkID0gQ0hFQ0tTVU1fVU5ORUNFU1NBUlk7DQotCQkJfQ0KIAkJfQ0KIA0KICNpZmRlZiBC
Q01fVkxBTg0K


--=-MjP9kNbfLluHpwDwIMre--

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 346A4FA13

	for <buffer@sniffo.org>; Tue, 24 May 2005 03:28:34 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1ScF3000570;

	Mon, 23 May 2005 18:28:39 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:27:46 -0700 (PDT)

Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1RhF3032603

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:27:43 -0700

Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom

 SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:26:49 -0700

X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA

Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by

 mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID#

 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:26:48

 -0700

Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com

 [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP

 id AZY38167; Mon, 23 May 2005 18:26:47 -0700 (PDT)

Received: from nt-irva-0741.brcm.ad.broadcom.com (

 nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by

 mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16842; Mon, 23

 May 2005 18:26:47 -0700 (PDT)

Received: from 10.7.17.55 ([10.7.17.55]) by

 NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft

 Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:26:47 +0000

Received: from rh4 by nt-irva-0741; 23 May 2005 17:29:03 -0700

Subject: [PATCH 4/6] bnx2: Fix bug in bnx2_close

From: "Michael Chan" <mchan@broadcom.com>
To: davem@davemloft.net
Cc: jgarzik@pobox.com, netdev@oss.sgi.com
In-Reply-To: <1116892439.4908.1.camel@rh4>

References: <1116892439.4908.1.camel@rh4>

Date: Mon, 23 May 2005 17:29:03 -0700

Message-ID: <1116894543.4908.32.camel@rh4>

MIME-Version: 1.0

X-Mailer: Evolution 2.0.2 (2.0.2-3)

X-WSS-ID: 6E8C5D531VO1443816-01-01

Content-Type: multipart/mixed;

 boundary="=-kVtupVzl5sY8iZGVxtrc"

X-archive-position: 1533

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: mchan@broadcom.com

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean




--=-kVtupVzl5sY8iZGVxtrc
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Fix bug in bnx2_close() by calling flush_scheduled_work() since we are
using a work queue in netdev watchdog. Also added bnx2_netif_stop() call
in bnx2_close().

Spotted by Jeff Garzik.

Signed-off-by: Michael Chan <mchan@broadcom.com>


--=-kVtupVzl5sY8iZGVxtrc
Content-Disposition: attachment;
 filename=bnx2-14.patch
Content-Type: text/x-patch;
 charset=utf-8;
 name=bnx2-14.patch
Content-Transfer-Encoding: base64

ZGlmZiAtTnJ1IDEzL2RyaXZlcnMvbmV0L2JueDIuYyAxNC9kcml2ZXJzL25ldC9ibngyLmMNCi0t
LSAxMy9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDo1Nzo0MS4wMDAwMDAwMDAgLTA3
MDANCisrKyAxNC9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzowMTo0NS4wMDAwMDAw
MDAgLTA3MDANCkBAIC00MTcyLDcgKzQxNzIsOCBAQA0KIAlzdHJ1Y3QgYm54MiAqYnAgPSBkZXYt
PnByaXY7DQogCXUzMiByZXNldF9jb2RlOw0KIA0KLQlibngyX2Rpc2FibGVfaW50X3N5bmMoYnAp
Ow0KKwlmbHVzaF9zY2hlZHVsZWRfd29yaygpOw0KKwlibngyX25ldGlmX3N0b3AoYnApOw0KIAlk
ZWxfdGltZXJfc3luYygmYnAtPnRpbWVyKTsNCiAJaWYgKGJwLT53b2wpDQogCQlyZXNldF9jb2Rl
ID0gQk5YMl9EUlZfTVNHX0NPREVfU1VTUEVORF9XT0w7DQo=


--=-kVtupVzl5sY8iZGVxtrc--

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 8C315FB6B

	for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:41 +0200 (CEST)

Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

	id S261350AbVEXGeu (ORCPT <rfc822;chiakotay@nexlab.it>);

	Tue, 24 May 2005 02:34:50 -0400

Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261334AbVEXGeu

	(ORCPT <rfc822;linux-kernel-outgoing>);

	Tue, 24 May 2005 02:34:50 -0400

Received: from mail.dvmed.net ([216.237.124.58]:8141 "EHLO mail.dvmed.net")

	by vger.kernel.org with ESMTP id S261353AbVEXGep (ORCPT

	<rfc822;linux-kernel@vger.kernel.org>);

	Tue, 24 May 2005 02:34:45 -0400

Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])

	by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))

	id 1DaT00-0001Ow-FO; Tue, 24 May 2005 06:34:44 +0000

Message-ID: <4292CB01.6090506@pobox.com>

Date:	Tue, 24 May 2005 02:34:41 -0400

From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates

References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

Content-Type: text/plain; charset=us-ascii; format=flowed

Content-Transfer-Encoding: 7bit

X-Spam-Score: 0.0 (/)

Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

X-Mailing-List:	linux-kernel@vger.kernel.org



Linus Torvalds wrote:
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the

You really can't beat

	cp .git/refs/heads/master .git/refs/heads/new-branch

as the fastest way to create a new branch off the tip.

	Jeff

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 2366BFB72

	for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:46 +0200 (CEST)

Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

	id S261334AbVEXGsu (ORCPT <rfc822;chiakotay@nexlab.it>);

	Tue, 24 May 2005 02:48:50 -0400

Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261362AbVEXGst

	(ORCPT <rfc822;linux-kernel-outgoing>);

	Tue, 24 May 2005 02:48:49 -0400

Received: from fire.osdl.org ([65.172.181.4]:20097 "EHLO smtp.osdl.org")

	by vger.kernel.org with ESMTP id S261334AbVEXGsj (ORCPT

	<rfc822;linux-kernel@vger.kernel.org>);

	Tue, 24 May 2005 02:48:39 -0400

Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6])

	by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O6mWjA025872

	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);

	Mon, 23 May 2005 23:48:32 -0700

Received: from localhost (shell0.pdx.osdl.net [10.9.0.31])

	by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O6mVWw012672;

	Mon, 23 May 2005 23:48:31 -0700

Date:	Mon, 23 May 2005 23:50:36 -0700 (PDT)

From: Linus Torvalds <torvalds@osdl.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates

In-Reply-To: <4292CB01.6090506@pobox.com>

Message-ID: <Pine.LNX.4.58.0505232349020.2307@ppc970.osdl.org>

References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

 <4292CB01.6090506@pobox.com>

MIME-Version: 1.0

Content-Type: TEXT/PLAIN; charset=US-ASCII

X-Spam-Status: No, hits=0 required=5 tests=

X-Spam-Checker-Version:	SpamAssassin 2.63-osdl_revision__1.40__

X-MIMEDefang-Filter: osdl$Revision: 1.109 $

X-Scanned-By: MIMEDefang 2.36

Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

X-Mailing-List:	linux-kernel@vger.kernel.org





On Tue, 24 May 2005, Jeff Garzik wrote:
> 
> You really can't beat
> 
> 	cp .git/refs/heads/master .git/refs/heads/new-branch
> 
> as the fastest way to create a new branch off the tip.

So? It's the fastest, but it's also BROKEN. Exactly because the way you do 
things, the merge messages are meaningless.

So fix your merge messages. 

		Linus

(no subject)

[Joni Sawyer]

[-- Attachment #1: Type: text/html, Size: 5825 bytes --]

(no subject)

[Jesse DeFer]

subscribe kernel-janitors

(no subject)

[Curtis Lehman]

Hi,

	I have been trying to load the latest RPM modules for hotplug but I have run into a problem with the rpm manager. It won't seem to install the latest hotplug rpm packages. I think it has something to do with the fact that they have been broken out to two packages. I am running on Redhat 9.0. I have tried searching through the hotplug developers mailing list, but know one seems to have had this problem before.  I am not real strong in the RPM usage department, so I would appreciate any suggestions on how to get the package installed. I was afraid to force the removal of the old package given the dependencies. Below is an output of what I have tried.

Thanks,
Curt

[root@localhost hotplug]# uname -a
Linux localhost.localdomain 2.4.20-13.9 #1 Mon May 12 10:55:37 EDT 2003 i686 i686 i386 GNU/Linux

[root@localhost hotplug]# rpm -v -i hotplug-2003_05_01-1.noarch.rpm
warning: hotplug-2003_05_01-1.noarch.rpm: V3 DSA signature: NOKEY, key ID db2dfb29
error: Failed dependencies:
        hotplug-base >= 2003_05_01 is needed by hotplug-2003_05_01-1

[root@localhost hotplug]# rpm -v -i hotplug-base-2003_05_01-1.noarch.rpm
warning: hotplug-base-2003_05_01-1.noarch.rpm: V3 DSA signature: NOKEY, key ID db2dfb29
Preparing packages for installation...
        file /sbin/hotplug from install of hotplug-base-2003_05_01-1 conflicts with file from package hotplug-2002_04_01-17

[root@localhost hotplug]# rpm -v -q hotplug
hotplug-2002_04_01-17

[root@localhost hotplug]# rpm -v -e hotplug-2002_04_01-17
error: Failed dependencies:
        hotplug >= 2001_04_24-9 is needed by (installed) kernel-pcmcia-cs-3.1.31-13
        hotplug >= 2001_04_24-13 is needed by (installed) gphoto2-2.1.0-7




-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

(no subject)

[Rajat Jain]

Hi,

I'm using 2.6 Kernel. I'm having a (Hot-pluggable)
Qlogic HBA plugged into a PCI Express Slot. 

I want to fake an hot-unplug event for this HBA,
without physically removing it from the slot.
Basically what I want is that while the HBA is still
physically present at the slot, I want to fire a
command / program that would fake the hot-unplug event
for this slot, and thus will deregister the HBA from
Linux. Ideally, I want to do this from userspace. But
if it is not possible, then I can go for a kernel
module as well.

I think that this feature was made available by "Fake
PCI Hot plug controller Driver", but I believe that
can only be used if my system does not have REAL
hot-plugging slots. Can "Fake PCI Hot-plug Controller
Driver" and "PCI Express Hot-plug Controller Driver"
Co-exist ??? (So that I can manually give fake unplug
event and THEN remove the device; While hot-plugging,
I want PCI Express HPC driver to take care of every
thing)

Is it possible to do what I am trying to do?

TIA,

Rajat



		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

(no subject)

[shubhrangam]

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

(no subject)

[Fabrice MARIE]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]


Hello,

Attached patch should fix the tftp conntrack patch to
make it apply properly again.

Have a nice day,

Fabrice.

http://fabnetwork.ifrance.com/fabnetwork/
--
Fabrice MARIE
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/

"Silly hacker, root is for administrators"
       -Unknown

[-- Attachment #2: conntrack_tftp_patch_makefile_fix.patch --]
[-- Type: text/x-diff, Size: 496 bytes --]

diff -uNr cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3 netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3
--- cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-04-15 19:33:13.000000000 +0800
+++ netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-07-04 18:43:00.000000000 +0800
@@ -1,2 +1,2 @@
-# NAT helpers
+# NAT helpers 
 obj-$(CONFIG_IP_NF_NAT_TFTP) += ip_nat_tftp.o

Re: (no subject)

[Amin Azez]

Fabrice MARIE wrote:
> Hello,
> 
> Attached patch should fix the tftp conntrack patch to
> make it apply properly again.
...
> ------------------------------------------------------------------------
> 
> diff -uNr cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3 netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3
> --- cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-04-15 19:33:13.000000000 +0800
> +++ netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-07-04 18:43:00.000000000 +0800
> @@ -1,2 +1,2 @@
> -# NAT helpers
> +# NAT helpers 
>  obj-$(CONFIG_IP_NF_NAT_TFTP) += ip_nat_tftp.o

Does this patch actually do anything?

Sam

Re: (no subject)

[Samuel Liddicott]

Why am I replying to 3 year old posts?

Saaid Kahn's recent "no subject" post caused Thunderbird to artificially
thread all the other "no subject" posts of the past onto it so I thought
they were recent.
Foolish Thunderbird, foolish me.

Apologies.

Sam

Amin Azez wrote:

>Fabrice MARIE wrote:
>  
>
>>Hello,
>>
>>Attached patch should fix the tftp conntrack patch to
>>make it apply properly again.
>>    
>>
>...
>  
>
>>------------------------------------------------------------------------
>>
>>diff -uNr cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3 netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3
>>--- cvs/netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-04-15 19:33:13.000000000 +0800
>>+++ netfilter/userspace/patch-o-matic/extra/tftp-conntrack-nat.patch.makefile-3	2002-07-04 18:43:00.000000000 +0800
>>@@ -1,2 +1,2 @@
>>-# NAT helpers
>>+# NAT helpers 
>> obj-$(CONFIG_IP_NF_NAT_TFTP) += ip_nat_tftp.o
>>    
>>
>
>Does this patch actually do anything?
>
>Sam
>
>  
>