subject:"Re\: 2.6.11\-rc5"

* Jeff Dike ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] said:
> > Thanks, I'll push that with rest of audit changes.
> 
> Applies on top of your changes.
> 
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1: reiser4 panic

Am Freitag, 4. März 2005 02:16 schrieb Alexander Gran:
> Hi,
>
> after my external USB hdd disconnected itself reiser4 paniced. I dont think
> a journalingfs should panic if its device fails..

Ähm correction: It's reiser4 on dm-crypto (aes) The crypto device is of cource 
not radable either: Buffer I/O error on device dm-0, logical block 7
scsi2 (0:0): rejecting I/O to dead device
Strangely enough, there were no "Buffer I/O error on device dm-0, logical 
block 7" mesages in demsg before reiser4 paniced

Alex
-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

[EMAIL PROTECTED] said:
> Thanks, I'll push that with rest of audit changes.

Applies on top of your changes.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: linux-2.6.10/arch/um/kernel/ptrace.c
===
--- linux-2.6.10.orig/arch/um/kernel/ptrace.c   2005-03-03 11:41:34.0 
-0500
+++ linux-2.6.10/arch/um/kernel/ptrace.c2005-03-03 11:42:41.0 
-0500
@@ -341,11 +341,15 @@
 
if (unlikely(current->audit_context)) {
if (!entryexit)
-   audit_syscall_entry(current, regs->orig_eax,
-   regs->ebx, regs->ecx,
-   regs->edx, regs->esi);
+   audit_syscall_entry(current, 
+   UPT_SYSCALL_NR(>regs),
+   UPT_SYSCALL_ARG1(>regs),
+   UPT_SYSCALL_ARG2(>regs),
+   UPT_SYSCALL_ARG3(>regs),
+   UPT_SYSCALL_ARG4(>regs));
else
-   audit_syscall_exit(current, regs->eax);
+   audit_syscall_exit(current, 
+  UPT_SYSCALL_RET(>regs));
}
 
/* Fake a debug trap */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

* Jeff Dike ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] said:
> > I just did a more complete grep of the symbols that can get config'd
> > away (including CONFIG_AUDIT as well), and I think there's a few more
> > missing pieces.  Sorry about that.  Jeff, Ralf, Martin, these look ok?
> 
> For UML, this is fine as far as it goes, but you're adding register references
> to arch-independent code, so this is needed as well:

Thanks, I'll push that with rest of audit changes.  Mind adding a
Signed-off-by?

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

[EMAIL PROTECTED] said:
> I just did a more complete grep of the symbols that can get config'd
> away (including CONFIG_AUDIT as well), and I think there's a few more
> missing pieces.  Sorry about that.  Jeff, Ralf, Martin, these look ok?

For UML, this is fine as far as it goes, but you're adding register references
to arch-independent code, so this is needed as well:

Index: linux-2.6.10/arch/um/kernel/ptrace.c
===
--- linux-2.6.10.orig/arch/um/kernel/ptrace.c   2005-03-03 00:14:46.0 
-0500
+++ linux-2.6.10/arch/um/kernel/ptrace.c2005-03-03 00:22:58.0 
-0500
@@ -340,11 +341,15 @@
 
if (unlikely(current->audit_context)) {
if (!entryexit)
-   audit_syscall_entry(current, regs->orig_eax,
-   regs->ebx, regs->ecx,
-   regs->edx, regs->esi);
+   audit_syscall_entry(current, 
+   UPT_SYSCALL_NR(>regs),
+   UPT_SYSCALL_ARG1(>regs),
+   UPT_SYSCALL_ARG2(>regs),
+   UPT_SYSCALL_ARG3(>regs),
+   UPT_SYSCALL_ARG4(>regs));
else
-   audit_syscall_exit(current, regs->eax);
+   audit_syscall_exit(current, 
+  UPT_SYSCALL_RET(>regs));
}
 
/* Fake a debug trap */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 reiser4,USB,crpyto: Something BAD happend

Am Donnerstag, 3. März 2005 09:12 schrieb Vladimir Saveliev:
> > http://zodiac.dnsalias.org/misc/crashlog
>
> I get "You do not have permission to access this document." trying to
> access it.

wrong file permissions. fixxed by now. My mistake...

regards
Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 nfs oddity, file creation => "no such file"

2005-03-03 Thread Helge Hafting

Andrew Morton wrote:
Helge Hafting <[EMAIL PROTECTED]> wrote:
 

I observed an oddity on a nfs-mounted fs while using 2.6.11-rc5-mm1.
   

Could you try this please?
--- 25/fs/nfs/nfs3proc.c~nfsacl-acl-umask-handling-workaround-in-nfs-client-fix 
2005-03-02 08:49:59.0 -0800
+++ 25-akpm/fs/nfs/nfs3proc.c   2005-03-02 08:49:59.0 -0800
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
out:
return ERR_PTR(status);
_
 

"cat > some_new_file" worked fine on NFS with this patch.  I'll keep using
nfs at work with this.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-03 Thread AurÃlien Francillon

Andreas Gruenbacher wrote:
Hello,
On Wed, 2005-03-02 at 09:53, Andrew Morton wrote:
AurÃlien Francillon <[EMAIL PROTECTED]> wrote:
[...]
cvs diff Makefile 
cvs diff: cannot create read lock in repository 
`/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
cvs [diff aborted]: read lock failed - giving up

but the file is created and i can "cat " it without problem ...

This fixes it:

yes, no more problems with nfs
thank you !
AurÃlien
--
Lat: 45:11:43N (45.1954)
Lon:  5:43:36E ( 5.7268)


signature.asc
Description: OpenPGP digital signature

Re: 2.6.11-rc5-mm1 reiser4,USB,crpyto: Something BAD happend

2005-03-03 Thread Vladimir Saveliev

Hello

On Wed, 2005-03-02 at 21:32, Alexander Gran wrote:
> Hi,
> 
> Whatever happens here, we need - at least - lower 
> the amount of log generatet. This is not really handy...
> lsusb still lists the disk
> syslog can be found (as soon as syslogd finished...;) at
> http://zodiac.dnsalias.org/misc/crashlog

I get "You do not have permission to access this document." trying to
access it.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

* Jeff Dike ([EMAIL PROTECTED]) wrote:
 [EMAIL PROTECTED] said:
  Thanks, I'll push that with rest of audit changes.
 
 Applies on top of your changes.
 
 Signed-off-by: Jeff Dike [EMAIL PROTECTED]

Thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1: reiser4 panic

2005-03-03 Thread Matt Mackall

On Fri, Mar 04, 2005 at 02:16:56AM +0100, Alexander Gran wrote:
 Hi,
 
 after my external USB hdd disconnected itself reiser4 paniced. I dont think a 
 journalingfs should panic if its device fails..

Panicking is sometimes what you want. Panic can trigger a reboot and
get the box back on its feet quickly.

But going read-only on errors is a more sensible default policy,
especially if you have other unrelated activities going on.
Ext2 and ext3 have such an option.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 reiser4,USB,crpyto: Something BAD happend

2005-03-03 Thread Vladimir Saveliev

Hello

On Wed, 2005-03-02 at 21:32, Alexander Gran wrote:
 Hi,
 
 Whatever happens here, we need - at least - lower 
 the amount of log generatet. This is not really handy...
 lsusb still lists the disk
 syslog can be found (as soon as syslogd finished...;) at
 http://zodiac.dnsalias.org/misc/crashlog

I get You do not have permission to access this document. trying to
access it.



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-03 Thread Aurlien Francillon

Andreas Gruenbacher wrote:
Hello,
On Wed, 2005-03-02 at 09:53, Andrew Morton wrote:
Aurlien Francillon [EMAIL PROTECTED] wrote:
[...]
cvs diff Makefile 
cvs diff: cannot create read lock in repository 
`/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
cvs [diff aborted]: read lock failed - giving up

but the file is created and i can cat  it without problem ...

This fixes it:

yes, no more problems with nfs
thank you !
Aurlien
--
Lat: 45:11:43N (45.1954)
Lon:  5:43:36E ( 5.7268)


signature.asc
Description: OpenPGP digital signature

Re: 2.6.11-rc5-mm1 nfs oddity, file creation = no such file

2005-03-03 Thread Helge Hafting

Andrew Morton wrote:
Helge Hafting [EMAIL PROTECTED] wrote:
 

I observed an oddity on a nfs-mounted fs while using 2.6.11-rc5-mm1.
   

Could you try this please?
--- 25/fs/nfs/nfs3proc.c~nfsacl-acl-umask-handling-workaround-in-nfs-client-fix 
2005-03-02 08:49:59.0 -0800
+++ 25-akpm/fs/nfs/nfs3proc.c   2005-03-02 08:49:59.0 -0800
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
out:
return ERR_PTR(status);
_
 

cat  some_new_file worked fine on NFS with this patch.  I'll keep using
nfs at work with this.
Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 reiser4,USB,crpyto: Something BAD happend

Am Donnerstag, 3. März 2005 09:12 schrieb Vladimir Saveliev:
  http://zodiac.dnsalias.org/misc/crashlog

 I get You do not have permission to access this document. trying to
 access it.

wrong file permissions. fixxed by now. My mistake...

regards
Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

[EMAIL PROTECTED] said:
 I just did a more complete grep of the symbols that can get config'd
 away (including CONFIG_AUDIT as well), and I think there's a few more
 missing pieces.  Sorry about that.  Jeff, Ralf, Martin, these look ok?

For UML, this is fine as far as it goes, but you're adding register references
to arch-independent code, so this is needed as well:

Index: linux-2.6.10/arch/um/kernel/ptrace.c
===
--- linux-2.6.10.orig/arch/um/kernel/ptrace.c   2005-03-03 00:14:46.0 
-0500
+++ linux-2.6.10/arch/um/kernel/ptrace.c2005-03-03 00:22:58.0 
-0500
@@ -340,11 +341,15 @@
 
if (unlikely(current-audit_context)) {
if (!entryexit)
-   audit_syscall_entry(current, regs-orig_eax,
-   regs-ebx, regs-ecx,
-   regs-edx, regs-esi);
+   audit_syscall_entry(current, 
+   UPT_SYSCALL_NR(regs-regs),
+   UPT_SYSCALL_ARG1(regs-regs),
+   UPT_SYSCALL_ARG2(regs-regs),
+   UPT_SYSCALL_ARG3(regs-regs),
+   UPT_SYSCALL_ARG4(regs-regs));
else
-   audit_syscall_exit(current, regs-eax);
+   audit_syscall_exit(current, 
+  UPT_SYSCALL_RET(regs-regs));
}
 
/* Fake a debug trap */

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

* Jeff Dike ([EMAIL PROTECTED]) wrote:
 [EMAIL PROTECTED] said:
  I just did a more complete grep of the symbols that can get config'd
  away (including CONFIG_AUDIT as well), and I think there's a few more
  missing pieces.  Sorry about that.  Jeff, Ralf, Martin, these look ok?
 
 For UML, this is fine as far as it goes, but you're adding register references
 to arch-independent code, so this is needed as well:

Thanks, I'll push that with rest of audit changes.  Mind adding a
Signed-off-by?

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

[EMAIL PROTECTED] said:
 Thanks, I'll push that with rest of audit changes.

Applies on top of your changes.

Signed-off-by: Jeff Dike [EMAIL PROTECTED]

Index: linux-2.6.10/arch/um/kernel/ptrace.c
===
--- linux-2.6.10.orig/arch/um/kernel/ptrace.c   2005-03-03 11:41:34.0 
-0500
+++ linux-2.6.10/arch/um/kernel/ptrace.c2005-03-03 11:42:41.0 
-0500
@@ -341,11 +341,15 @@
 
if (unlikely(current-audit_context)) {
if (!entryexit)
-   audit_syscall_entry(current, regs-orig_eax,
-   regs-ebx, regs-ecx,
-   regs-edx, regs-esi);
+   audit_syscall_entry(current, 
+   UPT_SYSCALL_NR(regs-regs),
+   UPT_SYSCALL_ARG1(regs-regs),
+   UPT_SYSCALL_ARG2(regs-regs),
+   UPT_SYSCALL_ARG3(regs-regs),
+   UPT_SYSCALL_ARG4(regs-regs));
else
-   audit_syscall_exit(current, regs-eax);
+   audit_syscall_exit(current, 
+  UPT_SYSCALL_RET(regs-regs));
}
 
/* Fake a debug trap */

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1: reiser4 panic

