Re: Linux 3.19-rc1 - merge window closed

[Grant Coady]

On Mon, 22 Dec 2014 12:43:10 -0800, you wrote:

>On Sat, 20 Dec 2014 23:11:39 -0800 "Nicholas A. Bellinger" 
> wrote:
>
>> Just hit the following build failure with CONFIG_AUDIT=y:
>> 
>> arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’:
>> arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in 
>> this function)
>> arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported 
>> only once for each function it appears in
>> make[2]: *** [arch/x86/ia32/audit.o] Error 1
>> make[1]: *** [arch/x86/ia32] Error 2
>> make: *** [arch/x86] Error 2
>> make: *** Waiting for unfinished jobs
>
>Your .config works for me.  Does a `make mrproper' fix it?

Wow. So long since I use make mrproper...

>
>I've seen a few reports like this in recent months.  Something's
>up with the build dependency system.

Yes, but nothing a fresh unpack tarball then start over didn't fix ;o)

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

Re: Linux 3.19-rc1 - merge window closed

[Grant Coady]

On Mon, 22 Dec 2014 12:43:10 -0800, you wrote:

On Sat, 20 Dec 2014 23:11:39 -0800 Nicholas A. Bellinger 
n...@linux-iscsi.org wrote:

 Just hit the following build failure with CONFIG_AUDIT=y:
 
 arch/x86/ia32/audit.c: In function ‘ia32_classify_syscall’:
 arch/x86/ia32/audit.c:38:7: error: ‘__NR_execveat’ undeclared (first use in 
 this function)
 arch/x86/ia32/audit.c:38:7: note: each undeclared identifier is reported 
 only once for each function it appears in
 make[2]: *** [arch/x86/ia32/audit.o] Error 1
 make[1]: *** [arch/x86/ia32] Error 2
 make: *** [arch/x86] Error 2
 make: *** Waiting for unfinished jobs

Your .config works for me.  Does a `make mrproper' fix it?

Wow. So long since I use make mrproper...


I've seen a few reports like this in recent months.  Something's
up with the build dependency system.

Yes, but nothing a fresh unpack tarball then start over didn't fix ;o)

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

3.7.5: Kernel panic on halt

[Grant Coady]

Hi there,

I was running machine overnight on 12V battery test, with this simple 
kernel compile loop:

  grant@itxmini:~/linux/linux-3.7.5a$ while :; do make clean; make -j5; done

Today it was time to shutdown the box ('halt' command) and recharge the battery.

Snapshot of screen:

  
http://bugsplatter.id.au/misc/image/IMG_5627-kernel-panic-itxmini-2013-01-05.jpg

Kernel .config and dmesg:

  http://bugsplatter.id.au/kernel/boxen/itxmini/config-3.7.5a.gz
  http://bugsplatter.id.au/kernel/boxen/itxmini/dmesg-3.7.5a.gz

Box is Intel D510MO mobo with dual core HT Atom CPU with 2GB memory, 2GB 
swap (unused), Intel pro/100 NIC (disconnected), onboard PS/2 keyboard, 
ps/2 mouse, 1Gbps NIC, VGA monitor connected.

What next?  Box rebooted normally.  Ha

Thanks,
Grant.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3.7.5: Kernel panic on halt

[Grant Coady]

Hi there,

I was running machine overnight on 12V battery test, with this simple 
kernel compile loop:

  grant@itxmini:~/linux/linux-3.7.5a$ while :; do make clean; make -j5; done

Today it was time to shutdown the box ('halt' command) and recharge the battery.

Snapshot of screen:

  
http://bugsplatter.id.au/misc/image/IMG_5627-kernel-panic-itxmini-2013-01-05.jpg

Kernel .config and dmesg:

  http://bugsplatter.id.au/kernel/boxen/itxmini/config-3.7.5a.gz
  http://bugsplatter.id.au/kernel/boxen/itxmini/dmesg-3.7.5a.gz

Box is Intel D510MO mobo with dual core HT Atom CPU with 2GB memory, 2GB 
swap (unused), Intel pro/100 NIC (disconnected), onboard PS/2 keyboard, 
ps/2 mouse, 1Gbps NIC, VGA monitor connected.

What next?  Box rebooted normally.  Ha

Thanks,
Grant.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RAID extremely slow

[Grant Coady]

On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:

>On 07/27/2012 12:08 PM, Bill Davidsen wrote:
>> Have you set the io scheduler to deadline on all members of the array? 
>> That's kind of "job one" on older kernels.
>>
>
>I have not, thanks for the tip, I'll look into that now.

Plus I disable the on-drive queuing (NCQ) during startup, right now 
I don't have benchmarks to show the difference.  This on a six by 1TB 
drive RAID6 array I built over a year ago on Slackware64-13.37:

# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo "rc.local: Disable RAID drives' NCQ"
for d in a b c d e f
do
echo "  set NCQ depth to $n on sd${d}"
echo $n > /sys/block/sd${d}/device/queue_depth
done
...

Maybe you could try that?  See if it makes a difference.  My drives 
are Seagate.

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

Re: RAID extremely slow

[Grant Coady]

On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:

On 07/27/2012 12:08 PM, Bill Davidsen wrote:
 Have you set the io scheduler to deadline on all members of the array? 
 That's kind of job one on older kernels.


I have not, thanks for the tip, I'll look into that now.

Plus I disable the on-drive queuing (NCQ) during startup, right now 
I don't have benchmarks to show the difference.  This on a six by 1TB 
drive RAID6 array I built over a year ago on Slackware64-13.37:

# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo rc.local: Disable RAID drives' NCQ
for d in a b c d e f
do
echo   set NCQ depth to $n on sd${d}
echo $n  /sys/block/sd${d}/device/queue_depth
done
...

Maybe you could try that?  See if it makes a difference.  My drives 
are Seagate.

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

Re: Intel DP965LT Mainboard running?

[Grant Coady]

On Sat, 31 Mar 2007 00:31:38 +0200, Oliver Joa <[EMAIL PROTECTED]> wrote:

>Hi,
>
>does anyone have a running Intel DP965LT Mainboard? I can not get this 
>Board running. You can see the Problems in the Thread "Corrupt 
>XFS-Filesystems on new Hardware and Kernel". Please can you give me a 
>running Kernel-Config?

http://bugsplatter.mine.nu/system/dp965lt.html  some notes and gotchas
http://bugsplatter.mine.nu/test/boxen/silly/configs and dmesgs

I've only had reiserfs and ext3 going, not XFS.  

Grant.
-
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: Intel DP965LT Mainboard running?

[Grant Coady]

On Sat, 31 Mar 2007 00:31:38 +0200, Oliver Joa [EMAIL PROTECTED] wrote:

Hi,

does anyone have a running Intel DP965LT Mainboard? I can not get this 
Board running. You can see the Problems in the Thread Corrupt 
XFS-Filesystems on new Hardware and Kernel. Please can you give me a 
running Kernel-Config?

http://bugsplatter.mine.nu/system/dp965lt.html  some notes and gotchas
http://bugsplatter.mine.nu/test/boxen/silly/configs and dmesgs

I've only had reiserfs and ext3 going, not XFS.  

Grant.
-
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 2.4.34.1

[Grant Coady]

On Sat, 3 Feb 2007 20:10:45 +, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hi all,
>
>activity has been very calm for 2.4 since 2.4.34. Three minor fixes
>were pending, and I finally decided to release 2.4.34.1 with them
>instead of keeping them in the fridge. Upgrade is recommended for
>users of smbfs with unix extension, since a security fix in 2.4.34
>broke symlinks. Special thanks to Dann Frazier, Santiago Garcia
>and Grant Coady who did the boring work of tracking and fixing the
>problem.
>
>The files are located at the usual places. Please give it some time
>to sync between the servers, and preferably use ftp2.kernel.org.

Hi Willy,

Done, runs okay here ;)

Grant.
-
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 2.4.34.1

[Grant Coady]

On Sat, 3 Feb 2007 20:10:45 +, Willy Tarreau [EMAIL PROTECTED] wrote:

Hi all,

activity has been very calm for 2.4 since 2.4.34. Three minor fixes
were pending, and I finally decided to release 2.4.34.1 with them
instead of keeping them in the fridge. Upgrade is recommended for
users of smbfs with unix extension, since a security fix in 2.4.34
broke symlinks. Special thanks to Dann Frazier, Santiago Garcia
and Grant Coady who did the boring work of tracking and fixing the
problem.

The files are located at the usual places. Please give it some time
to sync between the servers, and preferably use ftp2.kernel.org.

Hi Willy,

Done, runs okay here ;)

Grant.
-
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/

[RFC PATCH] 20-rc6-mm3: kernel/params.c: compile fail when CONFIG_SYSFS not set

[Grant Coady]

Hi there,

This patch is a guess at what's missing, to fix a compile failure when 
CONFIG_SYSFS not set, going by nearby context.  Please check (or forward 
to someone) as I'm not sure if this is the right thing to do here.  
Compile tested.

kernel/profile.c:247: warning: 'profile_flip_buffers' defined but not used
kernel/profile.c:270: warning: 'profile_discard_flip_buffers' defined but not 
used
kernel/profile.c:337: warning: 'profile_cpu_callback' defined but not used
kernel/params.c:700: error: `module_uevent_ops' undeclared here (not in a 
function)
kernel/params.c:700: error: initializer element is not constant
kernel/params.c:700: error: (near initialization for 
`module_subsys.kset.uevent_ops')
kernel/params.c:700: error: initializer element is not constant
kernel/params.c:700: error: (near initialization for `module_subsys.kset')
make[1]: *** [kernel/params.o] Error 1
make: *** [kernel] Error 2

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

---
 params.c |4 
 1 files changed, 4 insertions(+)

--- linux-2.6.20-rc6-mm3/kernel/params.c2007-01-30 16:25:34.0 
+1100
+++ linux-2.6.20-rc6-mm3c/kernel/params.c   2007-02-01 07:25:09.0 
+1100
@@ -691,6 +691,10 @@
.show = NULL,
.store = NULL,
 };
+
+static struct kset_uevent_ops module_uevent_ops = {
+   .filter = NULL,
+};
 #endif
 
 static struct kobj_type module_ktype = {
-
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/

[RFC PATCH] 20-rc6-mm3: kernel/params.c: compile fail when CONFIG_SYSFS not set

[Grant Coady]

Hi there,

This patch is a guess at what's missing, to fix a compile failure when 
CONFIG_SYSFS not set, going by nearby context.  Please check (or forward 
to someone) as I'm not sure if this is the right thing to do here.  
Compile tested.

kernel/profile.c:247: warning: 'profile_flip_buffers' defined but not used
kernel/profile.c:270: warning: 'profile_discard_flip_buffers' defined but not 
used
kernel/profile.c:337: warning: 'profile_cpu_callback' defined but not used
kernel/params.c:700: error: `module_uevent_ops' undeclared here (not in a 
function)
kernel/params.c:700: error: initializer element is not constant
kernel/params.c:700: error: (near initialization for 
`module_subsys.kset.uevent_ops')
kernel/params.c:700: error: initializer element is not constant
kernel/params.c:700: error: (near initialization for `module_subsys.kset')
make[1]: *** [kernel/params.o] Error 1
make: *** [kernel] Error 2

Signed-off-by: Grant Coady [EMAIL PROTECTED]

---
 params.c |4 
 1 files changed, 4 insertions(+)

--- linux-2.6.20-rc6-mm3/kernel/params.c2007-01-30 16:25:34.0 
+1100
+++ linux-2.6.20-rc6-mm3c/kernel/params.c   2007-02-01 07:25:09.0 
+1100
@@ -691,6 +691,10 @@
.show = NULL,
.store = NULL,
 };
+
+static struct kset_uevent_ops module_uevent_ops = {
+   .filter = NULL,
+};
 #endif
 
 static struct kobj_type module_ktype = {
-
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/

[PATCH] -mm3: include/linux/blkdev.h double def'd -> compile fail

[Grant Coady]

Hi there,

Random .config: 20-rc6-mm3a/002 found the following boo-boo...


From: Grant Coady <[EMAIL PROTECTED]>

Defining protos twice caused:

In file included from kernel/sched.c:39:
include/linux/blkdev.h:928: error: redefinition of 'blk_replug_current_nested'
include/linux/blkdev.h:907: error: previous definition of 
'blk_replug_current_nested' was here
include/linux/blkdev.h:932: error: redefinition of 'blk_plug_current'
include/linux/blkdev.h:911: error: previous definition of 'blk_plug_current' 
was here
include/linux/blkdev.h:936: error: redefinition of 'blk_unplug_current'
include/linux/blkdev.h:915: error: previous definition of 'blk_unplug_current' 
was here
include/linux/blkdev.h:940: error: redefinition of 'blk_unplug_current_nested'
include/linux/blkdev.h:919: error: previous definition of 
'blk_unplug_current_nested' was here
include/linux/blkdev.h:945: error: redefinition of 'blk_plug_current_nested'
include/linux/blkdev.h:924: error: previous definition of 
'blk_plug_current_nested' was here
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2

Patch is compile tested on 2.6.20-rc6-mm3.

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

---
 blkdev.h |   21 -
 1 files changed, 21 deletions(-)

--- linux-2.6.20-rc6-mm3/include/linux/blkdev.h 2007-01-30 16:25:30.0 
+1100
+++ linux-2.6.20-rc6-mm3c/include/linux/blkdev.h2007-01-31 
08:01:28.0 +1100
@@ -924,27 +924,6 @@
 {
 }
 
-static inline void blk_replug_current_nested(void)
-{
-}
-
-static inline void blk_plug_current(void)
-{
-}
-
-static inline void blk_unplug_current(void)
-{
-}
-
-static inline int blk_unplug_current_nested(void)
-{
-   return 0;
-}
-
-static inline void blk_plug_current_nested(int depth)
-{
-}
-
 #endif /* CONFIG_BLOCK */
 
 #endif
-
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/

[PATCH] -mm3: include/linux/blkdev.h double def'd - compile fail

[Grant Coady]

Hi there,

Random .config: 20-rc6-mm3a/002 found the following boo-boo...


From: Grant Coady [EMAIL PROTECTED]

Defining protos twice caused:

In file included from kernel/sched.c:39:
include/linux/blkdev.h:928: error: redefinition of 'blk_replug_current_nested'
include/linux/blkdev.h:907: error: previous definition of 
'blk_replug_current_nested' was here
include/linux/blkdev.h:932: error: redefinition of 'blk_plug_current'
include/linux/blkdev.h:911: error: previous definition of 'blk_plug_current' 
was here
include/linux/blkdev.h:936: error: redefinition of 'blk_unplug_current'
include/linux/blkdev.h:915: error: previous definition of 'blk_unplug_current' 
was here
include/linux/blkdev.h:940: error: redefinition of 'blk_unplug_current_nested'
include/linux/blkdev.h:919: error: previous definition of 
'blk_unplug_current_nested' was here
include/linux/blkdev.h:945: error: redefinition of 'blk_plug_current_nested'
include/linux/blkdev.h:924: error: previous definition of 
'blk_plug_current_nested' was here
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2

Patch is compile tested on 2.6.20-rc6-mm3.

Signed-off-by: Grant Coady [EMAIL PROTECTED]

---
 blkdev.h |   21 -
 1 files changed, 21 deletions(-)

--- linux-2.6.20-rc6-mm3/include/linux/blkdev.h 2007-01-30 16:25:30.0 
+1100
+++ linux-2.6.20-rc6-mm3c/include/linux/blkdev.h2007-01-31 
08:01:28.0 +1100
@@ -924,27 +924,6 @@
 {
 }
 
-static inline void blk_replug_current_nested(void)
-{
-}
-
-static inline void blk_plug_current(void)
-{
-}
-
-static inline void blk_unplug_current(void)
-{
-}
-
-static inline int blk_unplug_current_nested(void)
-{
-   return 0;
-}
-
-static inline void blk_plug_current_nested(int depth)
-{
-}
-
 #endif /* CONFIG_BLOCK */
 
 #endif
-
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/

[PATCH] -mm2: typo in ipc/ipc_sysctl.c -> compile failure

[Grant Coady]

Hi there,

Dunno who does IPC so hoping you do ;)  (ref.config: 20-rc6-mm2b/048)

Cheers,
Grant.
From: Grant Coady <[EMAIL PROTECTED]>

Fix typos causing compile failure when CONFIG_PROC_FS not set in 
ipc/ipc_sysctl.c, compile tested.

ipc/ipc_sysctl.c:107: error: `proc_ipc_doulongvec_minmax' undeclared here (not 
in a function)
ipc/ipc_sysctl.c:107: error: initializer element is not constant
[...]
ipc/ipc_sysctl.c:164: error: (near initialization for `ipc_kern_table[7]')
make[1]: *** [ipc/ipc_sysctl.o] Error 1
make: *** [ipc] Error 2

Also applies cleanly to 2.6.20-rc6-mm3.

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

---
 ipc_sysctl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.20-rc6-mm2a/ipc/ipc_sysctl.c  2007-01-30 07:41:08.0 
+1100
+++ linux-2.6.20-rc6-mm2b/ipc/ipc_sysctl.c  2007-01-30 16:45:03.0 
+1100
@@ -50,8 +50,8 @@
 }
 
 #else
-#define proc_ipc_do_ulongvec_minmax NULL
-#define proc_ipc_do_intvec NULL
+#define proc_ipc_doulongvec_minmax NULL
+#define proc_ipc_dointvec NULL
 #endif
 
 #ifdef CONFIG_SYSCTL_SYSCALL
