Re: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Wed, 2008-01-30 at 15:53 -0500, Richard Stallman wrote:
> I don't know what the circumstances are in this case, since the
> description quoted was quite sketchy.  I suggest that someone send a
> clear description of the case to [EMAIL PROTECTED] to find out what
> GPLv2 implies about it.

I don't think anyone implies that there are any real copyright issues
with ndiswrapper, at least in the US.  With all differences in
intonations, everybody seems to understand that.

It's understandable that kernel developers feel uncomfortable about
ndiswrapper, which loads non-free Windows drivers into the kernel
memory.  It's understandable that kernel developers don't want to
support systems where such code has been running at any time.

It's understandable that ndiswrapper can be considered as an unwelcome
alternative to free drivers, although it's actually used for reverse
engineering and it allows to check that the unsupported hardware is
functional without having to boot to a non-free OS.  A kernel that did
something unsupportable becomes "tainted".

Unfortunately, the code for making ndiswrapper taint the kernel is
similar to the code that makes non-free modules (i.e. non-free software
specifically designed to work with Linux) taint the kernel.  That's why
is has happened for the second time already that ndiswrapper was lumped
together with non-free modules and disallowed to use certain kernel
facilities that were only meant for free software.

Even though it was done by mistake both times, it looked as an
intentional change every time.  It is an emotional issue, but it has
little to do with copyright issues and more with understandable
antipathy of the kernel developer towards non-free software running with
the kernel privileges.

I think the whole idea to bring you into the discussion was based on
misunderstanding of my use of the word "linking".  There is a difference
between compiling and linking a non-free program from the source code
against free headers and free libraries and loading non-free code and
making it work by emulating non-free interfaces with free software.

I was merely saying that the later is OK.  I was not advocating the
former.

> If my message does not appear on linux-kernel@vger.kernel.org,
> would one of you please forward it?

It did appear on the list.

> It is not in general the case that "dynamic linking cannot violate the
> GPL".  It depends on circumstances.  Running a non-free program in a
> process in a GNU/Linux system is not linking of any kind with Linux.
> The program probably links with GNU libc, but the license of GNU libc
> permits that.

A better analogy would be running a non-free program in a free emulator.

I don't have any issues with ndiswrapper.  If anyone does, they should
write to FSF, or maybe to FSF Europe if the concern are about European
laws.

-- 
Regards,
Pavel Roskin
--
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] module: remove module taint on ndiswrapper

[Pavel Roskin]

Revert 0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, which disallowed
ndiswrapper to use GPL-only symbols.

Add comments why ndiswrapper and driverloader are tainted to avoid
similar mistakes in the future.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---

 kernel/module.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index bd60278..c7f3fa6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1933,8 +1933,13 @@ static struct module *load_module(void __user *umod,
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 
+   /* ndiswrapper can load proprietary drivers.  Don't use
+  add_taint_module(), as ndiswrapper needs GPL-only symbols. */
if (strcmp(mod->name, "ndiswrapper") == 0)
-   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+   add_taint(TAINT_PROPRIETARY_MODULE);
+
+   /* driverloader is proprietary, but it's known to be lying about
+  its license in the license info */
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 
--
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/

Bisected regression: iterate_fd() selinux change affects flash plugin

[Pavel Roskin]

Hello, Al!

I have noticed that Mozilla Firefox gets stuck for seconds or minutes  
on some sites, in particular on Facebook with Linux 3.7-rc1 and newer  
mainline kernels.  Disabling flash plugin fixes the delays.


This is a Fedora 17 system with SELinux enabled, on x86_64  
architecture, with all updates, with LXDE desktop.  It's not the  
Fedora 16 system I mentioned before, it has never had LXDE login  
problems due to replace_fd().


Bisecting lead me to the patch that introduced iterate_fd():

commit c3c073f808b22dfae15ef8412b6f7b998644139a
Author: Al Viro 
Date:   Tue Aug 21 22:32:06 2012 -0400

new helper: iterate_fd()

iterates through the opened files in given descriptor table,
calling a supplied function; we stop once non-zero is returned.
Callback gets struct file *, descriptor number and const void *
argument passed to iterator.  It is called with files->file_lock
held, so it is not allowed to block.

tty_io, netprio_cgroup and selinux flush_unauthorized_files()
converted to its use.

Signed-off-by: Al Viro 

I have found that reverting the changes to security/selinux/hooks.c is  
sufficient to restore the correct behavior.


--
Regards,
Pavel Roskin
--
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: [PATCH] x86: sysfb: mark simplefb resources as BUSY

[Pavel Roskin]

On Wed,  2 Oct 2013 16:41:04 +0200
David Herrmann  wrote:

> Tested-by: Pavel Roskin 

Tested indeed, on ThinkPad W530 with 32-bit and 64-bit kernels with
Intel and NVidia graphics enabled.

> Sorry for the delay, but I was in the US for the last 2 weeks and
> this is really no major issue, just suppresses a warning that says
> "Your kernel is fine".

It shows a stack trace, so it might confuse (and has confused) users
into thinking that it's a more important issue than it is.

> Anyhow, thanks to Tom and Pavel for reporting
> and testing this! This is targeted at 3.12-rc4 as bugfix. I think
> it's still early/mid rc-stage and is a one-line patch so it should be
> fine, right?

I second this.

-- 
Regards,
Pavel Roskin
--
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: Bisected regression: iterate_fd() selinux change affects flash plugin

[Pavel Roskin]

Quoting Al Viro :


On Fri, Nov 30, 2012 at 03:40:34AM +, Al Viro wrote:


The bug is real, but Pavel's patch is all wrong.  The problem is in the
argument; we should pass descriptor number, not descriptor + 1.  And fixing
that (in iterator_fd() itself) makes all callbacks work as they ought to.

PS: Pavel, the life is painful enough as it is, no need to involve BZ into
it.  Next time you need to post a patch, please do just that, especially
when it's so short, OK?


See tonight's vfs.git#for-linus; the head is at commit a77cfcb.


Works for me!  Thank you!  Sorry if I mishandled anything.

--
Regards,
Pavel Roskin
--
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: Bisected regression: iterate_fd() selinux change affects flash plugin

[Pavel Roskin]

Quoting Pavel Roskin :


Hello, Al!

I have noticed that Mozilla Firefox gets stuck for seconds or minutes
on some sites, in particular on Facebook with Linux 3.7-rc1 and newer
mainline kernels.  Disabling flash plugin fixes the delays.

This is a Fedora 17 system with SELinux enabled, on x86_64
architecture, with all updates, with LXDE desktop.  It's not the Fedora
16 system I mentioned before, it has never had LXDE login problems due
to replace_fd().

Bisecting lead me to the patch that introduced iterate_fd():

commit c3c073f808b22dfae15ef8412b6f7b998644139a
Author: Al Viro 
Date:   Tue Aug 21 22:32:06 2012 -0400

new helper: iterate_fd()

iterates through the opened files in given descriptor table,
calling a supplied function; we stop once non-zero is returned.
Callback gets struct file *, descriptor number and const void *
argument passed to iterator.  It is called with files->file_lock
held, so it is not allowed to block.

tty_io, netprio_cgroup and selinux flush_unauthorized_files()
converted to its use.

Signed-off-by: Al Viro 

I have found that reverting the changes to security/selinux/hooks.c is
sufficient to restore the correct behavior.

--
Regards,
Pavel Roskin


I've made a bugzilla entry for the bug and put a preliminary patch there.
https://bugzilla.kernel.org/show_bug.cgi?id=50401

--
Regards,
Pavel Roskin
--
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: Bisected regression: iterate_fd() selinux change affects flash plugin

[Pavel Roskin]

Quoting Eric Paris :


OMG this +1 -1 stuff is nuts...

iterate_fd passes fd+1 instead of the fd for the file?  seriously?
e.  I see how this patch fixes it, but still, wouldn't some magic
or negative value for no entries found be better than having to
understand the crazy logics?


I agree.  -ENOENT is both magic and negative :)

I tend to think now that iterate_fd() should be rewritten before it's too
late and all its current users should be cross-checked against the
code prior to the introduction of iterate_fd().

--
Regards,
Pavel Roskin
--
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/

[PATCH] kbuild: CONFIG_CC_OPTIMIZE_FOR_SIZE should not be default

[Pavel Roskin]

It's an experimental option and it's not generally recommended

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---

 init/Kconfig |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index dcef8b5..a998a13 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -477,7 +477,6 @@ endif
 
 config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size (Look out for broken compilers!)"
-   default y
depends on ARM || H8300 || SUPERH || EXPERIMENTAL
help
  Enabling this option will pass "-Os" instead of "-O2" to gcc
--
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/

ndiswrapper tainting

[Pavel Roskin]

Hello!

What are the chances that incorrect tainting of ndiswrapper will be
fixed in 2.6.25?  I'm worried that it still hasn't happened in the
mainline repository.  It's unfortunate to see that a long discussion
didn't result in a simple fix.  If anyone is waiting for my patch,
please let me know what kind of patch I'm supposed to submit and to
which address.

If the problem is not fixed in 2.6.25, the ndiswrapper module will need
to be renamed in the next release, because otherwise the problem with
unresolved symbols will quickly become the number one in the FAQ.  But
this is undesirable because it would break existing modprobe
configuration files that bind ndiswrapper to specific devices.

Please let's not turn it into another empty discussion.

I represent only myself and I'm not a lawyer.

-- 
Regards,
Pavel Roskin
--
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 PATCH v2] x86: explicit call to mmiotrace in do_page_fault()

[Pavel Roskin]

On Sun, 2008-02-10 at 20:05 +0200, Pekka Paalanen wrote:

> Sorry Jan and Pavel, I forgot to CC you in the first go of this
> patch. If this makes it into mainline, I don't think it will be left
> there for many kernel versions. I plan to make kmmio.h as the API towards
> modules in the future, and the page fault callback will "disappear".
> I think madwifi could use just fine the kmmio.h functions, if it
> works basically just like mmiotrace.

In fact, the tracing version of MadWifi has a directory called mmiotrace
with the files lifted from nouveau.  I guess if will just stay in sync
with the upstream.

Many thanks for pushing it into the kernel.

-- 
Regards,
Pavel Roskin
--
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: Bisected regression in Linux 3.7.0-rc1, hang on login caused by replace_fd()

[Pavel Roskin]

On Mon, 15 Oct 2012 22:51:27 +0100
Al Viro  wrote:

> On Mon, Oct 15, 2012 at 05:14:37PM -0400, Pavel Roskin wrote:
> > Hello!
> > 
> > I tried the current mainline Linux on Fedora 16 x64_64 and found
> > that I cannot login in gdm.  I'm using gdm with LXDE.  After a few
> > minutes, kernel messages appear indicating a hung process
> > gnome-settings-daemon.
> 
> What is it hanging on?

Sorry, I have no idea.  I select my name, enter password and nothing
happens.  I can still move the mouse and select some widgets in gdm.  I
can use Ctrl-Alt-F2 to switch to the test console and login.

I attached gdb to the process and that's what I got:

(gdb) where
#0  0x003c19ae8803 in __GI___poll (fds=, nfds=, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x003c1ba45448 in g_main_context_poll (n_fds=10, fds=0x2096dc0, 
priority=, timeout=41758, context=0x1e3e4a0) at gmain.c:3402
#2  g_main_context_iterate (context=0x1e3e4a0, block=, 
dispatch=1, self=) at gmain.c:3084
#3  0x003c1ba45c85 in g_main_loop_run (loop=0x1f35b70) at gmain.c:3297
#4  0x0033cf75198d in gtk_main () at gtkmain.c:1362
#5  0x00403d28 in main (argc=1, argv=0x7fffe57b3a78) at main.c:459
(gdb)

I'm not sure it's what you asked.

> Aha.  We have the first thing to test - is RLIMIT_NOFILE set to 0 for
> that process, by any chance?

No.  I made a copy of replace_fd() called by umh_pipe_setup() only, and
here's the output (debugging patch attached):

[   15.792895] replace_fd_debug: rlimit(RLIMIT_NOFILE) = 1024
[   15.792901] replace_fd_debug: file = 88011dd5db80
[   15.792903] replace_fd_debug: expand_files returned 0
[   15.792905] umh_pipe_setup: replace_fd_debug returned 0

>  We definitedly need to check
> replace_fd() return value, BTW.  OK, suppose it wasn't 0.

It's 0.

I made simplified functions replacing replace_fd() for umh_pipe_setup()
by substituting parameters and expanding do_dup2().  Here's the
combined function:

void replace_fd2(struct file *file)
{
struct fdtable *fdt;
struct files_struct *files = current->files;

/* old code */
sys_close(0);
fd_install(0, file);

spin_lock(&files->file_lock);
fdt = files_fdtable(files);

/* new code */
get_file(file);
rcu_assign_pointer(fdt->fd[0], file);

__set_open_fd(0, fdt);
__clear_close_on_exec(0, fdt);
spin_unlock(&files->file_lock);
}

If the "new code" (two lines below the comment) is commented out and the
"old code" is not, everything works.  If the new code is used and the
old code is commented out, I have a hang.  Enabling all code leads
to a hang too.

>   All right, so the next step in debugging is to print the damn
> return value of replace_fd().  That should narrow the things down.
> Another interesting question, of course, is what makes that gnome turd
> coredump on each boot?

I guess some GNOME programs are "uncomfortable" when launched by LXDE.
Considering that I'm running Fedora 16 with GNOME 3.2, I don't think
anyone would care about my bug reports.  But inability to login due to
kernel changes is bad and should not happen.

-- 
Regards,
Pavel Roskin
Debug replace_fd()

From: Pavel Roskin 


---

 fs/coredump.c |4 +++-
 fs/file.c |   27 +++
 2 files changed, 30 insertions(+), 1 deletions(-)


diff --git a/fs/coredump.c b/fs/coredump.c
index fd37fac..2a5ce3c 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -440,6 +440,7 @@ static void wait_for_dump_helpers(struct file *file)
  * is a special value that we use to trap recursive
  * core dumps
  */
+int replace_fd_debug(unsigned fd, struct file *file, unsigned flags);
 static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
 {
 	struct file *files[2];
@@ -450,7 +451,8 @@ static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
 
 	cp->file = files[1];
 
-	replace_fd(0, files[0], 0);
+	err = replace_fd_debug(0, files[0], 0);
+	printk("%s: replace_fd_debug returned %d\n", __func__, err);
 	/* and disallow core files too */
 	current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
 
diff --git a/fs/file.c b/fs/file.c
index d3b5fa8..e209b3c 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -913,6 +913,33 @@ out_unlock:
 	return err;
 }
 