Am Freitag, 4. März 2005 02:16 schrieb Alexander Gran:
 Hi,

 after my external USB hdd disconnected itself reiser4 paniced. I dont think
 a journalingfs should panic if its device fails..

Ähm correction: It's reiser4 on dm-crypto (aes) The crypto device is of cource 
not radable either: Buffer I/O error on device dm-0, logical block 7
scsi2 (0:0): rejecting I/O to dead device
Strangely enough, there were no Buffer I/O error on device dm-0, logical 
block 7 mesages in demsg before reiser4 paniced

Alex
-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 nfs oddity, file creation => "no such file"

Helge Hafting <[EMAIL PROTECTED]> wrote:
>
> I observed an oddity on a nfs-mounted fs while using 2.6.11-rc5-mm1.

Could you try this please?

--- 25/fs/nfs/nfs3proc.c~nfsacl-acl-umask-handling-workaround-in-nfs-client-fix 
2005-03-02 08:49:59.0 -0800
+++ 25-akpm/fs/nfs/nfs3proc.c   2005-03-02 08:49:59.0 -0800
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: 2.6.11-rc5-mm1

2005-03-02 Thread Dominik Brodowski

On Tue, Mar 01, 2005 at 11:57:03AM +0100, Alexander Gran wrote:
> Am Dienstag, 1. März 2005 11:48 schrieb Andrew Morton:
> > Alex, please use mailing lists...
> 
> sorry, I was used to have reply-to set to the mailing list ;) 
> double-checking next time..
> 
> > Dominik, do we really always want to drag in the firmware loader if
> > CONFIG_PCMCIA?
> 
> Hmm. I've enabled the firmware loader that fixes at least the compile error...
> Now rebooting. More info after my system programming exam in 1 hour. ;)

Updated patch submitted -- see

http://lists.infradead.org/pipermail/linux-pcmcia/2005-March/001580.html

Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-02 Thread Andreas Gruenbacher

Hello,