-
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/

[PATCH] -mm2: typo in ipc/ipc_sysctl.c - compile failure

[Grant Coady]

Hi there,

Dunno who does IPC so hoping you do ;)  (ref.config: 20-rc6-mm2b/048)

Cheers,
Grant.
From: Grant Coady [EMAIL PROTECTED]

Fix typos causing compile failure when CONFIG_PROC_FS not set in 
ipc/ipc_sysctl.c, compile tested.

ipc/ipc_sysctl.c:107: error: `proc_ipc_doulongvec_minmax' undeclared here (not 
in a function)
ipc/ipc_sysctl.c:107: error: initializer element is not constant
[...]
ipc/ipc_sysctl.c:164: error: (near initialization for `ipc_kern_table[7]')
make[1]: *** [ipc/ipc_sysctl.o] Error 1
make: *** [ipc] Error 2

Also applies cleanly to 2.6.20-rc6-mm3.

Signed-off-by: Grant Coady [EMAIL PROTECTED]

---
 ipc_sysctl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.20-rc6-mm2a/ipc/ipc_sysctl.c  2007-01-30 07:41:08.0 
+1100
+++ linux-2.6.20-rc6-mm2b/ipc/ipc_sysctl.c  2007-01-30 16:45:03.0 
+1100
@@ -50,8 +50,8 @@
 }
 
 #else
-#define proc_ipc_do_ulongvec_minmax NULL
-#define proc_ipc_do_intvec NULL
+#define proc_ipc_doulongvec_minmax NULL
+#define proc_ipc_dointvec NULL
 #endif
 
 #ifdef CONFIG_SYSCTL_SYSCALL
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Wed, 17 Jan 2007 22:55:19 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hello Santiago,
>
>On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
>> Hi!
>> 
>> I have discovered a problem with the changes applied to smbfs in 2.4.34 and
>> in the security backports like last Debian's 2.4 kernel update these changes
>> seem to be made to solve CVE-2006-5871 and they have broken symbolic links
>> and changed the way that special files (like devices) are seen.
>> 
>> For example:
>> Before: symbolic links were seen as that, symbolic links an thus if you tried
>> to open the file the link was followed and you ended up reading the
>> destination file
>> Now: symbolic links are seen as normal files (at least with a ls) but their
>> length (N) is the length of the symbolic link, if you read it, you'll get the
>> first N characters of the destination file. For example, on my filesystem
>> bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
>> get ELF (this is, the first 4 characters of the bash program, first one
>> being a DEL).
>> 
>> Another example:
>> Before: if you did a ls of a device file, like dev/zero you could see it as
>> a device, if you tried opening it, it wouldn't work, but if you did a cp -a
>> of that file to a local filesystem the result was a working zero device.
>> Now: the devices are seen as normal files with a length of 0 bytes.
>> 
>> Seems to me like a mask is erasing some mode bits that shouldn't be erased.
>> 
>> I have carried my tests on a Debian Sarge machine always mounting the share
>> using: smbmount //server/share /mnt without any other options. The tests
>> were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
>> Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
>> samba 3.0.23d and I have experienced the same behaviour with samba's
>> unix extensions = yes and unix extensions = no.
>> 
>> I don't know what else to add, if you need any more info or want me to do
>> any tests just ask for it.
>
>Well, there is not much to add there. Thanks very much for all your tests.
>This problem was not easy to fix, and Dann Frazier did a careful job at
>backporting it and testing it. Unfortunately, corner cases like this may
>sometimes pass through the tests.
>
>Dann, do you still have your samba server ready to try to reproduce this
>problem ? Also, there are very suspect lines right there in the patch :
>
>@@ -505,8 +510,13 @@
>   mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
>   mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> 
>-  mnt->flags = (oldmnt->file_mode >> 9);
>+  mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
>+  SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
>+  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG;
>+  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
>
>
>See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
>expected thing like this but I wonder if the initial intent was exactly this.
>Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
>what I say is stupid, but it's just a guess.
>
>Santiago, if you feel brave enough to try completely untested code, I
>would suggest to try this change :
>
>   } else {
>-  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFREG;
>-  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFDIR;
>+  mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
>+  mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;

I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
to directories seen as target, nor can they be created (Operation not 
permitted...)

(copied /usr to spare partition on server)

Grant.

Results:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 1536
lrwxrwxrwx 1 grant wheel  5 2007-01-18 10:08 X11 -> X11R6/
drwxr-xr-x 1 grant wheel  0 2002-02-22 11:45 X11R6/
lrwxrwxrwx 1 grant wheel  8 2007-01-18 10:08 adm -> /var/adm/
drwxr-xr-x 1 grant wheel  0 2006-12-05 09:06 bin/
drwxr-xr-x 1 grant wheel  0 1993-11-26 14:40 dict/
drwxr-xr-x 1 grant wheel  0 2006-12-01 09:00 doc/
drwxr-xr-x 1 grant 

Re: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Wed, 17 Jan 2007 22:55:19 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hello Santiago,

On Wed, Jan 17, 2007 at 11:00:30AM +0100, Santiago Garcia Mantinan wrote:
 Hi!
 
 I have discovered a problem with the changes applied to smbfs in 2.4.34 and
 in the security backports like last Debian's 2.4 kernel update these changes
 seem to be made to solve CVE-2006-5871 and they have broken symbolic links
 and changed the way that special files (like devices) are seen.
 
 For example:
 Before: symbolic links were seen as that, symbolic links an thus if you tried
 to open the file the link was followed and you ended up reading the
 destination file
 Now: symbolic links are seen as normal files (at least with a ls) but their
 length (N) is the length of the symbolic link, if you read it, you'll get the
 first N characters of the destination file. For example, on my filesystem
 bin/sh is a symlink to bash, thus it is 4 bytes long, if I to a cat bin/sh I
 get ELF (this is, the first 4 characters of the bash program, first one
 being a DEL).
 
 Another example:
 Before: if you did a ls of a device file, like dev/zero you could see it as
 a device, if you tried opening it, it wouldn't work, but if you did a cp -a
 of that file to a local filesystem the result was a working zero device.
 Now: the devices are seen as normal files with a length of 0 bytes.
 
 Seems to me like a mask is erasing some mode bits that shouldn't be erased.
 
 I have carried my tests on a Debian Sarge machine always mounting the share
 using: smbmount //server/share /mnt without any other options. The tests
 were carried on a unpatched 2.4.34 comparing it to 2.4.33 and also on
 Debian's 2.4.27 comparing 2.4.27-10sarge4 vs -10sarge5. The server is a
 samba 3.0.23d and I have experienced the same behaviour with samba's
 unix extensions = yes and unix extensions = no.
 
 I don't know what else to add, if you need any more info or want me to do
 any tests just ask for it.

Well, there is not much to add there. Thanks very much for all your tests.
This problem was not easy to fix, and Dann Frazier did a careful job at
backporting it and testing it. Unfortunately, corner cases like this may
sometimes pass through the tests.

Dann, do you still have your samba server ready to try to reproduce this
problem ? Also, there are very suspect lines right there in the patch :

@@ -505,8 +510,13 @@
   mnt-file_mode = (oldmnt-file_mode  S_IRWXUGO) | S_IFREG;
   mnt-dir_mode = (oldmnt-dir_mode  S_IRWXUGO) | S_IFDIR;
 
-  mnt-flags = (oldmnt-file_mode  9);
+  mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
+  SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
+  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG;
+  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }


See above ? mnt-dir_mode being assigned 3 times. It still *seems* to do the
expected thing like this but I wonder if the initial intent was exactly this.
Also, would not it be necessary to add |S_IFLNK to the file_mode ? Maybe
what I say is stupid, but it's just a guess.

Santiago, if you feel brave enough to try completely untested code, I
would suggest to try this change :

   } else {
-  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFREG;
-  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFDIR;
+  mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
+  mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;

I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
to directories seen as target, nor can they be created (Operation not 
permitted...)

(copied /usr to spare partition on server)

Grant.

Results:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 1536
lrwxrwxrwx 1 grant wheel  5 2007-01-18 10:08 X11 - X11R6/
drwxr-xr-x 1 grant wheel  0 2002-02-22 11:45 X11R6/
lrwxrwxrwx 1 grant wheel  8 2007-01-18 10:08 adm - /var/adm/
drwxr-xr-x 1 grant wheel  0 2006-12-05 09:06 bin/
drwxr-xr-x 1 grant wheel  0 1993-11-26 14:40 dict/
drwxr-xr-x 1 grant wheel  0 2006-12-01 09:00 doc/
drwxr-xr-x 1 grant wheel  0 2006-08-17 16:01 etc/
drwxr-xr-x 1 grant wheel  0 2006-09-09 10:51 games/
drwxr-xr-x 1 grant wheel  0 2005-04-22 05:45 

kernel.org: missing version in latest 2.6 snapshot

[Grant Coady]

Hi there,

This is odd:

Index of /pub/linux/kernel/v2.6/snapshots
NameLast modified  Size  
Parent Directory -   
incr/   13-Dec-2006 22:45-   
old/26-Sep-2006 07:41-   
patch--git1.sign25-Jan-2007 07:01  248   
patch--git1.log 25-Jan-2007 07:010   
patch--git1.id  25-Jan-2007 07:01   41   
patch--git1.gz.sign 25-Jan-2007 07:01  248   
patch--git1.gz  25-Jan-2007 07:01   20   
patch--git1.bz2.sign25-Jan-2007 07:01  248   
patch--git1.bz2 25-Jan-2007 07:01   14   
patch-2.6.20-rc5-git4.sign  24-Jan-2007 19:01  248   
...

Grant.
-
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/

kernel.org: missing version in latest 2.6 snapshot

[Grant Coady]

Hi there,

This is odd:

Index of /pub/linux/kernel/v2.6/snapshots
NameLast modified  Size  
Parent Directory -   
incr/   13-Dec-2006 22:45-   
old/26-Sep-2006 07:41-   
patch--git1.sign25-Jan-2007 07:01  248   
patch--git1.log 25-Jan-2007 07:010   
patch--git1.id  25-Jan-2007 07:01   41   
patch--git1.gz.sign 25-Jan-2007 07:01  248   
patch--git1.gz  25-Jan-2007 07:01   20   
patch--git1.bz2.sign25-Jan-2007 07:01  248   
patch--git1.bz2 25-Jan-2007 07:01   14   
patch-2.6.20-rc5-git4.sign  24-Jan-2007 19:01  248   
...

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>Users have reported a symlink issue with my recent smbfs backport.
>Turns out my backport overlooked a second 2.6 patch w/ the fix:
> http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
>
>This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
>issue, and also cleans up an unnecessary double assignment. As his
>commit message notes, you will need the userspace patches from Samba
>Bug #999 in order to use the permission/ownership assigned by the
>server.

Server-side:
[EMAIL PROTECTED]:/home/other$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:/home/other$ ls -l
total 8
drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
for comparison:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

[EMAIL PROTECTED]:~$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 10
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

[EMAIL PROTECTED]:~$ uname -r
2.4.34c
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Grant.

>
>Signed-off-by: dann frazier <[EMAIL PROTECTED]>
>
>diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
>index be975fe..7fd9b51 100644
>--- a/fs/smbfs/inode.c
>+++ b/fs/smbfs/inode.c
>@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
>int silent)
>   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
>   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
>-  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFREG;
>-  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFDIR;
>+  mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG;
>+  mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
>diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
>index 7f0794c..5570007 100644
>--- a/fs/smbfs/proc.c
>+++ b/fs/smbfs/proc.c
>@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
>struct smb_sb_info *server,
> 
>   if ( (server->mnt->flags & SMB_MOUNT_DMODE) &&
>(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFDIR;
>+  fattr->f_mode = (server->mnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFREG;
>+  fattr->f_mode = (server->mnt->file_mode & S_IRWXUGO) |
>+  (fattr->f_mode & S_IFMT);
> 
> }
> 

-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Tue, 23 Jan 2007 13:19:37 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
>> Hi Grant !
>> 
>> On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
>> > On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
>> > 
>> > >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>> > >Ah, think I see the problem now:
>> > >
>> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 
>> > >17:53:57.247695476 -0700
>> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
>> > >-0700
>> > >@@ -1997,7 +1997,7 @@
>> > >  fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>> > > S_IRWXO)) | S_IFDIR;
>> > >  else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
>> > >!(S_ISDIR(fattr->f_mode)) )
>> > >- fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> > >S_IRWXO)) | S_IFREG;
>> > >+ fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> > >S_IRWXO)) | (fattr->f_mode & S_IFMT);
>> > > 
>> > > }
>> > > 
>> > client running 2.4.34 with above patch, server is running 2.6.19.2 to 
>> > eliminate it from the problem space (hopefully ;) :
>> > [EMAIL PROTECTED]:/home/other$ uname -r
>> > 2.4.34b
>> > [EMAIL PROTECTED]:/home/other$ ls -l
>> > total 9
>> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
>> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
>> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
>> > -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
>> 
>> It seems to me that there is a difference, because filelink now appears the
>> same size as file. It's just as if we had hard links instead of symlinks.
>
>I was running into this yesterday - turns out that Debian's current
>smbfs package contains a patch that checks for user passed options,
>and disables unix capabilities in that case. It was added in
>3.0.14a-4. I've filed a bug requesting the removal of this patch:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033
>
>Grant: Do you know if are you running a version of smbfs w/ this
>   patch?

Hi Dann,
I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
package with two tiny unrelated (?) patches:

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ find . -name samba*
./n/samba
./n/samba/samba.cups.diff.gz
./n/samba/samba.ssl.diff.gz
./n/samba/samba.SlackBuild
./n/samba/samba-3.0.23c.tar.asc
./n/samba/samba-3.0.23c.tar.bz2
[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zless 
n/samba/samba.cups.diff.gz
--- ./source/configure.orig 2002-10-23 18:06:43.0 -0700
+++ ./source/configure  2002-10-23 18:07:12.0 -0700
@@ -3789,7 +3789,7 @@

CFLAGS="$CFLAGS `$CUPS_CONFIG --cflags`"
LDFLAGS="$LDFLAGS `$CUPS_CONFIG --ldflags`"
-   LIBS="$LIBS `$CUPS_CONFIG --libs`"
+   LIBS="-lcrypt $LIBS `$CUPS_CONFIG --libs`"
 fi
 fi

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zcat 
n/samba/samba.ssl.diff.gz
--- ./source/configure.orig 2002-10-09 13:27:21.0 -0700
+++ ./source/configure  2002-10-23 18:06:43.0 -0700
@@ -12479,7 +12479,7 @@

 fi

-LIBS="-lssl -lcrypto $LIBS"
+LIBS="$LIBS -lssl -lcrypto"

 #if test ! -d ${withval}; then
 #  echo "configure: error: called with --with-ssl, but ssl base directory 
${withval} does not exist or is not a directory. Aborting config" 1>&2

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Tue, 23 Jan 2007 13:19:37 -0700, dann frazier [EMAIL PROTECTED] wrote:

On Mon, Jan 22, 2007 at 12:03:21AM +0100, Willy Tarreau wrote:
 Hi Grant !
 
 On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
  On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
  
  On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
  Ah, think I see the problem now:
  
  --- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 
  17:53:57.247695476 -0700
  +++ kernel-source-2.4.27/fs/smbfs/proc.c  2007-01-19 17:49:07.480161733 
  -0700
  @@ -1997,7 +1997,7 @@
fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
   S_IRWXO)) | S_IFDIR;
else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
  !(S_ISDIR(fattr-f_mode)) )
  - fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFREG;
  + fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | (fattr-f_mode  S_IFMT);
   
   }
   
  client running 2.4.34 with above patch, server is running 2.6.19.2 to 
  eliminate it from the problem space (hopefully ;) :
  [EMAIL PROTECTED]:/home/other$ uname -r
  2.4.34b
  [EMAIL PROTECTED]:/home/other$ ls -l
  total 9
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
  drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
  -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
 
 It seems to me that there is a difference, because filelink now appears the
 same size as file. It's just as if we had hard links instead of symlinks.

I was running into this yesterday - turns out that Debian's current
smbfs package contains a patch that checks for user passed options,
and disables unix capabilities in that case. It was added in
3.0.14a-4. I've filed a bug requesting the removal of this patch:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408033

Grant: Do you know if are you running a version of smbfs w/ this
   patch?

