Re: autofs multi-map regression

[Dick Streefland]

On Friday 2017-06-16 15:57, Eric W. Biederman wrote:
| I don't believe this is a kernel change.
| 
| I dug up an old VM and I was able to reproduce this issue simply
| by installing autofs, and your auto.master and auto.net files.
| 
| # uname -a
| Linux ubuntu-16 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
| 
| # ls /net/
| localhost
| # ls /net/localhost/loc
| ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic 
links
| # ls /loc
| ls: cannot open directory '/loc/': Too many levels of symbolic links
| 
| I suspect there is configuration somewhere in your autofs
| configuration.  I don't speak autofs well enough to debug the issue at
| this point.  But I can conclusively say it was not the kernel commit you
| pointed at, as I see the issue you are reporting and I don't have that
| commit in the kernel under test.

I have a second partition mounted on /loc, that is the reason for the
multi-map autofs setup. With a separate mount on /loc, you won't see
the errors with the old kernel.

Fact is that my setup worked for a long time, and that it stopped
working after the backport of commit 1064f874 to the ubuntu 4.4
kernel.

-- 
Dick

Re: autofs multi-map regression

[Dick Streefland]

On Friday 2017-06-16 15:57, Eric W. Biederman wrote:
| I don't believe this is a kernel change.
| 
| I dug up an old VM and I was able to reproduce this issue simply
| by installing autofs, and your auto.master and auto.net files.
| 
| # uname -a
| Linux ubuntu-16 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
| 
| # ls /net/
| localhost
| # ls /net/localhost/loc
| ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic 
links
| # ls /loc
| ls: cannot open directory '/loc/': Too many levels of symbolic links
| 
| I suspect there is configuration somewhere in your autofs
| configuration.  I don't speak autofs well enough to debug the issue at
| this point.  But I can conclusively say it was not the kernel commit you
| pointed at, as I see the issue you are reporting and I don't have that
| commit in the kernel under test.

I have a second partition mounted on /loc, that is the reason for the
multi-map autofs setup. With a separate mount on /loc, you won't see
the errors with the old kernel.

Fact is that my setup worked for a long time, and that it stopped
working after the backport of commit 1064f874 to the ubuntu 4.4
kernel.

-- 
Dick

Re: autofs multi-map regression

[Dick Streefland]

On Friday 2017-06-16 12:03, Eric W. Biederman wrote:
| Interesting...
| 
| Can you test this on a stock 4.11 kernel?
| 
| I definitely need a little bit more information to solve this.  That
| commit did not add any new error condidtions so I need to understand
| what state you are getting yourself into that is affected by this
| commit.
| 
| Is there a chance you can post /proc/self/mountinfo from when this is
| happening?

I've installed the mainline 4.11 kernel from:

  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11/

and this kernel works correctly!

So either this issue was fixed in the meantime, or it is something
specific to the Ubuntu kernel. I guess I should file a bug report
with Ubuntu then?

I've also looked at /proc/self/mountinfo before and directly after the
mount attempt. Here are the ext4 and autofs entries for the failing 4.4
kernel:

before:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
41 19 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 
rw,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
46 23 8:4 / /loc rw,nosuid,nodev,noatime shared:30 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
202 23 0:44 / /net rw,relatime shared:160 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,indirect

after:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
41 19 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 
rw,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
46 162 8:4 / /loc rw,nosuid,nodev,noatime shared:30 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
202 23 0:44 / /net rw,relatime shared:160 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,indirect
157 202 8:2 / /net/localhost rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
161 157 0:47 / /net/localhost/loc rw,relatime shared:119 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,offset
162 23 0:47 / /loc rw,relatime shared:119 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,offset

And here the info for the working mainline 4.11 kernel:

before:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
74 19 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:56 - autofs systemd-1 
rw,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12754
45 23 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
208 23 0:46 / /net rw,relatime shared:164 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=26555

after:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
74 19 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:56 - autofs systemd-1 
rw,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12754
45 175 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
208 23 0:46 / /net rw,relatime shared:164 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=26555
162 208 8:2 / /net/localhost rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
166 162 0:48 / /net/localhost/loc rw,relatime shared:122 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,offset,pipe_ino=26555
167 23 0:48 / /loc rw,relatime shared:122 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,offset,pipe_ino=26555
174 166 8:4 / /net/localhost/loc rw,nosuid,nodev,noatime shared:28 - ext4 
/dev/sda4 rw,block_validity,delalloc,barrier,user_xattr,acl
175 167 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl

-- 
Dick

Re: autofs multi-map regression

[Dick Streefland]

On Friday 2017-06-16 12:03, Eric W. Biederman wrote:
| Interesting...
| 
| Can you test this on a stock 4.11 kernel?
| 
| I definitely need a little bit more information to solve this.  That
| commit did not add any new error condidtions so I need to understand
| what state you are getting yourself into that is affected by this
| commit.
| 
| Is there a chance you can post /proc/self/mountinfo from when this is
| happening?

I've installed the mainline 4.11 kernel from:

  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11/

and this kernel works correctly!

So either this issue was fixed in the meantime, or it is something
specific to the Ubuntu kernel. I guess I should file a bug report
with Ubuntu then?

I've also looked at /proc/self/mountinfo before and directly after the
mount attempt. Here are the ext4 and autofs entries for the failing 4.4
kernel:

before:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
41 19 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 
rw,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
46 23 8:4 / /loc rw,nosuid,nodev,noatime shared:30 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
202 23 0:44 / /net rw,relatime shared:160 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,indirect

after:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
41 19 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 
rw,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
46 162 8:4 / /loc rw,nosuid,nodev,noatime shared:30 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
202 23 0:44 / /net rw,relatime shared:160 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,indirect
157 202 8:2 / /net/localhost rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
161 157 0:47 / /net/localhost/loc rw,relatime shared:119 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,offset
162 23 0:47 / /loc rw,relatime shared:119 - autofs /etc/auto.net 
rw,fd=6,pgrp=1724,timeout=120,minproto=5,maxproto=5,offset

And here the info for the working mainline 4.11 kernel:

before:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
74 19 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:56 - autofs systemd-1 
rw,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12754
45 23 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
208 23 0:46 / /net rw,relatime shared:164 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=26555

after:
23 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
74 19 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:56 - autofs systemd-1 
rw,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12754
45 175 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl
208 23 0:46 / /net rw,relatime shared:164 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=26555
162 208 8:2 / /net/localhost rw,relatime shared:1 - ext4 /dev/sda2 
rw,errors=remount-ro,data=ordered
166 162 0:48 / /net/localhost/loc rw,relatime shared:122 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,offset,pipe_ino=26555
167 23 0:48 / /loc rw,relatime shared:122 - autofs /etc/auto.net 
rw,fd=6,pgrp=1545,timeout=120,minproto=5,maxproto=5,offset,pipe_ino=26555
174 166 8:4 / /net/localhost/loc rw,nosuid,nodev,noatime shared:28 - ext4 
/dev/sda4 rw,block_validity,delalloc,barrier,user_xattr,acl
175 167 8:4 / /loc rw,nosuid,nodev,noatime shared:28 - ext4 /dev/sda4 
rw,block_validity,delalloc,barrier,user_xattr,acl

-- 
Dick

autofs multi-map regression

[Dick Streefland]

After a recent upgrade of a Ubuntu xenial machine, a particular
autofs multi-map mount setup stopped working. A simplified example is:

::
auto.master
::
/net/etc/auto.net
::
auto.net
::
localhost / :/ /loc :/loc

Accessing /net/localhost/loc should trigger two nested bind mounts on
/net/localhost and /net/localhost/loc, but with the new kernel, it fails
with ELOOP:

$ ls /net/localhost/loc
ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic 
links

The problem is related to the upgrade of the Ubuntu xenial kernel from
4.4.0-38.57 to 4.4.0-78.99. I bisected the regression to commit
731ac92843877f3633325203abc942193c1e9001, which is a Ubuntu backport
of this upstream kernel commit:

commit 1064f874abc0d05eeed8993815f584d847b72486
Author: Eric W. Biederman 
Date:   Fri Jan 20 18:28:35 2017 +1300

mnt: Tuck mounts under others instead of creating shadow/side mounts.

-- 
Dick

autofs multi-map regression

[Dick Streefland]

After a recent upgrade of a Ubuntu xenial machine, a particular
autofs multi-map mount setup stopped working. A simplified example is:

::
auto.master
::
/net/etc/auto.net
::
auto.net
::
localhost / :/ /loc :/loc

Accessing /net/localhost/loc should trigger two nested bind mounts on
/net/localhost and /net/localhost/loc, but with the new kernel, it fails
with ELOOP:

$ ls /net/localhost/loc
ls: cannot open directory '/net/localhost/loc': Too many levels of symbolic 
links

The problem is related to the upgrade of the Ubuntu xenial kernel from
4.4.0-38.57 to 4.4.0-78.99. I bisected the regression to commit
731ac92843877f3633325203abc942193c1e9001, which is a Ubuntu backport
of this upstream kernel commit:

commit 1064f874abc0d05eeed8993815f584d847b72486
Author: Eric W. Biederman 
Date:   Fri Jan 20 18:28:35 2017 +1300

mnt: Tuck mounts under others instead of creating shadow/side mounts.

-- 
Dick

Re: Unexpected slow block device write IO performance compared to uncached, unsynced direct IO using stock kernels

[Dick Streefland]

On Tuesday 2015-09-01 11:15, Dick Streefland wrote:
| I'm seeing this as well here on a number of new Dell Optiplex 7020
| machines and one older Optiplex 780, all with 8GB RAM and running
| Ubuntu 14.04 in 32-bit mode.

It turned out that the dirty thresholds in /proc/vmstat became zero:

nr_dirty_threshold 0
nr_dirty_background_threshold 0

A workaround is:

# sysctl vm.highmem_is_dirtyable=1

-- 
Dick
--
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: Unexpected slow block device write IO performance compared to uncached, unsynced direct IO using stock kernels

[Dick Streefland]

On Tuesday 2015-09-01 11:15, Dick Streefland wrote:
| I'm seeing this as well here on a number of new Dell Optiplex 7020
| machines and one older Optiplex 780, all with 8GB RAM and running
| Ubuntu 14.04 in 32-bit mode.

It turned out that the dirty thresholds in /proc/vmstat became zero:

nr_dirty_threshold 0
nr_dirty_background_threshold 0

A workaround is:

# sysctl vm.highmem_is_dirtyable=1

-- 
Dick
--
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: Unexpected slow block device write IO performance compared to uncached, unsynced direct IO using stock kernels