On Wed, 2005-03-02 at 09:53, Andrew Morton wrote:
> AurÃlien Francillon <[EMAIL PROTECTED]> wrote:
> > [...]
> > cvs diff Makefile 
> >  cvs diff: cannot create read lock in repository 
> > `/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
> > cvs [diff aborted]: read lock failed - giving up
> > 
> > but the file is created and i can "cat " it without problem ...

This fixes it:

Index: linux-2.6.11/fs/nfs/nfs3proc.c
===
--- linux-2.6.11.orig/fs/nfs/nfs3proc.c
+++ linux-2.6.11/fs/nfs/nfs3proc.c
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);

I'll reply to this message with an updated patch:

  Re: [nfsacl v2 15/16] ACL umask handling workaround in nfs client

Regards,
-- 
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX GMBH
--- Begin Message ---
NFSv3 has no concept of a umask on the server side: The client applies
the umask locally, and sends the effective permissions to the server.
This behavior is wrong when files are created in a directory that has a
default ACL.  In this case, the umask is supposed to be ignored, and
only the default ACL determines the file's effective permissions.

Usually its the server's task to conditionally apply the umask.  But
since the server knows nothing about the umask, we have to do it on the
client side.  This patch tries to fetch the parent directory's default
ACL before creating a new file, computes the appropriate create mode to
send to the server, and finally sets the new file's access and default
acl appropriately.

Many thanks to Buck Huppmann <[EMAIL PROTECTED]> for sending the initial
version of this patch, as well as for arguing why we need this change.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Acked-by: Olaf Kirch <[EMAIL PROTECTED]>

Index: linux-2.6.11/fs/nfs/nfs3proc.c
===
--- linux-2.6.11.orig/fs/nfs/nfs3proc.c
+++ linux-2.6.11/fs/nfs/nfs3proc.c
@@ -292,6 +292,38 @@ static int nfs3_proc_commit(struct nfs_w
return status;
 }
 
+static int nfs3_set_default_acl(struct inode *dir, struct inode *inode,
+   mode_t mode)
+{
+#ifdef CONFIG_NFS_ACL
+   struct posix_acl *dfacl, *acl;
+   int error = 0;
+
+   dfacl = NFS_PROTO(dir)->getacl(dir, ACL_TYPE_DEFAULT);
+   if (IS_ERR(dfacl)) {
+   error = PTR_ERR(dfacl);
+   return (error == -EOPNOTSUPP) ? 0 : error;
+   }
+   if (!dfacl)
+   return 0;
+   acl = posix_acl_clone(dfacl, GFP_KERNEL);
+   error = -ENOMEM;
+   if (!acl)
+   goto out;
+   error = posix_acl_create_masq(acl, );
+   if (error < 0)
+   goto out;
+   error = NFS_PROTO(inode)->setacls(inode, acl, S_ISDIR(inode->i_mode) ?
+ dfacl : NULL);
+out:
+   posix_acl_release(acl);
+   posix_acl_release(dfacl);
+   return error;
+#else
+   return 0;
+#endif
+}
+
 /*
  * Create a regular file.
  * For now, we don't implement O_EXCL.
@@ -314,8 +346,12 @@ nfs3_proc_create(struct inode *dir, stru
.fh = ,
.fattr  = 
};
+   mode_t  mode;
int status;
 
+   mode = sattr->ia_mode;
+   sattr->ia_mode &= ~current->fs->umask;
+
dprintk("NFS call  create %s\n", dentry->d_name.name);
arg.createmode = NFS3_CREATE_UNCHECKED;
if (flags & O_EXCL) {
@@ -350,7 +386,6 @@ again:
 
 exit:
dprintk("NFS reply create: %d\n", status);
-
if (status != 0)
goto out;
if (fhandle.size == 0 || !(fattr.valid & NFS_ATTR_FATTR)) {
@@ -384,9 +419,13 @@ exit:
if (status == 0) {
struct inode *inode;
inode = nfs_fhget(dir->i_sb, , );
-   if (inode)
-   return inode;
status = -ENOMEM;
+   if (!inode)
+   goto out;
+   status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);
@@ -556,8 +595,12 @@ nfs3_proc_mkdir(struct inode *dir, struc
.fh = ,
.fattr  = 
};
+   mode_t mode;
int status;
 
+   mode = sattr->ia_mode;
+   sattr->ia_mode &= ~current->fs->umask;
+
dprintk("NFS call  mkdir %s\n", dentry->d_name.name);
dir_attr.valid = 0;
fattr.valid = 0;
@@ -566,6 +609,8 @@ nfs3_proc_mkdir(struct inode *dir, struc
if (!status)

Re: [2.6.11-rc5-mm1 patch] reiser4 cleanup (PG_arch_1)

2005-03-02 Thread Vladimir Saveliev

Hello

On Wed, 2005-03-02 at 12:14, Andrew Morton wrote:
> Jes Sorensen <[EMAIL PROTECTED]> wrote:
> >
> > > "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:
> > 
> > Adrian> The current reiser4 help texts have two disadvantages: 1. they
> > Adrian> are more marketing speech than technical speech with some
> > Adrian> debatable statements 2. they are too long
> > 
> > Excellent patch, that help description has been totally inappropriate
> > since it was first introduced. I'm sure it will do fine on namesys'
> > website, but not in the kernel.
> > 
> > Adrian> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> > 
> > Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
> > 
> > Speaking of inappropriate components in reiser4:
> > 
> > [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
> > fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
> > fs/reiser4/txnmgr.c:assert("vs-1448", 
> > test_and_clear_bit(PG_arch_1, >pg->flags));
> > fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
> > &(copy->pg)->flags));
> > 
> > Someone was obviously smoking something illegal, what part of 'arch'
> > did she/he not understand? I assume we can request this is fixed by
> > the patch owner asap.
> > 
> 
> Could the reiserfs team please comment?
> 

Yes, that was old debugging code. It is to be removed. The patch for
that is attached.

Please also apply another attached small bug fix.



> If it's just debug then probably it would be better to add a new flag.
> 
> If these pages are never mmapped then it'll just happen to work, I guess. 
> But a filesystem really shouldn't be dinking with PG_arch_1.
> 
> 

This cleanups old debugging code


 fs/reiser4/page_cache.c |6 --
 fs/reiser4/txnmgr.c |6 +-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff -puN fs/reiser4/txnmgr.c~reiser4-cleanup fs/reiser4/txnmgr.c
--- linux-2.6.11-rc4-mm1/fs/reiser4/txnmgr.c~reiser4-cleanup2005-03-02 
17:23:47.0 +0300
+++ linux-2.6.11-rc4-mm1-vs/fs/reiser4/txnmgr.c 2005-03-02 17:24:27.0 
+0300
@@ -1507,11 +1507,8 @@ invalidate_list(capture_list_head * head
atom = node->atom;
LOCK_ATOM(atom);
LOCK_JNODE(node);
-   if (JF_ISSET(node, JNODE_CC) && node->pg) {
-   /* corresponding page_cache_get is in swap_jnode_pages 
*/
-   assert("vs-1448", test_and_clear_bit(PG_arch_1, 
>pg->flags));
+   if (JF_ISSET(node, JNODE_CC) && node->pg)
page_cache_release(node->pg);
-   }
uncapture_block(node);
UNLOCK_ATOM(atom);
JF_CLR(node, JNODE_SCANNED);
@@ -3578,7 +3575,6 @@ swap_jnode_pages(jnode *node, jnode *cop
assert("vs-1416", radix_tree_lookup(>page_tree, index) 
== NULL);
check_me("vs-1418", radix_tree_insert(>page_tree, 
index, copy->pg) == 0);
___add_to_page_cache(copy->pg, mapping, index);
-   ON_DEBUG(set_bit(PG_arch_1, &(copy->pg)->flags));
 
/* corresponding page_cache_release is in invalidate_list */
page_cache_get(copy->pg);
diff -puN fs/reiser4/page_cache.c~reiser4-cleanup fs/reiser4/page_cache.c
--- linux-2.6.11-rc4-mm1/fs/reiser4/page_cache.c~reiser4-cleanup
2005-03-02 17:23:47.0 +0300
+++ linux-2.6.11-rc4-mm1-vs/fs/reiser4/page_cache.c 2005-03-02 
17:25:36.0 +0300
@@ -743,18 +743,20 @@ print_page(const char *prefix, struct pa
}
printk("%s: page index: %lu mapping: %p count: %i private: %lx\n",
   prefix, page->index, page->mapping, page_count(page), 
page->private);
-   printk("\tflags: %s%s%s%s %s%s%s %s%s%s%s %s%s%s\n",
+   printk("\tflags: %s%s%s%s %s%s%s %s%s%s %s%s%s\n",
   page_flag_name(page, PG_locked),
   page_flag_name(page, PG_error),
   page_flag_name(page, PG_referenced),
   page_flag_name(page, PG_uptodate),
+
   page_flag_name(page, PG_dirty),
   page_flag_name(page, PG_lru),
   page_flag_name(page, PG_slab),
+
   page_flag_name(page, PG_highmem),
   page_flag_name(page, PG_checked),
-  page_flag_name(page, PG_arch_1),
   page_flag_name(page, PG_reserved),
+
   page_flag_name(page, PG_private), page_flag_name(page, 
PG_writeback), page_flag_name(page, PG_nosave));
if (jprivate(page) != NULL) {
print_jnode("\tpage jnode", jprivate(page));

_

This patch adds missing spin_unlock to error handling path


 fs/reiser4/plugin/item/extent_file_ops.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN 
fs/reiser4/plugin/item/extent_file_ops.c~reiser4-add-missing-spin_unlock 
fs/reiser4/plugin/item/extent_file_ops.c
---

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

2005-03-02 Thread Nikita Danilov

Andrew Morton <[EMAIL PROTECTED]> writes:

> Jes Sorensen <[EMAIL PROTECTED]> wrote:
>>

[...]

>> 
>> [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
>> fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
>> fs/reiser4/txnmgr.c:assert("vs-1448", 
>> test_and_clear_bit(PG_arch_1, >pg->flags));
>> fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
>> &(copy->pg)->flags));
>> 
>> Someone was obviously smoking something illegal, what part of 'arch'
>> did she/he not understand? I assume we can request this is fixed by
>> the patch owner asap.
>> 
>
> Could the reiserfs team please comment?
>
> If it's just debug then probably it would be better to add a new flag.
>

Yes, this is debugging. I believe it can be removed now.

> If these pages are never mmapped then it'll just happen to work, I guess. 
> But a filesystem really shouldn't be dinking with PG_arch_1.

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

Jes Sorensen <[EMAIL PROTECTED]> wrote:
>
> > "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:
> 
> Adrian> The current reiser4 help texts have two disadvantages: 1. they
> Adrian> are more marketing speech than technical speech with some
> Adrian> debatable statements 2. they are too long
> 
> Excellent patch, that help description has been totally inappropriate
> since it was first introduced. I'm sure it will do fine on namesys'
> website, but not in the kernel.
> 
> Adrian> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
> 
> Speaking of inappropriate components in reiser4:
> 
> [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
> fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
> fs/reiser4/txnmgr.c:assert("vs-1448", 
> test_and_clear_bit(PG_arch_1, >pg->flags));
> fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
> &(copy->pg)->flags));
> 
> Someone was obviously smoking something illegal, what part of 'arch'
> did she/he not understand? I assume we can request this is fixed by
> the patch owner asap.
> 

Could the reiserfs team please comment?

If it's just debug then probably it would be better to add a new flag.

If these pages are never mmapped then it'll just happen to work, I guess. 
But a filesystem really shouldn't be dinking with PG_arch_1.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

2005-03-02 Thread Jes Sorensen

> "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:

Adrian> The current reiser4 help texts have two disadvantages: 1. they
Adrian> are more marketing speech than technical speech with some
Adrian> debatable statements 2. they are too long

Excellent patch, that help description has been totally inappropriate
since it was first introduced. I'm sure it will do fine on namesys'
website, but not in the kernel.

Adrian> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>

Speaking of inappropriate components in reiser4:

[EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
fs/reiser4/txnmgr.c:assert("vs-1448", 
test_and_clear_bit(PG_arch_1, >pg->flags));
fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
&(copy->pg)->flags));

Someone was obviously smoking something illegal, what part of 'arch'
did she/he not understand? I assume we can request this is fixed by
the patch owner asap.

Cheers,
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Aurélien Francillon <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/
> > 
> > 
> > - Lots of tuning/balancing changes in the CPU scheduler.  Mainly targetted
> >   at larger SMT/SMP/NUMA machines.  It's going to be hard to work out 
> > whether
> >   these are a net benefit.
> > 
> > - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
> >   makes pcmcia work more like regular hotpluggable devices.  See the
> >   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
> >   details.
> > 
> > - A new reiser4 code drop.
> > 
> > - A new rev of the NFS ACL code.
> 
> hi,
> I have a strange bug with nfs,
> this happens on the 2.6.11-rc5-mm1 and i have no problems with 2.6.11-rc5.
> 
> i have a cvsroot exported over nfs on a server running a fedora core
> kernel (kernel-2.6.5-1.358) and i use it from a notebook. With linus
> kernel no problem, but with mm i have the following error :
> 
> cvs diff Makefile 
>  cvs diff: cannot create read lock in repository 
> `/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
> cvs [diff aborted]: read lock failed - giving up
> 
> but the file is created and i can "cat " it without problem ...
> 
> strace gives me :
> 
> with  2.6.11-rc5-mm1:
> open("/mnt/iseran/roca/cvsroot/ldpc/#cvs.rfl.vanua.6860",O_RDWR|O_CREAT|O_TRUNC,
>  
> 0666) = -1 ENOENT (No such file or directory)
> 
> with 2.6.11-rc5 kernel:
> open("/mnt/iseran/roca/cvsroot/ldpc/#cvs.rfl.vanua.14403", 
> O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
> close(3)
> 
> 
> nfs is configured without acl in the .config
> and AFAK the server neither uses them
> 

Nice report, thanks.

I can reproduce the problem here.  Simple testcase:

main()
{
int fd;

fd = open("a", O_RDWR|O_CREAT|O_TRUNC, 0666);
if (fd < 0)
perror("open");
exit(0);
}

The same happens with CONFIG_NFS_ACL=y.

Binary searching shwos that the bug was introduced by
nfsacl-acl-umask-handling-workaround-in-nfs-client.patch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Aurélien Francillon [EMAIL PROTECTED] wrote:

 Andrew Morton wrote:
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/
  
  
  - Lots of tuning/balancing changes in the CPU scheduler.  Mainly targetted
at larger SMT/SMP/NUMA machines.  It's going to be hard to work out 
  whether
these are a net benefit.
  
  - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
makes pcmcia work more like regular hotpluggable devices.  See the
changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
details.
  
  - A new reiser4 code drop.
  
  - A new rev of the NFS ACL code.
 
 hi,
 I have a strange bug with nfs,
 this happens on the 2.6.11-rc5-mm1 and i have no problems with 2.6.11-rc5.
 
 i have a cvsroot exported over nfs on a server running a fedora core
 kernel (kernel-2.6.5-1.358) and i use it from a notebook. With linus
 kernel no problem, but with mm i have the following error :
 
 cvs diff Makefile 
  cvs diff: cannot create read lock in repository 
 `/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
 cvs [diff aborted]: read lock failed - giving up
 
 but the file is created and i can cat  it without problem ...
 
 strace gives me :
 
 with  2.6.11-rc5-mm1:
 open(/mnt/iseran/roca/cvsroot/ldpc/#cvs.rfl.vanua.6860,O_RDWR|O_CREAT|O_TRUNC,
  
 0666) = -1 ENOENT (No such file or directory)
 
 with 2.6.11-rc5 kernel:
 open(/mnt/iseran/roca/cvsroot/ldpc/#cvs.rfl.vanua.14403, 
 O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
 close(3)
 
 
 nfs is configured without acl in the .config
 and AFAK the server neither uses them
 

Nice report, thanks.

I can reproduce the problem here.  Simple testcase:

main()
{
int fd;

fd = open(a, O_RDWR|O_CREAT|O_TRUNC, 0666);
if (fd  0)
perror(open);
exit(0);
}

The same happens with CONFIG_NFS_ACL=y.

Binary searching shwos that the bug was introduced by
nfsacl-acl-umask-handling-workaround-in-nfs-client.patch

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

2005-03-02 Thread Jes Sorensen

 Adrian == Adrian Bunk [EMAIL PROTECTED] writes:

Adrian The current reiser4 help texts have two disadvantages: 1. they
Adrian are more marketing speech than technical speech with some
Adrian debatable statements 2. they are too long

Excellent patch, that help description has been totally inappropriate
since it was first introduced. I'm sure it will do fine on namesys'
website, but not in the kernel.

Adrian Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Signed-off-by: Jes Sorensen [EMAIL PROTECTED]

Speaking of inappropriate components in reiser4:

[EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
fs/reiser4/txnmgr.c:assert(vs-1448, 
test_and_clear_bit(PG_arch_1, node-pg-flags));
fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
(copy-pg)-flags));

Someone was obviously smoking something illegal, what part of 'arch'
did she/he not understand? I assume we can request this is fixed by
the patch owner asap.

Cheers,
Jes
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

Jes Sorensen [EMAIL PROTECTED] wrote:

  Adrian == Adrian Bunk [EMAIL PROTECTED] writes:
 
 Adrian The current reiser4 help texts have two disadvantages: 1. they
 Adrian are more marketing speech than technical speech with some
 Adrian debatable statements 2. they are too long
 
 Excellent patch, that help description has been totally inappropriate
 since it was first introduced. I'm sure it will do fine on namesys'
 website, but not in the kernel.
 
 Adrian Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
 
 Speaking of inappropriate components in reiser4:
 
 [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
 fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
 fs/reiser4/txnmgr.c:assert(vs-1448, 
 test_and_clear_bit(PG_arch_1, node-pg-flags));
 fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
 (copy-pg)-flags));
 
 Someone was obviously smoking something illegal, what part of 'arch'
 did she/he not understand? I assume we can request this is fixed by
 the patch owner asap.
 

Could the reiserfs team please comment?

If it's just debug then probably it would be better to add a new flag.

If these pages are never mmapped then it'll just happen to work, I guess. 
But a filesystem really shouldn't be dinking with PG_arch_1.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 Kconfig help cleanup

2005-03-02 Thread Nikita Danilov

Andrew Morton [EMAIL PROTECTED] writes:

 Jes Sorensen [EMAIL PROTECTED] wrote:


[...]

 
 [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
 fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
 fs/reiser4/txnmgr.c:assert(vs-1448, 
 test_and_clear_bit(PG_arch_1, node-pg-flags));
 fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
 (copy-pg)-flags));
 
 Someone was obviously smoking something illegal, what part of 'arch'
 did she/he not understand? I assume we can request this is fixed by
 the patch owner asap.
 

 Could the reiserfs team please comment?

 If it's just debug then probably it would be better to add a new flag.


Yes, this is debugging. I believe it can be removed now.

 If these pages are never mmapped then it'll just happen to work, I guess. 
 But a filesystem really shouldn't be dinking with PG_arch_1.

Nikita.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11-rc5-mm1 patch] reiser4 cleanup (PG_arch_1)

2005-03-02 Thread Vladimir Saveliev

Hello

On Wed, 2005-03-02 at 12:14, Andrew Morton wrote:
 Jes Sorensen [EMAIL PROTECTED] wrote:
 
   Adrian == Adrian Bunk [EMAIL PROTECTED] writes:
  
  Adrian The current reiser4 help texts have two disadvantages: 1. they
  Adrian are more marketing speech than technical speech with some
  Adrian debatable statements 2. they are too long
  
  Excellent patch, that help description has been totally inappropriate
  since it was first introduced. I'm sure it will do fine on namesys'
  website, but not in the kernel.
  
  Adrian Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
  
  Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
  
  Speaking of inappropriate components in reiser4:
  
  [EMAIL PROTECTED] linux-2.6.11-rc5-mm1]$ grep PG_arch fs/reiser4/*.c
  fs/reiser4/page_cache.c:   page_flag_name(page, PG_arch_1),
  fs/reiser4/txnmgr.c:assert(vs-1448, 
  test_and_clear_bit(PG_arch_1, node-pg-flags));
  fs/reiser4/txnmgr.c:ON_DEBUG(set_bit(PG_arch_1, 
  (copy-pg)-flags));
  
  Someone was obviously smoking something illegal, what part of 'arch'
  did she/he not understand? I assume we can request this is fixed by
  the patch owner asap.
  
 
 Could the reiserfs team please comment?
 

Yes, that was old debugging code. It is to be removed. The patch for
that is attached.

Please also apply another attached small bug fix.



 If it's just debug then probably it would be better to add a new flag.
 
 If these pages are never mmapped then it'll just happen to work, I guess. 
 But a filesystem really shouldn't be dinking with PG_arch_1.
 
 

This cleanups old debugging code


 fs/reiser4/page_cache.c |6 --
 fs/reiser4/txnmgr.c |6 +-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff -puN fs/reiser4/txnmgr.c~reiser4-cleanup fs/reiser4/txnmgr.c
--- linux-2.6.11-rc4-mm1/fs/reiser4/txnmgr.c~reiser4-cleanup2005-03-02 
17:23:47.0 +0300
+++ linux-2.6.11-rc4-mm1-vs/fs/reiser4/txnmgr.c 2005-03-02 17:24:27.0 
+0300
@@ -1507,11 +1507,8 @@ invalidate_list(capture_list_head * head
atom = node-atom;
LOCK_ATOM(atom);
LOCK_JNODE(node);
-   if (JF_ISSET(node, JNODE_CC)  node-pg) {
-   /* corresponding page_cache_get is in swap_jnode_pages 
*/
-   assert(vs-1448, test_and_clear_bit(PG_arch_1, 
node-pg-flags));
+   if (JF_ISSET(node, JNODE_CC)  node-pg)
page_cache_release(node-pg);
-   }
uncapture_block(node);
UNLOCK_ATOM(atom);
JF_CLR(node, JNODE_SCANNED);
@@ -3578,7 +3575,6 @@ swap_jnode_pages(jnode *node, jnode *cop
assert(vs-1416, radix_tree_lookup(mapping-page_tree, index) 
== NULL);
check_me(vs-1418, radix_tree_insert(mapping-page_tree, 
index, copy-pg) == 0);
___add_to_page_cache(copy-pg, mapping, index);
-   ON_DEBUG(set_bit(PG_arch_1, (copy-pg)-flags));
 
/* corresponding page_cache_release is in invalidate_list */
page_cache_get(copy-pg);
diff -puN fs/reiser4/page_cache.c~reiser4-cleanup fs/reiser4/page_cache.c
--- linux-2.6.11-rc4-mm1/fs/reiser4/page_cache.c~reiser4-cleanup
2005-03-02 17:23:47.0 +0300
+++ linux-2.6.11-rc4-mm1-vs/fs/reiser4/page_cache.c 2005-03-02 
17:25:36.0 +0300
@@ -743,18 +743,20 @@ print_page(const char *prefix, struct pa
}
printk(%s: page index: %lu mapping: %p count: %i private: %lx\n,
   prefix, page-index, page-mapping, page_count(page), 
page-private);
-   printk(\tflags: %s%s%s%s %s%s%s %s%s%s%s %s%s%s\n,
+   printk(\tflags: %s%s%s%s %s%s%s %s%s%s %s%s%s\n,
   page_flag_name(page, PG_locked),
   page_flag_name(page, PG_error),
   page_flag_name(page, PG_referenced),
   page_flag_name(page, PG_uptodate),
+
   page_flag_name(page, PG_dirty),
   page_flag_name(page, PG_lru),
   page_flag_name(page, PG_slab),
+
   page_flag_name(page, PG_highmem),
   page_flag_name(page, PG_checked),
-  page_flag_name(page, PG_arch_1),
   page_flag_name(page, PG_reserved),
+
   page_flag_name(page, PG_private), page_flag_name(page, 
PG_writeback), page_flag_name(page, PG_nosave));
if (jprivate(page) != NULL) {
print_jnode(\tpage jnode, jprivate(page));

_

This patch adds missing spin_unlock to error handling path


 fs/reiser4/plugin/item/extent_file_ops.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN 
fs/reiser4/plugin/item/extent_file_ops.c~reiser4-add-missing-spin_unlock 
fs/reiser4/plugin/item/extent_file_ops.c
--- 
linux-2.6.11-rc4-mm1/fs/reiser4/plugin/item/extent_file_ops.c~reiser4-add-missing-spin_unlock
   2005-03-02 17:29:46.0 +0300
+++

Re: 2.6.11-rc5-mm1

2005-03-02 Thread Andreas Gruenbacher

Hello,

On Wed, 2005-03-02 at 09:53, Andrew Morton wrote:
 Aurlien Francillon [EMAIL PROTECTED] wrote:
  [...]
  cvs diff Makefile 
   cvs diff: cannot create read lock in repository 
  `/mnt/iseran/roca/cvsroot/ldpc': No such file or directory
  cvs [diff aborted]: read lock failed - giving up
  
  but the file is created and i can cat  it without problem ...

This fixes it:

Index: linux-2.6.11/fs/nfs/nfs3proc.c
===
--- linux-2.6.11.orig/fs/nfs/nfs3proc.c
+++ linux-2.6.11/fs/nfs/nfs3proc.c
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);