+int replace_fd_debug(unsigned fd, struct file *file, unsigned flags);
+int replace_fd_debug(unsigned fd, struct file *file, unsigned flags)
+{
+	int err;
+	struct files_struct *files = current->files;
+
+	printk("%s: rlimit(RLIMIT_NOFILE) = %ld\n", __func__, rlimit(RLIMIT_NOFILE));
+	printk("%s: file = %p\n", __func__, file);
+
+	if (!file)
+		return __close_fd(files, fd);
+
+	if (fd >= rlimit(RLIMIT_NOFILE))
+		return -EMFILE;
+
+	spin_lock(&files->file_lock);
+	err = expand_file

Re: Bisected regression in Linux 3.7.0-rc1, hang on login caused by replace_fd()

[Pavel Roskin]

On Tue, 16 Oct 2012 00:27:05 +0100
Al Viro  wrote:

>   I think I understand what's going on there.  Add
> fput(files[0]) after that replace_fd(); we have a leak and while
> that's not the right way to fix it, that'd verify if anything else is
> going on there.

Yes, it's working now!  No more hang on login!

-- 
Regards,
Pavel Roskin
--
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: Bisected regression in Linux 3.7.0-rc1, hang on login caused by replace_fd()

[Pavel Roskin]

On Tue, 16 Oct 2012 00:48:53 +0100
Al Viro  wrote:

> On Mon, Oct 15, 2012 at 07:40:08PM -0400, Pavel Roskin wrote:
> > On Tue, 16 Oct 2012 00:27:05 +0100
> > Al Viro  wrote:
> > 
> > >   I think I understand what's going on there.  Add
> > > fput(files[0]) after that replace_fd(); we have a leak and while
> > > that's not the right way to fix it, that'd verify if anything
> > > else is going on there.
> > 
> > Yes, it's working now!  No more hang on login!
> 
> That should be closer to the final variant.

It works me, thank you!  I don't use SELinux, so I could not really
test the second part.

-- 
Regards,
Pavel Roskin
--
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: [PATCH] linux-firmware: add MISSING file

[Pavel Roskin]

On Sun, 13 Jan 2013 00:09:46 +0100
richard -rw- weinberger  wrote:

> > +This file attempts to document the reason why a firmware is not
> > present +in this bundle.
> 
> From the user's point of view this not really helpful.
> Wouldn't a in-kernel table of known but missing firmware files make
> more sense? The kernel could write a log like "Yeah, I know this
> firmware but sadly I don't have it because of ..."

The firmware file may be absent on the system even if it's in the
linux-firmware tree.  Conversely, the firmware may be present on the
system but not in the linux-firmware tree.

The kernel doesn't know whether the firmware is missing due to
licensing issues or due to misconfiguration.  The kernel cannot know
that.  And I don't think the kernel should include as much information
as the MISSING file would include.

-- 
Regards,
Pavel Roskin
--
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: [RFC] mmiotrace full patch, preview 1

[Pavel Roskin]

Quoting Christoph Hellwig <[EMAIL PROTECTED]>:


On Mon, Feb 25, 2008 at 02:49:22PM -0800, Andrew Morton wrote:

the things which it finds.

> +static DECLARE_MUTEX(kmmio_init_mutex);

That's not a mutex.

> +  down(&kmmio_init_mutex);

It's a semaphore.  Please do convert it to a mutex.

Andy, I'd say that addition of new semaphores is worth a warning - they're
rarely legitimate.


I'm not sure that any semaphore should be a warning, but the initializer
for semaphore used as binary mutex (DECLARE_MUTEX and init_MUTEX) are
worth it.


It looks like a mutex, it acts like a mutex, but it isn't a mutex,  
it's a trap for the unwary.  Weird.  I was annoyed by it before; now I  
see a fellow developer actually getting into that trap.


I'd say, rename DECLARE_MUTEX to DECLARE_SEMAPHORE and let external  
code be fixed one way or another (i.e. stick with the "mutex" name or  
stick with the semaphore functionality if it's really needed).


--
Regards,
Pavel Roskin
--
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/

Cannot unmount ramfs after chmod

[Pavel Roskin]

Hello!

This happens on RedHat Linux 7.0, i686 with Linux-2.4.3-ac3.
Chmod on the top-level inode of ramfs make it impossible to unmount the
filesystem.

Chmod on other files has no effect.

[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# touch t1/foo
[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# touch t1/foo
[root@fonzie /root]# chmod 600 t1/foo
[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# chmod 600 t1
[root@fonzie /root]# umount t1
umount: /root/t1: device is busy

-- 
Regards,
Pavel Roskin

-
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] Initial permissions on ramfs

[Pavel Roskin]

Hello!

This patch is against 2.4.3-ac4. It won't apply to the Linus' tree!

This patch makes it possible to manage all RAM filesystems in one place -
in /etc/fstab. No need to write scripts to change permissions after mount.

The patch adds "mode", "uid" and "gid" options to ramfs. They only affect
the top-level directory. The permissions can be changed later. For
example:

mount -t ramfs -o mode=1777,uid=0,gid=100 none /tmp

This patch superseeds my older patch that only allowed to specify "mode"
but not "gid" and "uid" of the top-level directory. It also includes
corresponding changes in the documentation.

I'm using this patch all the time on the system where I'm writing these
lines for /tmp. No problems so far.

This patch is orthogonal to the "umount" problem I reported yesterday
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.1/0414.html) - it
neither fixes nor introduces the "umount" problem.

The patch is also available online:
http://www.red-bean.com/~proski/linux/ramfs_access.diff

-- 
Regards,
Pavel Roskin

___
--- linux.orig/Documentation/filesystems/ramfs.txt
+++ linux/Documentation/filesystems/ramfs.txt
@@ -45,3 +45,18 @@
Sets the maximum number of inodes (i.e. distinct
 files) on the filesystem to NNN. If NNN=0 there is no limit. The
 default is no limit (but there can never be more inodes than dentries).
+
+   mode=NNN
+   Sets the initial permissions of the root inode. By
+default this is 755. You can specify the sticky bit if you want to
+mount /tmp as ramfs, but make sure to set maxsize (see above) to a safe
+value to avoid running out of memory.
+
+   uid=NNN
+   Sets the initial owner of the root inode. You can later
+change the owner. Other inodes are not affected.
+
+   gid=NNN
+   Sets the initial group of the root inode. You can later
+change the group. Other inodes are not affected.
+
--- linux.orig/fs/ramfs/inode.c
+++ linux/fs/ramfs/inode.c
@@ -297,7 +297,7 @@ static void ramfs_truncatepage(struct pa
ramfs_dealloc_page(inode, page);
 }

-struct inode *ramfs_get_inode(struct super_block *sb, int mode, int dev)
+struct inode *ramfs_get_inode(struct super_block *sb, int mode, int dev, uid_t uid, 
+gid_t gid)
 {
struct inode * inode;

@@ -308,8 +308,8 @@ struct inode *ramfs_get_inode(struct sup

if (inode) {
inode->i_mode = mode;
-   inode->i_uid = current->fsuid;
-   inode->i_gid = current->fsgid;
+   inode->i_uid = uid;
+   inode->i_gid = gid;
inode->i_blksize = PAGE_CACHE_SIZE;
inode->i_blocks = 0;
inode->i_rdev = to_kdev_t(dev);
@@ -349,7 +349,7 @@ static int ramfs_mknod(struct inode *dir
if (! ramfs_alloc_dentry(sb))
return error;

-   inode = ramfs_get_inode(dir->i_sb, mode, dev);
+   inode = ramfs_get_inode(dir->i_sb, mode, dev, current->fsuid, current->fsgid);

if (inode) {
d_instantiate(dentry, inode);
@@ -504,6 +504,9 @@ struct ramfs_params {
long filepages;
long inodes;
long dentries;
+   mode_t root_mode;
+   mode_t root_uid;
+   mode_t root_gid;
 };

 static int parse_options(char * options, struct ramfs_params *p)
@@ -514,6 +517,9 @@ static int parse_options(char * options,
p->filepages = -1;
p->inodes = -1;
p->dentries = -1;
+   p->root_mode = 755;
+   p->root_uid = current->uid;
+   p->root_gid = current->gid;

for (optname = strtok(options,","); optname;
 optname = strtok(NULL,",")) {
@@ -541,6 +547,18 @@ static int parse_options(char * options,
p->dentries = simple_strtoul(value, &value, 0);
if (*value)
return -EINVAL;
+   } else if (!strcmp(optname, "mode") && value) {
+   p->root_mode = simple_strtoul(value, &value, 8) & 0;
+   if (*value)
+   return -EINVAL;
+   } else if (!strcmp(optname, "uid") && value) {
+   p->root_uid = simple_strtoul(value, &value, 0);
+   if (*value)
+   return -EINVAL;
+   } else if (!strcmp(optname, "gid") && value) {
+   p->root_gid = simple_strtoul(value, &value, 0);
+   if (*value)
+   return -EINVAL;
}

if (optname != options)
@@ -725,7 +743,8 @@ static struct super_block *ramfs_read_su

init_limits(rsb, ¶ms);

-  

PNP BIOS and parport_pc - dma found but not used

[Pavel Roskin]

Hello!

I've compiled 2.4.3-ac9 with support for PNP BIOS. I understand that this
is a new feature experimental and the feedback is requested.

The setting is BIOS is to use irq 7 and dma 3. I normally use "options
parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
commented them out hoping that the driver will ask BIOS.

Although the kernel can see those settings, the dma is not used by the
driver. This is the output from dmesg.

PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 7
0x378: readIntrThreshold is 7
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x4b
0x378: ECP settings irq=7 dma=3
parport0: PC-style at 0x378 (0x778), irq 7, using FIFO
[PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(98)
parport0: assign_addrs: aa5500ff(98)
parport0: Printer, Canon BJC-1000
# cat /proc/dma
 4: cascade
# cat /proc/interrupts
   CPU0
  0:1323677  XT-PIC  timer
  1:  20176  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3:  0  XT-PIC  eth1
  4: 288111  XT-PIC
  7:  2  XT-PIC  parport0
  8:  1  XT-PIC  rtc
 12:  41138  XT-PIC  eth0
 14:  22503  XT-PIC  ide0
 15:  0  XT-PIC  ide1
NMI:  0
ERR:  0

The full output is here: http://www.red-bean.com/~proski/linux/dmesg
First time parport_pc was loaded with the explicit options.

-- 
Regards,
Pavel Roskin

-
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: PNP BIOS and parport_pc - dma found but not used

[Pavel Roskin]

Hello, Alan!

> > The setting is BIOS is to use irq 7 and dma 3. I normally use "options
> > parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
> > commented them out hoping that the driver will ask BIOS.
> >
> > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
>
> Do you have it set in the BIOS itself to use DMA mode and to use DMA 3. The
> PnPBIOS should be reflecting your BIOS choices if I understand rightly

Yes, it is set in BIOS to use ECP, EPP, IRQ 7 and DMA 3.

There is another interesting line in the log that you didn't quote. The
driver actually knows about DMA 3:

0x378: ECP settings irq=7 dma=3

Just in case, that board is Asus P5A-B with the latest BIOS:
P5A-B BIOS ver. 1010, 05/31/2000

For comparison, I took a board with VIA chipset and PhoenixBIOS 4.0
Release 6.0, and it works properly with another 2.4.3-ac9 kernel:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=3
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x4b
0x378: ECP settings irq=7 dma=3
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)

-- 
Regards,
Pavel Roskin

-
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: PNP BIOS and parport_pc - dma found but not used

[Pavel Roskin]

Hello, Gunther!

On Thu, 19 Apr 2001, Gunther Mayer wrote:

> > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
>^^ culprit !

For some reason I'm not getting that message anymore. PnPBIOS is in the
kernel, parport_pc is a module. This time I rebooted with the parport_pc
module already installed, as opposed to the first time when I compiled and
inserted it without a reboot.

I'm puzzled. Just in case, it's my .config:
http://www.red-bean.com/~proski/linux/config

Anyway, the result is still the same, just without this message.

> 1) Search for the right two-digit PNP handle for device "0104d041":

this is 01.

>cat /proc/bus/pnb/devices

01  0104d04107:01:000080
02  0105d04107:00:020180
06  0007d04101:02:000003
08  010cd04105:00:000003
09  d04108:00:010003
0a  0001d04108:02:010003
0b  000bd04108:03:010003
0c  0303d04109:00:00000b
0d  040cd0410b:01:000003
0e  0002d04108:01:010003
0f  0008d04108:80:000003
10  030ad04106:04:000003
11  020cd04108:80:ff0003

> 2) Send cat /proc/bus/pnp/01 | od -tx1

000 2a 00 00 22 80 00 47 01 78 03 78 03 00 08 47 01
020 78 07 78 07 00 08 79 00 30 2a 0a 00 22 80 00 47
040 01 bc 03 bc 03 00 03 47 01 bc 07 bc 07 00 03 30
060 2a 0a 00 22 80 00 47 01 78 03 78 03 00 08 47 01
100 78 07 78 07 00 08 30 2a 0a 00 22 20 00 47 01 78
120 02 78 02 00 08 47 01 78 06 78 06 00 08 38 79 00
140 79 00

Settings:
Parallel port mode: ECP+EPP
ECP DMA select: 3

-- 
Regards,
Pavel Roskin

-
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.4.1-ac10 compile error

[Pavel Roskin]

Hello, Keith!

I also noticed this error when I upgraded from ac9 to ac11.

My understanding is that if "make depend" is run on the sources that have
already been compiled, then names.o depends on devlist.h (with full path)
is ".depend".

If I run "make clean" first, then everything is fine. But I think that
something must have been broken in ac10. I'm always running "make clean"
after "make depend" and it's the first time that I have a problem with it.

Regards,
Pavel Roskin

-
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.4.1ac12 mkdep -I support - take 2

[Pavel Roskin]

Hello, Keith!

You patch has been applied to 2.4.1ac13, but it doesn't help:

$ HPATH=. ../../scripts/mkdep -- names.c
names.o: names.c \
   $(wildcard /home/proski/src/linux/drivers/pci/config/pci/names.h) \
   /home/proski/src/linux/drivers/pci/devlist.h \
   /home/proski/src/linux/drivers/pci/devlist.h \
   /home/proski/src/linux/drivers/pci/devlist.h
$ ls
Config.in  compat.o   names.c  pci.o quirks.o setup-res.c
Makefile   devlist.h  pci.cproc.csetup-bus.c  syscall.c
compat.c   gen-devlist.c  pci.ids  quirks.c  setup-irq.c

devlist.h is in the current directory, but the full path is used.

Regards,
Pavel Roskin

-
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.4.1ac12 mkdep -I support - take 2

[Pavel Roskin]

On Thu, 15 Feb 2001, Pavel Roskin wrote:

> Hello, Keith!
>
> You patch has been applied to 2.4.1ac13, but it doesn't help:

It's fixed in ac14. I ran twice

make depend && make clean && make bzImage && make modules

and it worked both times. Thanks!

Regards,
Pavel Roskin

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

ymfpci is 2.4.1-ac18

[Pavel Roskin]

Hello, Pete!

I understand that you tried to implement the native synthesizer for YMF
PCI cards. Thank you for your efforts!

Unfortunately, it doesn't work for me. Linux 2.4.1-ac18 is compiled with
CONFIG_SOUND_YMFPCI=m and CONFIG_SOUND_YMFPCI_LEGACY=y.

When I load ymfpci, the kernel messages are:

ymfpci: YMF740C at 0xf400 IRQ 10
ac97_codec: AC97 Audio codec, id: 0x4144:0x5303 (Analog Devices AD1819)

I'm using devfs, so I can see what files appear in /dev/sound.

# ls -l /dev/sound/
total 0
crw-rw1 root users 14,   4 Dec 31  1969 audio
crw-rw1 root users 14,   3 Dec 31  1969 dsp
crw-rw1 root users 14,   5 Dec 31  1969 dspW
crw-rw1 root users 14,   0 Dec 31  1969 mixer
crw-rw1 root users 14,   1 Dec 31  1969 sequencer
crw-rw1 root users 14,   8 Dec 31  1969 sequencer2

However, I cannot use sequencer or sequencer2:

[proski@fonzie media]$ cat ode2joy.mid >/dev/sound/sequencer
bash: /dev/sound/sequencer: No such device or address
[proski@fonzie media]$ cat ode2joy.mid >/dev/sound/sequencer2
bash: /dev/sound/sequencer2: No such device or address

"No such device or address" is ENXIO. I added debug printk's near
all ENXIO in ymfpci.c, but neither of them has triggered.

If I load opl3, /dev/sound/sequencer becomes useful - cat doesn't exit and
dmesg shows:

/dev/music: Obsolete (4 byte) API was used by cat

Regards,
Pavel Roskin

-
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: ymfpci is 2.4.1-ac18

[Pavel Roskin]

On Mon, 19 Feb 2001, Alan Cox wrote:

> > If I load opl3, /dev/sound/sequencer becomes useful - cat doesn't exit and
> > dmesg shows:
> >
> > /dev/music: Obsolete (4 byte) API was used by cat
>
> You need opl3. The ymfpci driver is the dsp and enabler for the opl3 gunge

Then I don't understand this comment in the beginning of ymfpci.c:

 *  - 2001/01/07 Replace the OPL3 part of CONFIG_SOUND_YMFPCI_LEGACY code with
 *native synthesizer through a playback slot.

It sounds more promising than it is :-(

Regards,
Pavel Roskin

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

usbdevfs can be mounted multiple times

[Pavel Roskin]

Hello!

I understand that root can do many strange and unsafe things, but mounting
the same filesystem many times is not allowed for systems other than
usbdevfs.

[root@fonzie proski]# mount
/dev/ide/host0/bus0/target0/lun0/part1 on / type reiserfs (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /proc/bus/usb type usbdevfs (rw)
[root@fonzie proski]# mount /proc/bus/usb
[root@fonzie proski]# mount /proc/bus/usb
[root@fonzie proski]# mount /proc/bus/usb
[root@fonzie proski]# mount /proc/bus/usb
[root@fonzie proski]# mount
/dev/ide/host0/bus0/target0/lun0/part1 on / type reiserfs (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /proc/bus/usb type usbdevfs (rw)
none on /proc/bus/usb type usbdevfs (rw)
none on /proc/bus/usb type usbdevfs (rw)
none on /proc/bus/usb type usbdevfs (rw)
none on /proc/bus/usb type usbdevfs (rw)
[root@fonzie proski]# mount /dev/pts
mount: none already mounted or /dev/pts busy
mount: according to mtab, none is already mounted on /dev/pts
[root@fonzie proski]# mount --version
mount: mount-2.10p
[root@fonzie proski]# uname -a
Linux fonzie 2.4.2-ac8 #3 Fri Mar 2 12:59:44 EST 2001 i686 unknown
[root@fonzie proski]#

Regards,
Pavel Roskin

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

YMF PCI - thanks, glitches, patches (fwd)

[Pavel Roskin]

Hello!

The Linux-sound list appears to be dead (I don't see my message in
http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the
authors and the people discussing the problem on the linux-kernel mailing
list.

An additional problem is that opl3 cannot find the device unless I load
and unload the old driver (ymf_sb). Probably the new driver should put the
OPL3 interface to the legacy mode if it cannot handle it directly.

This confirms my point that you should not disable building both drivers
as modules at this stage.

Regards,
Pavel Roskin

-- Forwarded message --
Date: Tue, 5 Dec 2000 19:26:34 -0500 (EST)
From: Pavel Roskin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: YMF PCI - thanks, glitches, patches

Hello!

The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:

Dec  5 18:07:11 fonzie kernel: ymfpci0: YMF740C at 0xf000 IRQ 10
Dec  5 18:07:11 fonzie kernel: ac97_codec: AC97 Audio codec, id:
0x4144:0x5303 (Unknown)

Thanks to everybody who made it!

Now about problems. Sometimes I get such messages in the log:

Dec  5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401
Dec  5 18:08:50 fonzie last message repeated 9 times

While playing some sounds I'm getting

$ play spinout.wav
sox: Unable to set audio speed to 5512 (set to 8000)
$ file spinout.wav
spinout.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
mono 5512 Hz

This always happens for some sounds, and never happens for others. This
message doesn't appear with the old driver (ymf_sb). I'm attaching
spinout.wav.

The next problem is the configuration file, linux/drivers/sound/Config.in.
I'm sending you a patch that fixes the following problems:

1) The new driver does not depend (directly or indirectly) on the OSS
sound.o module, thus CONFIG_SOUND_YMFPCI should not depend on
CONFIG_SOUND_OSS.

2) CONFIG_SOUND_YMFPCI should depend on CONFIG_PCI. You cannot compile the
driver without PCI support.

3) Both drivers (native and legacy) should disable the other driver if
eigther of them is to be compiled into the kernel. However, it should be
possible to compile both drivers as modules. I did it so I can compare
them.

4) Don't forget about spaces in the description.

You may also want to add a dependency to CONFIG_EXPERIMENTAL for
CONFIG_SOUND_YMFPCI (not in my patch) if you feel that the driver is not
ready for everybody. Just writing (EXPERIMENTAL) doesn't disable the
question about the driver when CONFIG_EXPERIMENTAL is not set.

The patch also contains minimal descriptions for CONFIG_SOUND_YMPCI and
CONFIG_SOUND_YMFPCI. I hope somebody will add more stuff there.

By the way, I'm surprised why many drivers for PCI sound cards don't
depend on CONFIG_PCI.

Regards,
Pavel Roskin

___
--- linux/Documentation/Configure.help  Tue Dec  5 10:08:10 2000
+++ linux/Documentation/Configure.help  Tue Dec  5 17:57:26 2000
@@ -14250,6 +14250,18 @@

   If unsure, say Y.

+Yamaha PCI native mode support (EXPERIMENTAL)
+CONFIG_SOUND_YMFPCI
+  This is an experimental driver that uses Yamaha PCI sound cards in
+  the native mode. You may also want to try another driver,
+  "Yamaha PCI legacy mode support" under the OSS drivers.
+
+Yamaha PCI legacy mode support
+CONFIG_SOUND_YMPCI
+  This is a driver for Yamaha PCI sound cards that turns them
+  to the Sound Blaster compatible mode. You don't need to enable
+  Sound Blaster support to use it.
+
 ACI mixer (miroPCM12/PCM20)
 CONFIG_SOUND_ACI_MIXER
   ACI (Audio Command Interface) is a protocol used to communicate with
--- linux/drivers/sound/Config.in   Tue Dec  5 10:08:13 2000
+++ linux/drivers/sound/Config.in   Tue Dec  5 17:59:30 2000
@@ -79,6 +79,9 @@
 fi

 dep_tristate '  VIA 82C686 Audio Codec' CONFIG_SOUND_VIA82CXXX $CONFIG_PCI
+if [ "$CONFIG_SOUND_YMPCI" != "y" ]; then
+  dep_tristate '  Yamaha PCI native mode support (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI 
+$CONFIG_SOUND $CONFIG_PCI
+fi

 dep_tristate '  OSS sound modules' CONFIG_SOUND_OSS $CONFIG_SOUND

@@ -142,9 +145,8 @@
dep_tristate 'Yamaha FM synthesizer (YM3812/OPL-3) support' 
CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 
$CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA2, SA3, and SAx based PnP cards' 
CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
-   dep_tristate 'Yamaha PCI legacy mode support' CONFIG_SOUND_YMPCI 
$CONFIG_SOUND_OSS $CONFIG_PCI
-   if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then
- dep_tristate 'Yamaha PCI native mode support (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI 
$CONFIG_SOUND_OSS
+   if [ "$CONFIG_SOUND_YMFPCI" != "y" ]; then
+ dep_tristate 'Yamaha PCI legacy mode support' CONFIG_SOUND_YMPCI 
+$CONFIG_SOUND_OSS $CONFIG_PCI
fi
dep_tristate '6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS

___

 spinout.wav

Re: YMF PCI - thanks, glitches, patches (fwd)

[Pavel Roskin]

On Wed, 6 Dec 2000, Pete Zaitcev wrote:

> > Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> > From: Pavel Roskin <[EMAIL PROTECTED]>
> > cc: Jaroslav Kysela <[EMAIL PROTECTED]>, Pete Zaitcev <[EMAIL PROTECTED]>,
> > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>
> > The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
>
> I did not have a chance to look at whatever is in 2.4, but from
> reading Linus's e-mails I understand that Jaroslav made a new
> port, which is probably unrelated to the stuff that I hastily
> cooked up for 2.2 (I really wanted to play Doom on my new Sony).

:-)))

> I am sorry for the lack of communication.

Why sorry? Do you mean that the linux-sound list is not dead and you saw
my message there?

> I'll see what 2.2 does about 1) playing at 5512 Hz, 2) compiling
> as modules together (non-modules are made to be exclusive),
> 3) compiling if CONFIG_PCI is not enabled, 4) has Configure.help
> update.
>
> I am not sure what to do about CONFIG_EXPERIMENTAL.
> My current plan is to discard "(EXPERIMENTAL)" and forget
> about it until the next case.

But please note that opl3 is not enabled by the new driver, so people do
lose some functionality they used to have.

> Ioctl 0x5401 is a mystery. I do not know what it is
> (looks like SNDCTL_TMR_TIMEBASE without uppper bits).

It is caused by an attempt to play at 5512 Hz. In fact, this time (I've
upgraded to test12-pre6 in the meantime) it hung very badly, so that even
"kill -KILL" doesn't help:

 3786 pts/3D  0:00 sox spinout.wav -t ossdsp /dev/dsp

sox-12.16-7, RedHat 6.2. The same with sox-12.17.1. The later uses
SNDCTL_DSP_SPEED to set the rate, but still the message about ioctl 0x5401
appears in the log.

> Please send fewer attachements to the lists. Your sound fragment
> is very useful, but I'd prefer to have it sent separately to me
> upon a request (in uuencode :).

Sorry :-(

> BTW, Legacy driver (ymf_sb) uses PC/DMA or whatever the name is,
> which requires the north bridge support and, sometimes, additional
> connections on the motherboard. This is not reflected in _any_
> kernel documentation. I have spent numerous hours trying to make
> it work on my laptop until I understood that even though my
> chipset supports PC/DMA, necessary connections are missing.
> At first glance, it looked as if IRQ does not come.

Maybe it explains why I'll have to reboot now to kill that "sox" :-/

Regards,
Pavel Roskin

 ymf.diff.gz

Re: YMF PCI - thanks, glitches, patches (fwd)

[Pavel Roskin]

> > Ioctl 0x5401 is a mystery. I do not know what it is
> > (looks like SNDCTL_TMR_TIMEBASE without uppper bits).
>
> It is caused by an attempt to play at 5512 Hz. In fact, this time (I've

I was wrong. It happens for all sounds when sox calls

setvbuf (ft->fp,NULL,_IOFBF,sizeof(char)*BUFSIZ)

Ioctl 0x5401 is not a mystery. It's TCGETS (see
include/asm-i386/ioctls.h). Other drivers (sb_mixer.c) return -EINVAL
silently while ymfpci.c returns -ENOTTY and writes to the log.

> upgraded to test12-pre6 in the meantime) it hung very badly, so that even
> "kill -KILL" doesn't help:

This problem is also fixed by my patch.

_
--- ymfpci.cWed Dec  6 11:19:15 2000
+++ ymfpci.cWed Dec  6 15:50:46 2000
@@ -1867,18 +1867,12 @@
case SNDCTL_DSP_SETSYNCRO:
case SOUND_PCM_WRITE_FILTER:
case SOUND_PCM_READ_FILTER:
-   return -ENOTTY;
+   printk("ymfpci: ioctl cmd 0x%x\n not yet supported", cmd);
+   return -EINVAL;

default:
-   /* P3 */ printk("ymfpci: ioctl cmd 0x%x\n", cmd);
-   /*
-* Some programs mix up audio devices and ioctls
-* or perhaps they expect "universal" ioctls,
-* for instance we get SNDCTL_TMR_CONTINUE here.
-* XXX Is there sound_generic_ioctl() around?
-*/
+   return -EINVAL;
}
-   return -ENOTTY;
 }

 static int ymf_open(struct inode *inode, struct file *file)
_

> Maybe it explains why I'll have to reboot now to kill that "sox" :-/

Nope :-)