Hi Dann,
I'm running slackware-11, no smbfs package, 'smbmnt' is from samba-3.0.23c 
package with two tiny unrelated (?) patches:

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ find . -name samba*
./n/samba
./n/samba/samba.cups.diff.gz
./n/samba/samba.ssl.diff.gz
./n/samba/samba.SlackBuild
./n/samba/samba-3.0.23c.tar.asc
./n/samba/samba-3.0.23c.tar.bz2
[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zless 
n/samba/samba.cups.diff.gz
--- ./source/configure.orig 2002-10-23 18:06:43.0 -0700
+++ ./source/configure  2002-10-23 18:07:12.0 -0700
@@ -3789,7 +3789,7 @@

CFLAGS=$CFLAGS `$CUPS_CONFIG --cflags`
LDFLAGS=$LDFLAGS `$CUPS_CONFIG --ldflags`
-   LIBS=$LIBS `$CUPS_CONFIG --libs`
+   LIBS=-lcrypt $LIBS `$CUPS_CONFIG --libs`
 fi
 fi

[EMAIL PROTECTED]:/home/mirror/slackware-11.0/source$ zcat 
n/samba/samba.ssl.diff.gz
--- ./source/configure.orig 2002-10-09 13:27:21.0 -0700
+++ ./source/configure  2002-10-23 18:06:43.0 -0700
@@ -12479,7 +12479,7 @@

 fi

-LIBS=-lssl -lcrypto $LIBS
+LIBS=$LIBS -lssl -lcrypto

 #if test ! -d ${withval}; then
 #  echo configure: error: called with --with-ssl, but ssl base directory 
${withval} does not exist or is not a directory. Aborting config 12

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier [EMAIL PROTECTED] wrote:

Users have reported a symlink issue with my recent smbfs backport.
Turns out my backport overlooked a second 2.6 patch w/ the fix:
 http://linux.bkbits.net:8080/linux-2.6/?PAGE=csetREV=419e7b76CdrmRG_NZ8LKj9DUUBGu1w

This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
issue, and also cleans up an unnecessary double assignment. As his
commit message notes, you will need the userspace patches from Samba
Bug #999 in order to use the permission/ownership assigned by the
server.

Server-side:
[EMAIL PROTECTED]:/home/other$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:/home/other$ ls -l
total 8
drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test

Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
for comparison:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink - file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink - test

[EMAIL PROTECTED]:~$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 10
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

[EMAIL PROTECTED]:~$ uname -r
2.4.34c
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink - test*

Grant.


Signed-off-by: dann frazier [EMAIL PROTECTED]

diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
index be975fe..7fd9b51 100644
--- a/fs/smbfs/inode.c
+++ b/fs/smbfs/inode.c
@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
int silent)
   mnt-flags = (oldmnt-file_mode  9) | SMB_MOUNT_UID |
   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
   } else {
-  mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFREG;
-  mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
-  S_IROTH | S_IXOTH | S_IFDIR;
+  mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFREG;
+  mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
+  S_IROTH | S_IXOTH | S_IFDIR;
   if (parse_options(mnt, raw_data))
   goto out_bad_option;
   }
diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
index 7f0794c..5570007 100644
--- a/fs/smbfs/proc.c
+++ b/fs/smbfs/proc.c
@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
struct smb_sb_info *server,
 
   if ( (server-mnt-flags  SMB_MOUNT_DMODE) 
(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFDIR;
+  fattr-f_mode = (server-mnt-dir_mode  S_IRWXUGO) | S_IFDIR;
   else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
 !(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+  fattr-f_mode = (server-mnt-file_mode  S_IRWXUGO) |
+  (fattr-f_mode  S_IFMT);
 
 }
 

-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 10:36:30 +0100, Santiago Garcia Mantinan <[EMAIL 
PROTECTED]> wrote:

>> > As you can see I now can see the symbolic links perfectly and they work as
>> > expected.
>> > 
>> > In fact, this patch is working so well that it poses a security risk, as 
>> > now
>> > the devices on my /mnt/dev directory are not only seen as devices (like 
>> > they
>> > were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
>> 
>> Why do you consider this a security problem ? Is any user able to create a
>> device entry with enough permissions ? As a general rule of thumb, networked
>> file systems should be mounted with the "nodev" option.
>
>You are completely right on that, it is just that I thought those devices
>didn't work on 2.4.33, but I just retested again and they work ok, only that
>they were not working to me on the PC I tested the other day and it was
>because of a nodev option :-) just that.
>
>So... I have finised with my tests, I have tested an x86 client on which it
>worked ok, just like on the PowerPC client, both working perfectly just like
>they used to do on 2.4.33.
>
>> Grant, just to be sure, are you really certain that you tried the fixed 
>> kernel ?
>> It is possible that you booted a wrong kernel during one of your tests. I'm
>> intrigued by the fact that it changed nothing for you and that it fixed the
>> problem for Santiago.
>
>Maybe he had also applied some of the earlier patches you had sent and that
>I did not apply to mine?
>
>Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
>I'm running a pristine kernel with just this latest patch applied, the one
>that changes S_IFREG for (fattr->f_mode & S_IFMT).

Same kernel + patch here for latest results posting :)  We seem to get 
similar results now -- though I query the file execute bits coming up.

Grant.
>
>Regards...

-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 10:18:16 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Grant, just to be sure, are you really certain that you tried the fixed kernel 
>?
>It is possible that you booted a wrong kernel during one of your tests. I'm
>intrigued by the fact that it changed nothing for you and that it fixed the
>problem for Santiago.

Closest I get to Santiago's results are with the 2.4.33.7 plus the patch, 
with 'use default NLS' option turned on, as well as the unix extensions.

2.4.34 was a no go for me.  Changing the default NLS made no difference, 
now trying with unix extensions turned on. . .  Yeah, that works, apart 
from the test file gaining execute bits, compared to operation under 
2.4.33.3, this is 2.4.34 + patch + default NLS and unix extensions:

[EMAIL PROTECTED]:/home/other$ cat dirlink/filelink
this is a test
[EMAIL PROTECTED]:/home/other$ echo "this is a test" > testfile
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
drwxr-xr-x 1 grant wheel  0 2007-01-22 10:45 test/
-rwxr-xr-x 1 grant wheel 15 2007-01-22 21:31 testfile*
lrwxr-xr-x 1 grant wheel  4 2007-01-22 21:29 testlink -> test/
[EMAIL PROTECTED]:/home/other$ ln -s testfile testfilelink
[EMAIL PROTECTED]:/home/other$ cat testfilelink
this is a test


The fix depends on the smbfs configuration?  Is this the requirement?
I ask as the other mode of operation (unix extensions turned off): do 
not display symlinks, prevent creation of symlinks, seems to be logically 
self-consistent, as well as matching what I see from a 'doze box.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 10:18:16 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Grant, just to be sure, are you really certain that you tried the fixed kernel 
?
It is possible that you booted a wrong kernel during one of your tests. I'm
intrigued by the fact that it changed nothing for you and that it fixed the
problem for Santiago.

Closest I get to Santiago's results are with the 2.4.33.7 plus the patch, 
with 'use default NLS' option turned on, as well as the unix extensions.

2.4.34 was a no go for me.  Changing the default NLS made no difference, 
now trying with unix extensions turned on. . .  Yeah, that works, apart 
from the test file gaining execute bits, compared to operation under 
2.4.33.3, this is 2.4.34 + patch + default NLS and unix extensions:

[EMAIL PROTECTED]:/home/other$ cat dirlink/filelink
this is a test
[EMAIL PROTECTED]:/home/other$ echo this is a test  testfile
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink - dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink - file*
drwxr-xr-x 1 grant wheel  0 2007-01-22 10:45 test/
-rwxr-xr-x 1 grant wheel 15 2007-01-22 21:31 testfile*
lrwxr-xr-x 1 grant wheel  4 2007-01-22 21:29 testlink - test/
[EMAIL PROTECTED]:/home/other$ ln -s testfile testfilelink
[EMAIL PROTECTED]:/home/other$ cat testfilelink
this is a test


The fix depends on the smbfs configuration?  Is this the requirement?
I ask as the other mode of operation (unix extensions turned off): do 
not display symlinks, prevent creation of symlinks, seems to be logically 
self-consistent, as well as matching what I see from a 'doze box.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 10:36:30 +0100, Santiago Garcia Mantinan [EMAIL 
PROTECTED] wrote:

  As you can see I now can see the symbolic links perfectly and they work as
  expected.
  
  In fact, this patch is working so well that it poses a security risk, as 
  now
  the devices on my /mnt/dev directory are not only seen as devices (like 
  they
  were seen on 2.4.33) but they also work (which didn't happen on 2.4.33).
 
 Why do you consider this a security problem ? Is any user able to create a
 device entry with enough permissions ? As a general rule of thumb, networked
 file systems should be mounted with the nodev option.

You are completely right on that, it is just that I thought those devices
didn't work on 2.4.33, but I just retested again and they work ok, only that
they were not working to me on the PC I tested the other day and it was
because of a nodev option :-) just that.

So... I have finised with my tests, I have tested an x86 client on which it
worked ok, just like on the PowerPC client, both working perfectly just like
they used to do on 2.4.33.

 Grant, just to be sure, are you really certain that you tried the fixed 
 kernel ?
 It is possible that you booted a wrong kernel during one of your tests. I'm
 intrigued by the fact that it changed nothing for you and that it fixed the
 problem for Santiago.

Maybe he had also applied some of the earlier patches you had sent and that
I did not apply to mine?

Just to clear things up a bit, I'm sure I'm with the 2.4.34 kernel and...
I'm running a pristine kernel with just this latest patch applied, the one
that changes S_IFREG for (fattr-f_mode  S_IFMT).

Same kernel + patch here for latest results posting :)  We seem to get 
similar results now -- though I query the file execute bits coming up.

Grant.

Regards...

-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>Ah, think I see the problem now:
>
>--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 17:53:57.247695476 
>-0700
>+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
>-0700
>@@ -1997,7 +1997,7 @@
>   fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
> S_IRWXO)) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFREG;
>+  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | (fattr->f_mode & S_IFMT);
> 
> }
> 
client running 2.4.34 with above patch, server is running 2.6.19.2 to 
eliminate it from the problem space (hopefully ;) :
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ ls -l
total 9
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 1
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
[EMAIL PROTECTED]:/home/other$

problem is still there :(

With client 2.4.33.3 (slackware-11 distro kernel):
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 2048
drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root root 15 2007-01-21 11:43 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 2048
-rw-r--r-- 1 root root 15 2007-01-21 11:44 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink -> file
[EMAIL PROTECTED]:/home/other$ cat filelink
this is a test

No problem with symlinks, execute flag.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hi Grant !
>
>On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
>> On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
>> 
>> >On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
>> >Ah, think I see the problem now:
>> >
>> >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 
>> >17:53:57.247695476 -0700
>> >+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
>> >-0700
>> >@@ -1997,7 +1997,7 @@
>> >fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>> > S_IRWXO)) | S_IFDIR;
>> >else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
>> >  !(S_ISDIR(fattr->f_mode)) )
>> >-   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> >S_IRWXO)) | S_IFREG;
>> >+   fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>> >S_IRWXO)) | (fattr->f_mode & S_IFMT);
>> > 
>> > }
>> > 
>> client running 2.4.34 with above patch, server is running 2.6.19.2 to 
>> eliminate it from the problem space (hopefully ;) :
>> [EMAIL PROTECTED]:/home/other$ uname -r
>> 2.4.34b
>> [EMAIL PROTECTED]:/home/other$ ls -l
>> total 9
>> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
>> drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
>> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
>> -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
>
>It seems to me that there is a difference, because filelink now appears the
>same size as file. It's just as if we had hard links instead of symlinks.

Hi Willy,

No, those dir and files were created server-side, sorry I gave wrong 
impression, I still get on client side:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ mkdir test
[EMAIL PROTECTED]:/home/other$ ln -s test testlink
ln: creating symbolic link `testlink' to `test': Operation not permitted
[EMAIL PROTECTED]:/home/other$ echo "this is also a test" > test/file
[EMAIL PROTECTED]:/home/other$ ln -s test/file test2
ln: creating symbolic link `test2' to `test/file': Operation not permitted

trying to create symlinks.

No problems creating symlinks with 2.4.33.3.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Thu, 18 Jan 2007 05:21:16 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:

>Hi Grant !
>
>On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
>(...)
>> >} else {
>> >-   mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >-   S_IROTH | S_IXOTH | S_IFREG;
>> >-   mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >-   S_IROTH | S_IXOTH | S_IFDIR;
>> >+   mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
>> >+   mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>> >+   S_IROTH | S_IXOTH | S_IFDIR;
>> >if (parse_options(mnt, raw_data))
>> >goto out_bad_option;
>> 
>> I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
>> to directories seen as target, nor can they be created (Operation not 
>> permitted...)
>
>Thanks very much Grant for the test. Could you try a symlink to a file ?

"Operation not permitted"

>And while we're at it, would you like to try to add "|S_IFLNK" to
>mnt->dir_mode ? If my suggestion was stupid, at least let's test it to
>full extent ;-)

Yep, already tried the obvious ;)  no difference :(

2.4.33.5 onwards also have a problem with symlinks, but it is slightly 
different presentation, the directory symlinks appear as normal files.

With 2.4.33.7 one is able to create file and directory symlinks, though 
the links appear as files.  Content problem as noted by OP:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.7
[EMAIL PROTECTED]:/home/other$ cat file
this is a test
[EMAIL PROTECTED]:/home/other$ cat filelink
[EMAIL PROTECTED]:/home/other$

[EMAIL PROTECTED]:/home/other$ mkdir directory
[EMAIL PROTECTED]:/home/other$ ln -s directory directorylink
[EMAIL PROTECTED]:/home/other$ cp file* directory
[EMAIL PROTECTED]:/home/other$ ls directory
file*  filelink*
[EMAIL PROTECTED]:/home/other$ ls directorylink
directorylink*

Now, WinXP sees the contents of directorylink:

X:\>cd directorylink

X:\directorylink>dir
 Volume in drive X is other
 Volume Serial Number is 107E-052F

 Directory of X:\directorylink

2007-01-18  16:36  .
2007-01-18  16:33  ..
2007-01-18  16:3615 file
2007-01-18  16:36 4 filelink
   2 File(s) 19 bytes
   2 Dir(s)   2,558,922,752 bytes free

X:\directorylink>type file
this is a test

X:\directorylink>type filelink
this
X:\directorylink>
>
>I had another idea looking at the code but since I really don't know it,
>I would not like to propose random changes till this magically works. I'd
>wait for Dann who understood the code.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Mon, 22 Jan 2007 00:03:21 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hi Grant !

On Mon, Jan 22, 2007 at 09:52:44AM +1100, Grant Coady wrote:
 On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:
 
 On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
 Ah, think I see the problem now:
 
 --- kernel-source-2.4.27.orig/fs/smbfs/proc.c   2007-01-19 
 17:53:57.247695476 -0700
 +++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733 
 -0700
 @@ -1997,7 +1997,7 @@
 fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
  S_IRWXO)) | S_IFDIR;
 else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
   !(S_ISDIR(fattr-f_mode)) )
 -   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFREG;
 +   fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | (fattr-f_mode  S_IFMT);
  
  }
  
 client running 2.4.34 with above patch, server is running 2.6.19.2 to 
 eliminate it from the problem space (hopefully ;) :
 [EMAIL PROTECTED]:/home/other$ uname -r
 2.4.34b
 [EMAIL PROTECTED]:/home/other$ ls -l
 total 9
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
 drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
 -rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*

It seems to me that there is a difference, because filelink now appears the
same size as file. It's just as if we had hard links instead of symlinks.

Hi Willy,

No, those dir and files were created server-side, sorry I gave wrong 
impression, I still get on client side:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ mkdir test
[EMAIL PROTECTED]:/home/other$ ln -s test testlink
ln: creating symbolic link `testlink' to `test': Operation not permitted
[EMAIL PROTECTED]:/home/other$ echo this is also a test  test/file
[EMAIL PROTECTED]:/home/other$ ln -s test/file test2
ln: creating symbolic link `test2' to `test/file': Operation not permitted

trying to create symlinks.

No problems creating symlinks with 2.4.33.3.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Thu, 18 Jan 2007 05:21:16 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:

Hi Grant !

On Thu, Jan 18, 2007 at 11:09:57AM +1100, Grant Coady wrote:
(...)
 } else {
 -   mnt-file_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -   S_IROTH | S_IXOTH | S_IFREG;
 -   mnt-dir_mode = mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 -   S_IROTH | S_IXOTH | S_IFDIR;
 +   mnt-file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +   S_IROTH | S_IXOTH | S_IFREG | S_IFLNK;
 +   mnt-dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
 +   S_IROTH | S_IXOTH | S_IFDIR;
 if (parse_options(mnt, raw_data))
 goto out_bad_option;
 
 I'm comparing 2.4.33.3 with 2.4.34, with 2.4.34 and above patch symlinks 
 to directories seen as target, nor can they be created (Operation not 
 permitted...)

Thanks very much Grant for the test. Could you try a symlink to a file ?

Operation not permitted

And while we're at it, would you like to try to add |S_IFLNK to
mnt-dir_mode ? If my suggestion was stupid, at least let's test it to
full extent ;-)