I'll reply to this message with an updated patch:

  Re: [nfsacl v2 15/16] ACL umask handling workaround in nfs client

Regards,
-- 
Andreas Gruenbacher [EMAIL PROTECTED]
SUSE Labs, SUSE LINUX GMBH
---BeginMessage---
NFSv3 has no concept of a umask on the server side: The client applies
the umask locally, and sends the effective permissions to the server.
This behavior is wrong when files are created in a directory that has a
default ACL.  In this case, the umask is supposed to be ignored, and
only the default ACL determines the file's effective permissions.

Usually its the server's task to conditionally apply the umask.  But
since the server knows nothing about the umask, we have to do it on the
client side.  This patch tries to fetch the parent directory's default
ACL before creating a new file, computes the appropriate create mode to
send to the server, and finally sets the new file's access and default
acl appropriately.

Many thanks to Buck Huppmann [EMAIL PROTECTED] for sending the initial
version of this patch, as well as for arguing why we need this change.

Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Acked-by: Olaf Kirch [EMAIL PROTECTED]

Index: linux-2.6.11/fs/nfs/nfs3proc.c
===
--- linux-2.6.11.orig/fs/nfs/nfs3proc.c
+++ linux-2.6.11/fs/nfs/nfs3proc.c
@@ -292,6 +292,38 @@ static int nfs3_proc_commit(struct nfs_w
return status;
 }
 