[Dick Streefland]

On Thursday 2015-06-18 09:35, Erik Cumps wrote:
| On Tue, Jun 16, 2015 at 3:56 PM, Erik Cumps  wrote:
| > The context is a 16 GB 32-bit intel debian workstation, using an ext4
| > filesystem with journalling, on a lvm SATA3 SSD disk, with relatively
| > recent stock kernels from 3.2 onwards to 4.0, running some KVM virtual
| > machines. The host system (so not the virual machines) shows sporadic
| > extremely slow write performance (around 4 megabytes per second).
| > However, if we use the debian 3.2.0 kernel this problem does not
| > manifest itself.
[...]
| Actually, it is the *synchronous*, direct IO that matches the expected
| raw write performance of the device.
| 
| The "regular IO" test is doing roughly this:
| 
| echo 3 > /proc/sys/vm/drop_caches
| dd if=ramdisk_file of=test_file bs=1M count=100
| dd if=ramdisk_file of=test_file bs=1M count=100
| dd if=ramdisk_file of=test_file bs=1M count=100
| 
| The direct IO test is doing roughly this:
| 
| echo 3 > /proc/sys/vm/drop_caches
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100

I'm seeing this as well here on a number of new Dell Optiplex 7020
machines and one older Optiplex 780, all with 8GB RAM and running
Ubuntu 14.04 in 32-bit mode.

A simple dd command shows the problem:

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 7.02392 s, 1.5 MB/s

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest oflag=sync,direct
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.535397 s, 19.6 MB/s

In my case, running:

  echo 3 > /proc/sys/vm/drop_caches

will restore the normal speed for a limited time:

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0123759 s, 847 MB/s

There is an old Ubuntu bug report describing the same issue:

  https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-trusty/+bug/1333294

-- 
Dick
--
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: Unexpected slow block device write IO performance compared to uncached, unsynced direct IO using stock kernels

[Dick Streefland]

On Thursday 2015-06-18 09:35, Erik Cumps wrote:
| On Tue, Jun 16, 2015 at 3:56 PM, Erik Cumps  wrote:
| > The context is a 16 GB 32-bit intel debian workstation, using an ext4
| > filesystem with journalling, on a lvm SATA3 SSD disk, with relatively
| > recent stock kernels from 3.2 onwards to 4.0, running some KVM virtual
| > machines. The host system (so not the virual machines) shows sporadic
| > extremely slow write performance (around 4 megabytes per second).
| > However, if we use the debian 3.2.0 kernel this problem does not
| > manifest itself.
[...]
| Actually, it is the *synchronous*, direct IO that matches the expected
| raw write performance of the device.
| 
| The "regular IO" test is doing roughly this:
| 
| echo 3 > /proc/sys/vm/drop_caches
| dd if=ramdisk_file of=test_file bs=1M count=100
| dd if=ramdisk_file of=test_file bs=1M count=100
| dd if=ramdisk_file of=test_file bs=1M count=100
| 
| The direct IO test is doing roughly this:
| 
| echo 3 > /proc/sys/vm/drop_caches
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100
| dd if=ramdisk_file of=test_file oflag=sync,direct bs=1M count=100

I'm seeing this as well here on a number of new Dell Optiplex 7020
machines and one older Optiplex 780, all with 8GB RAM and running
Ubuntu 14.04 in 32-bit mode.

A simple dd command shows the problem:

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 7.02392 s, 1.5 MB/s

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest oflag=sync,direct
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.535397 s, 19.6 MB/s

In my case, running:

  echo 3 > /proc/sys/vm/drop_caches

will restore the normal speed for a limited time:

$ dd bs=1M count=10 if=/dev/zero of=/tmp/ddtest
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0123759 s, 847 MB/s

There is an old Ubuntu bug report describing the same issue:

  https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-trusty/+bug/1333294

-- 
Dick
--
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: [Announce] Linux-tiny project revival

[Dick Streefland]

Rob Landley <[EMAIL PROTECTED]> wrote:
| The "change every printk in the kernel" suggestion came from me trying to 
| figure out how to get the printk() calls below a certain log level to 
| optimize out and not take up space in the binary.
| 
| The above doesn't address the original cause of the thread, as far as I can 
| tell.

It does, provided you change the macro definition to:

#define _printk(level, str, ...) \
   do { \
 if (sizeof(level) == 1) /* continued printk */\
  actual_printk(str, __VA_ARGS__); \
 else if ((level[1] - '0') < CONFIG_PRINTK_DOICARE) \
   actual_printk(level str, __VA_ARGS__); \
   } while(0);
#define printk(level_str, ...)  _printk(level_str, __VA_ARGS__)

Gcc will do constant folding on the string subscripts, and remove the
code and the string constants for calls above the desired level.

This is basically the same as I proposed in my earlier message [*],
but with the disadvantage that you need to modify all printk() calls
without an explicit level and add the ugly comma to the KERN_* macros.
Just compile the code in my message with -O and -S and you will see
that the KERN_NOTICE call and the corresponding string literal are
optimized away.

[*] http://lkml.org/lkml/2007/9/21/151

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: [RFC] New kernel-message logging API (take 2)

[Dick Streefland]