Yep, already tried the obvious ;)  no difference :(

2.4.33.5 onwards also have a problem with symlinks, but it is slightly 
different presentation, the directory symlinks appear as normal files.

With 2.4.33.7 one is able to create file and directory symlinks, though 
the links appear as files.  Content problem as noted by OP:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.7
[EMAIL PROTECTED]:/home/other$ cat file
this is a test
[EMAIL PROTECTED]:/home/other$ cat filelink
[EMAIL PROTECTED]:/home/other$

[EMAIL PROTECTED]:/home/other$ mkdir directory
[EMAIL PROTECTED]:/home/other$ ln -s directory directorylink
[EMAIL PROTECTED]:/home/other$ cp file* directory
[EMAIL PROTECTED]:/home/other$ ls directory
file*  filelink*
[EMAIL PROTECTED]:/home/other$ ls directorylink
directorylink*

Now, WinXP sees the contents of directorylink:

X:\cd directorylink

X:\directorylinkdir
 Volume in drive X is other
 Volume Serial Number is 107E-052F

 Directory of X:\directorylink

2007-01-18  16:36DIR  .
2007-01-18  16:33DIR  ..
2007-01-18  16:3615 file
2007-01-18  16:36 4 filelink
   2 File(s) 19 bytes
   2 Dir(s)   2,558,922,752 bytes free

X:\directorylinktype file
this is a test

X:\directorylinktype filelink
this
X:\directorylink

I had another idea looking at the code but since I really don't know it,
I would not like to propose random changes till this magically works. I'd
wait for Dann who understood the code.

Grant.
-
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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Fri, 19 Jan 2007 18:05:44 -0700, dann frazier [EMAIL PROTECTED] wrote:

On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
Ah, think I see the problem now:

--- kernel-source-2.4.27.orig/fs/smbfs/proc.c  2007-01-19 17:53:57.247695476 
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c   2007-01-19 17:49:07.480161733 
-0700
@@ -1997,7 +1997,7 @@
   fattr-f_mode = (server-mnt-dir_mode  (S_IRWXU | S_IRWXG | 
 S_IRWXO)) | S_IFDIR;
   else if ( (server-mnt-flags  SMB_MOUNT_FMODE) 
 !(S_ISDIR(fattr-f_mode)) )
-  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | S_IFREG;
+  fattr-f_mode = (server-mnt-file_mode  (S_IRWXU | S_IRWXG | 
S_IRWXO)) | (fattr-f_mode  S_IFMT);
 
 }
 
client running 2.4.34 with above patch, server is running 2.6.19.2 to 
eliminate it from the problem space (hopefully ;) :
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.34b
[EMAIL PROTECTED]:/home/other$ ls -l
total 9
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 file*
-rwxr-xr-x 1 grant wheel   15 2007-01-21 11:43 filelink*
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 1
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 file*
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:44 filelink*
[EMAIL PROTECTED]:/home/other$

problem is still there :(

With client 2.4.33.3 (slackware-11 distro kernel):
[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 2048
drwxr-xr-x 1 root root  0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root root  3 2007-01-21 11:43 dirlink - dir/
-rw-r--r-- 1 root root 15 2007-01-21 11:43 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
[EMAIL PROTECTED]:/home/other$ ls -l dirlink/
total 2048
-rw-r--r-- 1 root root 15 2007-01-21 11:44 file
lrwxrwxrwx 1 root root  4 2007-01-21 11:44 filelink - file
[EMAIL PROTECTED]:/home/other$ cat filelink
this is a test

No problem with symlinks, execute flag.

Grant.
-
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/

PATCH net-Kconfig-pocket_adapter-ISA-to-PARPORT

[Grant Coady]

Hi Jeff,


This patch changes pocket and parallel adaptors to depend on PARPORT 
instead of ISA in order to get the option in newer SuperIO based systems.

Tested on x86 (AMD K7).  Also applies to 2.6.13-git8 cleanly.

Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

---
 Kconfig |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.13-mm2/drivers/net/Kconfig2005-09-09 23:18:28.0 
+1000
+++ linux-2.6.13-mm2b/drivers/net/Kconfig   2005-09-09 23:58:46.0 
+1000
@@ -1647,7 +1647,7 @@
 
 config NET_POCKET
bool "Pocket and portable adapters"
-   depends on NET_ETHERNET && ISA
+   depends on NET_ETHERNET && PARPORT
---help---
  Cute little network (Ethernet) devices which attach to the parallel
  port ("pocket adapters"), commonly used with laptops. If you have
@@ -1671,7 +1671,7 @@
 
 config ATP
tristate "AT-LAN-TEC/RealTek pocket adapter support"
-   depends on NET_POCKET && ISA && X86
+   depends on NET_POCKET && PARPORT && X86
select CRC32
---help---
  This is a network (Ethernet) device which attaches to your parallel
@@ -1686,7 +1686,7 @@
 
 config DE600
tristate "D-Link DE600 pocket adapter support"
-   depends on NET_POCKET && ISA
+   depends on NET_POCKET && PARPORT
---help---
  This is a network (Ethernet) device which attaches to your parallel
  port. Read  as well as the
@@ -1701,7 +1701,7 @@
 
 config DE620
tristate "D-Link DE620 pocket adapter support"
-   depends on NET_POCKET && ISA
+   depends on NET_POCKET && PARPORT
---help---
  This is a network (Ethernet) device which attaches to your parallel
  port. Read  as well as the
-
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.13-mm2

[Grant Coady]

Hi Andrew, Marko,
On Fri, 9 Sep 2005 02:43:36 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

>Grant Coady <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>> 
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
>> 
>> Hi Andrew,
>> 
>> After this error:
>> 
>>   CC  drivers/parport/parport_pc.o
>> drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section 
>> type conflict
>> drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section 
>> type conflict
>> drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a 
>> section type conflict
>> drivers/parport/parport_pc.c:2782: error: cards causes a section type 
>> conflict
>> make[2]: *** [drivers/parport/parport_pc.o] Error 1
>> make[1]: *** [drivers/parport] Error 2
>> make: *** [drivers] Error 2
>
>Yes, gcc 4.x doesn't like the consts for some reason.

Not using gcc 4.x, Slackware-10.1+ with Gnu C 3.3.6
>
>diff -puN drivers/parport/parport_pc.c~a drivers/parport/parport_pc.c
[...]
Thank you, compile completed :o)  Bonus!  It booted too.

Grant.

-
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.13-mm2

[Grant Coady]

Hi Andrew, Marko,
On Fri, 9 Sep 2005 02:43:36 -0700, Andrew Morton [EMAIL PROTECTED] wrote:

Grant Coady [EMAIL PROTECTED] wrote:

 On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
 
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
 
 Hi Andrew,
 
 After this error:
 
   CC  drivers/parport/parport_pc.o
 drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section 
 type conflict
 drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section 
 type conflict
 drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a 
 section type conflict
 drivers/parport/parport_pc.c:2782: error: cards causes a section type 
 conflict
 make[2]: *** [drivers/parport/parport_pc.o] Error 1
 make[1]: *** [drivers/parport] Error 2
 make: *** [drivers] Error 2

Yes, gcc 4.x doesn't like the consts for some reason.

Not using gcc 4.x, Slackware-10.1+ with Gnu C 3.3.6

diff -puN drivers/parport/parport_pc.c~a drivers/parport/parport_pc.c
[...]
Thank you, compile completed :o)  Bonus!  It booted too.

Grant.

-
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/

PATCH net-Kconfig-pocket_adapter-ISA-to-PARPORT

[Grant Coady]

Hi Jeff,


This patch changes pocket and parallel adaptors to depend on PARPORT 
instead of ISA in order to get the option in newer SuperIO based systems.

Tested on x86 (AMD K7).  Also applies to 2.6.13-git8 cleanly.

Signed-off-by: Grant Coady [EMAIL PROTECTED]

---
 Kconfig |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.13-mm2/drivers/net/Kconfig2005-09-09 23:18:28.0 
+1000
+++ linux-2.6.13-mm2b/drivers/net/Kconfig   2005-09-09 23:58:46.0 
+1000
@@ -1647,7 +1647,7 @@
 
 config NET_POCKET
bool Pocket and portable adapters
-   depends on NET_ETHERNET  ISA
+   depends on NET_ETHERNET  PARPORT
---help---
  Cute little network (Ethernet) devices which attach to the parallel
  port (pocket adapters), commonly used with laptops. If you have
@@ -1671,7 +1671,7 @@
 
 config ATP
tristate AT-LAN-TEC/RealTek pocket adapter support
-   depends on NET_POCKET  ISA  X86
+   depends on NET_POCKET  PARPORT  X86
select CRC32
---help---
  This is a network (Ethernet) device which attaches to your parallel
@@ -1686,7 +1686,7 @@
 
 config DE600
tristate D-Link DE600 pocket adapter support
-   depends on NET_POCKET  ISA
+   depends on NET_POCKET  PARPORT
---help---
  This is a network (Ethernet) device which attaches to your parallel
  port. Read file:Documentation/networking/DLINK.txt as well as the
@@ -1701,7 +1701,7 @@
 
 config DE620
tristate D-Link DE620 pocket adapter support
-   depends on NET_POCKET  ISA
+   depends on NET_POCKET  PARPORT
---help---
  This is a network (Ethernet) device which attaches to your parallel
  port. Read file:Documentation/networking/DLINK.txt as well as the
-
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.13-mm2

[Grant Coady]

On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/

Hi Andrew,

After this error:

  CC  drivers/parport/parport_pc.o
drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section type 
conflict
drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section type 
conflict
drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a 
section type conflict
drivers/parport/parport_pc.c:2782: error: cards causes a section type conflict
make[2]: *** [drivers/parport/parport_pc.o] Error 1
make[1]: *** [drivers/parport] Error 2
make: *** [drivers] Error 2

got this:

[EMAIL PROTECTED]:/opt/linux/linux-2.6.13-mm2a$ make menuconfig
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/mconf
  HOSTCC  scripts/lxdialog/checklist.o
  HOSTCC  scripts/lxdialog/inputbox.o
  HOSTCC  scripts/lxdialog/lxdialog.o
  HOSTCC  scripts/lxdialog/menubox.o
  HOSTCC  scripts/lxdialog/msgbox.o
  HOSTCC  scripts/lxdialog/textbox.o
  HOSTCC  scripts/lxdialog/util.o
  HOSTCC  scripts/lxdialog/yesno.o
  HOSTLD  scripts/lxdialog/lxdialog
scripts/kconfig/mconf arch/i386/Kconfig
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_ANUBIS
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD4
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD5
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_AES_X86_64
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO 
HERMES TMD_HERMES
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
HOSTAP_PCI
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO 
WAVELAN
#
# using defaults found in .config
#
from this: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2a.gz
and: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2b.gz
when I tried again, slightly different config.  I don't do wireless networking, 
clueless ;-)

Grant.

-
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.13-mm2

[Grant Coady]

On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton [EMAIL PROTECTED] wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/

Hi Andrew,

After this error:

  CC  drivers/parport/parport_pc.o
drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section type 
conflict
drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section type 
conflict
drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a 
section type conflict
drivers/parport/parport_pc.c:2782: error: cards causes a section type conflict
make[2]: *** [drivers/parport/parport_pc.o] Error 1
make[1]: *** [drivers/parport] Error 2
make: *** [drivers] Error 2

got this:

[EMAIL PROTECTED]:/opt/linux/linux-2.6.13-mm2a$ make menuconfig
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/mconf
  HOSTCC  scripts/lxdialog/checklist.o
  HOSTCC  scripts/lxdialog/inputbox.o
  HOSTCC  scripts/lxdialog/lxdialog.o
  HOSTCC  scripts/lxdialog/menubox.o
  HOSTCC  scripts/lxdialog/msgbox.o
  HOSTCC  scripts/lxdialog/textbox.o
  HOSTCC  scripts/lxdialog/util.o
  HOSTCC  scripts/lxdialog/yesno.o
  HOSTLD  scripts/lxdialog/lxdialog
scripts/kconfig/mconf arch/i386/Kconfig
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_ANUBIS
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD4
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD5
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
IEEE80211_CRYPT_WEP CRYPTO CRYPTO_AES_X86_64
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO 
HERMES TMD_HERMES
Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP 
HOSTAP_PCI
Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO 
WAVELAN
#
# using defaults found in .config
#
from this: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2a.gz
and: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2b.gz
when I tried again, slightly different config.  I don't do wireless networking, 
clueless ;-)

Grant.

-
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-usb-devel] Genesys USB 2.0 enclosures

[Grant Coady]

On Sun, 4 Sep 2005 14:04:46 -0700, Matthew Dharm <[EMAIL PROTECTED]> wrote:

>On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote:
>> On Sat, 3 Sep 2005, Jan De Luyck wrote:
>> 
>> > I've posted in the past about problems with these enclosures - increasing 
>> > the 
>> > delay seems to fix it, albeit temporarily. The further you go in using the 
>> > disk in such an enclosure, the higher the udelay() had to be - atleast 
>> > that's 
>> > what I'm seeing here (I've got two of these now :/ )
>> > 
>> > One permanent fix is adding a powered USB-hub in between the drive 
>> > enclosures 
>> > and the computer. Since I've done that, I've no longer seen any of the 
>> > problems (i've attached the 'fault' log). Weird but true, since the drives 
>> > come with their own powersupply.
>> > 
>> > Hope this helps anyone in the future running into the same problem.
>> 
>> This one certainly goes into the Bizarro file.
>> 
>> Just out of curiosity -- when you use the powered hub, does the drive work 
>> even if you remove that delay completely?
>
>Aren't USB 2.0 hubs more "intelligent" as part of the requirement to
>support 1.1 and 2.0 devices?  I wonder if it's really a 2.0 drive, and if
>the timing is different enough with the hub to make a difference.

Fixed a USB powered (two USB plugs) Genesys based 2.5" HDD enclosure with 
extra 5V supply bypass capacitors, the HDD was shutting down without loss 
of data with a 'soft' 5V supply.  Now USB drive works everywhere except a 
laptop with a single USB.  HDD uses 700mA, USB is spec'd 500mA per socket.

Some bugs are the hardware :o)

Grant.

-
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-usb-devel] Genesys USB 2.0 enclosures

[Grant Coady]

On Sun, 4 Sep 2005 14:04:46 -0700, Matthew Dharm [EMAIL PROTECTED] wrote:

On Sat, Sep 03, 2005 at 09:53:19PM -0400, Alan Stern wrote:
 On Sat, 3 Sep 2005, Jan De Luyck wrote:
 
  I've posted in the past about problems with these enclosures - increasing 
  the 
  delay seems to fix it, albeit temporarily. The further you go in using the 
  disk in such an enclosure, the higher the udelay() had to be - atleast 
  that's 
  what I'm seeing here (I've got two of these now :/ )
  
  One permanent fix is adding a powered USB-hub in between the drive 
  enclosures 
  and the computer. Since I've done that, I've no longer seen any of the 
  problems (i've attached the 'fault' log). Weird but true, since the drives 
  come with their own powersupply.
  
  Hope this helps anyone in the future running into the same problem.
 
 This one certainly goes into the Bizarro file.
 
 Just out of curiosity -- when you use the powered hub, does the drive work 
 even if you remove that delay completely?

Aren't USB 2.0 hubs more intelligent as part of the requirement to
support 1.1 and 2.0 devices?  I wonder if it's really a 2.0 drive, and if
the timing is different enough with the hub to make a difference.

Fixed a USB powered (two USB plugs) Genesys based 2.5 HDD enclosure with 
extra 5V supply bypass capacitors, the HDD was shutting down without loss 
of data with a 'soft' 5V supply.  Now USB drive works everywhere except a 
laptop with a single USB.  HDD uses 700mA, USB is spec'd 500mA per socket.

Some bugs are the hardware :o)

Grant.

-
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.13-rc6-mm2

[Grant . Coady]

On Thu, 1 Sep 2005 09:03:38 +0200, Jean Delvare <[EMAIL PROTECTED]> wrote:

Hi Jean,

>Hi Grant,
>
>> adm9240 i2c still broken, spamming debug with:
>> (...)
>> Aug 23 18:48:40 peetoo kernel: [ 1591.151834] i2c_adapter i2c-0: Transaction 
>> (pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
>> Aug 23 18:48:40 peetoo kernel: [ 1591.170515] i2c_adapter i2c-0: Transaction 
>> (post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
>> (...)
>> As soon as write sysfs.
>
>This is not the adm9240 driver writing this, but the smbus driver for
>the SMBus chip your ADM9240 chip is connected to. Which driver is it for
>you? lsmod should tell (if not, modprobe i2c-dev && i2cdetect -l
>should.)

[EMAIL PROTECTED]:/var/log# modprobe adm9240
[EMAIL PROTECTED]:/var/log# sensors
adm9240-i2c-0-2d
Adapter: SMBus PIIX4 adapter at 7000
  2.5V:+1.51 V  (min =  +0.00 V, max =  +3.32 V)
   -5V:-5.08 V  (min = -11.66 V, max =  -0.01 V)
  3.3V:+3.37 V  (min =  +0.00 V, max =  +4.38 V)
5V:+5.18 V  (min =  +0.00 V, max =  +6.64 V)
   12V:   +12.31 V  (min =  +0.00 V, max = +15.94 V)
  -12V:   -11.69 V  (min = -28.33 V, max =  -5.14 V)
PS Fan:  0 RPM  (min =0 RPM, div = 2)
  Temp:+32.0°C  (high =  +127°C, hyst =  +127°C)
vid:   +2.00 V
alarms:   Chassis intrusion detection  ALARM

[EMAIL PROTECTED]:/sys/bus/i2c/devices/0-002d# echo -e "1\c" > chassis_clear
[EMAIL PROTECTED]:/sys/bus/i2c/devices/0-002d# echo -e "1" > chassis_clear



It seems now to be Jon Smirl's stomping sysfs, sorry for noise.

Cheers,
Grant.

-
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.13-rc6-mm2

[Grant . Coady]

On Thu, 1 Sep 2005 09:03:38 +0200, Jean Delvare [EMAIL PROTECTED] wrote:

Hi Jean,

Hi Grant,

 adm9240 i2c still broken, spamming debug with:
 (...)
 Aug 23 18:48:40 peetoo kernel: [ 1591.151834] i2c_adapter i2c-0: Transaction 
 (pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
 Aug 23 18:48:40 peetoo kernel: [ 1591.170515] i2c_adapter i2c-0: Transaction 
 (post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
 (...)
 As soon as write sysfs.

This is not the adm9240 driver writing this, but the smbus driver for
the SMBus chip your ADM9240 chip is connected to. Which driver is it for
you? lsmod should tell (if not, modprobe i2c-dev  i2cdetect -l
should.)

[EMAIL PROTECTED]:/var/log# modprobe adm9240
[EMAIL PROTECTED]:/var/log# sensors
adm9240-i2c-0-2d
Adapter: SMBus PIIX4 adapter at 7000
  2.5V:+1.51 V  (min =  +0.00 V, max =  +3.32 V)
   -5V:-5.08 V  (min = -11.66 V, max =  -0.01 V)
  3.3V:+3.37 V  (min =  +0.00 V, max =  +4.38 V)
5V:+5.18 V  (min =  +0.00 V, max =  +6.64 V)
   12V:   +12.31 V  (min =  +0.00 V, max = +15.94 V)
  -12V:   -11.69 V  (min = -28.33 V, max =  -5.14 V)
PS Fan:  0 RPM  (min =0 RPM, div = 2)
  Temp:+32.0°C  (high =  +127°C, hyst =  +127°C)
vid:   +2.00 V
alarms:   Chassis intrusion detection  ALARM

[EMAIL PROTECTED]:/sys/bus/i2c/devices/0-002d# echo -e 1\c  chassis_clear
[EMAIL PROTECTED]:/sys/bus/i2c/devices/0-002d# echo -e 1  chassis_clear

terminal lockup

It seems now to be Jon Smirl's stomping sysfs, sorry for noise.

Cheers,
Grant.

-
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.13-rc6-mm2

[Grant . Coady]

On Mon, 22 Aug 2005 21:30:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm2/
>
>- Various updates.  Nothing terribly noteworthy.

adm9240 i2c still broken, spamming debug with:
Aug 23 18:48:40 peetoo kernel: [ 1591.151460] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.151834] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.170515] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.170881] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.189837] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.190217] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.208927] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.209296] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00