+static int nfs3_set_default_acl(struct inode *dir, struct inode *inode,
+   mode_t mode)
+{
+#ifdef CONFIG_NFS_ACL
+   struct posix_acl *dfacl, *acl;
+   int error = 0;
+
+   dfacl = NFS_PROTO(dir)-getacl(dir, ACL_TYPE_DEFAULT);
+   if (IS_ERR(dfacl)) {
+   error = PTR_ERR(dfacl);
+   return (error == -EOPNOTSUPP) ? 0 : error;
+   }
+   if (!dfacl)
+   return 0;
+   acl = posix_acl_clone(dfacl, GFP_KERNEL);
+   error = -ENOMEM;
+   if (!acl)
+   goto out;
+   error = posix_acl_create_masq(acl, mode);
+   if (error  0)
+   goto out;
+   error = NFS_PROTO(inode)-setacls(inode, acl, S_ISDIR(inode-i_mode) ?
+ dfacl : NULL);
+out:
+   posix_acl_release(acl);
+   posix_acl_release(dfacl);
+   return error;
+#else
+   return 0;
+#endif
+}
+
 /*
  * Create a regular file.
  * For now, we don't implement O_EXCL.
@@ -314,8 +346,12 @@ nfs3_proc_create(struct inode *dir, stru
.fh = fhandle,
.fattr  = fattr
};
+   mode_t  mode;
int status;
 
+   mode = sattr-ia_mode;
+   sattr-ia_mode = ~current-fs-umask;
+
dprintk(NFS call  create %s\n, dentry-d_name.name);
arg.createmode = NFS3_CREATE_UNCHECKED;
if (flags  O_EXCL) {
@@ -350,7 +386,6 @@ again:
 
 exit:
dprintk(NFS reply create: %d\n, status);
-
if (status != 0)
goto out;
if (fhandle.size == 0 || !(fattr.valid  NFS_ATTR_FATTR)) {
@@ -384,9 +419,13 @@ exit:
if (status == 0) {
struct inode *inode;
inode = nfs_fhget(dir-i_sb, fhandle, fattr);
-   if (inode)
-   return inode;
status = -ENOMEM;
+   if (!inode)
+   goto out;
+   status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);
@@ -556,8 +595,12 @@ nfs3_proc_mkdir(struct inode *dir, struc
.fh = fh,
.fattr  = fattr
};
+   mode_t mode;
int status;
 
+   mode = sattr-ia_mode;
+   sattr-ia_mode = ~current-fs-umask;
+
dprintk(NFS call  mkdir %s\n, dentry-d_name.name);
dir_attr.valid = 0;
fattr.valid = 0;
@@ -566,6 +609,8 @@ nfs3_proc_mkdir(struct inode *dir, struc
if (!status)
status =

Re: Fw: Re: 2.6.11-rc5-mm1

2005-03-02 Thread Dominik Brodowski

On Tue, Mar 01, 2005 at 11:57:03AM +0100, Alexander Gran wrote:
 Am Dienstag, 1. März 2005 11:48 schrieb Andrew Morton:
  Alex, please use mailing lists...
 
 sorry, I was used to have reply-to set to the mailing list ;) 
 double-checking next time..
 
  Dominik, do we really always want to drag in the firmware loader if
  CONFIG_PCMCIA?
 
 Hmm. I've enabled the firmware loader that fixes at least the compile error...
 Now rebooting. More info after my system programming exam in 1 hour. ;)

Updated patch submitted -- see

http://lists.infradead.org/pipermail/linux-pcmcia/2005-March/001580.html

Dominik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 nfs oddity, file creation = no such file

Helge Hafting [EMAIL PROTECTED] wrote:

 I observed an oddity on a nfs-mounted fs while using 2.6.11-rc5-mm1.

Could you try this please?

--- 25/fs/nfs/nfs3proc.c~nfsacl-acl-umask-handling-workaround-in-nfs-client-fix 
2005-03-02 08:49:59.0 -0800
+++ 25-akpm/fs/nfs/nfs3proc.c   2005-03-02 08:49:59.0 -0800
@@ -423,6 +423,9 @@ exit:
if (!inode)
goto out;
status = nfs3_set_default_acl(dir, inode, mode);
+   if (status)
+   goto out;
+   return inode;
}
 out:
return ERR_PTR(status);
_

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5: Promise SATA150 TX4 failure

2005-03-01 Thread J.A. Magallon

On 03.01, Joerg Sommrey wrote:
> Hi all,
> 
> a problem that was introduced between 2.6.10-ac9 and 2.6.10-ac11 made
> it's way into 2.6.11-rc5.  While taking a backup onto a SCSI-streamer one
> of my RAID1-arrays gets corrupted.  Afterwards the system hangs and
> isn't even bootable.  Need to raidhotadd the failed partition in single
> user mode to get the box working again. Error messages:
> 

Me too :(. Just a slightly different case.
I have a server with 6x250Gb SATA drives, hanged on a pair of Promise
PDC20319 (FastTrak S150 TX4) (rev 02) controlers (each has 4 ports).
Main use for the box is as a smb/atalk/nfs server.

With 2.6.20-rc3-mm2+libata-dev2, the box is stable, we can drop
gigs of files throug samba amd it works. 
Anything newer that that makes the box hang siliently, no messages,
no oops. It also happened to me with just a local wget of a big
file (oofice-2.0-beta), after download the box locked hard.

I tried to apply libata-dev1 on top of newer kernels, but part of it
is already there, and the rest drops too many rejects/offsets for
me.

I also have one other problem with flock, but thats subject for another
post...

Any ideas about what changed wrt sata ?

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-jam12 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Chris Wright <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > - I seem to be getting a lot of patches which don't compile if you breathe
> >   on the .config file, let alone if you try them on another architecture.  
> > It
> >   would be nice to receive less such patches, please.
> 
> The ia64 audit bit is likely my fault from the audit header detangle.

I figured something like that, but the change is a good one anwyay.  IOW:
your cleanup exposed a prior problem...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

On Tuesday 01 March 2005 22:38, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
> > hi benjamin
> > 
> > now i had some spare time to do some investigation
> > 
> > booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> > brings up a framebuffer console. everything is fine.
> > starting xorg-x11 with Ati binary only drivers just brings up a black screen
> > without a mouse cursor and freezes the hole machine. even network ect. 
> > is no more reachable from outside the machine. worst thing out of that
> > a tail on the log files (on another machine) does immediately stop - also 
> > no 
> > output is written to syslog :/
> > 
> > next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> > starting xorg-x11 with Xorg Radeon driver. 
> > a grey screen comes up - mouse cursor is visible and also able to move for
> > 5 - 8 seconds after screen display - then freezes the whole machine again.
> 
> Ok, so it's not dynamic clocks. At this point, i have no idea what's
> going on. I don't yet have any access to PCI Express hardware. You
> should report this to X.org list where others can try to help me track
> this down.
> 
> Ben.

it's possible to do so, but i also will try to find out whats going on.
i don't know if i will have success.

regards
marcel



pgp2GpCGx86XC.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1

Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 01, 2005 at 01:27:41AM -0800, Andrew Morton wrote:
> >...
> > All 728 patches:
> >...
> > reiser4-rcu-barrier.patch
> >   reiser4: add rcu_barrier() synchronization point
> 
> Considering the patent situation at least in the USA, the 
> EXPORT_SYMBOL(rcu_barrier) has to become an EXPORT_SYMBOL_GPL.

I'll make that change.

> > reiser4-export-inode_lock.patch
> >   reiser4: export inode_lock to modules
> >...
> 
> __iget seems to be no longer used by reiser4.
> This part of the patch can therefore be dropped.

And that one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Chris Wright

* Andrew Morton ([EMAIL PROTECTED]) wrote:
> - I seem to be getting a lot of patches which don't compile if you breathe
>   on the .config file, let alone if you try them on another architecture.  It
>   would be nice to receive less such patches, please.

The ia64 audit bit is likely my fault from the audit header detangle.
I did try w/ and w/out CONFIG_AUDITSYSCALL set, but only on one arch.
I also did a grep, but was only looking at audit_putname/getname, and
missed the others.  I just did a more complete grep of the symbols that
can get config'd away (including CONFIG_AUDIT as well), and I think
there's a few more missing pieces.  Sorry about that.  Jeff, Ralf,
Martin, these look ok?

thanks,
-chris
--

A closer sweep of configurable audit symbols shows the following need
audit.h included when audit.h is detangled from fs.h as in -mm.

arch/um/kernel/ptrace.cfor audit_syscall_entry/exit
arch/s390/kernel/ptrace.c  for audit_syscall_entry/exit
arch/mips/kernel/ptrace.c  for audit_syscall_entry/exit

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

= arch/um/kernel/ptrace.c 1.21 vs edited =
--- 1.21/arch/um/kernel/ptrace.c2005-01-20 20:59:15 -08:00
+++ edited/arch/um/kernel/ptrace.c  2005-03-01 13:23:06 -08:00
@@ -9,6 +9,7 @@
 #include "linux/smp_lock.h"
 #include "linux/security.h"
 #include "linux/ptrace.h"
+#include "linux/audit.h"
 #ifdef CONFIG_PROC_MM
 #include "linux/proc_mm.h"
 #endif
= arch/s390/kernel/ptrace.c 1.28 vs edited =
--- 1.28/arch/s390/kernel/ptrace.c  2005-01-04 18:48:19 -08:00
+++ edited/arch/s390/kernel/ptrace.c2005-03-01 13:22:45 -08:00
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
= arch/mips/kernel/ptrace.c 1.15 vs edited =
--- 1.15/arch/mips/kernel/ptrace.c  2005-01-30 22:20:14 -08:00
+++ edited/arch/mips/kernel/ptrace.c2005-03-01 13:24:48 -08:00
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

2005-03-01 Thread Benjamin Herrenschmidt

On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
> hi benjamin
> 
> now i had some spare time to do some investigation
> 
> booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> brings up a framebuffer console. everything is fine.
> starting xorg-x11 with Ati binary only drivers just brings up a black screen
> without a mouse cursor and freezes the hole machine. even network ect. 
> is no more reachable from outside the machine. worst thing out of that
> a tail on the log files (on another machine) does immediately stop - also no 
> output is written to syslog :/
> 
> next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> starting xorg-x11 with Xorg Radeon driver. 
> a grey screen comes up - mouse cursor is visible and also able to move for
> 5 - 8 seconds after screen display - then freezes the whole machine again.

Ok, so it's not dynamic clocks. At this point, i have no idea what's
going on. I don't yet have any access to PCI Express hardware. You
should report this to X.org list where others can try to help me track
this down.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

 On Mon, Feb 28, Antonino A. Daplas wrote:

> On Monday 28 February 2005 04:32, Olaf Hering wrote:
> >  On Wed, Feb 23, Linus Torvalds wrote:
> > > This time it's really supposed to be a quickie, so people who can, please
> > > check it out, and we'll make the real 2.6.11 asap.
> >
> > Here is another one, probably not new.
> > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> > even if riva_create_i2c_busses fails to register all 3 busses.

Side note:

<[EMAIL PROTECTED]>: connect to
lists.surfsouth.com[216.128.200.12]: Connection timed out

Is this one supposed to work? perhaps the MAINTAINERS entry needs an
update.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 01, 2005 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote:
> > On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
> > > The PCI updates change the prototype of a helper function for 
> > > pci_bus_alloc_resource(), but don't touch the actual helper function
> > > in PCMCIA.
> > 
> > That explains the warning messages that gcc was tossing, which I suspected 
> > was
> > involved...
> > 
> > > This means that the PCI update is actually broken - if it's merged as
> > > is into Linus' tree, PCMCIA will break there as well.
> > 
> > Is the patch made to PCI actually incorrect, or is the proper way to do this
> > to propagate the changes into the relevant PCMCIA code?
> 
> PCI has been updated to accept 64-bit resources, but the PCMCIA code 
> has been missed.  So the correct fix is to propagate the changes where
> necessary into the PCMCIA code.

hmm, I missed that.  That's the price of two screenfuls of fscking compile
warnings.

> The minimalist solution is to fix up the PCMCIA alignment functions.

Greg's dropping the 64-bit-resource patch for now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Greg KH

On Tue, Mar 01, 2005 at 01:55:29PM +, Russell King wrote:
> On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
> > On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/
> > 
> > > - A pcmcia update which obsoletes cardmgr (although cardmgr still works) 
> > > and
> > >   makes pcmcia work more like regular hotpluggable devices.  See the
> > >   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch 
> > > for
> > >   details.
> > 
> > This is still showing the same 'cs: unable to map card memory!' issue on my
> > Dell laptop.  Backing out bk-pci.patch makes it work again.
> > 
> > For what it's worth, the hotplug system wasn't able to initialize the 
> > wireless
> > card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
> > But that might just me being an idiot...
> 
> It's probably a clash between the PCI updates and the PCMCIA updates.
> 
> The PCI updates change the prototype of a helper function for 
> pci_bus_alloc_resource(), but don't touch the actual helper function
> in PCMCIA.
> 
> This means that the PCI update is actually broken - if it's merged as
> is into Linus' tree, PCMCIA will break there as well.
> 
> Can whoever did the PCI update please resolve this mismatch.  Moreover,
> if 2.6.11 appears, please do not merge the PCI updates until this has
> been resolved.  Thanks.

Andrew had a stale bk-pci tree in his local copy, and that is where that
change came from.  It will not show up in the next -mm release, and will
not be sent to Linus until after I have fixed up the _whole_ tree.

So sorry for the inconvience.

thakns,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Adrian Bunk

On Tue, Mar 01, 2005 at 01:27:41AM -0800, Andrew Morton wrote:
>...
> All 728 patches:
>...
> reiser4-rcu-barrier.patch
>   reiser4: add rcu_barrier() synchronization point

Considering the patent situation at least in the USA, the 
EXPORT_SYMBOL(rcu_barrier) has to become an EXPORT_SYMBOL_GPL.

> reiser4-export-inode_lock.patch
>   reiser4: export inode_lock to modules
>...

__iget seems to be no longer used by reiser4.
This part of the patch can therefore be dropped.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 (compile stats)

2005-03-01 Thread John Cherry

Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

KernelbzImage   bzImage  bzImage  modules  bzImage  modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--- --     
2.6.11-rc5-mm1   21w/0e 0w/0e   262w/0e   10w/0e  26w/0e238w/0e
2.6.11-rc4-mm1   22w/0e 0w/0e   271w/0e   10w/0e  25w/0e249w/0e
2.6.11-rc3-mm2   14w/0e 0w/0e   192w/0e6w/0e  19w/0e172w/0e
2.6.11-rc3-mm1   13w/10e0w/7e   196w/12e   6w/0e  18w/12e   177w/0e
2.6.11-rc2-mm2   15w/0e 0w/0e   201w/0e6w/0e  18w/0e182w/0e
2.6.11-rc2-mm1   15w/0e 0w/0e   306w/14e   6w/0e  18w/0e294w/0e
2.6.11-rc1-mm2   21w/0e 0w/0e   316w/9e6w/0e  22w/0e294w/0e
2.6.11-rc1-mm1   21w/0e 0w/0e   319w/0e6w/0e  23w/0e298w/0e
2.6.10-mm3   21w/0e 0w/0e   320w/0e6w/0e  23w/0e299w/0e
2.6.10-mm2   21w/0e 0w/0e   440w/0e6w/0e  23w/0e420w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-rc1-mm1   16w/1e 1w/1e   592w/1e4w/0e  13w/1e857w/0e
2.6.9-mm1 6w/1e 1w/1e  1761w/15e  65w/0e   9w/0e   2086w/0e
2.6.9-rc4-mm1 5w/0e 0w/0e  1766w/11e  43w/0e   6w/0e   1798w/0e
2.6.9-rc3-mm3 5w/0e 0w/0e  1756w/11e  43w/0e   4w/0e   1786w/0e
2.6.9-rc3-mm210w/0e 4w/9e  1754w/14e  43w/0e   4w/0e   1782w/1e
2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e   43w/0e   4w/0e   1796w/0e
2.6.9-rc2-mm410w/0e 5w/0e  2573w/0e   41w/0e   4w/0e   2600w/0e
2.6.9-rc2-mm310w/0e 5w/0e  2400w/0e   41w/0e   4w/0e   2435w/0e
2.6.9-rc2-mm210w/0e 5w/0e  2919w/0e   41w/0e   4w/0e   2954w/0e
2.6.9-rc2-mm1 0w/0e 2w/0e  3541w/9e   41w/0e   3w/9e   3567w/0e
2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e   2w/0e 48w/0e
2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e   3w/0e   1w/0e 49w/1e
2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e   3w/0e   1w/0e 47w/0e
2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e   1w/0e 74w/0e
2.6.8.1-mm4   0w/0e 0w/0e78w/0e4w/0e   1w/0e 73w/0e
2.6.8.1-mm3   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm2   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm1   0w/0e 0w/0e78w/0e4w/0e   1w/0e 74w/0e
2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e   1w/0e 75w/0e
2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e   2w/8e 75w/0e
2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e   1w/0e 75w/0e
2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e   1w/0e 80w/0e
2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e   1w/0e 81w/0e
2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e   1w/0e 87w/0e
2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e   1w/0e 84w/0e
2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e   1w/0e 80w/0e
2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e   1w/0e 87w/0e
2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e   1w/0e 89w/0e
2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e   1w/0e 86w/0e
2.6.7-mm2 0w/0e 0w/0e   109w/0e7w/0e   1w/0e106w/0e
2.6.7-mm1 0w/0e 5w/0e   108w/0e5w/0e   1w/0e104w/0e
2.6.7-rc3-mm2 0w/0e 5w/0e   105w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc3-mm1 0w/0e 5w/0e   104w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc2-mm2 0w/0e 5w/0e   109w/10e

Re: 2.6.11-rc5-mm1

On Tue, Mar 01, 2005 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
> > The PCI updates change the prototype of a helper function for 
> > pci_bus_alloc_resource(), but don't touch the actual helper function
> > in PCMCIA.
> 
> That explains the warning messages that gcc was tossing, which I suspected was
> involved...
> 
> > This means that the PCI update is actually broken - if it's merged as
> > is into Linus' tree, PCMCIA will break there as well.
> 
> Is the patch made to PCI actually incorrect, or is the proper way to do this
> to propagate the changes into the relevant PCMCIA code?

PCI has been updated to accept 64-bit resources, but the PCMCIA code 
has been missed.  So the correct fix is to propagate the changes where
necessary into the PCMCIA code.

The minimalist solution is to fix up the PCMCIA alignment functions.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
> On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
> > This is still showing the same 'cs: unable to map card memory!' issue on my
> > Dell laptop.  Backing out bk-pci.patch makes it work again.
> > 
> > For what it's worth, the hotplug system wasn't able to initialize the 
> > wireless
> > card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
> > But that might just me being an idiot...
> 
> It's probably a clash between the PCI updates and the PCMCIA updates.
> 
> The PCI updates change the prototype of a helper function for 
> pci_bus_alloc_resource(), but don't touch the actual helper function
> in PCMCIA.

That explains the warning messages that gcc was tossing, which I suspected was
involved...

> This means that the PCI update is actually broken - if it's merged as
> is into Linus' tree, PCMCIA will break there as well.

Is the patch made to PCI actually incorrect, or is the proper way to do this
to propagate the changes into the relevant PCMCIA code?



pgpZrYJ6IDch6.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Edward Shishkin

Mathieu Segaud wrote:
Mathieu Segaud <[EMAIL PROTECTED]> disait derniÃrement que :
Hum, one hunk didn't make it.
The complete patch is attached
 

fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de ÃÂ ctail_ok ÃÂ sera toujours ÃÂvaluÃÂe comme 
ÃÂtant ÃÂ true ÃÂ
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de ÃÂ coord_is_unprepped_ctail ÃÂ sera toujours 
ÃÂvaluÃÂe comme ÃÂtant ÃÂ true ÃÂ
   

Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
 

 

Thanks for  catching this.
Edward.

--- fs/reiser4/plugin/item/ctail.c  2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new  2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
reiser4_internal int
check_ctail (const coord_t * coord, const char **error)
{
-   if (!ctail_ok) {
+   if (!ctail_ok(coord)) {
if (error)
*error = "bad cluster shift in ctail";
return 1;
@@ -1666,7 +1666,7 @@
detach_convert_idata(pos->sq);
break;
case CRC_OVERWRITE_ITEM:
-   if (coord_is_unprepped_ctail) {
+   if (coord_is_unprepped_ctail(>coord)) {
/* convert unpprepped ctail to prepped one */
int shift;
shift = 
inode_cluster_shift(item_convert_data(pos)->inode);

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