"Vegard Nossum" <[EMAIL PROTECTED]> wrote:
|   It should be possible to optimize out multi-line (block) entries
| based on log-level filtering even though the log-level is only given
| in the first call (the initializer). It may take the shape of an
| if-block that spans several macros. This is not very elegant or robust
| if the macros are used incorrectly, however. Aborting a message can
| also be hard this way (since the abort would usually appear inside an
| if-statement that tests for some abnormal condition, thus appear in a
| different block, and thoroughly mess up the bracket order).
| 
| Example: {
|   #define kprint_block_init(block, loglevel)  \
|   if(loglevel > CONFIG_KPRINT_LOGLEVEL_MAX) { \
|   kprint_real_block_init(block, loglevel);
| 
|   #define kprint_block(block, fmt, ...)   \
|   kprint_real_block(block, fmt, ## __VA_ARGS__);
| 
|   #define kprint_block_flush(block)   \
|   kprint_real_block_flush(block); \
|   }

As you point out yourself, this is not very elegant or robust. In fact,
it is very dangerous. Why not simply pass the loglevel to each macro?

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: [Announce] Linux-tiny project revival

[Dick Streefland]

Rob Landley [EMAIL PROTECTED] wrote:
| The change every printk in the kernel suggestion came from me trying to 
| figure out how to get the printk() calls below a certain log level to 
| optimize out and not take up space in the binary.
| 
| The above doesn't address the original cause of the thread, as far as I can 
| tell.

It does, provided you change the macro definition to:

#define _printk(level, str, ...) \
   do { \
 if (sizeof(level) == 1) /* continued printk */\
  actual_printk(str, __VA_ARGS__); \
 else if ((level[1] - '0')  CONFIG_PRINTK_DOICARE) \
   actual_printk(level str, __VA_ARGS__); \
   } while(0);
#define printk(level_str, ...)  _printk(level_str, __VA_ARGS__)

Gcc will do constant folding on the string subscripts, and remove the
code and the string constants for calls above the desired level.

This is basically the same as I proposed in my earlier message [*],
but with the disadvantage that you need to modify all printk() calls
without an explicit level and add the ugly comma to the KERN_* macros.
Just compile the code in my message with -O and -S and you will see
that the KERN_NOTICE call and the corresponding string literal are
optimized away.

[*] http://lkml.org/lkml/2007/9/21/151

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: [RFC] New kernel-message logging API (take 2)

[Dick Streefland]

Vegard Nossum [EMAIL PROTECTED] wrote:
|   It should be possible to optimize out multi-line (block) entries
| based on log-level filtering even though the log-level is only given
| in the first call (the initializer). It may take the shape of an
| if-block that spans several macros. This is not very elegant or robust
| if the macros are used incorrectly, however. Aborting a message can
| also be hard this way (since the abort would usually appear inside an
| if-statement that tests for some abnormal condition, thus appear in a
| different block, and thoroughly mess up the bracket order).
| 
| Example: {
|   #define kprint_block_init(block, loglevel)  \
|   if(loglevel  CONFIG_KPRINT_LOGLEVEL_MAX) { \
|   kprint_real_block_init(block, loglevel);
| 
|   #define kprint_block(block, fmt, ...)   \
|   kprint_real_block(block, fmt, ## __VA_ARGS__);
| 
|   #define kprint_block_flush(block)   \
|   kprint_real_block_flush(block); \
|   }

As you point out yourself, this is not very elegant or robust. In fact,
it is very dangerous. Why not simply pass the loglevel to each macro?

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: [Announce] Linux-tiny project revival

[Dick Streefland]

Rob Landley <[EMAIL PROTECTED]> wrote:
| I'm proposing allowing an ignore_loglevel to remove the unused messages at 
| compile time so they don't take up space.  Doing that requires the levels to 
| be integers so they can be compared with < or >, and the remaining changes 
| follow logically.  (To me, anyway...)

Gcc seems to be smart enough to do contant folding on string
subscripts, so you don't need to change any of the printk()s.
Here is what I mean:

#include 

#define actual_printk   printf

#define KERN_ERR"<3>"   /* error conditions */
#define KERN_WARNING"<4>"   /* warning conditions   */
#define KERN_NOTICE "<5>"   /* normal but significant condition */

#define printk(str, ...) \
  do { \
if ((str)[0] != '<' || (str)[1] < '5') \
  actual_printk((str), __VA_ARGS__); \
  } while(0);

int main(void)
{
printk(KERN_ERR "error %d\n", 1);
printk(KERN_WARNING "warning %d\n", 2);
printk(KERN_NOTICE "notice %d\n", 3);
printk("no level %d\n", 4);
return 0;
}

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: [Announce] Linux-tiny project revival

[Dick Streefland]

Rob Landley [EMAIL PROTECTED] wrote:
| I'm proposing allowing an ignore_loglevel to remove the unused messages at 
| compile time so they don't take up space.  Doing that requires the levels to 
| be integers so they can be compared with  or , and the remaining changes 
| follow logically.  (To me, anyway...)

Gcc seems to be smart enough to do contant folding on string
subscripts, so you don't need to change any of the printk()s.
Here is what I mean:

#include stdio.h

#define actual_printk   printf

#define KERN_ERR3   /* error conditions */
#define KERN_WARNING4   /* warning conditions   */
#define KERN_NOTICE 5   /* normal but significant condition */

#define printk(str, ...) \
  do { \
if ((str)[0] != '' || (str)[1]  '5') \
  actual_printk((str), __VA_ARGS__); \
  } while(0);

int main(void)
{
printk(KERN_ERR error %d\n, 1);
printk(KERN_WARNING warning %d\n, 2);
printk(KERN_NOTICE notice %d\n, 3);
printk(no level %d\n, 4);
return 0;
}

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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] ver_linux is [censored]

[Dick Streefland]

Al Viro <[EMAIL PROTECTED]> wrote:
| or, simpler yet,
| 
| sed -n -e '/^.*\/libc-\([^/]*\)\.so$/{s//\1/;p;q}' http://www.altium.com
oOO--(_)--OOo---

-
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] ver_linux is [censored]

[Dick Streefland]

Al Viro [EMAIL PROTECTED] wrote:
| or, simpler yet,
| 
| sed -n -e '/^.*\/libc-\([^/]*\)\.so$/{s//\1/;p;q}' /proc/self/maps

Or:

sed -n 's/^.*\/libc-\([^/]*\)\.so$/\1/p; T; q'  /proc/self/maps

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: somebody dropped a (warning) bomb

[Dick Streefland]

Jan Engelhardt <[EMAIL PROTECTED]> wrote:
| Further, giving again answer to the question whether they generate signed or
| unsigned comparisons: Have you ever seen a computer which addresses memory 
with
| negative numbers? Since the answer is most likely no, signed comparisons would
| not make sense for me.

The Transputer has (had?) a signed address space:

http://maven.smith.edu/~thiebaut/transputer/chapter2/chap2-3.html

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: somebody dropped a (warning) bomb

[Dick Streefland]

Jan Engelhardt [EMAIL PROTECTED] wrote:
| Further, giving again answer to the question whether they generate signed or
| unsigned comparisons: Have you ever seen a computer which addresses memory 
with
| negative numbers? Since the answer is most likely no, signed comparisons would
| not make sense for me.

The Transputer has (had?) a signed address space:

http://maven.smith.edu/~thiebaut/transputer/chapter2/chap2-3.html

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: Software RAID1 (with non-identical discs) performance

[Dick Streefland]

Wiebe Cazemier <[EMAIL PROTECTED]> wrote:
| And with one Maxtor 250 GB and one Seagate 250 GB, will that work? It can go
| wrong on two accounts; the geometry issue I desbribed (which, I understand,
| shouldn't be an issue at all), and if you're trying to clone the partition
| table on a smaller disk. The latter would be fixed by leaving some unpartioned
| space available.

Yes, that's what I usually do. I lookup the size a couple of disks of
that size, and make sure that the last partition ends before the size
of the smallest disk, by leaving some cylinders unused.

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: Software RAID1 (with non-identical discs) performance

[Dick Streefland]

Phillip Susi <[EMAIL PROTECTED]> wrote:
| The entire concept of geometry is a a carryover from days gone by. 
| These days it is just a farse maintained for backwards compatibility. 
| You can put fdisk into sector mode with the 'u' command and create 
| partitions of any number of sectors you desire, regardless of the 
| perceived geometry.

An easy way to clone a partition table is:

  sfdisk -d /dev/sdX | sfdisk /dev/sdY

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: Software RAID1 (with non-identical discs) performance

[Dick Streefland]

Phillip Susi [EMAIL PROTECTED] wrote:
| The entire concept of geometry is a a carryover from days gone by. 
| These days it is just a farse maintained for backwards compatibility. 
| You can put fdisk into sector mode with the 'u' command and create 
| partitions of any number of sectors you desire, regardless of the 
| perceived geometry.

An easy way to clone a partition table is:

  sfdisk -d /dev/sdX | sfdisk /dev/sdY

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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: Software RAID1 (with non-identical discs) performance

[Dick Streefland]

Wiebe Cazemier [EMAIL PROTECTED] wrote:
| And with one Maxtor 250 GB and one Seagate 250 GB, will that work? It can go
| wrong on two accounts; the geometry issue I desbribed (which, I understand,
| shouldn't be an issue at all), and if you're trying to clone the partition
| table on a smaller disk. The latter would be fixed by leaving some unpartioned
| space available.

Yes, that's what I usually do. I lookup the size a couple of disks of
that size, and make sure that the last partition ends before the size
of the smallest disk, by leaving some cylinders unused.

-- 
Dick Streefland    Altium BV
[EMAIL PROTECTED]   (@ @)  http://www.altium.com
oOO--(_)--OOo---

-
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.0-test12-pre7] kernel BUG at buffer.c:827!

[Dick Streefland]

This message showed up when running lilo on an ext2 image, mounted via
a loopback mount. Line 827 in fs/buffer.c is a call to UnlockPage().
The complete message from /var/log/messages:

Dec  9 18:24:51 tampere kernel: kernel BUG at buffer.c:827! 
Dec  9 18:24:51 tampere kernel: invalid operand:  
Dec  9 18:24:51 tampere kernel: CPU:0 
Dec  9 18:24:51 tampere kernel: EIP:0010:[end_buffer_io_async+195/240] 
Dec  9 18:24:51 tampere kernel: EFLAGS: 00010086 
Dec  9 18:24:51 tampere kernel: eax: 001c   ebx: c00142bc   ecx:    edx: 
0006 
Dec  9 18:24:51 tampere kernel: esi: c0597c20   edi: 0002   ebp: c0597c68   esp: 
c0499da0 
Dec  9 18:24:51 tampere kernel: ds: 0018   es: 0018   ss: 0018 
Dec  9 18:24:51 tampere kernel: Process lilo (pid: 3676, stackpage=c0499000) 
Dec  9 18:24:51 tampere kernel: Stack: c0230d89 c023105a 033b c0597c20 c0089620 
0002 0001 c018b115  
Dec  9 18:24:51 tampere kernel:c0597c20 0001 c0089620 c0088260 c0089620 
c0089620 c018c1c1 c0089620  
Dec  9 18:24:51 tampere kernel:0001 c024710b c0089620 0007 c0089620 
c02b99d8  0700  
Dec  9 18:24:52 tampere kernel: Call Trace: [tvecs+12861/115968] [tvecs+13582/115968] 
[end_that_request_first+101/192] [do_lo_request+993/1072] [tvecs+103871/115968] 
[__make_request+1597/1712] [generic_make_request+188/288]  
Dec  9 18:24:52 tampere kernel:[ll_rw_block+371/496] 
[block_read_full_page+541/656] [ext2_readpage+15/32] [ext2_get_block+0/1344] 
[do_generic_file_read+931/1504] [generic_file_read+99/128] [file_read_actor+0/112] 
[sys_read+142/208]  
Dec  9 18:24:52 tampere kernel:[system_call+51/64]  
Dec  9 18:24:52 tampere kernel: Code: 0f 0b 83 c4 0c 8d 73 28 8d 43 2c 39 43 2c 74 15 
b9 01 00 00  

I cannot reproduce it reliably, but after a few retries, it occured again.

-- 
Dick Streefland   De Bilt
[EMAIL PROTECTED]  (@ @)   The Netherlands
--oOO--(_)--OOo--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[2.4.0-test12-pre7] kernel BUG at buffer.c:827!

[Dick Streefland]

This message showed up when running lilo on an ext2 image, mounted via
a loopback mount. Line 827 in fs/buffer.c is a call to UnlockPage().
The complete message from /var/log/messages:

Dec  9 18:24:51 tampere kernel: kernel BUG at buffer.c:827! 
Dec  9 18:24:51 tampere kernel: invalid operand:  
Dec  9 18:24:51 tampere kernel: CPU:0 
Dec  9 18:24:51 tampere kernel: EIP:0010:[end_buffer_io_async+195/240] 
Dec  9 18:24:51 tampere kernel: EFLAGS: 00010086 
Dec  9 18:24:51 tampere kernel: eax: 001c   ebx: c00142bc   ecx:    edx: 
0006 
Dec  9 18:24:51 tampere kernel: esi: c0597c20   edi: 0002   ebp: c0597c68   esp: 
c0499da0 
Dec  9 18:24:51 tampere kernel: ds: 0018   es: 0018   ss: 0018 
Dec  9 18:24:51 tampere kernel: Process lilo (pid: 3676, stackpage=c0499000) 
Dec  9 18:24:51 tampere kernel: Stack: c0230d89 c023105a 033b c0597c20 c0089620 
0002 0001 c018b115  
Dec  9 18:24:51 tampere kernel:c0597c20 0001 c0089620 c0088260 c0089620 
c0089620 c018c1c1 c0089620  
Dec  9 18:24:51 tampere kernel:0001 c024710b c0089620 0007 c0089620 
c02b99d8  0700  
Dec  9 18:24:52 tampere kernel: Call Trace: [tvecs+12861/115968] [tvecs+13582/115968] 
[end_that_request_first+101/192] [do_lo_request+993/1072] [tvecs+103871/115968] 
[__make_request+1597/1712] [generic_make_request+188/288]  
Dec  9 18:24:52 tampere kernel:[ll_rw_block+371/496] 
[block_read_full_page+541/656] [ext2_readpage+15/32] [ext2_get_block+0/1344] 
[do_generic_file_read+931/1504] [generic_file_read+99/128] [file_read_actor+0/112] 
[sys_read+142/208]  
Dec  9 18:24:52 tampere kernel:[system_call+51/64]  
Dec  9 18:24:52 tampere kernel: Code: 0f 0b 83 c4 0c 8d 73 28 8d 43 2c 39 43 2c 74 15 
b9 01 00 00  

I cannot reproduce it reliably, but after a few retries, it occured again.

-- 
Dick Streefland   De Bilt
[EMAIL PROTECTED]  (@ @)   The Netherlands
--oOO--(_)--OOo--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: es1371 mixer problems

[Dick Streefland]

On Thursday 2000-11-30 18:24, Robert Schiele wrote:
| On Thu, Nov 30, 2000 at 01:47:25PM +0100, Dick Streefland wrote:
| > This mixer probably replaces the normal AC97 mixer device. So, in
| > what situations do you need CONFIG_SOUND_TVMIXER? It would be nice if
| > someone could come up with an entry for Documentation/Configure.help.
| 
| In fact it does not 'replace' the other mixer device, but it adds
| another one. The problem on your system is, that you load the new
| module before your sound card module.
| This means with only your sound card module, the mixer for your sound
| card is major 14/minor 0. With tvmixer module loaded before your sound
| card module, major 14/minor 0 is assigned to tvmixer and your sound
| card mixer gets major 14/minor 16. This is a problem for some mixer
| applications, because they always control the first mixer device.
| So you should just make sure, your sound card module is loaded
| _before_ the tvmixer module.

OK, that makes it somewhat clearer to me. However, I don't use modules
and have everything compiled in, so I can't control the order in which
the mixer devices get loaded. Perhaps the initialization order in the
kernel should be changed?

Excuse my ignorance, but what exactly is the purpose of the tvmixer?
I'm currently controlling the TV audio volume with the ac97 mixer,
using an external cable between the TV card and sound card.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: es1371 mixer problems

[Dick Streefland]

Dick Streefland <[EMAIL PROTECTED]> wrote:
| 2.4.0-test11 introduced a problem with the mixer device of my SB128
| soundcard (es1371 driver). When I start a mixer application like
| xmixer or aumix, only a small subset of the mixer devices are available.
| With 2.4.0-test10, using the same .config, all devices are available.

This is a followup to my own message to report that the mixer is
working again after I disabled the CONFIG_SOUND_TVMIXER option. I
don't know what exactly this option does (no help text), but since I
have a Hauppauge (BT878) TV-card, I did enable this option. In
test11, drivers/media/video/tvmixer.c was modified so that it now
looks for tvmixer devices, and it actually finds one:

  tvmixer: debug: MSP3415D-A2 
  tvmixer: MSP3415D-A2 (bt848 #0) registered with minor 0 
  tvmixer: debug: (unset) 

This mixer probably replaces the normal AC97 mixer device. So, in
what situations do you need CONFIG_SOUND_TVMIXER? It would be nice if
someone could come up with an entry for Documentation/Configure.help.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: es1371 mixer problems

[Dick Streefland]

Dick Streefland [EMAIL PROTECTED] wrote:
| 2.4.0-test11 introduced a problem with the mixer device of my SB128
| soundcard (es1371 driver). When I start a mixer application like
| xmixer or aumix, only a small subset of the mixer devices are available.
| With 2.4.0-test10, using the same .config, all devices are available.

This is a followup to my own message to report that the mixer is
working again after I disabled the CONFIG_SOUND_TVMIXER option. I
don't know what exactly this option does (no help text), but since I
have a Hauppauge (BT878) TV-card, I did enable this option. In
test11, drivers/media/video/tvmixer.c was modified so that it now
looks for tvmixer devices, and it actually finds one:

  tvmixer: debug: MSP3415D-A2 
  tvmixer: MSP3415D-A2 (bt848 #0) registered with minor 0 
  tvmixer: debug: (unset) 

This mixer probably replaces the normal AC97 mixer device. So, in
what situations do you need CONFIG_SOUND_TVMIXER? It would be nice if
someone could come up with an entry for Documentation/Configure.help.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11: es1371 mixer problems

[Dick Streefland]

On Thursday 2000-11-30 18:24, Robert Schiele wrote:
| On Thu, Nov 30, 2000 at 01:47:25PM +0100, Dick Streefland wrote:
|  This mixer probably replaces the normal AC97 mixer device. So, in
|  what situations do you need CONFIG_SOUND_TVMIXER? It would be nice if
|  someone could come up with an entry for Documentation/Configure.help.
| 
| In fact it does not 'replace' the other mixer device, but it adds
| another one. The problem on your system is, that you load the new
| module before your sound card module.
| This means with only your sound card module, the mixer for your sound
| card is major 14/minor 0. With tvmixer module loaded before your sound
| card module, major 14/minor 0 is assigned to tvmixer and your sound
| card mixer gets major 14/minor 16. This is a problem for some mixer
| applications, because they always control the first mixer device.
| So you should just make sure, your sound card module is loaded
| _before_ the tvmixer module.

OK, that makes it somewhat clearer to me. However, I don't use modules
and have everything compiled in, so I can't control the order in which
the mixer devices get loaded. Perhaps the initialization order in the
kernel should be changed?

Excuse my ignorance, but what exactly is the purpose of the tvmixer?
I'm currently controlling the TV audio volume with the ac97 mixer,
using an external cable between the TV card and sound card.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test11: es1371 mixer problems

[Dick Streefland]

2.4.0-test11 introduced a problem with the mixer device of my SB128
soundcard (es1371 driver). When I start a mixer application like
xmixer or aumix, only a small subset of the mixer devices are available.
With 2.4.0-test10, using the same .config, all devices are available.

I've looked through the test11 patch and noticed that it contains
a lot of changes like:

  _IOC_DIR  --> _SIOC_DIR
  _IOC_READ --> _SIOC_READ
  _IOC_WRITE--> _SIOC_WRITE
  _IOC_SIZE --> _SIOC_SIZE

These changes are not yet applied to ac97.c and ac97_codec.c, but that
does not seem to be the problem, because after making these changes
(see patch below), the problem persists.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---

--- linux-2.4.0-test11/drivers/sound/ac97.c.origFri Jan  7 00:01:56 2000
+++ linux-2.4.0-test11/drivers/sound/ac97.c Thu Nov 23 00:02:31 2000
@@ -407,19 +407,19 @@
/* Read or write request. */
ret = -EINVAL;
if (_IOC_TYPE (cmd) == 'M') {
-   int dir = _IOC_DIR (cmd);
+   int dir = _SIOC_DIR (cmd);
int channel = _IOC_NR (cmd);
 
if (channel >= 0 && channel < SOUND_MIXER_NRDEVICES) {
ret = 0;
-   if (dir & _IOC_WRITE) {
+   if (dir & _SIOC_WRITE) {
int val;
if (get_user (val, (int *) arg) == 0)
ret = ac97_set_mixer (dev, channel, val);
else
ret = -EFAULT;
}
-   if (ret >= 0 && (dir & _IOC_READ)) {
+   if (ret >= 0 && (dir & _SIOC_READ)) {
if (dev->last_written_OSS_values[channel]
== AC97_REGVAL_UNKNOWN)
dev->last_written_OSS_values[channel]
--- linux-2.4.0-test11/drivers/sound/ac97_codec.c.orig  Tue Nov 21 21:41:02 2000
+++ linux-2.4.0-test11/drivers/sound/ac97_codec.c   Thu Nov 23 00:02:45 2000
@@ -405,13 +405,13 @@
return 0;
}
 
-   if (_IOC_TYPE(cmd) != 'M' || _IOC_SIZE(cmd) != sizeof(int))
+   if (_IOC_TYPE(cmd) != 'M' || _SIOC_SIZE(cmd) != sizeof(int))
return -EINVAL;
 
if (cmd == OSS_GETVERSION)
return put_user(SOUND_VERSION, (int *)arg);
 
-   if (_IOC_DIR(cmd) == _IOC_READ) {
+   if (_SIOC_DIR(cmd) == _SIOC_READ) {
switch (_IOC_NR(cmd)) {
case SOUND_MIXER_RECSRC: /* give them the current record source */
if (!codec->recmask_io) {
@@ -451,7 +451,7 @@
return put_user(val, (int *)arg);
}
 
-   if (_IOC_DIR(cmd) == (_IOC_WRITE|_IOC_READ)) {
+   if (_SIOC_DIR(cmd) == (_SIOC_WRITE|_SIOC_READ)) {
codec->modcnt++;
if (get_user(val, (int *)arg))
return -EFAULT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test11: es1371 mixer problems

[Dick Streefland]

2.4.0-test11 introduced a problem with the mixer device of my SB128
soundcard (es1371 driver). When I start a mixer application like
xmixer or aumix, only a small subset of the mixer devices are available.
With 2.4.0-test10, using the same .config, all devices are available.

I've looked through the test11 patch and noticed that it contains
a lot of changes like:

  _IOC_DIR  -- _SIOC_DIR
  _IOC_READ -- _SIOC_READ
  _IOC_WRITE-- _SIOC_WRITE
  _IOC_SIZE -- _SIOC_SIZE

These changes are not yet applied to ac97.c and ac97_codec.c, but that
does not seem to be the problem, because after making these changes
(see patch below), the problem persists.

-- 
Dick Streefland  TASKING Software BV
[EMAIL PROTECTED] (@ @) http://www.tasking.com
oOO--(_)--OOo---

--- linux-2.4.0-test11/drivers/sound/ac97.c.origFri Jan  7 00:01:56 2000
+++ linux-2.4.0-test11/drivers/sound/ac97.c Thu Nov 23 00:02:31 2000
@@ -407,19 +407,19 @@
/* Read or write request. */
ret = -EINVAL;
if (_IOC_TYPE (cmd) == 'M') {
-   int dir = _IOC_DIR (cmd);
+   int dir = _SIOC_DIR (cmd);
int channel = _IOC_NR (cmd);
 
if (channel = 0  channel  SOUND_MIXER_NRDEVICES) {
ret = 0;
-   if (dir  _IOC_WRITE) {
+   if (dir  _SIOC_WRITE) {
int val;
if (get_user (val, (int *) arg) == 0)
ret = ac97_set_mixer (dev, channel, val);
else
ret = -EFAULT;
}
-   if (ret = 0  (dir  _IOC_READ)) {
+   if (ret = 0  (dir  _SIOC_READ)) {
if (dev-last_written_OSS_values[channel]
== AC97_REGVAL_UNKNOWN)
dev-last_written_OSS_values[channel]
--- linux-2.4.0-test11/drivers/sound/ac97_codec.c.orig  Tue Nov 21 21:41:02 2000
+++ linux-2.4.0-test11/drivers/sound/ac97_codec.c   Thu Nov 23 00:02:45 2000
@@ -405,13 +405,13 @@
return 0;
}
 
-   if (_IOC_TYPE(cmd) != 'M' || _IOC_SIZE(cmd) != sizeof(int))
+   if (_IOC_TYPE(cmd) != 'M' || _SIOC_SIZE(cmd) != sizeof(int))
return -EINVAL;
 
if (cmd == OSS_GETVERSION)
return put_user(SOUND_VERSION, (int *)arg);
 
-   if (_IOC_DIR(cmd) == _IOC_READ) {
+   if (_SIOC_DIR(cmd) == _SIOC_READ) {
switch (_IOC_NR(cmd)) {
case SOUND_MIXER_RECSRC: /* give them the current record source */
if (!codec-recmask_io) {
@@ -451,7 +451,7 @@
return put_user(val, (int *)arg);
}
 
-   if (_IOC_DIR(cmd) == (_IOC_WRITE|_IOC_READ)) {
+   if (_SIOC_DIR(cmd) == (_SIOC_WRITE|_SIOC_READ)) {
codec-modcnt++;
if (get_user(val, (int *)arg))
return -EFAULT;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/