As soon as write sysfs.  Dunno where to start, this is from adm9240 
driver that works in 2.6.13-rc6-git12 but not -mm1 or -mm2, terminal 
lost, but able to log in on another terminal.  -mm2 was okay until I 
wrote to sysfs.  With -mm1 it failed on reading the sysfs area as well, 
so there's a little progress.  

top:
top - 18:52:07 up 29 min,  2 users,  load average: 0.99, 0.62, 0.26
Tasks:  50 total,   3 running,  47 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3% us,  0.0% sy,  0.0% ni, 99.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:515360k total,   146504k used,   368856k free,15932k buffers
Swap:   514000k total,0k used,   514000k free,   109296k cached

Grant.

-
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.13-rc6-mm2

[Grant . Coady]

On Mon, 22 Aug 2005 21:30:21 -0700, Andrew Morton [EMAIL PROTECTED] wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm2/

- Various updates.  Nothing terribly noteworthy.

adm9240 i2c still broken, spamming debug with:
Aug 23 18:48:40 peetoo kernel: [ 1591.151460] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.151834] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.170515] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.170881] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.189837] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.190217] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.208927] i2c_adapter i2c-0: Transaction 
(post): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00
Aug 23 18:48:40 peetoo kernel: [ 1591.209296] i2c_adapter i2c-0: Transaction 
(pre): CNT=08, CMD=2c, ADD=5a, DAT0=00, DAT1=00

As soon as write sysfs.  Dunno where to start, this is from adm9240 
driver that works in 2.6.13-rc6-git12 but not -mm1 or -mm2, terminal 
lost, but able to log in on another terminal.  -mm2 was okay until I 
wrote to sysfs.  With -mm1 it failed on reading the sysfs area as well, 
so there's a little progress.  

top:
top - 18:52:07 up 29 min,  2 users,  load average: 0.99, 0.62, 0.26
Tasks:  50 total,   3 running,  47 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3% us,  0.0% sy,  0.0% ni, 99.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:515360k total,   146504k used,   368856k free,15932k buffers
Swap:   514000k total,0k used,   514000k free,   109296k cached

Grant.

-
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/

2.6.12.5 ATAPI Iomega Zip100 problem, more info, solved?

[Grant Coady]

Greetings,

Some more info on removable media oddness.  I use both vfat and ext2 
format zip disk.  Two mountpoints:

/dev/hdc4   /mnt/zipvfatnoauto,user 0 0
/dev/hdc1   /mnt/zip2   ext2noauto,user 0 0

Odd behaviour:

$ mount /mnt/zip
mount: /dev/hdc4 is not a valid block device

Yet at this point fdisk can access the zip disk.  On the other hand an ext2 
formatted zip disk works as expected with "mount /mnt/zip2"


Making ide_floppy a module avoids this odd behaviour.

Cheers,
Grant.

-
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/

2.6.12.5 ATAPI Iomega Zip100 problem, more info, solved?

[Grant Coady]

Greetings,

Some more info on removable media oddness.  I use both vfat and ext2 
format zip disk.  Two mountpoints:

/dev/hdc4   /mnt/zipvfatnoauto,user 0 0
/dev/hdc1   /mnt/zip2   ext2noauto,user 0 0

Odd behaviour:

$ mount /mnt/zip
mount: /dev/hdc4 is not a valid block device

Yet at this point fdisk can access the zip disk.  On the other hand an ext2 
formatted zip disk works as expected with mount /mnt/zip2


Making ide_floppy a module avoids this odd behaviour.

Cheers,
Grant.

-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Sun, 14 Aug 2005 22:12:55 +1000, Roger Luethi <[EMAIL PROTECTED]> wrote:


@@ -31,7 +31,7 @@
 #define APC_BPORT_REG  0x30

 #define APC_REGMASK0x01
-define APC_BPMASK  0x03
+#define APC_BPMASK 0x03


Color me skeptical. I've seen some weird bit flips and data corruption;
"paramters" to "paramEters" I could buy. But data corruption that
_inserts_ a hash mark a the beginning of a line of a header file? What
are the odds?


A bitflip in the compressed image could expand the wrong token
resulting in dataloss just as easily as flip character case.

Since reporting this error I've eliminated filesystem and NIC
by substitution, fault occurs on ext2 and Intel pro/100.



Today disabled onboard via-rhine and used Intel pro/100 + e100 driver,
several source trees unpacked identically, running 2.6.12.4 or 2.4.31-hf3


While that seems to point to the Rhine as the possible cause, I can't
see how any driver could possibly be involved in this.


Neither can I, now testing outside of linux, eliminate OS as factor,
or, is it hardware or software?  I dunno...

Grant.
-
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/

Resolved?: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Fri, 12 Aug 2005 09:43:31 +1000, Grant Coady <[EMAIL PROTECTED]> wrote:

Hi there,

Problem was dataloss on extracting kernel source, sometimes only 
one character changed.  Details on 

  http://bugsplatter.mine.nu/test/boxen/sempro/

Not the NIC, not reiserfs, not the kernel config, not even the 
SATA data cable...  Not make sense :o)

Dataloss seemed to be the buffered memory copy of the tarball, 
but this box also compile several hundred kernels in a session 
without a problem.  It also locked up after 4 1/2 hours compiling, 
at that time I thought a kernel config change fixed the issue.

Solution?

Set BIOS memory timing to manual, thinking perhaps BIOS sometimes 
not read SPD EEPROM correctly, 'cos it was like I had bad memory 
only sometimes, reboot, memory okay, next day maybe something bad 
again.

I'll be extracting source tarballs twice and diff for some time to 
be sure.  Built the box in March, it sometimes locked up, I'd do 
some ad hoc kernel config adjustments and carry on.  This time I try 
to methodically nail the issue and got nowhere with configuration 
changes.

Does BIOS not setting memory timing properly sometimes sound like a 
reasonable explanation for the fault?  Extracted about 100 tarballs 
without error.  Currently running 2.6.13-rc6-git5 which produced 
heaps of errors before I attacked the hardware, reseating memory 
modules, AGP card and adjust the BIOS settings.

Grant.

-
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/

Resolved?: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Fri, 12 Aug 2005 09:43:31 +1000, Grant Coady [EMAIL PROTECTED] wrote:

Hi there,

Problem was dataloss on extracting kernel source, sometimes only 
one character changed.  Details on 

  http://bugsplatter.mine.nu/test/boxen/sempro/

Not the NIC, not reiserfs, not the kernel config, not even the 
SATA data cable...  Not make sense :o)

Dataloss seemed to be the buffered memory copy of the tarball, 
but this box also compile several hundred kernels in a session 
without a problem.  It also locked up after 4 1/2 hours compiling, 
at that time I thought a kernel config change fixed the issue.

Solution?

Set BIOS memory timing to manual, thinking perhaps BIOS sometimes 
not read SPD EEPROM correctly, 'cos it was like I had bad memory 
only sometimes, reboot, memory okay, next day maybe something bad 
again.

I'll be extracting source tarballs twice and diff for some time to 
be sure.  Built the box in March, it sometimes locked up, I'd do 
some ad hoc kernel config adjustments and carry on.  This time I try 
to methodically nail the issue and got nowhere with configuration 
changes.

Does BIOS not setting memory timing properly sometimes sound like a 
reasonable explanation for the fault?  Extracted about 100 tarballs 
without error.  Currently running 2.6.13-rc6-git5 which produced 
heaps of errors before I attacked the hardware, reseating memory 
modules, AGP card and adjust the BIOS settings.

Grant.

-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Sun, 14 Aug 2005 22:12:55 +1000, Roger Luethi [EMAIL PROTECTED] wrote:


@@ -31,7 +31,7 @@
 #define APC_BPORT_REG  0x30

 #define APC_REGMASK0x01
-define APC_BPMASK  0x03
+#define APC_BPMASK 0x03


Color me skeptical. I've seen some weird bit flips and data corruption;
paramters to paramEters I could buy. But data corruption that
_inserts_ a hash mark a the beginning of a line of a header file? What
are the odds?


A bitflip in the compressed image could expand the wrong token
resulting in dataloss just as easily as flip character case.

Since reporting this error I've eliminated filesystem and NIC
by substitution, fault occurs on ext2 and Intel pro/100.



Today disabled onboard via-rhine and used Intel pro/100 + e100 driver,
several source trees unpacked identically, running 2.6.12.4 or 2.4.31-hf3


While that seems to point to the Rhine as the possible cause, I can't
see how any driver could possibly be involved in this.


Neither can I, now testing outside of linux, eliminate OS as factor,
or, is it hardware or software?  I dunno...

Grant.
-
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: [PATCH,RFC] quirks for VIA VT8237 southbridge

[Grant Coady]

On Sat, 13 Aug 2005 12:41:33 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote:

>Grant Coady wrote:
>> I'm tracking a dataloss on box with this chip, finding it difficult 
>> to nail a configuration that reliably produces dataloss, sometimes 
>> only one bit (e.g. 'c' --> 'C') of unpacking kernel source tree gets 
>> changed.
...
>Just to eliminate one possibility, I would definitely switch out SATA 
>cables, which are notoriously crappy.

Since I have a spare new cable, done so.  But just now check SMART (in 
windows) and have zero UltraATA CRC Error rate (cable errors) for HDD.

Thanks,
Grant.

-
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: [PATCH,RFC] quirks for VIA VT8237 southbridge

[Grant Coady]

On Sat, 13 Aug 2005 17:10:38 +0200, Karsten Wiese <[EMAIL PROTECTED]> wrote:

>Hi,
>
>this fixes the 'doubled ioapic level interrupt rate' issue I've been
>seeing on a K8T800/AMD64 mainboard.
>It also switches off quirk_via_irq() for the VT8237 southbridge.

I'm tracking a dataloss on box with this chip, finding it difficult 
to nail a configuration that reliably produces dataloss, sometimes 
only one bit (e.g. 'c' --> 'C') of unpacking kernel source tree gets 
changed.

Relevant?  This is on a KM400 with Skt A Sempron + Seagate SATA HDD.
http://bugsplatter.mine.nu/test/linux-2.6/sempro/

Thanks,
Grant.

-
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: [PATCH,RFC] quirks for VIA VT8237 southbridge

[Grant Coady]

On Sat, 13 Aug 2005 17:10:38 +0200, Karsten Wiese [EMAIL PROTECTED] wrote:

Hi,

this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.

I'm tracking a dataloss on box with this chip, finding it difficult 
to nail a configuration that reliably produces dataloss, sometimes 
only one bit (e.g. 'c' -- 'C') of unpacking kernel source tree gets 
changed.

Relevant?  This is on a KM400 with Skt A Sempron + Seagate SATA HDD.
http://bugsplatter.mine.nu/test/linux-2.6/sempro/

Thanks,
Grant.

-
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: [PATCH,RFC] quirks for VIA VT8237 southbridge

[Grant Coady]

On Sat, 13 Aug 2005 12:41:33 -0400, Jeff Garzik [EMAIL PROTECTED] wrote:

Grant Coady wrote:
 I'm tracking a dataloss on box with this chip, finding it difficult 
 to nail a configuration that reliably produces dataloss, sometimes 
 only one bit (e.g. 'c' -- 'C') of unpacking kernel source tree gets 
 changed.
...
Just to eliminate one possibility, I would definitely switch out SATA 
cables, which are notoriously crappy.

Since I have a spare new cable, done so.  But just now check SMART (in 
windows) and have zero UltraATA CRC Error rate (cable errors) for HDD.

Thanks,
Grant.

-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Sat, 13 Aug 2005 00:21:30 +1000, Masoud Sharbiani <[EMAIL PROTECTED]> wrote:


Can you turn on UDP checksums and try again? That would isolate the
fault between the network or SATA.


It is the second tarball extraction from cache that suffers data
corruption, not a network error.  I am in process of narrowing
down cause as I now have 2.4.32-pre3 and 2.6.13-rc6-git3 .configs
that work okay (5 tarball extracts, diff okay)on reiserfs and ext2.

Something to do with MTRR, highmem (box has 1GB), unwanted MP
detection in dmesg --> no longer network, filesystem and/or SATA
driver directly, dunno what yet, but tedious process of elimination
will take time.

How do I force fetching tarball from over NFS again?  At present
the repeat extractions are from memory, not from network.

Cheers,
Grant.
-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Fri, 12 Aug 2005 14:43:42 +0400, "Vladimir V. Saveliev" <[EMAIL PROTECTED]> 
wrote:
>> How to test and isolate this error is in NIC driver, SATA driver or 
>> filesystem?  
>> 
>
>Could it be that tarbal on NFS server changed?
>It is not very likely that error in kernel drivers fixed typos in source code.

The 'typos' are the observed errors from extracting kernel source tarball, 
renaming top level directory and extracting tarball again.  Other times 
extraction fails with corrupt tarball error.  Cached image of tarball is 
corrupted as box doesn't go back to server.

Since first report I've changed to using ext2 target filesystem, still get 
errors, so not reiserfs specific either.  

Am in process of reducing options in kernel config, try to narrow down 
what problem is.  Nothing in logs, me have no idea ... yet.  

Not a memory error as box compiled many hundred kernels last week without 
choking.  Test just now was with 2.6.13-rc6-git3, very repeatable.

Same test on different box, no errors.  Other box has pro/100 NIC, 
reiserfs, unpack tarball from same server.  Never a problem.

Cheers,
Grant.

-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Fri, 12 Aug 2005 14:43:42 +0400, Vladimir V. Saveliev [EMAIL PROTECTED] 
wrote:
 How to test and isolate this error is in NIC driver, SATA driver or 
 filesystem?  
 

Could it be that tarbal on NFS server changed?
It is not very likely that error in kernel drivers fixed typos in source code.

The 'typos' are the observed errors from extracting kernel source tarball, 
renaming top level directory and extracting tarball again.  Other times 
extraction fails with corrupt tarball error.  Cached image of tarball is 
corrupted as box doesn't go back to server.

Since first report I've changed to using ext2 target filesystem, still get 
errors, so not reiserfs specific either.  

Am in process of reducing options in kernel config, try to narrow down 
what problem is.  Nothing in logs, me have no idea ... yet.  

Not a memory error as box compiled many hundred kernels last week without 
choking.  Test just now was with 2.6.13-rc6-git3, very repeatable.

Same test on different box, no errors.  Other box has pro/100 NIC, 
reiserfs, unpack tarball from same server.  Never a problem.

Cheers,
Grant.

-
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: Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

On Sat, 13 Aug 2005 00:21:30 +1000, Masoud Sharbiani [EMAIL PROTECTED] wrote:


Can you turn on UDP checksums and try again? That would isolate the
fault between the network or SATA.


It is the second tarball extraction from cache that suffers data
corruption, not a network error.  I am in process of narrowing
down cause as I now have 2.4.32-pre3 and 2.6.13-rc6-git3 .configs
that work okay (5 tarball extracts, diff okay)on reiserfs and ext2.

Something to do with MTRR, highmem (box has 1GB), unwanted MP
detection in dmesg -- no longer network, filesystem and/or SATA
driver directly, dunno what yet, but tedious process of elimination
will take time.

How do I force fetching tarball from over NFS again?  At present
the repeat extractions are from memory, not from network.

Cheers,
Grant.
-
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/

Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

Greetings,

Situation is dataloss with no errors logged.

Test: unpack 2.6.12 tarball from NFS mount source, diff against 
previous attempt:

$ diff -Nrup linux-2.6.12.old linux-2.6.12
Binary files linux-2.6.12.old/include/asm-sparc/a.out.h and 
linux-2.6.12/include/asm-sparc/a.out.h differ
diff -Nrup linux-2.6.12.old/include/asm-sparc/apc.h 
linux-2.6.12/include/asm-sparc/apc.h
--- linux-2.6.12.old/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
@@ -31,7 +31,7 @@
 #define APC_BPORT_REG  0x30

 #define APC_REGMASK0x01
-define APC_BPMASK  0x03
+#define APC_BPMASK 0x03

 /*
  * IDLE - CPU standby values (set to initiate standby)
diff -Nrup linux-2.6.12.old/include/asm-sparc/svr4.h 
linux-2.6.12/include/asm-sparc/svr4.h
--- linux-2.6.12.old/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
@@ -15,7 +15,7 @@ typedef struct {/* signa

 /* Values for siginfo.code */
 #define SVR4_SINOINFO 32767
-/* Siginfo, sucker expects bunch of information on those paramEters */
+/* Siginfo, sucker expects bunch of information on those parameters */
 typedef union {
char total_size [128];
struct {


Seems like three bit errors for source tree.  Other times I've noted 
compile failures where unpacking source tree fresh would 'fix' error.
I'd previously assumed that I accidentally killed source tree with 
'cp -al ...' copies but I've had a segfault on that operation, hence 
I do not know if this be NIC or filesystem (reiserfs on via SATA).


Today disabled onboard via-rhine and used Intel pro/100 + e100 driver, 
several source trees unpacked identically, running 2.6.12.4 or 2.4.31-hf3

The fault occurs on 2.4 latest or 2.6 latest only on particular target 
box, so problem is not the NFS server.

How to test and isolate this error is in NIC driver, SATA driver or 
filesystem?  

Thanks,
Grant.

-
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/

Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

Greetings,

Situation is dataloss with no errors logged.

Test: unpack 2.6.12 tarball from NFS mount source, diff against 
previous attempt:

$ diff -Nrup linux-2.6.12.old linux-2.6.12
Binary files linux-2.6.12.old/include/asm-sparc/a.out.h and 
linux-2.6.12/include/asm-sparc/a.out.h differ
diff -Nrup linux-2.6.12.old/include/asm-sparc/apc.h 
linux-2.6.12/include/asm-sparc/apc.h
--- linux-2.6.12.old/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
@@ -31,7 +31,7 @@
 #define APC_BPORT_REG  0x30

 #define APC_REGMASK0x01
-define APC_BPMASK  0x03
+#define APC_BPMASK 0x03

 /*
  * IDLE - CPU standby values (set to initiate standby)
diff -Nrup linux-2.6.12.old/include/asm-sparc/svr4.h 
linux-2.6.12/include/asm-sparc/svr4.h
--- linux-2.6.12.old/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
@@ -15,7 +15,7 @@ typedef struct {/* signa

 /* Values for siginfo.code */
 #define SVR4_SINOINFO 32767
-/* Siginfo, sucker expects bunch of information on those paramEters */
+/* Siginfo, sucker expects bunch of information on those parameters */
 typedef union {
char total_size [128];
struct {


Seems like three bit errors for source tree.  Other times I've noted 
compile failures where unpacking source tree fresh would 'fix' error.
I'd previously assumed that I accidentally killed source tree with 
'cp -al ...' copies but I've had a segfault on that operation, hence 
I do not know if this be NIC or filesystem (reiserfs on via SATA).


Today disabled onboard via-rhine and used Intel pro/100 + e100 driver, 
several source trees unpacked identically, running 2.6.12.4 or 2.4.31-hf3

The fault occurs on 2.4 latest or 2.6 latest only on particular target 
box, so problem is not the NFS server.

How to test and isolate this error is in NIC driver, SATA driver or 
filesystem?  

Thanks,
Grant.

-
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: Documentation - how to apply patches for various trees

[Grant Coady]

Hi Jesper,
On Wed, 3 Aug 2005 23:28:06 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote:

I like it, just a little concerned about confusing new user with too 
many alternative patching methods up front...

>+ This (as usual with Linux and other UNIX like operating systems) can be
>+done in several different ways.
>+In all the examples below I feed the file (in uncompressed form) to patch
>+via stdin using the following syntax:
>+  patch -p1 < path/to/patch-x.y.z
>+
>+but patch can also get the name of the file to use via the -i argument, like
>+this:
>+  patch -p1 -i path/to/patch-x.y.z
>+
>+If your patch file is compressed with gzip or bzip2 and you don't want to
>+uncompress it before applying it, then you can feed it to patch like this
>+instead:

cat path/to/patch-x.y.z.gz | patch -p1
>+  zcat path/to/patch-x.y.z.gz | patch -p1
>+  bzcat path/to/patch-x.y.z.bz2 | patch -p1

In a howto, I'd prefer  _one_ consistent method to reduce the 
reader's confusion.  

The above trio of commands serves me well over many years' kernel 
patching, and it is trivial to up-arrow, home, change compression 
method, retry ... when my fingers get ahead of my mind :)


Experience users recognise the intent of the commands and use their 
favourite method instead, almost without thinking.


Spelling:

s/uncompression/decompression/
s/adviced/advised/
s/bandwith/bandwidth/

Cheers,
Grant.

-
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.13-rc5 randconfig kernel build errors

[Grant Coady]

Hi Adrian,
On Wed, 3 Aug 2005 13:20:50 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:

>> 
>> After 300 random builds, add one more error:
>> drivers/acpi/osl.c:261: error: `AmlCode' undeclared (first use in this 
>> function)
>> drivers/acpi/osl.c:61:10: empty file name in #include
>
>Please exclude builds with CONFIG_STANDALONE=n.
Okay.
>
>And please don't send every new error you are finding to this list.
Go tell the dimwits not trimming their posts to control themselves, 
I'm generating minimal traffic with this project.  Certainly far 
less traffic then that imbecile arguing for _his_ default setting.

>As I've already said generating the errors is the the easy part -
>analyzing them is the real work.

Starting somewhere, I'll settle :)  It is this feedback I need at 
start -- sorts of things to exclude.  I'll not get any feedback 
without reporting stuff to the list.
>
>It would be best if you would do this yourself and send specific bug 
>reports (or even patches) for the problems you've find.

I looked at that AmlCode error source file and grepping for a match 
failed for entire source tree, so did not understand it.  
>
>If you want to publish the errors you've found, send a pointer to a 
>location where it is available _once_ and update the information there.

Killfile me.  I'm posting far less noise to lkml per month than 
your daily line count of repetitive, non-informational space 
wasting dot_sig.

Thanks,
Grant.

-
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.13-rc5 randconfig kernel build errors

[Grant Coady]

On Tue, 02 Aug 2005 22:58:59 +1000, Grant Coady <[EMAIL PROTECTED]> wrote:

>Greetings,
>
>Preliminary results, better sample (some hundreds) in a day or so.

After 300 random builds, add one more error:
drivers/acpi/osl.c:261: error: `AmlCode' undeclared (first use in this function)
drivers/acpi/osl.c:61:10: empty file name in #include

Cheers,
Grant.

-
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.13-rc5 randconfig kernel build errors

[Grant Coady]

On Tue, 02 Aug 2005 22:58:59 +1000, Grant Coady [EMAIL PROTECTED] wrote:

Greetings,

Preliminary results, better sample (some hundreds) in a day or so.

After 300 random builds, add one more error:
drivers/acpi/osl.c:261: error: `AmlCode' undeclared (first use in this function)
drivers/acpi/osl.c:61:10: empty file name in #include

Cheers,
Grant.

-
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.13-rc5 randconfig kernel build errors

[Grant Coady]

Hi Adrian,
On Wed, 3 Aug 2005 13:20:50 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:

 
 After 300 random builds, add one more error:
 drivers/acpi/osl.c:261: error: `AmlCode' undeclared (first use in this 
 function)
 drivers/acpi/osl.c:61:10: empty file name in #include

Please exclude builds with CONFIG_STANDALONE=n.
Okay.

And please don't send every new error you are finding to this list.
Go tell the dimwits not trimming their posts to control themselves, 
I'm generating minimal traffic with this project.  Certainly far 
less traffic then that imbecile arguing for _his_ default setting.

As I've already said generating the errors is the the easy part -
analyzing them is the real work.

Starting somewhere, I'll settle :)  It is this feedback I need at 
start -- sorts of things to exclude.  I'll not get any feedback 
without reporting stuff to the list.

It would be best if you would do this yourself and send specific bug 
reports (or even patches) for the problems you've find.

I looked at that AmlCode error source file and grepping for a match 
failed for entire source tree, so did not understand it.  

If you want to publish the errors you've found, send a pointer to a 
location where it is available _once_ and update the information there.

Killfile me.  I'm posting far less noise to lkml per month than 
your daily line count of repetitive, non-informational space 
wasting dot_sig.

Thanks,
Grant.

-
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: Documentation - how to apply patches for various trees

[Grant Coady]

Hi Jesper,
On Wed, 3 Aug 2005 23:28:06 +0200, Jesper Juhl [EMAIL PROTECTED] wrote:

I like it, just a little concerned about confusing new user with too 
many alternative patching methods up front...

+ This (as usual with Linux and other UNIX like operating systems) can be
+done in several different ways.
+In all the examples below I feed the file (in uncompressed form) to patch
+via stdin using the following syntax:
+  patch -p1  path/to/patch-x.y.z
+
+but patch can also get the name of the file to use via the -i argument, like
+this:
+  patch -p1 -i path/to/patch-x.y.z
+
+If your patch file is compressed with gzip or bzip2 and you don't want to
+uncompress it before applying it, then you can feed it to patch like this
+instead:

cat path/to/patch-x.y.z.gz | patch -p1
+  zcat path/to/patch-x.y.z.gz | patch -p1
+  bzcat path/to/patch-x.y.z.bz2 | patch -p1

In a howto, I'd prefer  _one_ consistent method to reduce the 
reader's confusion.  

The above trio of commands serves me well over many years' kernel 
patching, and it is trivial to up-arrow, home, change compression 
method, retry ... when my fingers get ahead of my mind :)


Experience users recognise the intent of the commands and use their 
favourite method instead, almost without thinking.


Spelling:

s/uncompression/decompression/
s/adviced/advised/
s/bandwith/bandwidth/

Cheers,
Grant.

-
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/

2.6.13-rc5 randconfig kernel build errors

[Grant Coady]

Greetings,

Preliminary results, better sample (some hundreds) in a day or so.

2.6.13-rc5
~~
Done processing 70 random builds, from which:
###   6 .configs produced errors
###   4 .configs produced undefs
###  29 .configs produced warnings

# zcat result-report-error-abbrev.gz|cut -d: -f2-
arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomplete type
arch/i386/mach-es7000/es7000.h:88: error: field `Header' has incomplete type
arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_gsi' undeclared 
(first use in this function)
arch/i386/mach-es7000/es7000plat.c:168: warning: implicit declaration of 
function `acpi_find_rsdp'
arch/i386/mach-es7000/es7000plat.c:170: error: dereferencing pointer to 
incomplete type
drivers/char/ipmi/ipmi_msghandler.c:1397: warning: `ipmb_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1406: warning: `version_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1416: warning: `stat_file_read_proc' 
defined but not used
drivers/mtd/maps/nettel.c:419: error: `ROOT_DEV' undeclared (first use in this 
function)
drivers/mtd/maps/nettel.c:419: warning: implicit declaration of function `MKDEV'
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:100: error: dereferencing pointer to 
incomplete type
include/asm-i386/mach-default/mach_apic.h:109: error: `phys_cpu_present_map' 
undeclared (first use in this function)
include/asm-i386/mach-visws/do_timer.h:32: error: `i8259A_lock' undeclared 
(first use in this function)
sound/core/memalloc.c:658: error: `snd_mem_proc' undeclared (first use in this 
function)

Details: http://scatter.mine.nu/test/kernel/2.6.13-rc5/

Grant.

-
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/

2.6.13-rc5 randconfig kernel build errors

[Grant Coady]

Greetings,

Preliminary results, better sample (some hundreds) in a day or so.

2.6.13-rc5
~~
Done processing 70 random builds, from which:
###   6 .configs produced errors
###   4 .configs produced undefs
###  29 .configs produced warnings

# zcat result-report-error-abbrev.gz|cut -d: -f2-
arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomplete type
arch/i386/mach-es7000/es7000.h:88: error: field `Header' has incomplete type
arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_gsi' undeclared 
(first use in this function)
arch/i386/mach-es7000/es7000plat.c:168: warning: implicit declaration of 
function `acpi_find_rsdp'
arch/i386/mach-es7000/es7000plat.c:170: error: dereferencing pointer to 
incomplete type
drivers/char/ipmi/ipmi_msghandler.c:1397: warning: `ipmb_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1406: warning: `version_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1416: warning: `stat_file_read_proc' 
defined but not used
drivers/mtd/maps/nettel.c:419: error: `ROOT_DEV' undeclared (first use in this 
function)
drivers/mtd/maps/nettel.c:419: warning: implicit declaration of function `MKDEV'
include/asm-i386/mach-default/mach_apic.h: At top level:
include/asm-i386/mach-default/mach_apic.h:100: error: dereferencing pointer to 
incomplete type
include/asm-i386/mach-default/mach_apic.h:109: error: `phys_cpu_present_map' 
undeclared (first use in this function)
include/asm-i386/mach-visws/do_timer.h:32: error: `i8259A_lock' undeclared 
(first use in this function)
sound/core/memalloc.c:658: error: `snd_mem_proc' undeclared (first use in this 
function)

Details: http://scatter.mine.nu/test/kernel/2.6.13-rc5/

Grant.

-
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/

Report: 2.6.13-rc4-mm1: only 8 errors for 752 randconfig builds

[Grant Coady]

Greetings,

Automating random config kernel build testing, for 2.6.13-rc4-mm1:

Done processing 752 random builds, from which:
###   8 .configs produced errors
###  11 .configs produced undefs
###  52 .configs produced warnings

Abbreviated errors (first 2 lines/error):

[EMAIL PROTECTED]:/opt/linux$ zcat result-report-error-abbrev.gz|cut -d: -f2-
arch/i386/kernel/cpu/transmeta.c: In function `init_transmeta':
arch/i386/kernel/cpu/transmeta.c:82: error: invalid lvalue in assignment
arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomplete type
arch/i386/mach-es7000/es7000.h:88: error: field `Header' has incomplete type
arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_oem':
arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_gsi' undeclared 
(first use in this function)
drivers/char/ipmi/ipmi_msghandler.c:1397: warning: `ipmb_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1406: warning: `version_file_read_proc' 
defined but not used
drivers/char/speakup/speakup.c: In function `speakup_bits':
drivers/char/speakup/speakup.c:1983: error: `pb_edit' undeclared (first use in 
this function)
drivers/mtd/maps/nettel.c: In function `nettel_init':
drivers/mtd/maps/nettel.c:419: error: `ROOT_DEV' undeclared (first use in this 
function)
include/asm-i386/mach-default/mach_apic.h:25: error: syntax error before 
"bitmap"
include/asm-i386/mach-default/mach_apic.h:26: warning: function declaration 
isn't a prototype
include/asm-i386/mach-visws/do_timer.h: In function `do_timer_overflow':
include/asm-i386/mach-visws/do_timer.h:32: error: `i8259A_lock' undeclared 
(first use in this function)
ipc/shm.c:174: error: `shmem_set_policy' undeclared here (not in a function)
ipc/shm.c:174: error: initializer element is not constant
sound/core/memalloc.c: In function `snd_mem_exit':
sound/core/memalloc.c:658: error: `snd_mem_proc' undeclared (first use in this 
function)

Further info, full error results, configs producing errors, etc from 
http://scatter.mine.nu/test/kernel/2.6.13-rc4-mm1/

Warnings recorded are those not deprecated, not #warning.
bzip2 tarballs of configs producing errors, undefs 22kB, warnings 86kB
A significant data reduction from the 28MB raw build results :)

Note: the report generator lists all faults for a particular source file, 
explains why summary above for errors shows warnings in first 2 lines.

Grant.

-
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/

Report: 2.6.13-rc4-mm1: only 8 errors for 752 randconfig builds

[Grant Coady]

Greetings,

Automating random config kernel build testing, for 2.6.13-rc4-mm1:

Done processing 752 random builds, from which:
###   8 .configs produced errors
###  11 .configs produced undefs
###  52 .configs produced warnings

Abbreviated errors (first 2 lines/error):

[EMAIL PROTECTED]:/opt/linux$ zcat result-report-error-abbrev.gz|cut -d: -f2-
arch/i386/kernel/cpu/transmeta.c: In function `init_transmeta':
arch/i386/kernel/cpu/transmeta.c:82: error: invalid lvalue in assignment
arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomplete type
arch/i386/mach-es7000/es7000.h:88: error: field `Header' has incomplete type
arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_oem':
arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_gsi' undeclared 
(first use in this function)
drivers/char/ipmi/ipmi_msghandler.c:1397: warning: `ipmb_file_read_proc' 
defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1406: warning: `version_file_read_proc' 
defined but not used
drivers/char/speakup/speakup.c: In function `speakup_bits':
drivers/char/speakup/speakup.c:1983: error: `pb_edit' undeclared (first use in 
this function)
drivers/mtd/maps/nettel.c: In function `nettel_init':
drivers/mtd/maps/nettel.c:419: error: `ROOT_DEV' undeclared (first use in this 
function)
include/asm-i386/mach-default/mach_apic.h:25: error: syntax error before 
bitmap
include/asm-i386/mach-default/mach_apic.h:26: warning: function declaration 
isn't a prototype
include/asm-i386/mach-visws/do_timer.h: In function `do_timer_overflow':
include/asm-i386/mach-visws/do_timer.h:32: error: `i8259A_lock' undeclared 
(first use in this function)
ipc/shm.c:174: error: `shmem_set_policy' undeclared here (not in a function)
ipc/shm.c:174: error: initializer element is not constant
sound/core/memalloc.c: In function `snd_mem_exit':
sound/core/memalloc.c:658: error: `snd_mem_proc' undeclared (first use in this 
function)