On Tuesday 01 March 2005 15:36, Helge Hafting wrote:
> Mws wrote:
> 
> >hi benjamin
> >
> >now i had some spare time to do some investigation
> >
> >booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
> >brings up a framebuffer console. everything is fine.
> >starting xorg-x11 with Ati binary only drivers just brings up a black screen
> >without a mouse cursor and freezes the hole machine. even network ect. 
> >is no more reachable from outside the machine. worst thing out of that
> >a tail on the log files (on another machine) does immediately stop - also no 
> >output is written to syslog :/
> >
> >next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
> >starting xorg-x11 with Xorg Radeon driver. 
> >a grey screen comes up - mouse cursor is visible and also able to move for
> >5 - 8 seconds after screen display - then freezes the whole machine again.
> >  
> >
> Did you try without dri? (Comment out dri in the X config file)
> I use a radeon 7000 VE at work, where X will hang after a few
> seconds if dri is enabled in X.  Disable dri, and it is
> rock solid. xfree or x.org makes no difference here.
> 
> Helge Hafting

hi, 

i had dri disabled already :/

regards
marcel


pgpml38TTNxWC.pgp
Description: PGP signature

Re: 2.6.11-rc5

2005-03-01 Thread Helge Hafting

Mws wrote:
hi benjamin
now i had some spare time to do some investigation
booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
brings up a framebuffer console. everything is fine.
starting xorg-x11 with Ati binary only drivers just brings up a black screen
without a mouse cursor and freezes the hole machine. even network ect. 
is no more reachable from outside the machine. worst thing out of that
a tail on the log files (on another machine) does immediately stop - also no 
output is written to syslog :/

next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
starting xorg-x11 with Xorg Radeon driver. 
a grey screen comes up - mouse cursor is visible and also able to move for
5 - 8 seconds after screen display - then freezes the whole machine again.
 

Did you try without dri? (Comment out dri in the X config file)
I use a radeon 7000 VE at work, where X will hang after a few
seconds if dri is enabled in X.  Disable dri, and it is
rock solid. xfree or x.org makes no difference here.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Mathieu Segaud <[EMAIL PROTECTED]> disait derniÃrement que :

> Mathieu Segaud <[EMAIL PROTECTED]> disait derniÃrement que :
>
> Hum, one hunk didn't make it.
> The complete patch is attached

as any time I post with no sleep for 3 days, more noodles than brain
are in my skull. Did tha wrong strip level, didn't I ?

well, this the last one, with every hunk, and correct strip level

--- linux/fs/reiser4/plugin/item/ctail.c	2005-03-01 14:57:52.756014040 +0100
+++ linux/fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = "bad cluster shift in ctail";
 		return 1;
@@ -1666,7 +1666,7 @@
 		detach_convert_idata(pos->sq);
 		break;
 	case CRC_OVERWRITE_ITEM:
-		if (coord_is_unprepped_ctail) {
+		if (coord_is_unprepped_ctail(>coord)) {
 			/* convert unpprepped ctail to prepped one */
 			int shift;
 			shift = inode_cluster_shift(item_convert_data(pos)->inode);

Regards, time to go to bed

-- 
> >
> > Wait. Don't you mean:

Yes. Just ignore me when I show extreme signs of Alzheimers.

- Linus Torvalds on linux-kernel

Re: 2.6.11-rc5-mm1

Mathieu Segaud <[EMAIL PROTECTED]> disait derniÃrement que :

Hum, one hunk didn't make it.
The complete patch is attached

>
> fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
> fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de ÃÂ ctail_ok 
> ÃÂ sera toujours ÃÂvaluÃÂe comme ÃÂtant ÃÂ true ÃÂ
> fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
> fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de ÃÂ 
> coord_is_unprepped_ctail ÃÂ sera toujours ÃÂvaluÃÂe comme ÃÂtant ÃÂ 
> true ÃÂ
>

Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>

--- fs/reiser4/plugin/item/ctail.c	2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = "bad cluster shift in ctail";
 		return 1;
@@ -1666,7 +1666,7 @@
 		detach_convert_idata(pos->sq);
 		break;
 	case CRC_OVERWRITE_ITEM:
-		if (coord_is_unprepped_ctail) {
+		if (coord_is_unprepped_ctail(>coord)) {
 			/* convert unpprepped ctail to prepped one */
 			int shift;
 			shift = inode_cluster_shift(item_convert_data(pos)->inode);


-- 
Outlook, n.:
A virus delivery system with added email functionality.

- Kurt Wall on linux-kernel

Re: 2.6.11-rc5-mm1

On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/
> 
> > - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
> >   makes pcmcia work more like regular hotpluggable devices.  See the
> >   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
> >   details.
> 
> This is still showing the same 'cs: unable to map card memory!' issue on my
> Dell laptop.  Backing out bk-pci.patch makes it work again.
> 
> For what it's worth, the hotplug system wasn't able to initialize the wireless
> card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
> But that might just me being an idiot...

It's probably a clash between the PCI updates and the PCMCIA updates.

The PCI updates change the prototype of a helper function for 
pci_bus_alloc_resource(), but don't touch the actual helper function
in PCMCIA.

This means that the PCI update is actually broken - if it's merged as
is into Linus' tree, PCMCIA will break there as well.

Can whoever did the PCI update please resolve this mismatch.  Moreover,
if 2.6.11 appears, please do not merge the PCI updates until this has
been resolved.  Thanks.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Andrew Morton <[EMAIL PROTECTED]> disait derniÃrement que :

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/
>
>
> - Lots of tuning/balancing changes in the CPU scheduler.  Mainly targetted
>   at larger SMT/SMP/NUMA machines.  It's going to be hard to work out whether
>   these are a net benefit.
>
> - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
>   makes pcmcia work more like regular hotpluggable devices.  See the
>   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
>   details.
>
> - A new reiser4 code drop.

By the way, I got an strange warning compiling fs/reiser4/plugin/ctail.c
obvious fix is attached

fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de ÃÂ ctail_ok ÃÂ 
sera toujours ÃÂvaluÃÂe comme ÃÂtant ÃÂ true ÃÂ
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de ÃÂ 
coord_is_unprepped_ctail ÃÂ sera toujours ÃÂvaluÃÂe comme ÃÂtant ÃÂ 
true ÃÂ

Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>

--- fs/reiser4/plugin/item/ctail.c	2005-03-01 14:32:10.750179296 +0100
+++ fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:46:15.282790824 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = "bad cluster shift in ctail";
 		return 1;

-- 
What would you expect to gain from XIP besides being buzzword
compliant?

- Erik Mouw on linux-arm-kernel

Re: 2.6.11-rc5-mm1

On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/

> - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
>   makes pcmcia work more like regular hotpluggable devices.  See the
>   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
>   details.

This is still showing the same 'cs: unable to map card memory!' issue on my
Dell laptop.  Backing out bk-pci.patch makes it work again.

For what it's worth, the hotplug system wasn't able to initialize the wireless
card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
But that might just me being an idiot...



pgpNIo72wMPGQ.pgp
Description: PGP signature

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

 On Mon, Feb 28, Antonino A. Daplas wrote:

> On Monday 28 February 2005 04:32, Olaf Hering wrote:
> >  On Wed, Feb 23, Linus Torvalds wrote:
> > > This time it's really supposed to be a quickie, so people who can, please
> > > check it out, and we'll make the real 2.6.11 asap.
> >
> > Here is another one, probably not new.
> > Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
> > member in riva_par->riva_i2c_chan? It calls riva_probe_i2c_connector
> > even if riva_create_i2c_busses fails to register all 3 busses.
> >
> 
> Thanks,
> 
> Can you try this?
> 
> Fixed error handling in rivafb-i2c.c if bus registration fails.

I havent heard back from the reporter, yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

hi benjamin

now i had some spare time to do some investigation

booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
brings up a framebuffer console. everything is fine.
starting xorg-x11 with Ati binary only drivers just brings up a black screen
without a mouse cursor and freezes the hole machine. even network ect. 
is no more reachable from outside the machine. worst thing out of that
a tail on the log files (on another machine) does immediately stop - also no 
output is written to syslog :/

next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
starting xorg-x11 with Xorg Radeon driver. 
a grey screen comes up - mouse cursor is visible and also able to move for
5 - 8 seconds after screen display - then freezes the whole machine again.

regards
marcel

On Saturday 26 February 2005 01:50, Benjamin Herrenschmidt wrote:
> On Fri, 2005-02-25 at 14:30 +0100, Mws wrote:
> > hi,
> > 
> > i also have problems with 2.6.11-rc5 and radeon:
> > 
> > i am using a ATI Radeon X600 PciExpress.
> > 
> > a) now the console framebuffer seems to bee working, thx benjamin :)
> > b) when bootup seq ist completed and i want to start X (xorg-x11) with 
> > ati-drivers
> > x is freezing - not your problem, but the console is not correctly 
> > restored :/ the only way
> > out is to reset the machine :/
> > 2.6.11-rc3 was running fine in this case
> 
> Hrm, the binary drivers ? oh well... some users had them freezing vs.
> radeonfb before and not now. I don't know what they do and don't have
> access to a machine with them (there are no ppc versions) so it will be
> difficult to track. I suspect they completely reconfigure the chip and
> don't restore it properly tho.

> What exactly is happening. Does X launches at all ? When does it
> freeze ? On X launch or when exiting it ? Have you tried disabling
> dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the
> cmdline, first one means "don't touch the registers", secoond one means
> "disable dynamic clocks").

pgpBlKkcSxfka.pgp
Description: PGP signature

Re: Fw: Re: 2.6.11-rc5-mm1

2005-03-01 Thread Alexander Gran

Am Dienstag, 1. März 2005 11:48 schrieb Andrew Morton:
> Alex, please use mailing lists...

sorry, I was used to have reply-to set to the mailing list ;) 
double-checking next time..

> Dominik, do we really always want to drag in the firmware loader if
> CONFIG_PCMCIA?

Hmm. I've enabled the firmware loader that fixes at least the compile error...
Now rebooting. More info after my system programming exam in 1 hour. ;)

regards
Alex

> Begin forwarded message:
>
> Date: Tue, 1 Mar 2005 11:35:40 +0100
> From: Alexander Gran <[EMAIL PROTECTED]>
> To: Andrew Morton <[EMAIL PROTECTED]>
> Subject: Re: 2.6.11-rc5-mm1
>
> Am Dienstag, 1. März 2005 10:27 schrieben Sie:
> > - A pcmcia update which obsoletes cardmgr (although cardmgr still works)
> > and makes pcmcia work more like regular hotpluggable devices.  See the
> > changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch
> > for details.
>
> drivers/built-in.o(.text+0xdd219): In function `pcmcia_load_firmware':
> : undefined reference to `request_firmware'
>
> drivers/built-in.o(.text+0xdd295): In function `pcmcia_load_firmware':
> : undefined reference to `release_firmware'
>
> make: *** [.tmp_vmlinux1] Error 1
>
> .config attached
>
> regards
> Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: Re: 2.6.11-rc5-mm1

2005-03-01 Thread Alexander Gran

Am Dienstag, 1. März 2005 11:48 schrieb Andrew Morton:
 Alex, please use mailing lists...

sorry, I was used to have reply-to set to the mailing list ;) 
double-checking next time..

 Dominik, do we really always want to drag in the firmware loader if
 CONFIG_PCMCIA?

Hmm. I've enabled the firmware loader that fixes at least the compile error...
Now rebooting. More info after my system programming exam in 1 hour. ;)

regards
Alex

 Begin forwarded message:

 Date: Tue, 1 Mar 2005 11:35:40 +0100
 From: Alexander Gran [EMAIL PROTECTED]
 To: Andrew Morton [EMAIL PROTECTED]
 Subject: Re: 2.6.11-rc5-mm1

 Am Dienstag, 1. März 2005 10:27 schrieben Sie:
  - A pcmcia update which obsoletes cardmgr (although cardmgr still works)
  and makes pcmcia work more like regular hotpluggable devices.  See the
  changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch
  for details.

 drivers/built-in.o(.text+0xdd219): In function `pcmcia_load_firmware':
 : undefined reference to `request_firmware'

 drivers/built-in.o(.text+0xdd295): In function `pcmcia_load_firmware':
 : undefined reference to `release_firmware'

 make: *** [.tmp_vmlinux1] Error 1

 .config attached

 regards
 Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

hi benjamin

now i had some spare time to do some investigation

booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
brings up a framebuffer console. everything is fine.
starting xorg-x11 with Ati binary only drivers just brings up a black screen
without a mouse cursor and freezes the hole machine. even network ect. 
is no more reachable from outside the machine. worst thing out of that
a tail on the log files (on another machine) does immediately stop - also no 
output is written to syslog :/

next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
starting xorg-x11 with Xorg Radeon driver. 
a grey screen comes up - mouse cursor is visible and also able to move for
5 - 8 seconds after screen display - then freezes the whole machine again.

regards
marcel


