Re: [PATCH] ia64: check-segrel.lds vs --build-id

2007-10-25 Thread Doug Chapman
On Thu, 2007-10-18 at 12:54 -0700, Roland McGrath wrote: > Some versions of ld with --build-id support will crash when using the flag > with a linker script that discards notes. This bites ia64's check-segrel.lds. > The bug is easy to avoid. > > Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>

Re: [PATCH] ia64 vDSO vs --build-id

2007-10-25 Thread Doug Chapman
On Thu, 2007-10-18 at 15:11 -0700, Roland McGrath wrote: > When gcc uses --build-id by default, the gate.lds.S linker script runs afoul > of the new note section and produces a bad DSO image. This fixes it. > > Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> > > ---

Re: [PATCH] ia64 vDSO vs --build-id

2007-10-25 Thread Doug Chapman
On Thu, 2007-10-18 at 15:11 -0700, Roland McGrath wrote: When gcc uses --build-id by default, the gate.lds.S linker script runs afoul of the new note section and produces a bad DSO image. This fixes it. Signed-off-by: Roland McGrath [EMAIL PROTECTED] --- a/arch/ia64/kernel/gate.lds.S +++

Re: [PATCH] ia64: check-segrel.lds vs --build-id

2007-10-25 Thread Doug Chapman
On Thu, 2007-10-18 at 12:54 -0700, Roland McGrath wrote: Some versions of ld with --build-id support will crash when using the flag with a linker script that discards notes. This bites ia64's check-segrel.lds. The bug is easy to avoid. Signed-off-by: Roland McGrath [EMAIL PROTECTED] ---

RE: regression on HP zx1 platform from ACPI autoload modulespatches

2007-07-31 Thread Doug Chapman
On Tue, 2007-07-31 at 09:29 -0700, Luck, Tony wrote: > > commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7 > > Oops. I cut & pasted the wrong commit id. The fix went in as > commit 7091138fb762aed22317b4ff91eb211e7da3865c. > > > FYI, I did a git pull yesterday just before I hit this issue so I

Re: regression on HP zx1 platform from ACPI autoload modules patches - PATCH that fixes it

2007-07-31 Thread Doug Chapman
On Tue, 2007-07-31 at 15:01 +0200, Thomas Renninger wrote: > On Tue, 2007-07-31 at 08:06 -0400, Doug Chapman wrote: > > On Tue, 2007-07-31 at 01:07 +0200, Michal Piotrowski wrote: > > > Hi Doug, > > > > > > On 31/07/07, Doug Chapman <[EMAIL PROTECTED]&g

Re: regression on HP zx1 platform from ACPI autoload modules patches

2007-07-31 Thread Doug Chapman
On Mon, 2007-07-30 at 22:12 -0700, Tony Luck wrote: > > > During bootup it panics with: > > > > > > Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or > > > DIG kernel > > I think that the fix for this has already gone into Linus's tree (on > Friday). Commit SHA1 > for the

Re: regression on HP zx1 platform from ACPI autoload modules patches

2007-07-31 Thread Doug Chapman
On Mon, 2007-07-30 at 22:12 -0700, Tony Luck wrote: During bootup it panics with: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel I think that the fix for this has already gone into Linus's tree (on Friday). Commit SHA1 for the patch that should

Re: regression on HP zx1 platform from ACPI autoload modules patches - PATCH that fixes it

2007-07-31 Thread Doug Chapman
On Tue, 2007-07-31 at 15:01 +0200, Thomas Renninger wrote: On Tue, 2007-07-31 at 08:06 -0400, Doug Chapman wrote: On Tue, 2007-07-31 at 01:07 +0200, Michal Piotrowski wrote: Hi Doug, On 31/07/07, Doug Chapman [EMAIL PROTECTED] wrote: I am seeing a regression on the HP ia64 zx1

RE: regression on HP zx1 platform from ACPI autoload modulespatches

2007-07-31 Thread Doug Chapman
On Tue, 2007-07-31 at 09:29 -0700, Luck, Tony wrote: commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7 Oops. I cut pasted the wrong commit id. The fix went in as commit 7091138fb762aed22317b4ff91eb211e7da3865c. FYI, I did a git pull yesterday just before I hit this issue so I should

regression on HP zx1 platform from ACPI autoload modules patches