Regards,
Pavel Roskin

-
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: YMF PCI - thanks, glitches, patches (fwd)

[Pavel Roskin]

Hello, Alan!

> > The Linux-sound list appears to be dead (I don't see my message in
> > http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the
>
> [EMAIL PROTECTED] is alive and well however.

You cannot imagine how frustrating it was to search for the archive.  I
couldn't find an up-to-date archive, and www.kernel.org keeps silence
about mailing lists. I cannot afford subscribing to every list just to
slightly polish support for my hardware.

> > Dec  5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401
> > Dec  5 18:08:50 fonzie last message repeated 9 times
>
> Just debugging this is fine

Well, 0x5401 is TCGETS. Other sound drivers just ignore it. I believe the
drivers should only log the ioctls that are relevant to them (i.e.
sound-related ioctls for sound drivers) and are not implemented.

> > $ play spinout.wav
> > sox: Unable to set audio speed to 5512 (set to 8000)
>
> 8Khz is the lower limit right now the way the board is driven.

So, it's not just a matter of changing the constants under "case
SNDCTL_DSP_SPEED" in ymf_ioctl()? Actually, I hacked them to be
4000http://www.tux.org/lkml/

[PATCH] for YMF PCI sound cards

[Pavel Roskin]

Hello!

Description of the changes:

Changed logic in drivers/sound/Config.in so that both drivers for YMF PCI
can be compiled as modules, but neither of them is enabled if the other
one is linked into the kernel (just like the UHCI drivers).

Don't use ENOTTY in the ioctl routine in drivers/sound/ymfpci.c - use
EINVAL instead.

Initialize the legacy OPL3 interface in drivers/sound/ymfpci.c since there
is no native synthesizer support yet. Added parameter synth_io to specify
the address of the OPL3 interface.

Add YMF cards to the table of known codecs in drivers/sound/ac97_codec.c

For your convenience, the patch is also available at
http://www.red-bean.com/~proski/ymf.patch

Regards,
Pavel Roskin

_
--- ./drivers/sound/Config.in   Thu Dec  7 10:59:06 2000
+++ ./drivers/sound/Config.in   Fri Dec  8 11:25:08 2000
@@ -142,8 +142,10 @@
dep_tristate 'Yamaha FM synthesizer (YM3812/OPL-3) support' 
CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 
$CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA2, SA3, and SAx based PnP cards' 
CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
-   dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI 
$CONFIG_SOUND_OSS $CONFIG_PCI
-   if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then
+   if [ "$CONFIG_SOUND_YMFPCI" != "y" ]; then
+  dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI 
+$CONFIG_SOUND_OSS $CONFIG_PCI
+   fi
+   if [ "$CONFIG_SOUND_YMPCI" != "y" ]; then
   dep_tristate 'Yamaha YMF7xx PCI audio (native mode) (EXPERIMENTAL)' 
CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS $CONFIG_PCI $CONFIG_EXPERIMENTAL
fi
dep_tristate '6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS
--- ./drivers/sound/ymfpci.cThu Dec  7 10:59:06 2000
+++ ./drivers/sound/ymfpci.cFri Dec  8 11:33:51 2000
@@ -81,6 +81,13 @@
 };
 MODULE_DEVICE_TABLE(pci, ymf_id_tbl);

+#ifdef MODULE
+static int synth_io = 0;
+MODULE_PARM(synth_io, "i");
+#else
+static int synth_io   = 0x388;
+#endif
+
 /*
  * Mindlessly copied from cs46xx XXX
  */
@@ -1868,7 +1875,7 @@
case SNDCTL_DSP_SETSYNCRO:
case SOUND_PCM_WRITE_FILTER:
case SOUND_PCM_READ_FILTER:
-   return -ENOTTY;
+   return -EINVAL;

default:
/* P3 */ printk(KERN_WARNING "ymfpci: unknown ioctl cmd 0x%x\n", cmd);
@@ -1879,7 +1886,76 @@
 * XXX Is there sound_generic_ioctl() around?
 */
}
-   return -ENOTTY;
+   return -EINVAL;
+}
+
+#defineYMFSB_PCIR_LEGCTRL  0x40
+#defineYMFSB_PCIR_ELEGCTRL 0x42
+#define YMFSB_PCIR_OPLADR   0x60
+static int ymfpci_opl3_init(struct pci_dev *pcidev, int instance)
+{
+   int v;
+   int oplio = 0;
+
+   switch(synth_io) {
+   case 0:
+   /* Only enable OPL3 by default for the first card */
+   if (instance == 0) {
+   synth_io = 0x388;
+   } else {
+   return 0;
+   }
+   break;
+   case 0x388:
+   oplio = 0;
+   break;
+   case 0x398:
+   oplio = 1;
+   break;
+   case 0x3a0:
+   oplio = 2;
+   break;
+   case 0x3a8:
+   oplio = 3;
+   break;
+   case -1:
+   return 0;
+   break;
+   default:
+   printk(KERN_ERR
+  "ymfpci%d: synth_io=0x%x is not valid\n",
+  instance, synth_io);
+   return -1;
+   break;
+   }
+
+   printk("ymfpci%d: set OPL3 I/O at 0x%x\n", instance, synth_io);
+
+   v = 0x003f;
+   pci_write_config_word(pcidev, YMFSB_PCIR_LEGCTRL, v);
+
+   v = 0x8800;
+   switch( pcidev->device ) {
+   case PCI_DEVICE_ID_YAMAHA_724:
+   case PCI_DEVICE_ID_YAMAHA_724F:
+   case PCI_DEVICE_ID_YAMAHA_740:
+   case PCI_DEVICE_ID_YAMAHA_740C:
+   v = v | (oplio & 0x03);
+   pci_write_config_word(pcidev, YMFSB_PCIR_ELEGCTRL, v);
+   break;
+
+   case PCI_DEVICE_ID_YAMAHA_744:
+   case PCI_DEVICE_ID_YAMAHA_754:
+   pci_write_config_word(pcidev, YMFSB_PCIR_ELEGCTRL, v);
+   pci_write_config_word(pcidev, YMFSB_PCIR_OPLADR, synth_io);
+   break;
+
+   default:
+   return -1;
+   break;
+   }
+
+   return 0;
 }

 static int ymf_open(struct inode *inode, struct file *file)
@@ -2290,6 +2366,8 @@