On Saturday 26 February 2005 01:50, Benjamin Herrenschmidt wrote:
 On Fri, 2005-02-25 at 14:30 +0100, Mws wrote:
  hi,
  
  i also have problems with 2.6.11-rc5 and radeon:
  
  i am using a ATI Radeon X600 PciExpress.
  
  a) now the console framebuffer seems to bee working, thx benjamin :)
  b) when bootup seq ist completed and i want to start X (xorg-x11) with 
  ati-drivers
  x is freezing - not your problem, but the console is not correctly 
  restored :/ the only way
  out is to reset the machine :/
  2.6.11-rc3 was running fine in this case
 
 Hrm, the binary drivers ? oh well... some users had them freezing vs.
 radeonfb before and not now. I don't know what they do and don't have
 access to a machine with them (there are no ppc versions) so it will be
 difficult to track. I suspect they completely reconfigure the chip and
 don't restore it properly tho.


 
 What exactly is happening. Does X launches at all ? When does it
 freeze ? On X launch or when exiting it ? Have you tried disabling
 dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the
 cmdline, first one means don't touch the registers, secoond one means
 disable dynamic clocks).
 


pgpBlKkcSxfka.pgp
Description: PGP signature

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

 On Mon, Feb 28, Antonino A. Daplas wrote:

 On Monday 28 February 2005 04:32, Olaf Hering wrote:
   On Wed, Feb 23, Linus Torvalds wrote:
   This time it's really supposed to be a quickie, so people who can, please
   check it out, and we'll make the real 2.6.11 asap.
 
  Here is another one, probably not new.
  Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
  member in riva_par-riva_i2c_chan? It calls riva_probe_i2c_connector
  even if riva_create_i2c_busses fails to register all 3 busses.
 
 
 Thanks,
 
 Can you try this?
 
 Fixed error handling in rivafb-i2c.c if bus registration fails.

I havent heard back from the reporter, yet.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/

 - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
   makes pcmcia work more like regular hotpluggable devices.  See the
   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
   details.

This is still showing the same 'cs: unable to map card memory!' issue on my
Dell laptop.  Backing out bk-pci.patch makes it work again.

For what it's worth, the hotplug system wasn't able to initialize the wireless
card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
But that might just me being an idiot...



pgpNIo72wMPGQ.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1

On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/

- A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
makes pcmcia work more like regular hotpluggable devices. See the
changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
details.

This is still showing the same 'cs: unable to map card memory!' issue on my
Dell laptop. Backing out bk-pci.patch makes it work again.

For what it's worth, the hotplug system wasn't able to initialize the wireless
card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
But that might just me being an idiot...

It's probably a clash between the PCI updates and the PCMCIA updates.

The PCI updates change the prototype of a helper function for
pci_bus_alloc_resource(), but don't touch the actual helper function
in PCMCIA.

This means that the PCI update is actually broken - if it's merged as
is into Linus' tree, PCMCIA will break there as well.

Can whoever did the PCI update please resolve this mismatch. Moreover,
if 2.6.11 appears, please do not merge the PCI updates until this has
been resolved. Thanks.

--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Andrew Morton [EMAIL PROTECTED] disait dernirement que :

 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/


 - Lots of tuning/balancing changes in the CPU scheduler.  Mainly targetted
   at larger SMT/SMP/NUMA machines.  It's going to be hard to work out whether
   these are a net benefit.

 - A pcmcia update which obsoletes cardmgr (although cardmgr still works) and
   makes pcmcia work more like regular hotpluggable devices.  See the
   changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch for
   details.

 - A new reiser4 code drop.

By the way, I got an strange warning compiling fs/reiser4/plugin/ctail.c
obvious fix is attached

fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de  ctail_ok  
sera toujours value comme tant  true 
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de  
coord_is_unprepped_ctail  sera toujours value comme tant  
true 

Signed-off-by: Mathieu Segaud [EMAIL PROTECTED]

--- fs/reiser4/plugin/item/ctail.c	2005-03-01 14:32:10.750179296 +0100
+++ fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:46:15.282790824 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = bad cluster shift in ctail;
 		return 1;

-- 
What would you expect to gain from XIP besides being buzzword
compliant?

- Erik Mouw on linux-arm-kernel

Re: 2.6.11-rc5-mm1

Mathieu Segaud [EMAIL PROTECTED] disait dernirement que :

Hum, one hunk didn't make it.
The complete patch is attached


 fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
 fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de  ctail_ok 
  sera toujours value comme tant  true 
 fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
 fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de  
 coord_is_unprepped_ctail  sera toujours value comme tant  
 true 


Signed-off-by: Mathieu Segaud [EMAIL PROTECTED]

--- fs/reiser4/plugin/item/ctail.c	2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = bad cluster shift in ctail;
 		return 1;
@@ -1666,7 +1666,7 @@
 		detach_convert_idata(pos-sq);
 		break;
 	case CRC_OVERWRITE_ITEM:
-		if (coord_is_unprepped_ctail) {
+		if (coord_is_unprepped_ctail(pos-coord)) {
 			/* convert unpprepped ctail to prepped one */
 			int shift;
 			shift = inode_cluster_shift(item_convert_data(pos)-inode);


-- 
Outlook, n.:
A virus delivery system with added email functionality.

- Kurt Wall on linux-kernel

Re: 2.6.11-rc5-mm1

Mathieu Segaud [EMAIL PROTECTED] disait dernirement que :

 Mathieu Segaud [EMAIL PROTECTED] disait dernirement que :

 Hum, one hunk didn't make it.
 The complete patch is attached

as any time I post with no sleep for 3 days, more noodles than brain
are in my skull. Did tha wrong strip level, didn't I ?

well, this the last one, with every hunk, and correct strip level

--- linux/fs/reiser4/plugin/item/ctail.c	2005-03-01 14:57:52.756014040 +0100
+++ linux/fs/reiser4/plugin/item/ctail.c.new	2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
 reiser4_internal int
 check_ctail (const coord_t * coord, const char **error)
 {
-	if (!ctail_ok) {
+	if (!ctail_ok(coord)) {
 		if (error)
 			*error = bad cluster shift in ctail;
 		return 1;
@@ -1666,7 +1666,7 @@
 		detach_convert_idata(pos-sq);
 		break;
 	case CRC_OVERWRITE_ITEM:
-		if (coord_is_unprepped_ctail) {
+		if (coord_is_unprepped_ctail(pos-coord)) {
 			/* convert unpprepped ctail to prepped one */
 			int shift;
 			shift = inode_cluster_shift(item_convert_data(pos)-inode);

Regards, time to go to bed

-- 
 
  Wait. Don't you mean:

Yes. Just ignore me when I show extreme signs of Alzheimers.

- Linus Torvalds on linux-kernel

Re: 2.6.11-rc5

2005-03-01 Thread Helge Hafting

Mws wrote:
hi benjamin
now i had some spare time to do some investigation
booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
brings up a framebuffer console. everything is fine.
starting xorg-x11 with Ati binary only drivers just brings up a black screen
without a mouse cursor and freezes the hole machine. even network ect. 
is no more reachable from outside the machine. worst thing out of that
a tail on the log files (on another machine) does immediately stop - also no 
output is written to syslog :/

next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
starting xorg-x11 with Xorg Radeon driver. 
a grey screen comes up - mouse cursor is visible and also able to move for
5 - 8 seconds after screen display - then freezes the whole machine again.
 

Did you try without dri? (Comment out dri in the X config file)
I use a radeon 7000 VE at work, where X will hang after a few
seconds if dri is enabled in X.  Disable dri, and it is
rock solid. xfree or x.org makes no difference here.
Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

On Tuesday 01 March 2005 15:36, Helge Hafting wrote:
 Mws wrote:
 
 hi benjamin
 
 now i had some spare time to do some investigation
 
 booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
 brings up a framebuffer console. everything is fine.
 starting xorg-x11 with Ati binary only drivers just brings up a black screen
 without a mouse cursor and freezes the hole machine. even network ect. 
 is no more reachable from outside the machine. worst thing out of that
 a tail on the log files (on another machine) does immediately stop - also no 
 output is written to syslog :/
 
 next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
 starting xorg-x11 with Xorg Radeon driver. 
 a grey screen comes up - mouse cursor is visible and also able to move for
 5 - 8 seconds after screen display - then freezes the whole machine again.
   
 
 Did you try without dri? (Comment out dri in the X config file)
 I use a radeon 7000 VE at work, where X will hang after a few
 seconds if dri is enabled in X.  Disable dri, and it is
 rock solid. xfree or x.org makes no difference here.
 
 Helge Hafting

hi, 

i had dri disabled already :/

regards
marcel


pgpml38TTNxWC.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1

On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
 On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
  This is still showing the same 'cs: unable to map card memory!' issue on my
  Dell laptop.  Backing out bk-pci.patch makes it work again.
  
  For what it's worth, the hotplug system wasn't able to initialize the 
  wireless
  card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
  But that might just me being an idiot...
 
 It's probably a clash between the PCI updates and the PCMCIA updates.
 
 The PCI updates change the prototype of a helper function for 
 pci_bus_alloc_resource(), but don't touch the actual helper function
 in PCMCIA.

That explains the warning messages that gcc was tossing, which I suspected was
involved...

 This means that the PCI update is actually broken - if it's merged as
 is into Linus' tree, PCMCIA will break there as well.

Is the patch made to PCI actually incorrect, or is the proper way to do this
to propagate the changes into the relevant PCMCIA code?



pgpZrYJ6IDch6.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Edward Shishkin

Mathieu Segaud wrote:
Mathieu Segaud [EMAIL PROTECTED] disait dernirement que :
Hum, one hunk didn't make it.
The complete patch is attached
 

fs/reiser4/plugin/item/ctail.c: In function `check_ctail':
fs/reiser4/plugin/item/ctail.c:250: attention : l'adresse de  ctail_ok  sera toujours value comme 
tant  true 
fs/reiser4/plugin/item/ctail.c: In function `convert_ctail':
fs/reiser4/plugin/item/ctail.c:1669: attention : l'adresse de  coord_is_unprepped_ctail  sera toujours 
value comme tant  true 
   

Signed-off-by: Mathieu Segaud [EMAIL PROTECTED]
 

 

Thanks for  catching this.
Edward.

--- fs/reiser4/plugin/item/ctail.c  2005-03-01 14:57:52.756014040 +0100
+++ fs/reiser4/plugin/item/ctail.c.new  2005-03-01 14:57:19.791025480 +0100
@@ -247,7 +247,7 @@
reiser4_internal int
check_ctail (const coord_t * coord, const char **error)
{
-   if (!ctail_ok) {
+   if (!ctail_ok(coord)) {
if (error)
*error = bad cluster shift in ctail;
return 1;
@@ -1666,7 +1666,7 @@
detach_convert_idata(pos-sq);
break;
case CRC_OVERWRITE_ITEM:
-   if (coord_is_unprepped_ctail) {
+   if (coord_is_unprepped_ctail(pos-coord)) {
/* convert unpprepped ctail to prepped one */
int shift;
shift = 
inode_cluster_shift(item_convert_data(pos)-inode);

 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

On Tue, Mar 01, 2005 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote:
 On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
  The PCI updates change the prototype of a helper function for 
  pci_bus_alloc_resource(), but don't touch the actual helper function
  in PCMCIA.
 
 That explains the warning messages that gcc was tossing, which I suspected was
 involved...
 
  This means that the PCI update is actually broken - if it's merged as
  is into Linus' tree, PCMCIA will break there as well.
 
 Is the patch made to PCI actually incorrect, or is the proper way to do this
 to propagate the changes into the relevant PCMCIA code?

PCI has been updated to accept 64-bit resources, but the PCMCIA code 
has been missed.  So the correct fix is to propagate the changes where
necessary into the PCMCIA code.

The minimalist solution is to fix up the PCMCIA alignment functions.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1 (compile stats)

2005-03-01 Thread John Cherry

Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

KernelbzImage   bzImage  bzImage  modules  bzImage  modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--- --     
2.6.11-rc5-mm1   21w/0e 0w/0e   262w/0e   10w/0e  26w/0e238w/0e
2.6.11-rc4-mm1   22w/0e 0w/0e   271w/0e   10w/0e  25w/0e249w/0e
2.6.11-rc3-mm2   14w/0e 0w/0e   192w/0e6w/0e  19w/0e172w/0e
2.6.11-rc3-mm1   13w/10e0w/7e   196w/12e   6w/0e  18w/12e   177w/0e
2.6.11-rc2-mm2   15w/0e 0w/0e   201w/0e6w/0e  18w/0e182w/0e
2.6.11-rc2-mm1   15w/0e 0w/0e   306w/14e   6w/0e  18w/0e294w/0e
2.6.11-rc1-mm2   21w/0e 0w/0e   316w/9e6w/0e  22w/0e294w/0e
2.6.11-rc1-mm1   21w/0e 0w/0e   319w/0e6w/0e  23w/0e298w/0e
2.6.10-mm3   21w/0e 0w/0e   320w/0e6w/0e  23w/0e299w/0e
2.6.10-mm2   21w/0e 0w/0e   440w/0e6w/0e  23w/0e420w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-rc1-mm1   16w/1e 1w/1e   592w/1e4w/0e  13w/1e857w/0e
2.6.9-mm1 6w/1e 1w/1e  1761w/15e  65w/0e   9w/0e   2086w/0e
2.6.9-rc4-mm1 5w/0e 0w/0e  1766w/11e  43w/0e   6w/0e   1798w/0e
2.6.9-rc3-mm3 5w/0e 0w/0e  1756w/11e  43w/0e   4w/0e   1786w/0e
2.6.9-rc3-mm210w/0e 4w/9e  1754w/14e  43w/0e   4w/0e   1782w/1e
2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e   43w/0e   4w/0e   1796w/0e
2.6.9-rc2-mm410w/0e 5w/0e  2573w/0e   41w/0e   4w/0e   2600w/0e
2.6.9-rc2-mm310w/0e 5w/0e  2400w/0e   41w/0e   4w/0e   2435w/0e
2.6.9-rc2-mm210w/0e 5w/0e  2919w/0e   41w/0e   4w/0e   2954w/0e
2.6.9-rc2-mm1 0w/0e 2w/0e  3541w/9e   41w/0e   3w/9e   3567w/0e
2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e   2w/0e 48w/0e
2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e   3w/0e   1w/0e 49w/1e
2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e   3w/0e   1w/0e 47w/0e
2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e   1w/0e 74w/0e
2.6.8.1-mm4   0w/0e 0w/0e78w/0e4w/0e   1w/0e 73w/0e
2.6.8.1-mm3   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm2   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm1   0w/0e 0w/0e78w/0e4w/0e   1w/0e 74w/0e
2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e   1w/0e 75w/0e
2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e   2w/8e 75w/0e
2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e   1w/0e 75w/0e
2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e   1w/0e 80w/0e
2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e   1w/0e 81w/0e
2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e   1w/0e 87w/0e
2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e   1w/0e 84w/0e
2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e   1w/0e 80w/0e
2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e   1w/0e 87w/0e
2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e   1w/0e 89w/0e
2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e   1w/0e 86w/0e
2.6.7-mm2 0w/0e 0w/0e   109w/0e7w/0e   1w/0e106w/0e
2.6.7-mm1 0w/0e 5w/0e   108w/0e5w/0e   1w/0e104w/0e
2.6.7-rc3-mm2 0w/0e 5w/0e   105w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc3-mm1 0w/0e 5w/0e   104w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc2-mm2 0w/0e 5w/0e   109w/10e

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Adrian Bunk

On Tue, Mar 01, 2005 at 01:27:41AM -0800, Andrew Morton wrote:
...
 All 728 patches:
...
 reiser4-rcu-barrier.patch
   reiser4: add rcu_barrier() synchronization point

Considering the patent situation at least in the USA, the 
EXPORT_SYMBOL(rcu_barrier) has to become an EXPORT_SYMBOL_GPL.

 reiser4-export-inode_lock.patch
   reiser4: export inode_lock to modules
...

__iget seems to be no longer used by reiser4.
This part of the patch can therefore be dropped.

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Greg KH

On Tue, Mar 01, 2005 at 01:55:29PM +, Russell King wrote:
On Tue, Mar 01, 2005 at 08:36:36AM -0500, [EMAIL PROTECTED] wrote:
On Tue, 01 Mar 2005 01:27:41 PST, Andrew Morton said:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/

- A pcmcia update which obsoletes cardmgr (although cardmgr still works)
and
makes pcmcia work more like regular hotpluggable devices. See the
changelong in pcmcia-dont-send-eject-request-events-to-userspace.patch
for
details.

This is still showing the same 'cs: unable to map card memory!' issue on my
Dell laptop. Backing out bk-pci.patch makes it work again.

For what it's worth, the hotplug system wasn't able to initialize the
wireless
card (TrueMobile 1150) at boot - still needed cardmgr to get it started up.
But that might just me being an idiot...

It's probably a clash between the PCI updates and the PCMCIA updates.

The PCI updates change the prototype of a helper function for
pci_bus_alloc_resource(), but don't touch the actual helper function
in PCMCIA.

This means that the PCI update is actually broken - if it's merged as
is into Linus' tree, PCMCIA will break there as well.

Can whoever did the PCI update please resolve this mismatch. Moreover,
if 2.6.11 appears, please do not merge the PCI updates until this has
been resolved. Thanks.

Andrew had a stale bk-pci tree in his local copy, and that is where that
change came from. It will not show up in the next -mm release, and will
not be sent to Linus until after I have fixed up the _whole_ tree.

So sorry for the inconvience.

thakns,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Russell King [EMAIL PROTECTED] wrote:

 On Tue, Mar 01, 2005 at 10:18:56AM -0500, [EMAIL PROTECTED] wrote:
  On Tue, 01 Mar 2005 13:55:29 GMT, Russell King said:
   The PCI updates change the prototype of a helper function for 
   pci_bus_alloc_resource(), but don't touch the actual helper function
   in PCMCIA.
  
  That explains the warning messages that gcc was tossing, which I suspected 
  was
  involved...
  
   This means that the PCI update is actually broken - if it's merged as
   is into Linus' tree, PCMCIA will break there as well.
  
  Is the patch made to PCI actually incorrect, or is the proper way to do this
  to propagate the changes into the relevant PCMCIA code?
 
 PCI has been updated to accept 64-bit resources, but the PCMCIA code 
 has been missed.  So the correct fix is to propagate the changes where
 necessary into the PCMCIA code.

hmm, I missed that.  That's the price of two screenfuls of fscking compile
warnings.

 The minimalist solution is to fix up the PCMCIA alignment functions.

Greg's dropping the 64-bit-resource patch for now.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Re: 2.6.11-rc5, rivafb i2c oops, bogus error handling

 On Mon, Feb 28, Antonino A. Daplas wrote:

 On Monday 28 February 2005 04:32, Olaf Hering wrote:
   On Wed, Feb 23, Linus Torvalds wrote:
   This time it's really supposed to be a quickie, so people who can, please
   check it out, and we'll make the real 2.6.11 asap.
 
  Here is another one, probably not new.
  Is riva_get_EDID_i2c a bit too optimistic by not having a $i2cadapter_ok
  member in riva_par-riva_i2c_chan? It calls riva_probe_i2c_connector
  even if riva_create_i2c_busses fails to register all 3 busses.

Side note:

[EMAIL PROTECTED]: connect to
lists.surfsouth.com[216.128.200.12]: Connection timed out

Is this one supposed to work? perhaps the MAINTAINERS entry needs an
update.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

2005-03-01 Thread Benjamin Herrenschmidt

On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
 hi benjamin
 
 now i had some spare time to do some investigation
 
 booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
 brings up a framebuffer console. everything is fine.
 starting xorg-x11 with Ati binary only drivers just brings up a black screen
 without a mouse cursor and freezes the hole machine. even network ect. 
 is no more reachable from outside the machine. worst thing out of that
 a tail on the log files (on another machine) does immediately stop - also no 
 output is written to syslog :/
 
 next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
 starting xorg-x11 with Xorg Radeon driver. 
 a grey screen comes up - mouse cursor is visible and also able to move for
 5 - 8 seconds after screen display - then freezes the whole machine again.

Ok, so it's not dynamic clocks. At this point, i have no idea what's
going on. I don't yet have any access to PCI Express hardware. You
should report this to X.org list where others can try to help me track
this down.

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

2005-03-01 Thread Chris Wright

* Andrew Morton ([EMAIL PROTECTED]) wrote:
 - I seem to be getting a lot of patches which don't compile if you breathe
   on the .config file, let alone if you try them on another architecture.  It
   would be nice to receive less such patches, please.

The ia64 audit bit is likely my fault from the audit header detangle.
I did try w/ and w/out CONFIG_AUDITSYSCALL set, but only on one arch.
I also did a grep, but was only looking at audit_putname/getname, and
missed the others.  I just did a more complete grep of the symbols that
can get config'd away (including CONFIG_AUDIT as well), and I think
there's a few more missing pieces.  Sorry about that.  Jeff, Ralf,
Martin, these look ok?

thanks,
-chris
--

A closer sweep of configurable audit symbols shows the following need
audit.h included when audit.h is detangled from fs.h as in -mm.

arch/um/kernel/ptrace.cfor audit_syscall_entry/exit
arch/s390/kernel/ptrace.c  for audit_syscall_entry/exit
arch/mips/kernel/ptrace.c  for audit_syscall_entry/exit

Signed-off-by: Chris Wright [EMAIL PROTECTED]

= arch/um/kernel/ptrace.c 1.21 vs edited =
--- 1.21/arch/um/kernel/ptrace.c2005-01-20 20:59:15 -08:00
+++ edited/arch/um/kernel/ptrace.c  2005-03-01 13:23:06 -08:00
@@ -9,6 +9,7 @@
 #include linux/smp_lock.h
 #include linux/security.h
 #include linux/ptrace.h
+#include linux/audit.h
 #ifdef CONFIG_PROC_MM
 #include linux/proc_mm.h
 #endif
= arch/s390/kernel/ptrace.c 1.28 vs edited =
--- 1.28/arch/s390/kernel/ptrace.c  2005-01-04 18:48:19 -08:00
+++ edited/arch/s390/kernel/ptrace.c2005-03-01 13:22:45 -08:00
@@ -31,6 +31,7 @@
 #include linux/ptrace.h
 #include linux/user.h
 #include linux/security.h
+#include linux/audit.h
 
 #include asm/segment.h
 #include asm/page.h
= arch/mips/kernel/ptrace.c 1.15 vs edited =
--- 1.15/arch/mips/kernel/ptrace.c  2005-01-30 22:20:14 -08:00
+++ edited/arch/mips/kernel/ptrace.c2005-03-01 13:24:48 -08:00
@@ -25,6 +25,7 @@
 #include linux/smp_lock.h
 #include linux/user.h
 #include linux/security.h
+#include linux/audit.h
 
 #include asm/cpu.h
 #include asm/fpu.h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5-mm1

Adrian Bunk [EMAIL PROTECTED] wrote:

 On Tue, Mar 01, 2005 at 01:27:41AM -0800, Andrew Morton wrote:
 ...
  All 728 patches:
 ...
  reiser4-rcu-barrier.patch
reiser4: add rcu_barrier() synchronization point
 
 Considering the patent situation at least in the USA, the 
 EXPORT_SYMBOL(rcu_barrier) has to become an EXPORT_SYMBOL_GPL.

I'll make that change.

  reiser4-export-inode_lock.patch
reiser4: export inode_lock to modules
 ...
 
 __iget seems to be no longer used by reiser4.
 This part of the patch can therefore be dropped.

And that one.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc5

On Tuesday 01 March 2005 22:38, Benjamin Herrenschmidt wrote:
 On Tue, 2005-03-01 at 12:36 +0100, Mws wrote:
  hi benjamin
  
  now i had some spare time to do some investigation
  
  booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1
  brings up a framebuffer console. everything is fine.
  starting xorg-x11 with Ati binary only drivers just brings up a black screen
  without a mouse cursor and freezes the hole machine. even network ect. 
  is no more reachable from outside the machine. worst thing out of that
  a tail on the log files (on another machine) does immediately stop - also 
  no 
  output is written to syslog :/
  
  next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1
  starting xorg-x11 with Xorg Radeon driver. 
  a grey screen comes up - mouse cursor is visible and also able to move for
  5 - 8 seconds after screen display - then freezes the whole machine again.
 
 Ok, so it's not dynamic clocks. At this point, i have no idea what's
 going on. I don't yet have any access to PCI Express hardware. You
 should report this to X.org list where others can try to help me track
 this down.
 
 Ben.

it's possible to do so, but i also will try to find out whats going on.
i don't know if i will have success.

regards
marcel



pgp2GpCGx86XC.pgp
Description: PGP signature

Re: 2.6.11-rc5-mm1