Further info, full error results, configs producing errors, etc from 
http://scatter.mine.nu/test/kernel/2.6.13-rc4-mm1/

Warnings recorded are those not deprecated, not #warning.
bzip2 tarballs of configs producing errors, undefs 22kB, warnings 86kB
A significant data reduction from the 28MB raw build results :)

Note: the report generator lists all faults for a particular source file, 
explains why summary above for errors shows warnings in first 2 lines.

Grant.

-
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.13 ub 2/3: Fold one line

[Grant Coady]

On Sun, 31 Jul 2005 09:37:43 -0400, Yani Ioannou <[EMAIL PROTECTED]> wrote:

>On 7/31/05, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>> Evidently, Yani Ioannou's display is wider than mine.
>
>[EMAIL PROTECTED]" (Thinkpad) ;-). The changes were done by a script I
>wrote which wasn't checking if the 80 chars limit was surpassed. 

And repairing the files you stomped on?  A combination of you stomping 
coding style plus a maintainer insisting on trailing whitespace was 
enough for me to give up working in that area.  

Grant.

-
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.13 ub 2/3: Fold one line

[Grant Coady]

On Sun, 31 Jul 2005 09:37:43 -0400, Yani Ioannou [EMAIL PROTECTED] wrote:

On 7/31/05, Pete Zaitcev [EMAIL PROTECTED] wrote:
 Evidently, Yani Ioannou's display is wider than mine.

[EMAIL PROTECTED] (Thinkpad) ;-). The changes were done by a script I
wrote which wasn't checking if the 80 chars limit was surpassed. 

And repairing the files you stomped on?  A combination of you stomping 
coding style plus a maintainer insisting on trailing whitespace was 
enough for me to give up working in that area.  

Grant.

-
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/

[PATCH] 2.6: fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling

[Grant Coady]

Greetings,

Patch to fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling.



Signed-off-by: Grant Coady <[EMAIL PROTECTED]>

---
 drivers/ide/ppc/pmac.c  |2 +-
 include/linux/pci_ids.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -X dontdiff -Nrup linux-2.6.13-rc4-git2/drivers/ide/ppc/pmac.c 
linux-2.6.13-rc4-git2a/drivers/ide/ppc/pmac.c
--- linux-2.6.13-rc4-git2/drivers/ide/ppc/pmac.c2005-07-31 
11:32:18.0 +1000
+++ linux-2.6.13-rc4-git2a/drivers/ide/ppc/pmac.c   2005-07-31 
11:32:53.0 +1000
@@ -1664,7 +1664,7 @@ static struct macio_driver pmac_ide_maci
 };
 
 static struct pci_device_id pmac_ide_pci_match[] = {
-   { PCI_VENDOR_ID_APPLE, PCI_DEVIEC_ID_APPLE_UNI_N_ATA, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
+   { PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_ATA, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID_ATA100, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_K2_ATA100, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_SH_ATA,
diff -X dontdiff -Nrup linux-2.6.13-rc4-git2/include/linux/pci_ids.h 
linux-2.6.13-rc4-git2a/include/linux/pci_ids.h
--- linux-2.6.13-rc4-git2/include/linux/pci_ids.h   2005-07-31 
11:32:18.0 +1000
+++ linux-2.6.13-rc4-git2a/include/linux/pci_ids.h  2005-07-31 
11:32:53.0 +1000
@@ -581,7 +581,7 @@
 #define PCI_DEVICE_ID_APPLE_UNI_N_AGP150x002d
 #define PCI_DEVICE_ID_APPLE_UNI_N_PCI150x002e
 #define PCI_DEVICE_ID_APPLE_UNI_N_GMAC20x0032
-#define PCI_DEVIEC_ID_APPLE_UNI_N_ATA  0x0033
+#define PCI_DEVICE_ID_APPLE_UNI_N_ATA  0x0033
 #define PCI_DEVICE_ID_APPLE_UNI_N_AGP2 0x0034
 #define PCI_DEVICE_ID_APPLE_IPID_ATA1000x003b
 #define PCI_DEVICE_ID_APPLE_K2_ATA100  0x0043
-
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: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)

[Grant Coady]

On Sat, 30 Jul 2005 22:36:28 +0100, Russell King <[EMAIL PROTECTED]> wrote:
>
>Let me qualify that, because it's not 100% fine due to the changes in
>PCMCIA land.
>
>Since PCMCIA cards are detected and drivers bound at boot time, we no

Without an unbind/eject option?  Implies reboot to remove a device...

Grant.

-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 18:21:05 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>[speaking to the audience]  I wouldn't mind if someone did a pass 
>through pci_ids.h and removed all the constants that are not being used. 
>  If constants are not being used, it's IMHO more appropriate to store 
>that info in pci.ids.

For: 

linux-2.6.13-rc4:
118 pci_ids-defined_elsewhere-files
475 pci_ids-defined_elsewhere-items
7 pci_ids-duplicate-items
2321 pci_ids-list
725 pci_ids-not_used

linux-2.6.13-rc3-mm3:
119 pci_ids-defined_elsewhere-files
475 pci_ids-defined_elsewhere-items
7 pci_ids-duplicate-items
2325 pci_ids-list
723 pci_ids-not_used

Should the 'defined elsewhere' items be brought into the one 
pci_ids.h file?  Testing will take time.  Patch is ~70kB.

Grant.
-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 18:21:05 -0400, Jeff Garzik [EMAIL PROTECTED] wrote:

[speaking to the audience]  I wouldn't mind if someone did a pass 
through pci_ids.h and removed all the constants that are not being used. 
  If constants are not being used, it's IMHO more appropriate to store 
that info in pci.ids.

For: 

linux-2.6.13-rc4:
118 pci_ids-defined_elsewhere-files
475 pci_ids-defined_elsewhere-items
7 pci_ids-duplicate-items
2321 pci_ids-list
725 pci_ids-not_used

linux-2.6.13-rc3-mm3:
119 pci_ids-defined_elsewhere-files
475 pci_ids-defined_elsewhere-items
7 pci_ids-duplicate-items
2325 pci_ids-list
723 pci_ids-not_used

Should the 'defined elsewhere' items be brought into the one 
pci_ids.h file?  Testing will take time.  Patch is ~70kB.

Grant.
-
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: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)

[Grant Coady]

On Sat, 30 Jul 2005 22:36:28 +0100, Russell King [EMAIL PROTECTED] wrote:

Let me qualify that, because it's not 100% fine due to the changes in
PCMCIA land.

Since PCMCIA cards are detected and drivers bound at boot time, we no

Without an unbind/eject option?  Implies reboot to remove a device...

Grant.

-
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/

[PATCH] 2.6: fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling

[Grant Coady]

Greetings,

Patch to fix PCI_DEVIEC_ID_APPLE_UNI_N_ATA spelling.



Signed-off-by: Grant Coady [EMAIL PROTECTED]

---
 drivers/ide/ppc/pmac.c  |2 +-
 include/linux/pci_ids.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -X dontdiff -Nrup linux-2.6.13-rc4-git2/drivers/ide/ppc/pmac.c 
linux-2.6.13-rc4-git2a/drivers/ide/ppc/pmac.c
--- linux-2.6.13-rc4-git2/drivers/ide/ppc/pmac.c2005-07-31 
11:32:18.0 +1000
+++ linux-2.6.13-rc4-git2a/drivers/ide/ppc/pmac.c   2005-07-31 
11:32:53.0 +1000
@@ -1664,7 +1664,7 @@ static struct macio_driver pmac_ide_maci
 };
 
 static struct pci_device_id pmac_ide_pci_match[] = {
-   { PCI_VENDOR_ID_APPLE, PCI_DEVIEC_ID_APPLE_UNI_N_ATA, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
+   { PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_ATA, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_IPID_ATA100, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_K2_ATA100, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_SH_ATA,
diff -X dontdiff -Nrup linux-2.6.13-rc4-git2/include/linux/pci_ids.h 
linux-2.6.13-rc4-git2a/include/linux/pci_ids.h
--- linux-2.6.13-rc4-git2/include/linux/pci_ids.h   2005-07-31 
11:32:18.0 +1000
+++ linux-2.6.13-rc4-git2a/include/linux/pci_ids.h  2005-07-31 
11:32:53.0 +1000
@@ -581,7 +581,7 @@
 #define PCI_DEVICE_ID_APPLE_UNI_N_AGP150x002d
 #define PCI_DEVICE_ID_APPLE_UNI_N_PCI150x002e
 #define PCI_DEVICE_ID_APPLE_UNI_N_GMAC20x0032
-#define PCI_DEVIEC_ID_APPLE_UNI_N_ATA  0x0033
+#define PCI_DEVICE_ID_APPLE_UNI_N_ATA  0x0033
 #define PCI_DEVICE_ID_APPLE_UNI_N_AGP2 0x0034
 #define PCI_DEVICE_ID_APPLE_IPID_ATA1000x003b
 #define PCI_DEVICE_ID_APPLE_K2_ATA100  0x0043
-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 23:52:39 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>However you did your search, you did it wrong.  The very first two 
>entries I tried had zero uses:
>
>[EMAIL PROTECTED] linux-2.6]$ grepsrc ICH7_22
>./include/linux/pci_ids.h:#define PCI_DEVICE_ID_INTEL_ICH7_22   0x27e0
>[EMAIL PROTECTED] linux-2.6]$ grepsrc ICH7_23
>./include/linux/pci_ids.h:#define PCI_DEVICE_ID_INTEL_ICH7_23   0x27e2
>[EMAIL PROTECTED] linux-2.6]$

Sorry Jeff, excluding "include/linux/pci_ids.h" makes a huge difference :o)

Does roughly 1/3 unused:

63065 2005-07-30 14:51 pci_ids-list
19243 2005-07-30 14:52 pci_ids-not_used

Seem in ballpark?

Thanks,
Grant.
-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 18:21:05 -0400, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>[speaking to the audience]  I wouldn't mind if someone did a pass 
>through pci_ids.h and removed all the constants that are not being used. 

Only these seem not referenced by source:
PCI_CLASS_SYSTEM_PCI_HOTPLUG
PCI_DEVICE_ID_CYRIX_PCI_MASTER
PCI_DEVICE_ID_HP_PCI_LBA
PCI_DEVICE_ID_NP_PCI_FDDI
PCI_DEVICE_ID_UPCI_RM3_4PORT
PCI_DEVICE_ID_UPCI_RM3_8PORT

Source macros refer to:
  BROOKTREE sound/pci/bt87x.c
  YAMAHAsound/oss/ymfpci.c

6 from 2329 entries hardly worth it?

Grant.

-
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: Obsolete files in 2.6 tree

[Grant Coady]

On Fri, 29 Jul 2005 18:40:46 -0300, Mauro Carvalho Chehab <[EMAIL PROTECTED]> 
wrote:
drivers/media/video/zr36120.c
drivers/media/video/zr36120_i2c.c
drivers/media/video/zr36120_mem.c
>> 
>> 
>> Being discussed on the V4L list
>   It seems that nobody are interested on maintaining it. No answer from
>V4L list subscribers.
>
>   I think it may be removed.

Please no, I'll get to it, I have one to play with.
Grant.

-
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: Obsolete files in 2.6 tree

[Grant Coady]

On Fri, 29 Jul 2005 18:40:46 -0300, Mauro Carvalho Chehab [EMAIL PROTECTED] 
wrote:
drivers/media/video/zr36120.c
drivers/media/video/zr36120_i2c.c
drivers/media/video/zr36120_mem.c
 
 
 Being discussed on the V4L list
   It seems that nobody are interested on maintaining it. No answer from
V4L list subscribers.

   I think it may be removed.

Please no, I'll get to it, I have one to play with.
Grant.

-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 18:21:05 -0400, Jeff Garzik [EMAIL PROTECTED] wrote:

[speaking to the audience]  I wouldn't mind if someone did a pass 
through pci_ids.h and removed all the constants that are not being used. 

Only these seem not referenced by source:
PCI_CLASS_SYSTEM_PCI_HOTPLUG
PCI_DEVICE_ID_CYRIX_PCI_MASTER
PCI_DEVICE_ID_HP_PCI_LBA
PCI_DEVICE_ID_NP_PCI_FDDI
PCI_DEVICE_ID_UPCI_RM3_4PORT
PCI_DEVICE_ID_UPCI_RM3_8PORT

Source macros refer to:
  BROOKTREE sound/pci/bt87x.c
  YAMAHAsound/oss/ymfpci.c

6 from 2329 entries hardly worth it?

Grant.

-
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: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R

[Grant Coady]

On Fri, 29 Jul 2005 23:52:39 -0400, Jeff Garzik [EMAIL PROTECTED] wrote:

However you did your search, you did it wrong.  The very first two 
entries I tried had zero uses:

[EMAIL PROTECTED] linux-2.6]$ grepsrc ICH7_22
./include/linux/pci_ids.h:#define PCI_DEVICE_ID_INTEL_ICH7_22   0x27e0
[EMAIL PROTECTED] linux-2.6]$ grepsrc ICH7_23
./include/linux/pci_ids.h:#define PCI_DEVICE_ID_INTEL_ICH7_23   0x27e2
[EMAIL PROTECTED] linux-2.6]$

Sorry Jeff, excluding include/linux/pci_ids.h makes a huge difference :o)

Does roughly 1/3 unused:

63065 2005-07-30 14:51 pci_ids-list
19243 2005-07-30 14:52 pci_ids-not_used

Seem in ballpark?

Thanks,
Grant.
-
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 2.4.32-pre2

[Grant Coady]

On Thu, 28 Jul 2005 07:22:25 -0300, Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>> 
>> Breaks Toshiba laptop: hard lockup --> what is on screen is same as 
>> working dmesg up to point: "host/uhci.c: detected 2 port"
>> 
>> Same .config as for 2.4.31-hf3 or 2.4.32-pre1
>> http://scatter.mine.nu/test/linux-2.4/tosh/
>
>Please try to revert the attached? 

Yes, that fixed it :o) a USB mouse works.

dmesg:
...
host/uhci.c: detected 2 ports <<== previous lockup after this
usb.c: kmalloc IF c12f36e0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: ff80
...

And the other USB driver (usb-uhci) didn't lockup.

Thanks,
Grant.

-
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/

2.4.32-pre2: uhci.c: ff80: host controller halted. very bad

[Grant Coady]

Hi there,
More info on Toshiba laptop lockup with 2.4.32-pre2:

/var/log/syslog:
Jul 28 22:59:33 tosh kernel: Linux version 2.4.32-pre2 ([EMAIL PROTECTED]) (gcc 
version 3.3.5) #4 Thu Jul 28 22:57:05 EST 2005
Jul 28 22:59:33 tosh kernel:  BIOS-e820:  - 0009fc00 
(usable)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0009fc00 - 000a 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 000f - 0010 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0010 - 0bfe 
(usable)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0bfe - 0bff 
(ACPI data)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0bff - 0c00 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100a - 100b6e00 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100b6e00 - 100b7000 
(ACPI NVS)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100b7000 - 1010 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: fff8 - 0001 
(reserved)
Jul 28 22:59:33 tosh kernel: On node 0 totalpages: 49120
Jul 28 22:59:33 tosh kernel: zone(0): 4096 pages.
Jul 28 22:59:33 tosh kernel: zone(1): 45024 pages.
Jul 28 22:59:33 tosh kernel: zone(2): 0 pages.
Jul 28 22:59:33 tosh kernel: Kernel command line: BOOT_IMAGE=2.4.32-pre2 ro 
root=303 video=vesafb:mtrr,ywrap
Jul 28 22:59:33 tosh kernel: Detected 497.562 MHz processor.
Jul 28 22:59:33 tosh kernel: Console: colour dummy device 80x25
Jul 28 22:59:33 tosh kernel: Calibrating delay loop... 992.87 BogoMIPS
Jul 28 22:59:33 tosh kernel: Page-cache hash table entries: 65536 (order: 6, 
262144 bytes)
Jul 28 22:59:33 tosh kernel: CPU: Intel Celeron (Coppermine) stepping 01
Jul 28 22:59:33 tosh kernel: POSIX conformance testing by UNIFIX
Jul 28 22:59:33 tosh kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL 
PROTECTED])
Jul 28 22:59:33 tosh kernel: mtrr: detected mtrr type: Intel
Jul 28 22:59:33 tosh kernel: PCI: Probing PCI hardware (bus 00)
Jul 28 22:59:33 tosh kernel: Initializing RT netlink socket
Jul 28 22:59:33 tosh kernel: Starting kswapd
Jul 28 22:59:33 tosh kernel: Console: switching to colour frame buffer device 
100x37
Jul 28 22:59:33 tosh kernel: pty: 256 Unix98 ptys configured
Jul 28 22:59:33 tosh kernel: hda: SAMSUNG MP0402H, ATA DISK drive
Jul 28 22:59:33 tosh kernel: blk: queue c034ca20, I/O limit 4095Mb (mask 
0x)
Jul 28 22:59:33 tosh kernel: hdc: CD-224E-B, ATAPI CD/DVD-ROM drive
Jul 28 22:59:33 tosh kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jul 28 22:59:33 tosh kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jul 28 22:59:33 tosh kernel: hda: attached ide-disk driver.
Jul 28 22:59:33 tosh kernel: hda: host protected area => 1
Jul 28 22:59:33 tosh kernel: hdc: attached ide-cdrom driver.
Jul 28 22:59:33 tosh kernel: ip_conntrack version 2.1 (1535 buckets, 12280 max) 
- 152 bytes per conntrack
Jul 28 22:59:33 tosh kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jul 28 22:59:33 tosh kernel: PCI: Enabling device 14:00.0 ( -> 0003)
Jul 28 22:59:33 tosh kernel: reiserfs: found format "3.6" with standard journal
Jul 28 22:59:33 tosh kernel: reiserfs: checking transaction log (device 
ide0(3,3)) ...
Jul 28 22:59:33 tosh kernel: for (ide0(3,3))
Jul 28 22:59:33 tosh kernel: ide0(3,3):Using r5 hash to sort names
Jul 28 22:59:33 tosh kernel: VFS: Mounted root (reiserfs filesystem) readonly.
Jul 28 23:01:25 tosh kernel: uhci.c: ff80: host controller process error. 
something bad happened
Jul 28 23:01:25 tosh kernel: uhci.c: ff80: host controller halted. very bad