printk(KERN_INFO "ymfpci%d: %s at 0x%lx IRQ %d\n", ymf_instance,
(char *)ent->driver_data, pci_resource_start(

Re: [PATCH] for YMF PCI sound cards

[Pavel Roskin]

Hello, Pete!

> The idea of the patch looks good but there is a small problem.
> I have an open/close fix queued with Alan for post-2.2.18,
> which changes the enumeration scheme for ymfcpi to make it
> more friendly to other sound cards (Bug from Abhijit Menon-Sen).
> This is a conflict because you use instance number to find
> what card goes in first. In fact I plan to send the same
> thing to Linus for 2.4 (if he have not fixed that already).

Ok, I'm not a good kernel hacker. I simply did what I believed would be
the behaviour that minimizes the number of gotchas for the end user. If
the instance number isn't reliable then drop it and initialize OPL for all
cards.

The users of multiple cards will have to supply synth_io, but I wouldn't
fight to save few keystrokes for the insane people with more than one YMF
soundcard :-)

> Would you please to hold on to your patch for couple of weeks
> and then resync and redo it? Alternatively, I'll keep your
> patch and will reapply it in the way I see sane, but you will
> have to retest it before I issue it.

The later is better. I never know whether I'll have a free minute in a
couple of weeks.

> > +   {0x41445303, "Yamaha YMF"  , NULL},
>
> Are you sure it's correct? I am almost certain that no YMFxxx
> has on-chip AC97. I'd like to see a document that allows you
> the change quoted above.

I have no documents, only the log from the patched module:

Dec  8 13:29:35 fonzie kernel: ymfpci0: YMF740C at 0xf000 IRQ 10
Dec  8 13:29:35 fonzie kernel: ymfpci0: set OPL3 I/O at 0x388
Dec  8 13:29:36 fonzie kernel: ac97_codec: AC97 Audio codec, id:
0x4144:0x5303 (Yamaha YMF)

Drop it if it's not convincing.

Regards,
Pavel Roskin

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

[PATCH] for ymf_sb (YMF PCI legacy driver)

[Pavel Roskin]

Hello!

I just found two serious bugs in the YMF PCI legacy driver (i.e. the
driver that puts it to the Sound Blaster compatible mode).

pci_unregister_driver() was not called from the cleanup routine, which
caused a recoverable oops while running /sbin/lspci.

Also some module parameters were OR'd with 0x03 _after_ shifting them.
Those parameters were ignored while setting up the card.

For example, "modprobe ymf_sb io=0x240" didn't work - it would set up the
card to 0x220 but the sb driver would be told to check 0x240 for the Sound
Blaster.

For your convenience, the patch is also available at
http://www.red-bean.com/~proski/ymf_sb.patch

Regards,
Pavel Roskin

_
--- linux.orig/drivers/sound/ymf_sb.c
+++ linux/drivers/sound/ymf_sb.c
@@ -436,7 +436,7 @@
printk(PFX "set DMA address at 0x%x\n",sb_data[cards].dma);
 #endif

-   v = 0x | ((dma<<6)&0x03) | 0x003f;
+   v = 0x | ((dma & 0x03) << 6) | 0x003f;
pci_write_config_word(pcidev, YMFSB_PCIR_LEGCTRL, v);
 #ifdef YMF_DEBUG
printk(PFX "LEGCTRL: 0x%x\n",v);
@@ -446,7 +446,9 @@
case PCI_DEVICE_ID_YMF740:
case PCI_DEVICE_ID_YMF724F:
case PCI_DEVICE_ID_YMF740C:
-   v = 0x8800 | ((mpuio<<4)&0x03) | ((sbio<<2)&0x03) | (oplio&0x03);
+   v = 0x8800 | ((mpuio & 0x03) << 4)
+  | ((sbio & 0x03) << 2)
+  | (oplio & 0x03);
pci_write_config_word(pcidev, YMFSB_PCIR_ELEGCTRL, v);
 #ifdef YMF_DEBUG
printk(PFX "ELEGCTRL: 0x%x\n",v);
@@ -843,6 +845,7 @@
}

free_iomaps();
+   pci_unregister_driver(&ymf7xxsb_driver);

 }

_

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

SNDCTL_DSP_SETFRAGMENT broken in OSS drivers?

[Pavel Roskin]

Hello!

I'm using 2.4.0-test12-pre7. I have noticed that the game "Abuse" produces
only noise with the legacy YMF PCI driver but works with the native driver
(ymfpci.o).

I found that Abuse uses SNDCTL_DSP_SETFRAGMENT ioctl. When I disable this
ioctl in audio.c (which is used only by OSS drivers, such as ymf_sb), i.e.
make it return -EINVAL, Abuse works and produces correct sounds. I
understand that it uses an alternative way to output the sound.

This looks like a bug in the OSS driver (sound.o). Could anybody please
test Abuse on SoundBlaster or some other OSS driver?

Regards,
Pavel Roskin

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

[PATCH] few fixes for ymf_sb.c in test13pre3-ac3

[Pavel Roskin]

Hello, Alan!

Thank you for applying my patch to test13pre3-ac3!

However, there is a glaring bug in drivers/sound/Config.in -
CONFIG_SOUND_YMFPCI is declared twice - once outside CONFIG_OSS, then
inside CONFIG_OSS. I'm removing the later declaration.

CONFIG_SOUND_YMPCI should be disabled if the native driver is compiled
into the kernel. I'm fixing it as well.

Also I tried ymf_sb.c without SUPPORT_UART401_MIDI defined (you have to
edit ymf_sb.c to undefine it). I noticed that the "soundcore"  module
would remain in memory with usage count 1 after inserting and removing
"ymf_sb".

It appears that ymf_sb.c should never call sb_dsp_unload with the second
argument being 1 (unload_mpu). It's a 1-byte fix. I decided not to change
the signature of ymf7xxsb_unload_sb for now.

The patch is also available here:
http://www.red-bean.com/~proski/ymf/ymf_sb.patch

P.S. The patch has been tested. My system is running test13pre3-ac3 and
playing nice music :-)

Regards,
Pavel Roskin


--- linux.orig/drivers/sound/Config.in
+++ linux/drivers/sound/Config.in
@@ -145,9 +145,8 @@
dep_tristate 'Yamaha FM synthesizer (YM3812/OPL-3) support' 
CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 
$CONFIG_SOUND_OSS
dep_tristate 'Yamaha OPL3-SA2, SA3, and SAx based PnP cards' 
CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
-   dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI 
$CONFIG_SOUND_OSS $CONFIG_PCI
-   if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then
-  dep_tristate 'Yamaha YMF7xx PCI audio (native mode) (EXPERIMENTAL)' 
CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS $CONFIG_PCI $CONFIG_EXPERIMENTAL
+   if [ "$CONFIG_SOUND_YMFPCI" != "y" ]; then
+ dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI 
+$CONFIG_SOUND_OSS $CONFIG_PCI
fi
dep_tristate '6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS

--- linux.orig/drivers/sound/ymf_sb.c
+++ linux/drivers/sound/ymf_sb.c
@@ -836,7 +836,7 @@
ymf7xxsb_unload_sb (&sb_data[i], 0);
ymf7xxsb_unload_midi (&mpu_data[i]);
 #else
-   ymf7xxsb_unload_sb (&sb_data[i], 1);
+   ymf7xxsb_unload_sb (&sb_data[i], 0);
 #endif
}




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

[PATCH] CONFIG_MOUSE should not be tristate

[Pavel Roskin]

Hello!

CONFIG_MOUSE only enables further questions. It is never used except
drivers/char/Config.in where it's checked for being "n".

CONFIG_MOUSE=m makes no sence.

The patch is against 2.4.0-test13-pre4.

___
--- linux.orig/drivers/char/Config.in
+++ linux/drivers/char/Config.in
@@ -95,7 +95,7 @@
fi
 fi

-tristate 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
+bool 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
 if [ "$CONFIG_MOUSE" != "n" ]; then
bool '  PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
tristate '  C&T 82C710 mouse port support (as on TI Travelmate)' 
CONFIG_82C710_MOUSE
___

Regards,
Pavel Roskin

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

KERN_ERR for missing codecs?

[Pavel Roskin]

Hello!

The following piece of code from drivers/sound/ac97_codec.c would print a
kernel error message:

if ((audio = codec->codec_read(codec, AC97_RESET)) & 0x8000) {
printk(KERN_ERR "ac97_codec: %s ac97 codec not present\n",
   codec->id ? "Secondary" : "Primary");
return 0;
}

I believe that the kernel should not worry _so_ much about things that
don't exist on the system. KERN_ERR is normally used for really serious
problem.

Probably this error indicates that the driver of a particular card expects
more codecs than there are. But it's a issue of that driver - some of them
may refuse to load, some of them may print error messages. It depends on
what that driver expects.

I suggest removing that printk - the sound card drivers that care about
codecs already print appropriate messages (maestro3.c, via82cxxx_audio.c).
Some drivers that don't care (trident.c, ymfpci.c) because they are
probing more than one codec.

Or at least that KERN_ERR could be downgraded to KERN_WARNING.

Regards,
Pavel Roskin

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

Trident sound driver - global registers not restored

[Pavel Roskin]

Hello!

The driver for Trident sound cards in 2.4.2-ac20 has functions
ali_save_regs() and ali_restore_regs() that are supposed to save and
restore the hardware registers over the power management events.

ali_restore_regs() restores mixer and channel registers from memory, but
it _saves_ the global registers instead of restoring them:

ali_registers.global_regs[i] = inl(TRID_REG(card, i*4));

It must be an error (most likely a result of cut-and-paste).

Regards,
Pavel Roskin

-
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.2-ac23 compile error on i686

[Pavel Roskin]

Hello!

2.4.2-ac23 doesn't compile in arch/i386/kernel/setup.c. Somebody has
changed CONFIG_TSC to CONFIG_X86_TSC, probably without testing the
resulting code.

CONFIG_TSC was never defined, so it was an error. However, what we have
now is that tsc_disable is declared if CONFIG_X86_TSC is not defined, but
is used if it is defined.

I think we should be a little more consistent here. Possible solutions:

1) "notsc" should be enabled in the kernels for old processors the the
case if they run on a better processor and the user may need to disable
TSC (ifndef CONFIG_X86_TSC everywhere in setup.c)

2) "notsc" should be enabled in the kernels for the new processors. It
would save few bytes in the kernels for i386, but the code for i686 will
function even if "notsc" is used (ifdef CONFIG_X86_TSC everywhere in
setup.c)

3) Remove all those silly if[n]defs. We have the "cpu_has_tsc"  variable
on all platforms. clear_bit() and set_in_cr4() are already used on all
processors. It should be safe.

Regards,
Pavel Roskin

-
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] Support for "mode" parameter in ramfs

[Pavel Roskin]

Hello!

This patch adds support for the "mode" parameter in ramfs. This parameter
only affects one inode - the top-level directory (since you can specify
mode in open() and mkdir() for everything else) and thus eliminates the
race condition between "mount" and "chmod" by eliminating the need to use
"chmod".

Like other filesystems, the "mode" is parsed as an octal number.

It is now possible to put the following line in /etc/fstab:

none  /tmp ramfs mode=1777 0 0

but please make sure that untrusted users cannot kill your system by
creating huge files in /tmp!

The patch is also available online at
http://www.red-bean.com/~proski/linux/root_mode.diff

Regards,
Pavel Roskin

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

Weird hidden /dev/audio on devfs

[Pavel Roskin]

Hello!

I'm using 2.4.0-ac11 with devfs support. Something is very strange in the
way how devfs behaves with respect to OSS sound drivers.

devfsd version 1.3.10 is running. There is an entry "alias /dev/audio
/dev/sound" in modules.devfs, which is the default.

If the "sound" module is not loaded, there are no files named "audio"
under /dev:

[proski@fonzie /dev]$ ls -al audio
ls: audio: No such file or directory
[proski@fonzie /dev]$ ls -alR | grep audio
[proski@fonzie /dev]$

Now I load sound.o and strange things begin:

[proski@fonzie /dev]$ ls -al audio
lr-xr-xr-x1 root root   11 Jan 24 18:08 audio ->
sound/audio
[proski@fonzie /dev]$ ls -alR | grep audio
crw-rw--w-1 root root  14,   4 Dec 31  1969 audio
[proski@fonzie /dev]$

/dev/audio exists when named explicitly, but otherwise only
/dev/sound/audio can be found.

No sound-card specific modules are loaded at this point:

[proski@fonzie /dev]$ /sbin/lsmod
Module  Size  Used by
sound  60880   0 (unused)
soundcore   4240   2 [sound]
mga95424   1
agpgart14080   3
floppy 46384   0 (autoclean)
[proski@fonzie /dev]$

All relevant config files are here:
http://www.red-bean.com/~proski/sound_devfs/

Regards,
Pavel Roskin

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

[PATCH] Cleaner SNDCTL_DSP_SETFRAGMENT for ymfpci

[Pavel Roskin]

Hello!

The implementation of SNDCTL_DSP_SETFRAGMENT in ymfpci.c is too hacky (as
of 2.4.1-ac3). The comment says that it was done for Doom only.

The attached patch makes the implementation of SNDCTL_DSP_SETFRAGMENT
similar to those of other cards (the code from cmpci.c was used).

The patch has been tested. Abuse (my favorite linux game) produces
absolutely normal sounds. Actually, it did before. It would be nice to
test this code with something else. Does anybody have a test program?

However, it has been verified that the code in question is actually
executed when Abuse is run.

The patch is also available here:
http://www.red-bean.com/~proski/ymf/ymf_setfrag.diff

Regards,
Pavel Roskin


--- linux.orig/drivers/sound/ymfpci.c
+++ linux/drivers/sound/ymfpci.c
@@ -1718,21 +1718,15 @@
case SNDCTL_DSP_SETFRAGMENT:
if (get_user(val, (int *)arg))
return -EFAULT;
-   /* P3: these frags are for Doom. Amasingly, it sets [2,2**11]. */
-   /* P3 */ // printk("ymfpci: ioctl SNDCTL_DSP_SETFRAGMENT 0x%x\n", val);
-
dmabuf = &state->wpcm.dmabuf;
dmabuf->ossfragshift = val & 0x;
dmabuf->ossmaxfrags = (val >> 16) & 0x;
-   switch (dmabuf->ossmaxfrags) {
-   case 1:
-   dmabuf->ossfragshift = 12;
-   return 0;
-   default:
-   /* Fragments must be 2K long */
-   dmabuf->ossfragshift = 11;
-   dmabuf->ossmaxfrags = 2;
-   }
+   if (dmabuf->ossfragshift < 4)
+   dmabuf->ossfragshift = 4;
+   if (dmabuf->ossfragshift > 15)
+   dmabuf->ossfragshift = 15;
+   if (dmabuf->ossmaxfrags < 4)
+   dmabuf->ossmaxfrags = 4;
return 0;

case SNDCTL_DSP_GETOSPACE:



-
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: VIA/PDC/Athlon

[Pavel Roskin]

Hi, Steven!

> Ehm, "lspci" and "setpci" is part of the pci-utils package (at least on RedHat)
> and is used to dump/modify PCI configuration space (/proc/bus/pci). If you know
> how to use these tools to dump PNP bios, please tell us.

Sorry, of course I meant "lspnp" and "setpnp" from pcmcia-cs.

-- 
Regards,
Pavel Roskin

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

AT keyboard optional on i386?

[Pavel Roskin]

Hello!

I'm trying to run Linux on a broken motherboard that is constantly
producing random noice on the AT keyboard port. I'm going to use a USB
keyboard, but I cannot get Linux to ignore the AT keyboard port.

Is there any way to disable the AT keyboard? I think the best solution
would be to make it optional, just like almost everything in the kernel,
e.g. PS/2 mouse. Some embedded i386 systems could save a few kilobytes of
RAM by disabling the AT keyboard.

It looks like that other architectures (arm and mips) already have an
option CONFIG_PC_KEYB exactly for that. However, it's a dependent variable
- it's set based on the machine type.

Does anybody have a patch for making AT keyboard optional on i386 or
should I make it myself?

-- 
Regards,
Pavel Roskin

-
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: AT keyboard optional on i386?

[Pavel Roskin]

Hi, James!

> So as you can see even USB keyboards depend on pc_keyb.c. So their is
> no way around this.

Perhaps redefining kbd_read_input() will help. It's cruel, I know :-)

> You can a few nice tricks with it like plug in two PS/2 keyboards. I
> have this for my home setup. The only thing is make sure you don't
> have both keyboards plugged in when you turn your PC on. I found BIOS
> get confused by two PS/2 keyboards. As you can it is very easy to
> multiplex many keyboards with the above design. I have had 4 different
> keyboards hooked up to my system and functioning at the same time. We
> even got a Sun keyboard to work on a intel box :-)

That's what we like Linux for. It doesn't get confused when everything
else does :-)

Thanks for your very interesting reply.

-- 
Regards,
Pavel Roskin

-
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] for Matrox FB config help

[Pavel Roskin]

Hello!

This patch moves the sentence about multihead support where it belongs,
i.e. to CONFIG_FB_MATROX_MULTIHEAD, and removes it where it's meaningless,
i.e. from CONFIG_FB_MATROX_MAVEN and CONFIG_FB_MATROX_G450.

The patch is against 2.4.5-ac5.


--- linux.orig/Documentation/Configure.help
+++ linux/Documentation/Configure.help
@@ -3503,9 +3503,6 @@
   too. You can use only some font widths, as the driver uses generic
   painting procedures (the secondary head does not use acceleration
   engine).
-
-  There is no need for enabling 'Matrox multihead support' if you have
-  only one Matrox card in the box.

 Matrox G450 second head support
 CONFIG_FB_MATROX_G450
@@ -3528,9 +3525,6 @@
   painting procedures (the secondary head does not use acceleration
   engine).

-  There is no need for enabling 'Matrox multihead support' if you have
-  only one Matrox card in the box.
-
 Matrox unified driver multihead support
 CONFIG_FB_MATROX_MULTIHEAD
   Say Y here if you have more than one (supported) Matrox device in