2007-07-30 Thread Doug Chapman
I am seeing a regression on the HP ia64 zx1 platforms when using a .config with CONFIG_IA64_HP_ZX1=y. Oddly it works OK with CONFIG_IA64_GENERIC=y. During bootup it panics with: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel I can provide the full console

regression on HP zx1 platform from ACPI autoload modules patches

2007-07-30 Thread Doug Chapman
I am seeing a regression on the HP ia64 zx1 platforms when using a .config with CONFIG_IA64_HP_ZX1=y. Oddly it works OK with CONFIG_IA64_GENERIC=y. During bootup it panics with: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel I can provide the full console

RE: [PATCH] ia64: fix build failure on fs/quota.c

2007-07-26 Thread Doug Chapman
On Thu, 2007-07-26 at 14:24 -0700, Luck, Tony wrote: > This issue wandered off onto a long thread "build fix for x86_64" which > died out without a final patch. Here's the summary: > Ahh, thanks, I had not seen that thread. > > +#if defined(CONFIG_X86_64) || (defined(CONFIG_IA64) && > >

Re: [PATCH] ia64: fix build failure on fs/quota.c

2007-07-26 Thread Doug Chapman
On Thu, 2007-07-19 at 13:15 -0400, Doug Chapman wrote: > Fix ia64 build failure on fs/qutoa.c. A recent patch used the > type compat_u64 which on ia64 is only available if CONFIG_COMPAT > is defined. > > > From: Tony Luck <[EMAIL PROTECTED]> > Signed-off-by: Dou

RE: [PATCH] ia64: fix build failure on fs/quota.c

2007-07-26 Thread Doug Chapman
On Thu, 2007-07-26 at 14:24 -0700, Luck, Tony wrote: This issue wandered off onto a long thread build fix for x86_64 which died out without a final patch. Here's the summary: Ahh, thanks, I had not seen that thread. +#if defined(CONFIG_X86_64) || (defined(CONFIG_IA64)

Re: [PATCH] ia64: fix build failure on fs/quota.c

2007-07-26 Thread Doug Chapman
On Thu, 2007-07-19 at 13:15 -0400, Doug Chapman wrote: Fix ia64 build failure on fs/qutoa.c. A recent patch used the type compat_u64 which on ia64 is only available if CONFIG_COMPAT is defined. From: Tony Luck [EMAIL PROTECTED] Signed-off-by: Doug Chapman [EMAIL PROTECTED

[PATCH] ia64: fix build failure on fs/quota.c

2007-07-19 Thread Doug Chapman
Fix ia64 build failure on fs/qutoa.c. A recent patch used the type compat_u64 which on ia64 is only available if CONFIG_COMPAT is defined. From: Tony Luck <[EMAIL PROTECTED]> Signed-off-by: Doug Chapman <[EMAIL PROTECTED]> -- --- a/fs/quota.c +++ b/fs/quota.c @@ -387,7 +387,7 @

[PATCH] ia64: fix build failure on fs/quota.c

2007-07-19 Thread Doug Chapman
Fix ia64 build failure on fs/qutoa.c. A recent patch used the type compat_u64 which on ia64 is only available if CONFIG_COMPAT is defined. From: Tony Luck [EMAIL PROTECTED] Signed-off-by: Doug Chapman [EMAIL PROTECTED] -- --- a/fs/quota.c +++ b/fs/quota.c @@ -387,7 +387,7 @@ asmlinkage long

RE: ia64 build failure from recent diskquota patch

2007-07-18 Thread Doug Chapman
On Wed, 2007-07-18 at 14:45 -0700, Luck, Tony wrote: > > The type compat_u64 on ia64 is defined if CONFIG_COMPAT is defined > > (which is rare these days on ia64) So, it appears we are missing > > an #ifdef CONFIG_COMPAT somewhere in fs/quota.c. I will leave that > > up to the original author to

ia64 build failure from recent diskquota patch

2007-07-18 Thread Doug Chapman
The commit: b716395e2b8e450e294537de0c91476ded2f0395 introduces a build failure on ia64. CC fs/quota.o fs/quota.c:396: error: expected specifier-qualifier-list before ‘compat_u64’ fs/quota.c:409: error: expected specifier-qualifier-list before ‘compat_u64’ fs/quota.c:420: error: expected

ia64 build failure from recent diskquota patch

2007-07-18 Thread Doug Chapman
The commit: b716395e2b8e450e294537de0c91476ded2f0395 introduces a build failure on ia64. CC fs/quota.o fs/quota.c:396: error: expected specifier-qualifier-list before ‘compat_u64’ fs/quota.c:409: error: expected specifier-qualifier-list before ‘compat_u64’ fs/quota.c:420: error: expected

RE: ia64 build failure from recent diskquota patch

2007-07-18 Thread Doug Chapman
On Wed, 2007-07-18 at 14:45 -0700, Luck, Tony wrote: The type compat_u64 on ia64 is defined if CONFIG_COMPAT is defined (which is rare these days on ia64) So, it appears we are missing an #ifdef CONFIG_COMPAT somewhere in fs/quota.c. I will leave that up to the original author to

Re: [PATCH] locks: fix F_GETLK regression (failure to find conflicts)

2007-05-10 Thread Doug Chapman
own locking). > > Also fix posix_lock_to_flock() to copy the lock type. This isn't > strictly necessary, since the caller already does this; but it seems > less likely to cause confusion in the future. > > Thanks to Doug Chapman for the bug report. > > Signed-off-by: "

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 16:23 -0400, J. Bruce Fields wrote: > On Thu, May 10, 2007 at 03:38:59PM -0400, bfields wrote: > > On Thu, May 10, 2007 at 03:30:50PM -0400, bfields wrote: > > > On Thu, May 10, 2007 at 02:56:15PM -0400, Doug Chapman wrote: > > > > A recent regre

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 15:38 -0400, J. Bruce Fields wrote: > On Thu, May 10, 2007 at 03:30:50PM -0400, bfields wrote: > > On Thu, May 10, 2007 at 02:56:15PM -0400, Doug Chapman wrote: > > > A recent regression (introduced after 2.6.21) was caught by the LTP test > >

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 14:56 -0400, Doug Chapman wrote: > A recent regression (introduced after 2.6.21) was caught by the LTP test > fcntl11. It appears that F_GETLK is not properly checking for existing > F_RDLCK and allows taking out a write lock. > > This can be demonstrated by