Running okay with USB "< >" off...
http://scatter.mine.nu/test/linux-2.4/tosh/ for more info

Grant.
-
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 2.4.32-pre2

[Grant Coady]

On Wed, 27 Jul 2005 05:05:12 -0300, Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>
>Here goes another -pre, after a long period.

Breaks Toshiba laptop: hard lockup --> what is on screen is same as 
working dmesg up to point: "host/uhci.c: detected 2 port"

Same .config as for 2.4.31-hf3 or 2.4.32-pre1
http://scatter.mine.nu/test/linux-2.4/tosh/

Grant.

-
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 2.4.32-pre2

[Grant Coady]

On Wed, 27 Jul 2005 05:05:12 -0300, Marcelo Tosatti [EMAIL PROTECTED] wrote:

Here goes another -pre, after a long period.

Breaks Toshiba laptop: hard lockup -- what is on screen is same as 
working dmesg up to point: host/uhci.c: detected 2 port

Same .config as for 2.4.31-hf3 or 2.4.32-pre1
http://scatter.mine.nu/test/linux-2.4/tosh/

Grant.

-
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/

2.4.32-pre2: uhci.c: ff80: host controller halted. very bad

[Grant Coady]

Hi there,
More info on Toshiba laptop lockup with 2.4.32-pre2:

/var/log/syslog:
Jul 28 22:59:33 tosh kernel: Linux version 2.4.32-pre2 ([EMAIL PROTECTED]) (gcc 
version 3.3.5) #4 Thu Jul 28 22:57:05 EST 2005
Jul 28 22:59:33 tosh kernel:  BIOS-e820:  - 0009fc00 
(usable)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0009fc00 - 000a 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 000f - 0010 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0010 - 0bfe 
(usable)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0bfe - 0bff 
(ACPI data)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 0bff - 0c00 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100a - 100b6e00 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100b6e00 - 100b7000 
(ACPI NVS)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: 100b7000 - 1010 
(reserved)
Jul 28 22:59:33 tosh kernel:  BIOS-e820: fff8 - 0001 
(reserved)
Jul 28 22:59:33 tosh kernel: On node 0 totalpages: 49120
Jul 28 22:59:33 tosh kernel: zone(0): 4096 pages.
Jul 28 22:59:33 tosh kernel: zone(1): 45024 pages.
Jul 28 22:59:33 tosh kernel: zone(2): 0 pages.
Jul 28 22:59:33 tosh kernel: Kernel command line: BOOT_IMAGE=2.4.32-pre2 ro 
root=303 video=vesafb:mtrr,ywrap
Jul 28 22:59:33 tosh kernel: Detected 497.562 MHz processor.
Jul 28 22:59:33 tosh kernel: Console: colour dummy device 80x25
Jul 28 22:59:33 tosh kernel: Calibrating delay loop... 992.87 BogoMIPS
Jul 28 22:59:33 tosh kernel: Page-cache hash table entries: 65536 (order: 6, 
262144 bytes)
Jul 28 22:59:33 tosh kernel: CPU: Intel Celeron (Coppermine) stepping 01
Jul 28 22:59:33 tosh kernel: POSIX conformance testing by UNIFIX
Jul 28 22:59:33 tosh kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL 
PROTECTED])
Jul 28 22:59:33 tosh kernel: mtrr: detected mtrr type: Intel
Jul 28 22:59:33 tosh kernel: PCI: Probing PCI hardware (bus 00)
Jul 28 22:59:33 tosh kernel: Initializing RT netlink socket
Jul 28 22:59:33 tosh kernel: Starting kswapd
Jul 28 22:59:33 tosh kernel: Console: switching to colour frame buffer device 
100x37
Jul 28 22:59:33 tosh kernel: pty: 256 Unix98 ptys configured
Jul 28 22:59:33 tosh kernel: hda: SAMSUNG MP0402H, ATA DISK drive
Jul 28 22:59:33 tosh kernel: blk: queue c034ca20, I/O limit 4095Mb (mask 
0x)
Jul 28 22:59:33 tosh kernel: hdc: CD-224E-B, ATAPI CD/DVD-ROM drive
Jul 28 22:59:33 tosh kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jul 28 22:59:33 tosh kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jul 28 22:59:33 tosh kernel: hda: attached ide-disk driver.
Jul 28 22:59:33 tosh kernel: hda: host protected area = 1
Jul 28 22:59:33 tosh kernel: hdc: attached ide-cdrom driver.
Jul 28 22:59:33 tosh kernel: ip_conntrack version 2.1 (1535 buckets, 12280 max) 
- 152 bytes per conntrack
Jul 28 22:59:33 tosh kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jul 28 22:59:33 tosh kernel: PCI: Enabling device 14:00.0 ( - 0003)
Jul 28 22:59:33 tosh kernel: reiserfs: found format 3.6 with standard journal
Jul 28 22:59:33 tosh kernel: reiserfs: checking transaction log (device 
ide0(3,3)) ...
Jul 28 22:59:33 tosh kernel: for (ide0(3,3))
Jul 28 22:59:33 tosh kernel: ide0(3,3):Using r5 hash to sort names
Jul 28 22:59:33 tosh kernel: VFS: Mounted root (reiserfs filesystem) readonly.
Jul 28 23:01:25 tosh kernel: uhci.c: ff80: host controller process error. 
something bad happened
Jul 28 23:01:25 tosh kernel: uhci.c: ff80: host controller halted. very bad

Running okay with USB   off...
http://scatter.mine.nu/test/linux-2.4/tosh/ for more info

Grant.
-
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 2.4.32-pre2

[Grant Coady]

On Thu, 28 Jul 2005 07:22:25 -0300, Marcelo Tosatti [EMAIL PROTECTED] wrote:
 
 Breaks Toshiba laptop: hard lockup -- what is on screen is same as 
 working dmesg up to point: host/uhci.c: detected 2 port
 
 Same .config as for 2.4.31-hf3 or 2.4.32-pre1
 http://scatter.mine.nu/test/linux-2.4/tosh/

Please try to revert the attached? 

Yes, that fixed it :o) a USB mouse works.

dmesg:
...
host/uhci.c: detected 2 ports == previous lockup after this
usb.c: kmalloc IF c12f36e0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: ff80
...

And the other USB driver (usb-uhci) didn't lockup.

Thanks,
Grant.

-
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: xor as a lazy comparison

[Grant Coady]

On Wed, 27 Jul 2005 15:58:48 -0400, "linux-os \(Dick Johnson\)" <[EMAIL 
PROTECTED]> wrote:
>
>I think the XOR thread was started by somebody as a ruse or
>a joke. XOR will always destroy the value of an operand. 

You missed the part where somebody checked assembler output and
found compiler optimised xor to cmp as nothing referenced the result.

Grant.

-
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: xor as a lazy comparison

[Grant Coady]

On Wed, 27 Jul 2005 15:58:48 -0400, linux-os \(Dick Johnson\) [EMAIL 
PROTECTED] wrote:

I think the XOR thread was started by somebody as a ruse or
a joke. XOR will always destroy the value of an operand. 

You missed the part where somebody checked assembler output and
found compiler optimised xor to cmp as nothing referenced the result.

Grant.

-
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: Weird USB errors on HD

[Grant Coady]

On Tue, 26 Jul 2005 20:34:10 -0600, Robert Hancock <[EMAIL PROTECTED]> wrote:

>Karim Yaghmour wrote:
>> That being said, shouldn't there be a way for the kernel to refuse to
>> use this hd if it's not getting enough power. I don't know enough about
>> USB to say, but isn't there something more elegant that could be done in
>> software?
>
>Not really.. It seems like pretty much a matter of the controller saying 
>  it can supply so much power, the drive says it uses so much power, but 
>one of them is lying and the drive ends up tripping the overcurrent.

The drive itself may shutdown until power cycled.  I sorted this issue 
some months ago with a 2.5" 6GB drive in USB enclosure and the fix was 
hardware, adding bypass capacitors to supply peak HDD current.  Software 
cannot fix that.  No dataloss, just apparent lockup from OS point of view.

Drive fails to work on one laptop with a single USB port, but asking for 
700mA from a 500mA USB port is too much, needs external 5V instead.

Grant.

-
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: [SOLVED ?] VIA KT400 + Kernel 2.6.12 + IO-APIC + ehci_hcd = IRQ trouble

[Grant Coady]

On Tue, 26 Jul 2005 21:39:26 +0200, Michel Bouissou <[EMAIL PROTECTED]> wrote:
>
>Yes, but it doesn't tell us why kernels 2.4x felt perfectly happy with the old 
>BIOS...
You turned off 4k stacks?  I have a Via KM400 chipset box locked 
up a few times, once under 2.4.31-hf2 after 4.5 hours compiling 
kernels, fixed with some .config tuning.  Done 48+ hours continuous 
compiling kernels with 2.6.12.3 + 8k stacks, load ~2.2.  Just adding 
a datapoint...  Dunno if this relevant.  Simpler, older box with 
Intel 440BX chipset is happy with 4k stacks, only 2 USB ports.

Grant.

-
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: [SOLVED ?] VIA KT400 + Kernel 2.6.12 + IO-APIC + ehci_hcd = IRQ trouble

[Grant Coady]

On Tue, 26 Jul 2005 21:39:26 +0200, Michel Bouissou [EMAIL PROTECTED] wrote:

Yes, but it doesn't tell us why kernels 2.4x felt perfectly happy with the old 
BIOS...
You turned off 4k stacks?  I have a Via KM400 chipset box locked 
up a few times, once under 2.4.31-hf2 after 4.5 hours compiling 
kernels, fixed with some .config tuning.  Done 48+ hours continuous 
compiling kernels with 2.6.12.3 + 8k stacks, load ~2.2.  Just adding 
a datapoint...  Dunno if this relevant.  Simpler, older box with 
Intel 440BX chipset is happy with 4k stacks, only 2 USB ports.

Grant.

-
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: Weird USB errors on HD

[Grant Coady]

On Tue, 26 Jul 2005 20:34:10 -0600, Robert Hancock [EMAIL PROTECTED] wrote:

Karim Yaghmour wrote:
 That being said, shouldn't there be a way for the kernel to refuse to
 use this hd if it's not getting enough power. I don't know enough about
 USB to say, but isn't there something more elegant that could be done in
 software?

Not really.. It seems like pretty much a matter of the controller saying 
  it can supply so much power, the drive says it uses so much power, but 
one of them is lying and the drive ends up tripping the overcurrent.

The drive itself may shutdown until power cycled.  I sorted this issue 
some months ago with a 2.5 6GB drive in USB enclosure and the fix was 
hardware, adding bypass capacitors to supply peak HDD current.  Software 
cannot fix that.  No dataloss, just apparent lockup from OS point of view.

Drive fails to work on one laptop with a single USB port, but asking for 
700mA from a 500mA USB port is too much, needs external 5V instead.

Grant.

-
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.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
>any errors you see with CONFIG_BROKEN=y aren't interesting.

Straight over the top of my head yesterday :)  Is the following 
what you had in mind?  (current script does retry if BROKEN)

[EMAIL PROTECTED]:/opt/linux$ diff -u linux-2.6.13-rc3-git6/init/Kconfig~ 
linux-2.6.13-rc3-git6/init/Kconfig
--- linux-2.6.13-rc3-git6/init/Kconfig~ 2005-07-25 08:23:04.0 +1000
+++ linux-2.6.13-rc3-git6/init/Kconfig  2005-07-26 10:25:59.0 +1000
@@ -42,7 +42,7 @@

 config BROKEN
bool
-   depends on !CLEAN_COMPILE
+   depends on !CLEAN_COMPILE && 0
default y

 config BROKEN_ON_SMP

- - - 
results first run:
--
Here http://scatter.mine.nu/test/scripts/counterror-2005-07-26.gz
is post-processing script (work in progress) extracts errors and 
non-deprecated warnings, linked to first triggering .config like so:

[EMAIL PROTECTED]:/opt/linux$ cat error-error-list
trial1/run-004:arch/i386/mach-es7000/es7000.h
trial1/run-004:arch/i386/mach-es7000/es7000plat.c
trial1/run-009:drivers/char/ipmi/ipmi_msghandler.c
trial2/run-082:drivers/mtd/maps/nettel.c
trial3/run-018:drivers/pnp/pnpbios/rsparser.c
trial2/run-044:include/asm-i386/mach-default/mach_apic.h
trial1/run-008:include/asm-i386/mach-visws/do_timer.h
trial2/run-081:ipc/shm.c
trial1/run-015:net/rxrpc/main.c
trial2/run-027:sound/core/memalloc.c

then extracts compiler messages:

[EMAIL PROTECTED]:/opt/linux$ head error-error-report |cut -c-78
trial1/run-004:arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomp
trial1/run-004:arch/i386/mach-es7000/es7000.h:88: error: field `Header' has in
trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_o
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_g
trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `find_unisys_ac
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:168: warning: implicit decla
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:170: error: dereferencing po
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:172: error: dereferencing po
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: warning: implicit decla
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: error: invalid applicat
^^\
--> link to .config producing the error / warning:

[EMAIL PROTECTED]:/opt/linux$ head trial1/run-004-config
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc3
# Tue Jul 19 04:31:27 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

Current compile run is with linux-2.6.13-rc3-git6

Datastore is denormalised flat text.  Query language: grep :)

Thanks,
Grant.

-
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.13-rc3 test: finding compile errors with make randconfig

[Grant Coady]

On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:

You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
any errors you see with CONFIG_BROKEN=y aren't interesting.

Straight over the top of my head yesterday :)  Is the following 
what you had in mind?  (current script does retry if BROKEN)

[EMAIL PROTECTED]:/opt/linux$ diff -u linux-2.6.13-rc3-git6/init/Kconfig~ 
linux-2.6.13-rc3-git6/init/Kconfig
--- linux-2.6.13-rc3-git6/init/Kconfig~ 2005-07-25 08:23:04.0 +1000
+++ linux-2.6.13-rc3-git6/init/Kconfig  2005-07-26 10:25:59.0 +1000
@@ -42,7 +42,7 @@

 config BROKEN
bool
-   depends on !CLEAN_COMPILE
+   depends on !CLEAN_COMPILE  0
default y

 config BROKEN_ON_SMP

- - - 
results first run:
--
Here http://scatter.mine.nu/test/scripts/counterror-2005-07-26.gz
is post-processing script (work in progress) extracts errors and 
non-deprecated warnings, linked to first triggering .config like so:

[EMAIL PROTECTED]:/opt/linux$ cat error-error-list
trial1/run-004:arch/i386/mach-es7000/es7000.h
trial1/run-004:arch/i386/mach-es7000/es7000plat.c
trial1/run-009:drivers/char/ipmi/ipmi_msghandler.c
trial2/run-082:drivers/mtd/maps/nettel.c
trial3/run-018:drivers/pnp/pnpbios/rsparser.c
trial2/run-044:include/asm-i386/mach-default/mach_apic.h
trial1/run-008:include/asm-i386/mach-visws/do_timer.h
trial2/run-081:ipc/shm.c
trial1/run-015:net/rxrpc/main.c
trial2/run-027:sound/core/memalloc.c

then extracts compiler messages:

[EMAIL PROTECTED]:/opt/linux$ head error-error-report |cut -c-78
trial1/run-004:arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomp
trial1/run-004:arch/i386/mach-es7000/es7000.h:88: error: field `Header' has in
trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_o
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_g
trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `find_unisys_ac
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:168: warning: implicit decla
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:170: error: dereferencing po
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:172: error: dereferencing po
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: warning: implicit decla
trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: error: invalid applicat
^^\
-- link to .config producing the error / warning:

[EMAIL PROTECTED]:/opt/linux$ head trial1/run-004-config
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc3
# Tue Jul 19 04:31:27 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

Current compile run is with linux-2.6.13-rc3-git6

Datastore is denormalised flat text.  Query language: grep :)

Thanks,
Grant.

-
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/