@@ -3545,6 +3539,9 @@
   with insmod, supplying the parameter "dev=N" where N is 0, 1, etc.
   for the different Matrox devices. This method is slightly faster but
   uses 40 KB of kernel memory per Matrox card.
+
+  There is no need for enabling 'Matrox multihead support' if you have
+  only one Matrox card in the box.

 MDA text console (dual-headed)
 CONFIG_MDA_CONSOLE
________

-- 
Regards,
Pavel Roskin

-
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.5-ac5 locks on ReiserFS umount (ac4 doesn't)

[Pavel Roskin]

Hello!

I'm using ReiserFS in the kernel, not as a module. My root filesystem is
ReiserFS. I mounted another ReiserFS partition and then tried to unmount
it. umount hung. sync hung. shutdown hung.

Both umount and sync were shown in the "D" state on Ctrl-ScrollLock.

I reverted to 2.4.5-ac4 and could not reproduce the problem. I saw a
suggestion that it may have to do with module unloading, but in my case
reiserfs is not a module.

Full config file if here:
http://www.red-bean.com/~proski/linux/config

-- 
Regards,
Pavel Roskin

-
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.4.5-ac5 locks on ReiserFS umount (ac4 doesn't)

[Pavel Roskin]

Hi, Ken!

> Try -ac6, this issue was discussed in depth on the list yesterday and
> rehashed twice already today.  Check the archives.

Too bad that the changelog for -ac6 doesn't mention reiserfs, so I didn't
bother trying it.

Another problem is that the archive at
http://www.uwsg.indiana.edu/hypermail/linux/kernel/ updates only once a
day. I checked it and decided that my information could still be useful.

I'd be grateful if somebody pointed me to a better archive.

-- 
Regards,
Pavel Roskin

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

CONFIG_X86_UP_APIC undocumented

[Pavel Roskin]

Hello, Eric!

For some reason CONFIG_X86_UP_APIC doesn't appear in your list of
undocumented symbols. You may need to adjust your checker. It is used in
2.4.5-ac7 kernel in arch/i386/config.in:

bool 'APIC support on uniprocessors' CONFIG_X86_UP_APIC

The entry for CONFIG_X86_UP_IOAPIC seems to talk both about APIC and
IO-APIC. Maybe it just needs splitting. But I'm leaving it to somebody
more competent in the matter.

It would also be nice to have some info about the difference between APIC
and IO-APIC and why only the former works on uniprocessor VIA boards.

-- 
Regards,
Pavel Roskin

-
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.5-ac7 usb-uhci appears twice in /proc/interrupts

[Pavel Roskin]

Hello!

I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed
twice on the same IRQ 9.

# cat /proc/interrupts
   CPU0
  0:  82287  XT-PIC  timer
  1:   2624  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  8:  1  XT-PIC  rtc
  9:  0  XT-PIC  usb-uhci, usb-uhci
 10:781  XT-PIC  eth0
 11:  0  XT-PIC  eth1
 12:900  XT-PIC  PS/2 Mouse
 14:  17434  XT-PIC  ide0
 15:  9  XT-PIC  ide1
NMI:  0
LOC:  82250
ERR: 15

.config is here: http://www.red-bean.com/~proski/linux/config

In short, all USB stuff is compiled as modules.

# CONFIG_USB_UHCI is not set
CONFIG_USB_UHCI_ALT=m
# CONFIG_USB_OHCI is not set

It's a brand new VIA motherboard, so I don't know whether the problem
existed in the earlier kernels or not (if it's a problem).

It looks like that the motherboard has two USB controllers:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 
20)
00:08.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang]
00:09.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)

-- 
Regards,
Pavel Roskin

-
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] USB Scanner devfs support

[Pavel Roskin]

Hello!

I've made a patch for devfs support in USB scanners (against 2.4.5-ac9).
It can be found here:

http://www.red-bean.com/~proski/linux/scanner-devfs.diff

The patch is quite straightforward. The necessary changes have been taken
from usb-skeleton.c and verified against printer.c.

The scanner names will be /dev/usb/scanner0 ... /dev/usb/scanner15 in full
accordance will Documentation/devices.txt.

For some reason private structures of the driver are kept in scanner.h,
but it's only included by scanner.c, so please don't worry about changes
in the headers. Ideally, most (all?) stuff from scanner.h should be moved
into scanner.c, but I don't want to mix two patches.

The patch has been tested with ScanPrisa 640U.

The patch is below my signature as well as at
http://www.red-bean.com/~proski/linux/scanner-devfs.diff

-- 
Regards,
Pavel Roskin


-
--- linux.orig/drivers/usb/scanner.c
+++ linux/drivers/usb/scanner.c
@@ -263,6 +263,13 @@
  */
 #include "scanner.h"

+/* the global usb devfs handle */
+extern devfs_handle_t usb_devfs_handle;
+
+/* Forward declarations */
+static struct
+file_operations usb_scanner_fops;
+

 static void
 irq_scanner(struct urb *urb)