post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
A recent regression (introduced after 2.6.21) was caught by the LTP test fcntl11. It appears that F_GETLK is not properly checking for existing F_RDLCK and allows taking out a write lock. This can be demonstrated by either running fcntl11 from the LTP suite or I have hacked up a much shorter

post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
A recent regression (introduced after 2.6.21) was caught by the LTP test fcntl11. It appears that F_GETLK is not properly checking for existing F_RDLCK and allows taking out a write lock. This can be demonstrated by either running fcntl11 from the LTP suite or I have hacked up a much shorter

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 14:56 -0400, Doug Chapman wrote: A recent regression (introduced after 2.6.21) was caught by the LTP test fcntl11. It appears that F_GETLK is not properly checking for existing F_RDLCK and allows taking out a write lock. This can be demonstrated by either running

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 15:38 -0400, J. Bruce Fields wrote: On Thu, May 10, 2007 at 03:30:50PM -0400, bfields wrote: On Thu, May 10, 2007 at 02:56:15PM -0400, Doug Chapman wrote: A recent regression (introduced after 2.6.21) was caught by the LTP test fcntl11. It appears that F_GETLK

Re: post 2.6.21 regression in F_GETLK

2007-05-10 Thread Doug Chapman
On Thu, 2007-05-10 at 16:23 -0400, J. Bruce Fields wrote: On Thu, May 10, 2007 at 03:38:59PM -0400, bfields wrote: On Thu, May 10, 2007 at 03:30:50PM -0400, bfields wrote: On Thu, May 10, 2007 at 02:56:15PM -0400, Doug Chapman wrote: A recent regression (introduced after 2.6.21

Re: [PATCH] locks: fix F_GETLK regression (failure to find conflicts)

2007-05-10 Thread Doug Chapman
posix_lock_to_flock() to copy the lock type. This isn't strictly necessary, since the caller already does this; but it seems less likely to cause confusion in the future. Thanks to Doug Chapman for the bug report. Signed-off-by: J. Bruce Fields [EMAIL PROTECTED] --- fs/locks.c |5 +++-- 1 files