Re: autofs multi-map regression
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
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
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
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
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
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)
"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
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: [PATCH] ver_linux is [censored]
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: somebody dropped a (warning) bomb
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
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
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/
[2.4.0-test12-pre7] kernel BUG at buffer.c:827!
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
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 <[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/
2.4.0-test11: es1371 mixer problems
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/