@@ -363,6 +370,8 @@ close_scanner(struct inode * inode, stru

scn = p_scn_table[scn_minor];

+   devfs_unregister(scn->devfs);
+
scn->isopen = 0;

file->private_data = NULL;
@@ -594,6 +603,7 @@ probe_scanner(struct usb_device *dev, un

char valid_device = 0;
char have_bulk_in, have_bulk_out, have_intr;
+   char name[12];

if (vendor != -1 && product != -1) {
info("probe_scanner: User specified USB scanner -- Vendor:Product - 
%x:%x", vendor, product);
@@ -813,6 +823,17 @@ probe_scanner(struct usb_device *dev, un

init_MUTEX(&(scn->gen_lock));

+   sprintf(name, "scanner%d", scn_minor);
+
+   /* Create with perms=664 */
+   scn->devfs = devfs_register(usb_devfs_handle, name,
+   DEVFS_FL_DEFAULT, USB_MAJOR,
+   SCN_BASE_MNR + scn_minor,
+   S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP |
+   S_IWGRP, &usb_scanner_fops, NULL);
+   if (scn->devfs == NULL)
+   err("scanner%d: device node registration failed", scn_minor);
+
return p_scn_table[scn_minor] = scn;
 }

@@ -830,6 +851,8 @@ disconnect_scanner(struct usb_device *de

kfree(scn->ibuf);
kfree(scn->obuf);
+
+   devfs_unregister(scn->devfs);

dbg("disconnect_scanner: De-allocating minor:%d", scn->scn_minor);
p_scn_table[scn->scn_minor] = NULL;
--- linux.orig/drivers/usb/scanner.h
+++ linux/drivers/usb/scanner.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 

 // #define DEBUG

@@ -169,6 +170,7 @@

 struct scn_usb_data {
struct usb_device *scn_dev;
+   devfs_handle_t devfs;   /* devfs device */
struct urb scn_irq;
unsigned int ifnum; /* Interface number of the USB device */
kdev_t scn_minor;   /* Scanner minor - used in disconnect() */
-

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

DoS using tmpfs

[Pavel Roskin]

Hello!

It appears that a system with tmpfs mounted with the default (!!!)
parameters can be used by ordinary users to make the system
non-functional.

Let me tell you the whole story. I don't know what is wrong here and what
is not, but the end result is a security hole.

The kernel version is 2.4.5-ac9. It's compiled with gcc from RedHat 7.1.
The processor is Pentium III 550 MHz. Alt-Sysrq is enabled - we'll need it
later.

# mount
/dev/ide/host2/bus0/target0/lun0/part4 on / type reiserfs (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
devfs on /dev type devfs (rw)
none on /tmp type tmpfs (rw,mode=1777)
none on /dev/shm type shm (rw)

Note the "mode=1777" is not required - it's the default. I put is here
just in case if the default changes.

# df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/ide/host2/bus0/target0/lun0/part4
   5124540   3510036   1614504  69% /
none277728 0277728   0% /tmp
none277728 0277728   0% /dev/shm

# free
 total   used   free sharedbuffers cached
Mem:255948  97520 158428  0  14880  68172
-/+ buffers/cache:  14468 241480
Swap:   104380  0 104380

Note that my swap file is just 100M compared to 256M memory, but I never
run anything bigger than Mozilla, so even 350M virtual memory is more than
enough for me.

Now I log in on tty2 as user.

$ dd if=/dev/zero of=/tmp/foo

If a few seconds I'm pressing Ctrl-C - it doesn't work. Alt-F1 works. I
type df as root, press enter and it hangs. I'm hitting Ctrl-C in vain. Now
I press Alt-F2 - it works. I'm trying the last resort - Alt-Sysrq-K. It
works, the login appears.

Now let's see what we have.

# df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/ide/host2/bus0/target0/lun0/part4
   5124540   3510044   1614496  69% /
none177124159968 17156  91% /tmp
none 17156 0 17156   0% /dev/shm

There is still free space in /tmp, but ...

# free
 total   used   free sharedbuffers cached
Mem:255948 253680   2268  55588  14880 171280
-/+ buffers/cache:  67520 188428
Swap:   104380 104380  0

... the swap is exhausted, and so it the memory. Now let's remove /tmp/foo
and see what happens.

# df
Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/ide/host2/bus0/target0/lun0/part4
   5124540   3510044   1614496  69% /
none 72340 0 72340   0% /tmp
none 72340 0 72340   0% /dev/shm

The free space didn't rebound to it's initial value, and here's why:

# free
 total   used   free sharedbuffers cached
Mem:255948 198492  57456  0  14880 171284
-/+ buffers/cache:  12328 243620
Swap:   104380 104380  0

The memory is freed, but the swap is still full!

Running "swapoff -a" followed by "swapon -a" brings the system to the sane
state.

Now let me stress some points where the kernel is _possibly_ at fault.

1) tmpfs, as opposed to ramfs doesn't limit the usage by default. It's not
a good default for a filesystem designed for temporary files.

2) Not delivering SIGINT to processes is probably not the best behavior if
the memory if low. However, one could argue that some processes would use
even more resources if they get control with SIGINT.

3) All swap in the system was exhausted and yet tmpfs didn't return ENOSPC
to "dd".

4) The swap wasn't freed. Yes, I know, it's not a new problem.

I don't really know much about OS design and VM in particular, but I was
bitten by this behavior, so I desided to report it. If you cannot find
anything useful in this message, I'm sorry for your time. "IMHO" applies
to all statements made in this message.

-- 
Regards,
Pavel Roskin

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

Major breakage in linux-git on x86_64, oom killer goes on rampage

[Pavel Roskin]

Hello!

This fix breaks x64_64:

commit f33ea7f404e592e4563b12101b7a4d17da6558d7 
tree 1d587ad8a06cb6d2e3a187f0312c8a524ffefe53 
parent 5cb4cc0d8211c490537c8568001958fc76741312 
author Nick Piggin <[EMAIL PROTECTED]> Wed, 03 Aug 2005 20:24:01
+1000 
committer Linus Torvalds <[EMAIL PROTECTED]> Wed, 03 Aug 2005
09:12:05 -0700 

* include/linux/mm.h, mm/memory.c:

[PATCH] fix get_user_pages bug
...

The system doesn't boot.  Most processes are killed by VM.

The patch does more than it claims.  It actually redefines VM_FAULT_OOM
and VM_FAULT_SIGBUS.  Unfortunately, a quick look at
arch/x86_64/mm/fault.c shows that the return value of handle_mm_fault()
is compared with numerical constants.  This patch helps partly:

--- arch/x86_64/mm/fault.c
+++ arch/x86_64/mm/fault.c
@@ -439,15 +439,15 @@ good_area:
 * the fault.
 */
switch (handle_mm_fault(mm, vma, address, write)) {
-   case 1:
+   case VM_FAULT_MINOR:
tsk->min_flt++;
break;
-   case 2:
+   case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
-   case 0:
+   case VM_FAULT_SIGBUS:
goto do_sigbus;
-   default:
+   case VM_FAULT_OOM:
goto out_of_memory;
}
 
Now the system boot goes a little further and then the kernel reports a
BUG in mm/memory.c:985.  Apparently __handle_mm_fault() returns
something unexpected.  My guess is that some x86_64 specific functions
return -1 and 0 when they mean VM_FAULT_SIGBUS and VM_FAULT_OOM.
Returning -1 would trigger BUG(), returning 0 would be treated as
VM_FAULT_OOM rather than VM_FAULT_SIGBUS.

I'm not sure I'll be able to fix it quickly, but I hope the gurus will
beat me at that.  In the meantime, please don't make any releases unless
the "commit f33ea7f404e592e4563b12101b7a4d17da6558d7" is reverted.

-- 
Regards,
Pavel Roskin

-
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 1/2] Re: Major breakage in linux-git on x86_64, oom killer goes on rampage

[Pavel Roskin]

Hello again,

here's the solution.  The x86_64 specific portion will be posted as a
separate patch.

> Now the system boot goes a little further and then the kernel reports a
> BUG in mm/memory.c:985.  Apparently __handle_mm_fault() returns
> something unexpected.

I'm getting a BUG in mm/memory.c:985.  The unexpected value is 18 or
VM_FAULT_MINOR|VM_FAULT_WRITE.  As it turns out, __handle_mm_fault()
never returns VM_FAULT_WRITE, but in combination with VM_FAULT_MINOR.
Apparently, that's what was meant, and the fallthrough to case
VM_FAULT_MINOR is an indication of that.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>

diff --git a/mm/memory.c b/mm/memory.c
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -963,7 +963,7 @@ int get_user_pages(struct task_struct *t
spin_unlock(&mm->page_table_lock);
switch (__handle_mm_fault(mm, vma, start,
write_access)) {
-   case VM_FAULT_WRITE:
+   case VM_FAULT_WRITE|VM_FAULT_MINOR:
/*
 * do_wp_page has broken COW when
 * necessary, even if maybe_mkwrite

-- 
Regards,
Pavel Roskin

-
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/2] Re: Major breakage in linux-git on x86_64, oom killer goes on rampage

[Pavel Roskin]

Here's the x86_64 specific part.

The return value of handle_mm_fault() should be compared with symbolic
constants, not numbers.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>

diff --git a/arch/x86_64/mm/fault.c b/arch/x86_64/mm/fault.c
--- a/arch/x86_64/mm/fault.c
+++ b/arch/x86_64/mm/fault.c
@@ -439,15 +439,15 @@ good_area:
 * the fault.
 */
switch (handle_mm_fault(mm, vma, address, write)) {
-   case 1:
+   case VM_FAULT_MINOR:
tsk->min_flt++;
break;
-   case 2:
+   case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
-   case 0:
+   case VM_FAULT_SIGBUS:
goto do_sigbus;
-   default:
+   case VM_FAULT_OOM:
goto out_of_memory;
}
 

-- 
Regards,
Pavel Roskin

-
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: Replacement for page fault notifiers?

[Pavel Roskin]

On Wed, 2008-01-09 at 11:26 +1100, Benjamin Herrenschmidt wrote:
> > Christoph,
> > 
> > it is generic code, it works by patching the module you load and is in
> > no way nvidia specific, I think we should revert your chance
> > as the notifiers have a valid user and one it has been planned to upstream..
> 
> Agreed, it looks like a sane enough user of page fault notifiers, it's
> going to be upstream, and it's useful to fight evil binary drivers so
> that sounds like a good justification to bring those back in :-)

The fault notifiers are used in a special version of MadWifi (Atheros
wireless driver with some non-free parts) to figure out which registers
are being accessed.  The tracing capability has been essential for the
development of the free replacement, ath5k.

Considering that ath5k is being developed in the kernel tree, whereas
madwifi-trace needs 2.6.23, one needs different kernels for tracing and
development.  Lifting this requirement would be a time saver for the the
developers of ath5k.  And once 2.6.24 is released, ath5k developers will
be in the position to ask users to downgrade their kernels to get traces
for their cards.  That's something I'd like to avoid.

I looked at ways to implement the page fault handler using kprobes, but
I could not find a simple solution.  The problem is that kprobes uses
the fault notifier for its own needs.  I'm still hopeful that somebody
with a better understanding of kprobes will be able to implement fault
notification without patching the kernel.  But if no such solution is
found, I would also support reverting the patch that removed fault
notifiers on i386.

-- 
Regards,
Pavel Roskin
--
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: Replacement for page fault notifiers?

[Pavel Roskin]

On Thu, 2008-01-10 at 06:58 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-01-09 at 18:21 +, Christoph Hellwig wrote:
> > On Wed, Jan 09, 2008 at 01:18:44PM -0500, Pavel Roskin wrote:
> > > notification without patching the kernel.  But if no such solution is
> > > found, I would also support reverting the patch that removed fault
> > > notifiers on i386.
> > 
> > With your fixation on not patching the kernel you sound like a windows
> > developer.

I just assumed (wrongly, as it seems) that the API change didn't remove
any useful functionality.

Also, I don't want to ask users with unusual hardware to patch their
kernels to take the trace.

> > There is no problem with patching the kernel, but the best
> > patching of that kernel is that which happens upstream so please folks
> > start submitting an mmiotrace variant for kernel inclusion.

The problem is that mmiotrace only makes sense in combination with
non-free drivers, and I'm not sure it would be welcome in the kernel
even if you say so.

The hooks for page faults could be useful for something (debugging, some
non-traditional swap implementations), but I don't want to invent
reasons why somebody else might need them.

> > Then again I don't quite get why you absolutely want to track pagefaults
> > anyway.  Just hooking into ioremap and read*/write* and iomap +
> > ioread*/iowrite* would be much easier and also a lot faster.  It would
> > also allow adding a nice sysfs attribute to enable this per-device.
> 
> Because binary drivers don't use ioread/iowrite/readX/writeX (or if they
> do, they've long been inlined in the blob). The only solution is to map
> things as non-accessible and trap the page faults.

Exactly.  In MadWifi, they are inlined on i386 and x86_64, and I cannot
ask every user with an unsupported card to get a Mac.

> It's a sane thing to do, Christoph, I don't think it's a unreasonable
> request to put the hooks back in.

Seconded.

-- 
Regards,
Pavel Roskin
--
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: Replacement for page fault notifiers?

[Pavel Roskin]

On Wed, 2008-01-09 at 20:26 +, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 03:24:16PM -0500, Pavel Roskin wrote:
> > I just assumed (wrongly, as it seems) that the API change didn't remove
> > any useful functionality.
> 
> No, this was exactly the correct assumption.  Out of tree modules simply
> don't count.
> 
> > The problem is that mmiotrace only makes sense in combination with
> > non-free drivers, and I'm not sure it would be welcome in the kernel
> > even if you say so.
> 
> It can trace every driver in theory although it's of course not
> really interesting for free drivers.  But it's not actually
> functionality used by the drivers but functionlity to trace the drivers
> so it's quite different anyway.

OK, that's reassuring.  Maybe it could be used for profiling or to find
bugs that are not obvious otherwise.

-- 
Regards,
Pavel Roskin
--
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: Replacement for page fault notifiers?

[Pavel Roskin]

On Wed, 2008-01-09 at 20:03 -0600, Matt Mackall wrote:

> That makes it way too easy for drivers of questionable legality to just
> clear that bit. Also, we've got a shortage of page bits, etc.

If we ever have this problem, the bit can be changed in the kernel to
fool those drivers (I hope the shortage is not so dire that there will
be no more bits left).

I don't think evil drivers should be a problem per se.  There are
existing non-free drivers that still need to be traced over and over
again.  I guess ndiswrapper could use tracing for Windows drivers that
don't know anything about Linux page flags.

Last but not least, mmiotrace should be useful for free drivers in the
first place to have a legitimate reason to be in the kernel.

-- 
Regards,
Pavel Roskin
--
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: idio{,ma}tic typos (was Re: + fix-vm_can_nonlinear-check-in-sys_remap_file_pages.patch added to -mm tree)

[Pavel Roskin]

On Wed, 2007-10-10 at 11:08 -0700, Josh Triplett wrote:

> Sparse has a notion of "integer constant expression" already, which it
> uses to validate expressions used for things like bitfield widths or
> array sizes.  I could easily have Sparse warn on any use of an integer
> constant expression as an operand of || or &&.  However, I can imagine
> that that might lead to some false positives when intentionally using
> an integer constant expression in a condition and expecting the
> compiler to optimize it out at compile time.

I can imagine 0 or 1 being used, maybe -1, but hardly anything else.
Maybe you could add the code printing the value and then get some
statics on the actual Linux kernel to see which values are common and
which are not?

-- 
Regards,
Pavel Roskin

-
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] drivers/net/: Spelling fixes

[Pavel Roskin]

On Mon, 2007-12-17 at 11:40 -0800, Joe Perches wrote:
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>

> diff --git a/drivers/net/wireless/orinoco.h
> b/drivers/net/wireless/orinoco.h
> index 4720fb2..703a4cf 100644
> --- a/drivers/net/wireless/orinoco.h
> +++ b/drivers/net/wireless/orinoco.h
> @@ -108,7 +108,7 @@ struct orinoco_private {
>   int scan_inprogress;/* Scan pending... */
>   u32 scan_mode;  /* Type of scan done */
>   char *  scan_result;/* Result of previous scan */
> - int scan_len;   /* Lenght of result */
> + int scan_len;   /* Length of result */
>  };
>  
>  #ifdef ORINOCO_DEBUG

Acked-by: Pavel Roskin <[EMAIL PROTECTED]>

Actually, I don't think such minor comment fixes need to be reviewed by
the maintainers.  Thanks anyway.

-- 
Regards,
Pavel Roskin
--
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/

ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

Hello!

It have come to my attention that a patch has been committed to the
kernel with the explicit purpose of tainting ndiswrapper - the kernel
module allowing Windows NDIS drivers for Ethernet and Wireless cards to
be used by the kernel.

That's the commit in question:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9

It is not the first time it has happened.  The same was done in October
2006.  A heated discussion ensued, and the patch was reverted as
erroneous.  For those wishing to refresh their memories, this LWN story
would be a great starting point:

http://lwn.net/Articles/205644/

I'd like to see this mistake to be fixed without lengthy arguments this
time around.

Just to reiterate some points from the old discussion:

- ndiswrapper is licensed under GPL

- ndiswrapper needs GPL-only symbols

- tainting ndiswrapper denies its access to GPL-only symbols

- denying ndiswrapper access to GPL-only symbols is unfair and not based
on any copyright law

- denying ndiswrapper access to GPL-only symbols makes it impossible for
ndiswrapper to function

- no copyright violation is involved, as Windows drivers are not derived
from Linux sources

- Windows drivers don't call GPL-only symbols directly; ndiswrapper
stands in the middle and sanitizes the access

- it's a fair game to taint the kernel in some way if ndiswrapper has
been loaded at some point, since tainting per se is just an indicator
that the kernel has been used in an unsupportable way

- if this change stands, ndiswrapper will be renamed, which would only
create more confusion and would thus defeat the purpose of tainting

- ndiswrapper is used by kernel developers to create native drivers

- ndiswrapper is a stepping stone towards a completely free OS; take it
away and see less users, less testers and less reverse engineering
efforts

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Tue, 2008-01-29 at 17:27 -0500, [EMAIL PROTECTED] wrote:
> On Tue, 29 Jan 2008 16:22:45 EST, Pavel Roskin said:
> > Hello!
> > 
> > It have come to my attention that a patch has been committed to the
> > kernel with the explicit purpose of tainting ndiswrapper - the kernel
> > module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> > be used by the kernel.
> 
> At some point, a compromise position of "Have ndiswrapper do the tainting
> if it loads something with contentious licensing" was suggested - whatever
> happened to that?
> 
> (If for no other reason than if you load ndiswrapper for testing, and then
> do *not* actually load something, your kernel should remain untainted...)

We should distinguish kernel tainting and module tainting.  Kernel
tainting affects the stack dumps.  Module tainting affects access to
GPL-only symbols.

Kernel tainting for "ndiswrapper" is in the code already.  The patch I'm
complaining about is replacing kernel tainting with both kinds of
tainting.

Of course, ndiswrapper could taint itself as a module, but it would be a
purely symbolic act, since the module would be loaded already, and the
GPL-only symbols resolved.

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Wed, 2008-01-30 at 00:57 +0200, Adrian Bunk wrote:
> On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> > Hello!
> > 
> > It have come to my attention that a patch has been committed to the
> > kernel with the explicit purpose of tainting ndiswrapper - the kernel
> > module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> > be used by the kernel.
> >...
> > Just to reiterate some points from the old discussion:
> >...
> > - no copyright violation is involved, as Windows drivers are not derived
> > from Linux sources
> >...
> 
> It is interesting that someone posting with an @gnu.org address claims
> that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> not a copyright violation.

No, I'm representing myself only.  I don't think you represent all
kernel developers when posting from the kernel.org address.

I'm actually surprised that you are raising this issue.  If the
motivation to ban ndiswrapper is based on the copyright law, doesn't it
meant that we have DRM in the kernel now?  Is Linux going to enforce
copyright laws across the world?

> Is it an official statement of the FSF that such linking is considered 
> legal?

Absolutely not.

> (RMS added to Cc)

I, for one, would welcome an informed position of the FSF.  It may have
interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
other programs loading non-free compiled code at the run time.

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Tue, 2008-01-29 at 22:45 +, Alan Cox wrote:
> > - it's a fair game to taint the kernel in some way if ndiswrapper has
> > been loaded at some point, since tainting per se is just an indicator
> > that the kernel has been used in an unsupportable way
> 
> That's all the patch appears to do. Se the taint flag.

There are two taint flags.  Let's see:

if (strcmp(mod->name, "ndiswrapper") == 0)
-   add_taint(TAINT_PROPRIETARY_MODULE);
+   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);

And that's add_taint_module():

static inline void add_taint_module(struct module *mod, unsigned flag)
{
add_taint(flag);
mod->taints |= flag;
}

The module taint is set before the symbols are resolved.  Therefore, the
GPL-only symbols won't be resolved.

> > - if this change stands, ndiswrapper will be renamed, which would only
> > create more confusion and would thus defeat the purpose of tainting
> 
> Not a productive approach. It will only harm support for everyone.

I know.  But ndiswrapper is a maintained program, which is regularly
updated to work with the latest kernels.  If the author fails to make
the necessary updates for the next kernel for whatever reason, somebody
will fork it and make such updates.

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Tue, 2008-01-29 at 19:48 -0500, Jon Masters wrote:
> On Wed, 2008-01-30 at 01:35 +0100, Jan Engelhardt wrote:
> > On Jan 29 2008 19:20, Jon Masters wrote:
> 
> > >Another fix would be for ndiswrapper to explicitly set the taint when it
> > >loads a tainted driver? Or do we just want to go back to globally
> > >"tainting" the kernel without assigning the blame to any module?
> > 
> > I think the global taint flag is always needed because you never know
> > what the proprietary module actually did to our memory. Unloading
> > the driver and ndiswrapper should retain some sort of taintedness
> > should it oops much later.
> 
> It will. The module taint variant also sets the global taint. But it
> helps to know why you set that if you oops now and get a list of
> modules. Yeah, we know about ndiswrapper, I just mean in general.

Then we can move add_taint_module() for ndiswrapper closer to the end of
load_module(), so that it's not prevented from using GPL-only symbols.

driverloader should stay where it is, since we don't trust its license.

> Man, that'll teach me to send one-liners without checking the entire
> history of LWN stories beforehand. I'm going to the gym to escape :)

I'm actually so relieved that it has been mistake, just like it was the
last time.  Good luck!

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Tue, 2008-01-29 at 19:20 -0500, Jon Masters wrote:

> Yes it is. But I thought the existing code was intending to taint the
> kernel (that's what it does), so it would really help to identify why it
> tainted the kernel, by calling add_taint_module instead of add_taint. I
> didn't put the existing match in there...don't shoot the messenger :)

So, it's the same thing as in year 2006.  Good intentions, unexpected
side effects, and a long discussion.

> > - ndiswrapper needs GPL-only symbols
> 
> Another fix would be for ndiswrapper to explicitly set the taint when it
> loads a tainted driver? Or do we just want to go back to globally
> "tainting" the kernel without assigning the blame to any module?

It taints the kernel, but not the module.  I could add tainting the
module to the ndiswrapper code, but it would reply on the internals of
the "struct module".  And I think we really don't want modules tainting
and untainting themselves by changing THIS_MODULE->taints.  It's a
Pandora's box that's better kept closed.

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Wed, 2008-01-30 at 02:25 +0200, Adrian Bunk wrote:

> > > It is interesting that someone posting with an @gnu.org address claims
> > > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > > not a copyright violation.
> > 
> > No, I'm representing myself only.  I don't think you represent all
> > kernel developers when posting from the kernel.org address.
> 
> I'm not using my @kernel.org address except for kernel issues and I'm 
> not using a company address in linux-kernel discussions.
> 
> Mailing lists of a project or a company are something completely 
> different from using a project or company address outside of the 
> project.

OK, I'll think about it.

> > I, for one, would welcome an informed position of the FSF.  It may have
> > interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
> > other programs loading non-free compiled code at the run time.
> 
> Wine is licenced under the terms of the LGPL.
> 
> ReactOS is licenced under the terms of the GPL with a licence 
> exception for runtime linking of non-free modules.
> 
> QEMU is licenced under the terms of the GPL with a licence exception for 
> runtime linking with libqemu.a.
> 
> GNU classpath (and libgcj) are licenced under the terms of the GPL with 
> a licence exception for runtime linking with it.
> 
> As you can see, all of the above explicitely address this issue.
> 
> The only program from your list that has a fishy licencing is mplayer.

Thanks for the detailed analysis!

Anyway, as far as I know, copyright covers copying of works, and dynamic
linking never creates anything suitable for copying.  The "derived work"
stays in memory, just like it does when a proprietary program runs on
top of the Linux kernel.  Memory dumps might be illegal to distribute
though.

I'm not a lawyer and the above is not a legal advice.  I don't represent
Free Software Foundation.

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

On Wed, 2008-01-30 at 05:07 +, Jon Masters wrote:
> *). Add a new taint?
> *). Move it later?
> 
> It's all trivial, but a policy should be established for the future.

I'd prefer a new taint.  It's less likely to break.  It provides more
information in the stack dumps.  It makes it clear the difference
ndiswrapper and driverloader.

Here's the patch:
---

Introduce a new taint flag for ndiswrapper

Although ndiswrapper loads proprietary code, it's under GPL itself.
Introduce a different taint flag for this case, so that ndiswrapper
retains access to GPL-only symbols.

Add comments to show the difference between driverloader and
ndiswrapper.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---

 include/linux/kernel.h |1 +
 kernel/module.c|5 -
 kernel/panic.c |2 ++
 3 files changed, 7 insertions(+), 1 deletions(-)


diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a7283c9..861a6ae 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -240,6 +240,7 @@ extern enum system_states {
 #define TAINT_BAD_PAGE (1<<5)
 #define TAINT_USER (1<<6)
 #define TAINT_DIE  (1<<7)
+#define TAINT_BLOB_WRAPPER (1<<8)
 
 extern void dump_stack(void) __cold;
 
diff --git a/kernel/module.c b/kernel/module.c
index f6a4e72..a64380c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1925,8 +1925,11 @@ static struct module *load_module(void __user *umod,
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
 
+   /* GPL, but may load proprietary code */
if (strcmp(mod->name, "ndiswrapper") == 0)
-   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+   add_taint_module(mod, TAINT_BLOB_WRAPPER);
+
+   /* Wrongly claims to be under GPL */
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
 
diff --git a/kernel/panic.c b/kernel/panic.c
index da4d6ba..b040812 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -152,6 +152,7 @@ EXPORT_SYMBOL(panic);
  *  'M' - System experienced a machine check exception.
  *  'B' - System has hit bad_page.
  *  'U' - Userspace-defined naughtiness.
+ *  'W' - Wrapper for untrusted binary blobs has been loaded.
  *
  * The string is overwritten by the next call to print_taint().
  */
@@ -162,6 +163,7 @@ const char *print_tainted(void)
if (tainted) {
snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c",
tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
+   tainted & TAINT_BLOB_WRAPPER ? 'W' : ' ',
        tainted & TAINT_FORCED_MODULE ? 'F' : ' ',
tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
tainted & TAINT_FORCED_RMMOD ? 'R' : ' ',

-- 
Regards,
Pavel Roskin
--
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: ndiswrapper and GPL-only symbols redux

[Pavel Roskin]

Quoting Andi Kleen <[EMAIL PROTECTED]>:


Pavel Roskin <[EMAIL PROTECTED]> writes:

  */
@@ -162,6 +163,7 @@ const char *print_tainted(void)
if (tainted) {
snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c",
tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
+   tainted & TAINT_BLOB_WRAPPER ? 'W' : ' ',



Are you sure you don't need to add a new '%c' to the format string too?
I think gcc should have warned.


You are right!  Thanks.

--
Regards,
Pavel Roskin
--
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] Move HPET options from top level, enable HPET_TIMER prompt

[Pavel Roskin]

Hello!
"make menuconfig" for x86_64 looks somewhat funky:
[ ] Provide RTC interrupt (NEW)
Code maturity level options  --->
General setup  --->
...
I believe all x86_64 specific options for HPET timer should be moved to 
the "Processor type and features" menu.  That's where they are located for 
i386.  There are two such options - HPET_TIMER and HPET_EMULATE_RTC.

Also, there is no prompt for HPET_TIMER, so it's always set.  However, the 
help text ends with "If unsure, say Y".  Kind of pointless, isn't it?  I 
enabled the prompt and deselected HPET_TIMER.  The kernel compiled and 
booted just fine.  Kernel messages don't indicate that HPET is used, but 
they said so when HPET_TIMER was enabled.

The patch does two things:
- HPET_TIMER and HPET_EMULATE_RTC are moved from the top-level to
  "Processor type and features"
- HPET_TIMER can be deselected (just like on i386)
The patch is against current Linux snapshot (svn revision 26268).
--
Regards,
Pavel RoskinIndex: arch/x86_64/Kconfig
===
--- arch/x86_64/Kconfig (revision 26268)
+++ arch/x86_64/Kconfig (working copy)
@@ -62,23 +62,6 @@
  with klogd/syslogd or the X server. You should normally N here,
  unless you want to debug such a crash.
 
-config HPET_TIMER
-   bool
-   default y
-   help
- Use the IA-PC HPET (High Precision Event Timer) to manage
- time in preference to the PIT and RTC, if a HPET is
- present.  The HPET provides a stable time base on SMP
- systems, unlike the RTC, but it is more expensive to access,
- as it is off-chip.  You can find the HPET spec at
- .
-
- If unsure, say Y.
-
-config HPET_EMULATE_RTC
-   bool "Provide RTC interrupt"
-   depends on HPET_TIMER && RTC=y
-
 config GENERIC_ISA_DMA
bool
default y
@@ -193,6 +176,23 @@
bool
default y
 
+config HPET_TIMER
+   bool "HPET Timer Support"
+   default y
+   help
+ Use the IA-PC HPET (High Precision Event Timer) to manage
+ time in preference to the PIT and RTC, if a HPET is
+ present.  The HPET provides a stable time base on SMP
+ systems, unlike the RTC, but it is more expensive to access,
+ as it is off-chip.  You can find the HPET spec at
+ .
+
+ If unsure, say Y.
+
+config HPET_EMULATE_RTC
+   bool "Provide RTC interrupt"
+   depends on HPET_TIMER && RTC=y
+
 config MTRR
bool "MTRR (Memory Type Range Register) support"
---help---

Please open sysfs symbols to proprietary modules

[Pavel Roskin]

Hello!
I'm writing a module under a proprietary license.  I decided to use sysfs 
to do the configuration.  Unfortunately, all sysfs exports are available 
to GPL modules only because they are exported by EXPORT_SYMBOL_GPL.

I have found the original e-mail where this change was proposed:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.3/0345.html
Patrick writes:
"The users of these functions are all, in most cases, other subsystems, 
which provide a layer of abstraction for the downstream users (drivers, 
etc)."

Maybe it was true in September 2004, but it's not true in February 2005. 
sysfs has become a standard way to make configurable parameters available 
to userspace, just like sysctl and ioctl.

All I want to do is to have a module that would create subdirectories for 
some network interfaces under /sys/class/net/*/, which would contain 
additional parameters for those interfaces.  I'm not creating a new 
subsystem or anything like that.  sysctl is not good because the data is 
interface specific.  ioctl on a socket would be OK, although it wouldn't 
be easily scriptable.  The restriction on sysfs symbols would just force 
me to write a proprietary userspace utility to set those parameters 
instead of using a shell script.

My understanding is that EXPORT_SYMBOL_GPL is only useful for symbols so 
specific to the kernel that the modules that use them would be effectively 
based on GPL code.  But a module providing its internal state to the 
userspace doesn't need to be based on the kernel code in any way.

Please replace every EXPORT_SYMBOL_GPL with EXPORT_SYMBOL in fs/sysfs/*.c
--
Regards,
Pavel Roskin
-
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: Please open sysfs symbols to proprietary modules

[Pavel Roskin]

Hi, Greg and Patrick!
On Wed, 2 Feb 2005, Greg KH wrote:
On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote:
What is wrong with creating a (GPL'd) abstraction layer that exports
symbols to the proprietary modules?
Ick, no!
Please consult with a lawyer before trying this.  I know a lot of them
consider doing this just as forbidden as marking your module
MODULE_LICENSE("GPL"); when it really isn't.
There will be a GPL'd layer, and it's likely that sysfs interaction will 
be on the GPL'd side anyway, for purely technical reasons.  But it does 
feel like circumvention of the limitations set in the kernel.  I thought 
it would be polite to ask the developers to lift those limitations, 
considering that they seem unfair and inconsistent with the stated 
purpose of EXPORT_SYMBOL_GPL.

Sorry for using my gnu.org address.  I'll use my rajant.com address for 
further questions about that project.

--
Regards,
Pavel Roskin
-
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: Please open sysfs symbols to proprietary modules

[Pavel Roskin]

Hi, Joseph!
On Wed, 2 Feb 2005, Joseph Pingenot wrote:
From Pavel Roskin on Wednesday, 02 February, 2005:
All I want to do is to have a module that would create subdirectories for
some network interfaces under /sys/class/net/*/, which would contain
additional parameters for those interfaces.  I'm not creating a new
subsystem or anything like that.  sysctl is not good because the data is
interface specific.  ioctl on a socket would be OK, although it wouldn't
be easily scriptable.  The restriction on sysfs symbols would just force
me to write a proprietary userspace utility to set those parameters
instead of using a shell script.
Please pardon my ignorance, but if the existing network device management
 framework is insufficient, it seems that the optimal way to deal with
 this is to work with the community to address the insufficiencies, not
 hacking in a new interface to the device.
OK, then the "insufficiency" is inability to set and get additional named 
variables for network interfaces.

I won't open all details, but suppose I want the bridge to handle certain 
frames in a special way, just like BPDU frames are handled if STP is 
enabled.  There is a hook for that already - see br_handle_frame_hook. 
The proprietary module would just have to change it.

What I want it to tell that module what to do with those special frames. 
I also want to get information like what was in the last special frame and 
how many of them have been received.  In other words, I want the 
proprietary module to communicate with userspace.  Ideally, the userspace 
application should be a simple shell script, so I'm reluctant to use 
ioctl.

--
Regards,
Pavel Roskin
-
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] orinoco rfmon

[Pavel Roskin]

Hello!

>> I just disabled the check for broken firmware and things seem fine (better 
>> than the original
>> patch I posted). The iwlist command now works. Could the buggy firmware be 
>> generalized a bit
>> too much? Perhaps only certain versions > 8 are buggy?
>
>Possibly, but I don't really have the means to find out in more
>detail.  The trouble is that when it falls over, it falls over very
>badly, which is why we disable this rather than just letting the user
>risk it.  Pavel knows more of the details on this one.
>
Try AirSnort with scanning enabled - it will bring the firmware down in
a few minutes.

-- 
Regards,
Pavel Roskin


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

ACPI + Promise IDE = disk corruption :-(((

[Pavel Roskin]

Hello!

It's just a word of warning for those who are trying ACPI with the latest
kernels.

I enabled ACPI in 2.4.5-ac17 (2.4.5-ac16 works fine with the same config
except ACPI). When I booted I saw a message

ACPI: If experiencing system slowness, try adding "acpi=no-idle" to
cmdline

and after that ...

reiserfs: checking transaction log (device 21:04) ...

Normally it takes few seconds before the system goes further, but that
time it tool much longer (one minute maybe), and the next message was
something like "hde: DMA timeout"

I hit reset hoping to boot the system with "acpi=no-idle", but GRUB
couldn't load stage2, which resides on the root partition (reiserfs).

I had to install Linux on another drive and run reiserfsck. It found many
errors, fixed them all, and now I'm happily running my old system.

I also checked the same kernel with "acpi=no-idle" - it works. The ACPI
messages are now:

ACPI: Core Subsystem version [20010208]
ACPI: Subsystem enabled
ACPI: System firmware supports: C2 C3
ACPI: plvl2lat=10 plvl3lat=20
ACPI: C2 enter=143 C2 exit=35
ACPI: C3 enter=858 C3 exit=71
ACPI: Not using ACPI idle
ACPI: System firmware supports: S0 S1 S5

The config file is here: http://www.red-bean.com/~proski/linux/config
dmesg output is here: http://www.red-bean.com/~proski/linux/dmesg

Possibly important data:

Kernel compiled with gcc-3.0
Motherboard Micron SE440-BX2
BIOS 4S4EB2X0.05A.0016.P15 (the latest)
1 Intel Pentium III 550MHz
Root filesystem is reiserfs
Root filesystem is on Promise PDC20267 ide controller
Local APIC (but not IO-APIC) is used.

I can make more experiments (with other hard drives) if needed.

-- 
Regards,
Pavel Roskin

-
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: cd writer problems with 2.4.5ac17

[Pavel Roskin]

Hello!

I wrote a CD today under 2.4.5-ac17 on MITSUMI CR-4804TE using SCSI
emulation and cdrecord 1.9. No problems at all.

Another computer is running 2.4.5-ac17 with Promise controller, but I only
have hard drives connected to it. No problems except when ACPI was
enabled.

I understand that your CDR is the first (and maybe the only) device
connected to the Promise controller. Consider connecting it to the onboard
controller if you have one.

What you are describing sounds like a hardware problem. You could try the
old kernel and restore the original confuguration of the system.

If it turns out to be a software problem, I'll appreciate if you locate
the change that caused the problem. Also more details about your hardware
would be useful.

-- 
Regards,
Pavel Roskin

-
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.4.4-ac3 +IPX -SYSCTL compile fix

[Pavel Roskin]

Hello!

File net/ipx/sysctl_net_ipx.c provides dummy functions for
ipx_register_sysctl and ipx_unregister_sysctl if CONFIG_SYSCTL is not
defined. The problem is, sysctl_net_ipx.c is not even compiled in this
case.

I'm moving the dummy functions to af_ipx.c where they are used. Not sure
about conformance with the coding standards, but I think that "static
inline" is preferred over defines. Feel free to correct me.

The patch is also here:
http://www.red-bean.com/~proski/linux/ipxsysctl.diff

The patch has been tested. IPX works fine without SYSCTL.

Regards,
Pavel Roskin

--
--- linux.orig/net/ipx/af_ipx.c
+++ linux/net/ipx/af_ipx.c
@@ -116,8 +116,18 @@
 #include 
 #include 

+#ifdef CONFIG_SYSCTL
 extern void ipx_register_sysctl(void);
 extern void ipx_unregister_sysctl(void);
+#else
+static inline void ipx_register_sysctl(void)
+{
+}
+
+static inline void ipx_unregister_sysctl(void)
+{
+}
+#endif

 /* Configuration Variables */
 static unsigned char ipxcfg_max_hops = 16;
--- linux.orig/net/ipx/sysctl_net_ipx.c
+++ linux/net/ipx/sysctl_net_ipx.c
@@ -44,11 +44,5 @@ void ipx_unregister_sysctl(void)
 }

 #else
-void ipx_register_sysctl(void)
-{
-}
-
-void ipx_unregister_sysctl(void)
-{
-}
+#error This file shouldn't be compiled without CONFIG_SYSCTL defined
 #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/

Re: [PATCH] 2.4.4-ac3 +IPX -SYSCTL compile fix

[Pavel Roskin]

> +#error This file shouldn't be compiled without CONFIG_SYSCTL defined

Oops, sorry! Unterminated string constant in preprocessor. It should be

#error This file should not be compiled without CONFIG_SYSCTL defined

The patch at http://www.red-bean.com/~proski/linux/ipxsysctl.diff has been
updated.

-- 
Regards,
Pavel Roskin

-
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.4-ac4 - oops on unload "cdrom" module

[Pavel Roskin]

Hello!

This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.

Full .config is here:
http://www.red-bean.com/~proski/linux/config

sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
this oops the "cdrom" module remains in memory in the "deleted" state.

$ /sbin/lsmod
Module  Size  Used by
hid11760   0 (unused)
keybdev 1632   0 (unused)
mga85312   1
agpgart13136   3
mousedev3936   1 (autoclean)
input   3296   0 (autoclean) [hid keybdev mousedev]
nfsd   67504   8 (autoclean)
lockd  48752   1 (autoclean) [nfsd]
sunrpc 56800   1 (autoclean) [nfsd lockd]
3c59x  24320   1 (autoclean)
ipx14496   1 (autoclean)
ramfs   3728   1 (autoclean)
cdrom  28864   0 (deleted)

ksymoops 2.3.4 on i686 2.4.4-ac4.  Options used
 -v vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.4-ac4/ (default)
 -m System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 0008
c0118051
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax:    ebx:    ecx: d08c9000   edx: 
esi: d08c9000   edi:    ebp: bfffe968   esp: c181bf80
ds: 0018   es: 0018   ss: 0018
Process rmmod (pid: 11303, stackpage=c181b000)
Stack: d08c9000 d08cd92f  d08cd97a  d08cf5c0 c01157eb d08c9000
   fff0 c62dc000 c0114c87 d08c9000  c181a000 bb47 0001
   c0106af7 bb47 0805eee8 0100 bb47 0001 bfffe968 0081
Call Trace: [] [] [] [] []
   [] [] [] []
Code: 8b 53 08 8b 43 04 89 50 04 89 02 a1 a0 46 27 c0 50 8b 03 50

>>EIP; c0118051<=
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; d08cd92f <[cdrom]cdrom_sysctl_unregister+b/10>
Trace; d08cd97a <[cdrom]cdrom_exit+1a/28>
Trace; d08cf5c0 <[cdrom].rodata.start+1a00/1a22>
Trace; c01157eb 
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; c0114c87 
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; c0106af7 
Code;  c0118051 
 <_EIP>:
Code;  c0118051<=
   0:   8b 53 08  mov0x8(%ebx),%edx   <=
Code;  c0118054 
   3:   8b 43 04  mov0x4(%ebx),%eax
Code;  c0118057 
   6:   89 50 04  mov%edx,0x4(%eax)
Code;  c011805a 
   9:   89 02 mov%eax,(%edx)
Code;  c011805c 
   b:   a1 a0 46 27 c0mov0xc02746a0,%eax
Code;  c0118061 
  10:   50push   %eax
Code;  c0118062 
  11:   8b 03 mov    (%ebx),%eax
Code;  c0118064 
  13:   50push   %eax


-- 
Regards,
Pavel Roskin

-
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.4.4-ac4 - oops on unload "cdrom" module

[Pavel Roskin]

Hi, Andrzej!

> The following patch fixes unloading of cdrom module when no cdrom driver
> loaded (2.4.5-pre, 2.4.4-ac):

It works for me. Thank you! You have even managed to find out that I had
my CD-ROM disconnected :-)

By the way, shouldn't we register sysctl, /proc/sys/dev/cdrom/ and
/dev/cdrom/ always when the cdrom driver is loaded/initialized, not when a
cdrom unit is found?

I don't know what's the official "policy" is, but wouldn't it be logical
to have some control over the drivers that handle no devices in the
moment?

Actually, the scsi module behaves differently. Right now I have empty
/dev/scsi and /proc/scsi/scsi contains "Attached devices: none"

Anyway, the patch is small, straightforward and consistent with the
current behavior of the driver. And it works.

-- 
Regards,
Pavel Roskin

-
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.4 add suffix for uname -r

[Pavel Roskin]

Hi, Keith!

> A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or
> 2.x.y.save to preserve a working kernel.  But renaming the image does
> not change the value of uname -r so it still tries to use modules
> 2.x.y, which defeats the purpose of saving an working kernel.

Thank you for the patch and for taking care of the problem! I've tested it
and it works for me. I'm using kernel modules and ALSA.

> Objects that "know" the value of uname -r that they were compiled with
> will not work with unamersfx.  Are there any?

"floppy" hardcodes the version but doesn't protest.

inserting floppy driver for 2.4.4-ac5
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
# uname -a
Linux fonzie 2.4.4-ac5-new #3 Mon May 7 12:06:39 EDT 2001 i686 unknown

-- 
Regards,
Pavel Roskin

-
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 to make ymfpci legacy address 16 bits

[Pavel Roskin]

Hi, Pete!

Next time you are asking my opinion please cc: me, so that I can quote
you.

Yes, I think you have fixed a terrible bug in ymfpci. Decoding only 10-bit
addresses is extremely dangerous, considering that only 388-38b is
reserved, while 788-78b etc are not.

In order to get your patch accepted sooner please use symbolic constants
and better indentation. I don't want to steal your credits by doing it for
you :-)

If you want to play further with APM and ymfpci, I made a stub for proper
apm support in the ymfpci driver. It's available here:

http://www.red-bean.com/~proski/linux/ymfpci_pm.diff

You may need to save some data in memory when the system goes to suspend
and restore them afterwards. I believe that the PCI config space should be
saved by BIOS. Everything else is the responsibility of the driver.

If I find a similar problem in ALSA it will be reported with cc: to you.

-- 
Regards,
Pavel Roskin

-
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 to make ymfpci legacy address 16 bits

[Pavel Roskin]

Hi, Jeff!

Thanks for your very (!!!) fast response :-)

> > http://www.red-bean.com/~proski/linux/ymfpci_pm.diff
>
> Why not use pci_driver::{suspend,resume} ?

I'm just a bit conservative. There are several drivers that don't use this
mechanism, notably trident and maestro. Do you think it's safe to switch
all sound drivers to the mechanism you are proposing?

I'm worried about a comment in maestro.c:

/*
 * we'd also like to find out about
 * power level changes because some biosen
 * do mean things to the maestro when they
 * change their power state.
 */

If we switch to pci_driver::{suspend,resume}, will it ever be possible to
add support for any messages other than PM_SUSPEND and PM_RESUME? Probably
yes, but only in the PCI driver dispatches them.

By the way, I don't like the way how pm_unregister_all() is used in
several sound drivers. If a unit is removed its power manager callback
remains registered until the module is unloaded.

> In ACPI land the kernel should save and restore the PCI device config
> space and the PCI bus config space.  It is probably that similar is
> necessary under APM.

I have never seen any sound driver doing that. I also know that PCI
settings are saved by some BIOSes on some hardware.

I'm sorry if I put it wrong. Perhaps I should have added a few IMHO.

PS. The 0x20 bit in 0x40 is not set if I load CVS ALSA drivers, even if I
set it before loading the driver. It's a problem with the kernel driver
only and should be fixed IMHO.

-- 
Regards,
Pavel Roskin

-
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 to make ymfpci legacy address 16 bits

[Pavel Roskin]

Hi, Jeff!

> Basically the PCI core should implement what PM is necessary, because
> eventually struct pci_driver will become a more generic struct driver.

I just wanted to make sure that you don't expect any problems if we go
this way.

> Why does maestro.c not use my suggestion?  Because it doesn't use struct
> pci_driver.

I see. It's not a pure PCI driver. I wonder what happens if some other
driver becomes "impure" e.g. by adding PCMCIA support.

> Why does trident.c not use my suggestion?  Only because noone has
> written and tested the patch for it yet :)  It uses struct pci_driver
> and should be updated to use ::suspend/resume.

First part (writing the patch) is done:

http://www.red-bean.com/~proski/linux/trident_pm.diff

I only know that it compiles. I have no hardware I can test it on. Please
don't apply until tested!

-- 
Regards,
Pavel Roskin

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

[Pavel Roskin]

Hello, Zilvinas!

There are utilities that work with PnP BIOS. They are included with
pcmcia-cs (which is weird - it should be a separate package) and called
"lspci" and "setpci". They depend on PnP BIOS support in the kernel
(CONFIG_PNPBIOS).

Dumping your PnP BIOS configuration and checking whether it has changed
after booting to Windows would be more reasonable than checking your PCI
configuration (IMHO).

-- 
Regards,
Pavel Roskin

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

Need help with register_page_fault_notifier() replacement in 2.6.24

[Pavel Roskin]

Hello!

I'm trying to update a special tracing version of madwifi (driver for
Atheros wireless cards) for Linux 2.6.24.  This version was created to
help reverse engineering the non-free part of the driver (also known as
HAL, hardware abstraction layer).

The problem is that functions register_page_fault_notifier() and
unregister_page_fault_notifier() are gone in the current kernel git
repository.

They are needed to intercept access to the card by causing page fault
and intercepting it.

Those functions were removed on i386 platform because kprobes now
registers the flat handler directly.  The log says that other callers
are supposed to use kprobes now.

But what would be the right way to do it?  I can intercept
do_page_fault() with kprobes, but that looks unsafe, since
do_page_fault() is used by kprobes internally.

Or maybe I should install a fault handler with register_kprobe()?  The
problem is, it is only called for faults in kp->pre_handler and
kp->post_handler and for single-stepping.  I don't want to single-step
anything, and moving all driver functionality in kp->pre_handler would
be strange.

Perhaps I'm missing something obvious.  Any help will be appreciated.

-- 
Regards,
Pavel Roskin

-
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: Need help with register_page_fault_notifier() replacement in 2.6.24

[Pavel Roskin]

Quoting Arjan van de Ven <[EMAIL PROTECTED]>:


if it's just for a custom case (as it sounds like).. a simple small
change to the pagefault handler sounds like the easiest thing to do...
(eg just a direct function call to what would have been your notifier)


Thanks!  Actually, the idea is to make it easy many people to run the  
trace without having them to patch or downgrade their kernels.  Also,  
it would be convenient for ath5k developers to run (and perhaps  
improve) the trace on the current development kernel.


Also, the code was lifted from some nvidia debugging tool, so the  
improved code could be contributed back there.


I guess if there is no simple answer, I'll have to try a few crazy  
ideas.  If nothing works, the fault handler chain could be reinstated,  
perhaps as a separate configuration option.


--
Regards,
Pavel Roskin
-
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] [360/2many] MAINTAINERS - ORINOCO DRIVER

[Pavel Roskin]

On Sun, 2007-08-12 at 23:33 -0700, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
> 
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96aeb40..f374fa8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3463,6 +3463,7 @@ L:  [EMAIL PROTECTED]
>  L:   [EMAIL PROTECTED]
>  W:   http://www.nongnu.org/orinoco/
>  S:   Maintained
> +F:   drivers/net/wireless/orinoco*

NAK.  Please also add airport*, spectrum* and hermes* in the same
directory.

Sorry for delay (due to vacation).

-- 
Regards,
Pavel Roskin

-
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] [360/2many] MAINTAINERS - ORINOCO DRIVER

[Pavel Roskin]

Quoting Joe Perches <[EMAIL PROTECTED]>:


On Tue, 2007-08-28 at 13:15 -0400, Pavel Roskin wrote:

NAK.  Please also add airport*, spectrum* and hermes* in the same
directory.


Here's what I have now:

ORINOCO/AIRPORT/SPECTRUM/HERMES WIRELESS DRIVERS
P:  Pavel Roskin
M:  [EMAIL PROTECTED]
P:  David Gibson
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
W:  http://www.nongnu.org/orinoco/
S:  Maintained
F:  drivers/net/wireless/orinoco*
F:  drivers/net/wireless/airport*
F:  drivers/net/wireless/spectrum*
F:  drivers/net/wireless/hermes*


Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>

--
Regards,
Pavel Roskin
-
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/

Distinguishing releases from pre-rc snapshots

[Pavel Roskin]

Hello!

I'm trying to keep some external drivers up to date with the kernel, and
the first two weeks after the release is the worst time for me.  There
is no way to distinguish the current git kernel from the latest release.
It's only after rc1 is released that I can use preprocessor to check
LINUX_VERSION_CODE.

Before that, I have to rely on tricks or change the kernel version
myself in a separate patch and tell other team members to do the same.

Basically, I only care about kernel releases, but I also want to
increase the probability that the next standalone release of my drivers
will work with the next release on the kernel.  That's why I check
compatibility with the tip of the linux-2.6 repository.

Calling git version of Linux "2.6.23" one day before 2.6.24-rc1 is
preposterous, as it's likely to be compatible with 2.6.24, not 2.6.23.
Calling git version of Linux "2.6.24-pre" or something next day after
2.6.23 release is OK in comparison, since nobody developing external
drivers cares about old revisions of the kernel.  And the developers of
the kernel itself shouldn't care about versions at all.

It would be nice to establish a rule to increment the version number
immediately after the kernel release and have a suffix to indicate that
it's a pre-rc version.  "rc0" is my personal favorite.

It would also be helpful for other repositories, as it would indicate
whether any post-release changes have been merged in.

-- 
Regards,
Pavel Roskin

-
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: Distinguishing releases from pre-rc snapshots

[Pavel Roskin]

On Tue, 2007-10-16 at 22:34 -0400, Dave Jones wrote:
> On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote:
> 
>  > It would be nice to establish a rule to increment the version number
>  > immediately after the kernel release and have a suffix to indicate that
>  > it's a pre-rc version.  "rc0" is my personal favorite.
> 
> fwiw, rc0 is also what the Fedora kernel uses for versioning when we're
> shipping pre-rc1 kernels.

Thanks!  I didn't think of the possibility of anyone distributing
precompiled kernels from the "pre-rc" window, but if Fedora does it
(hopefully for beta-testers only), it should be absolutely clear that
it's not just a release with some minor fixes.

Anyone adjusting any software for that kernel would be adjusting for the
next kernel release.

-- 
Regards,
Pavel Roskin

-
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: Distinguishing releases from pre-rc snapshots

[Pavel Roskin]

On Tue, 2007-10-16 at 22:41 -0400, Rik van Riel wrote:
> On Tue, 16 Oct 2007 22:22:43 -0400
> Pavel Roskin <[EMAIL PROTECTED]> wrote:
> 
> > I'm trying to keep some external drivers up to date with the kernel,
> > and the first two weeks after the release is the worst time for me.
> 
> Consider this an incentive to submit your code for inclusion
> in the upstream kernel.  Having all the common drivers integrated
> in the mainline kernel makes it much easier for users to use all
> their hardware, external drivers are not just a pain for the developers.

The incentive has already worked for MadWifi, which has landed in the
wireless-2.6 repository under the name "ath5k".  Still, there is a lot
of work to do, and some features won't appear in the kernel driver soon,
partly because they rely on the chipset features that still need to be
reverse engineered.

In the meantime, somebody has to maintain the old madwifi and release
fixed for security and kernel compatibility.

Also, there are drivers that are just to unwieldy to be shaped into
something resembling a typical Linux driver.  linux-wlan-ng is such
project.  No matter what the incentive, it won't go to the kernel.
Maybe somebody will write a clean driver for Prism USB devices one day,
but it didn't happen so far.

Finally, there is a little at76_usb driver, which supports quite old
802.11b devices.  It's in wireless-2.6 as well, but I simply cannot
expect users to test it from there.  And if I make a standalone release,
I'd rather not make another one when 2.6.24 comes out.

-- 
Regards,
Pavel Roskin

-
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: Distinguishing releases from pre-rc snapshots

[Pavel Roskin]

Quoting Frans Pop <[EMAIL PROTECTED]>:

Note that you can see if there have been commits since a release   
(the last git tag) by using the command 'git describe'.


$ git checkout -b temp v2.6.23
Switched to a new branch "temp"
$ git describe
v2.6.23
$ git checkout master
$ git describe
v2.6.23-4223-g65a6ec0

Format is: last tag - # commits since last tag - id of HEAD commit


I don't see how I can use it in preprocessor conditions.

--
Regards,
Pavel Roskin
-
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] fix unaligned exception in /drivers/net/wireless/orinoco.c

[Pavel Roskin]

On Fri, 2007-02-02 at 15:20 -0500, John W. Linville wrote:
> On Thu, Jan 18, 2007 at 09:57:18AM -, Hennerich, Michael wrote:
> > 
> > This short patch prevents an unaligned exception to occur. (GCC 4.1)
> > tmp is defined as char pointer while it is later accessed as short.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>

> This patch seems fine, such as it is.  But, it seems like it might
> also be appropriate to change hermes_read_ltv and/or hermes_read_words
> to not take void * parameters?  This patch would still be needed,
> but it might be more obvious to future coders?

I agree.  If we use any optimization that requires alignment of the
buffer for aligned access, it needs to be clearly specified and
(ideally) enforced.

I've tried to make a patch, but it seems to be a bigger effort than I
expected.  It turns out that hermes_clear_words() is not doing what it
should (although it would only affect some buggy firmwares), and it's
clear that I just cannot replace a couple of arguments and hope for the
best.  I need to dust off my 802.11b cards and re-test everything.

I've started orinoco branch locally, and I hope I'll be able to clean
the driver from all that bitrot soon.

-- 
Regards,
Pavel Roskin

-
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: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG

[Pavel Roskin]

Quoting "John W. Linville" <[EMAIL PROTECTED]>:

> > Very cool!  Is it likely that d80211 and iwlwifi will be pushed into
> > mainline in time for 2.6.21?
>
> Hmmm...I think we need to spend a cycle or so in -mm.  2.6.22 seems
> more likely for mainline.

I think we should take this as a goal.  Last time I checked, d80211 wasn't in
-mm.  Perhaps it should go there.  And by the way, the latest changes from
netdev->class_dev to netdev->dev break d80211.  Perhaps we should rebase
wireless-dev immediately after 2.6.21-rc1, fix all compile issues and submit
the patch to -mm.

And iwlwifi is surprisingly good for a just announced driver.  It worked for me
from the first attempt, and that's the first d80211 driver to do so.  In my
opinion, it should go to wireless-dev as soon as possible so it can go to -mm
toghether with other drivers.  A couple of wrinkles in the standalone build
system are irrelevant to the kernel interation.

--
Regards,
Pavel Roskin
-
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/

Two unclear places in lockdep-design.txt

[Pavel Roskin]

Hello, Ingo!

Many thanks for the lockdep validator!  It has helped me immensely.
However, lockdep-design.txt has been pretty hard to read for me.

It would be great if you find an opportunity to clarify two things in
the documentation.

1) What is a lock dependency?  What does "L1 -> L2" mean?  Does it mean
that L1 should be first or second to be acquired?

2) What is "ever held with hardirqs enabled"?  Does it mean that the
lock was used in the code where hardirqs were enabled, or that it _also_
didn't disable hardirqs by itself (e.g. by spin_lock_irq)?  I suspect
the later is the case.

I wish I could submit a patch for the documentation, but I still don't
understand much of the theory.  Still, I was able to interpret the error
messages in a way that allows me to fix the locking issues in some
drivers.

-- 
Regards,
Pavel Roskin

-
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: PCMCIA WLAN card initialization error

[Pavel Roskin]

On Sun, 2007-02-18 at 23:40 +0200, Timur Aydin wrote:
> reg is indeed 0x and the function returns -ENODEV.
> 
> I need help to further troubleshoot the problem, any directions or
> hints welcome...

The card is likely dead, but please check it with hostap_cs and on
different hardware just in case.  If you have further questions, please
post them to [EMAIL PROTECTED]

-- 
Regards,
Pavel Roskin

-
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] Fix sparse annotation of spin unlock macros in one case

[Pavel Roskin]

From: Pavel Roskin <[EMAIL PROTECTED]>

SMP systems without preemption and spinlock debugging enabled use unlock
macros that don't tell sparse that the lock is being released.  Add
sparse annotations in this case.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---

 include/linux/spinlock.h |   33 -
 1 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 94b767d..d3b6397 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -228,15 +228,30 @@ do {  
\
 # define read_unlock_irq(lock) _read_unlock_irq(lock)
 # define write_unlock_irq(lock)_write_unlock_irq(lock)
 #else
-# define spin_unlock(lock) __raw_spin_unlock(&(lock)->raw_lock)
-# define read_unlock(lock) __raw_read_unlock(&(lock)->raw_lock)
-# define write_unlock(lock)__raw_write_unlock(&(lock)->raw_lock)
-# define spin_unlock_irq(lock) \
-do { __raw_spin_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
-# define read_unlock_irq(lock) \
-do { __raw_read_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
-# define write_unlock_irq(lock) \
-do { __raw_write_unlock(&(lock)->raw_lock); local_irq_enable(); } while (0)
+# define spin_unlock(lock) \
+do {__raw_spin_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define read_unlock(lock) \
+do {__raw_read_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define write_unlock(lock) \
+do {__raw_write_unlock(&(lock)->raw_lock); __release(lock); } while (0)
+# define spin_unlock_irq(lock) \
+do {   \
+   __raw_spin_unlock(&(lock)->raw_lock);   \
+   local_irq_enable(); \
+   __release(lock);\
+} while (0)
+# define read_unlock_irq(lock) \
+do {   \
+   __raw_read_unlock(&(lock)->raw_lock);   \
+   local_irq_enable(); \
+   __release(lock);\
+} while (0)
+# define write_unlock_irq(lock)\
+do {   \
+   __raw_write_unlock(&(lock)->raw_lock);  \
+   local_irq_enable(); \
+   __release(lock);        \
+} while (0)
 #endif
 
 #define spin_unlock_irqrestore(lock, flags) \


-- 
Regards,
Pavel Roskin


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

MontaVista spam

[Pavel Roskin]

Mr Ready,

If you want to invite Linux kernel developers to your "webinar", please
ask your secretary to send individual invitations.  I'm sure you can do
it as the CTO of MontaVista Software.

Please don't pay spammers.  Nobody likes them, especially those who are
subjected to spam as a result of their participation in free software
development.  MontaVista Software uses some code I helped improve.  Is
that your gratitude, Mr Ready?

Spammers lie.  I have never subscribed to the "OE Trends Email List".
Do you want your name and the name of your company associated with spam
and lies?

MontaVista Software has contributed some useful code to the kernel.
Your patches are still welcome.  But your spam is not.

P.S. My original e-mail was denied by LKML because the mail filter
considered it to be spam.  Indeed, the forwarded message must have
triggered quite a lot of spam rules.  This time the message it not
forwarded.  Instead, it can be found on my website with full headers:
http://80211libre.org/mvistaspam.txt

-- 
Regards,
Pavel Roskin

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