* policy patch for 2002121210
From: Russell Coker @ 2002-12-16 16:13 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
I've attached my first policy patch for the latest release.
It doesn't contain anything exciting, just small tweaks and some patches for
things that have changed since the last patch I sent in.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 9461 bytes --]
diff -ru /tmp/policy/domains/program/bootloader.te policy/domains/program/bootloader.te
--- /tmp/policy/domains/program/bootloader.te 2002-12-16 17:06:02.000000000 +0100
+++ policy/domains/program/bootloader.te 2002-12-13 21:03:06.000000000 +0100
@@ -48,6 +48,7 @@
# for ldd
allow bootloader_t { insmod_exec_t fsadm_exec_t }:file { rx_file_perms execute_no_trans };
+allow bootloader_t insmod_exec_t:lnk_file { getattr read };
dontaudit bootloader_t sysadm_home_dir_t:dir search;
diff -ru /tmp/policy/domains/program/crack.te policy/domains/program/crack.te
--- /tmp/policy/domains/program/crack.te 2002-12-03 15:56:39.000000000 +0100
+++ policy/domains/program/crack.te 2002-12-13 21:03:18.000000000 +0100
@@ -35,4 +35,6 @@
allow crack_t { etc_t etc_runtime_t }:file { getattr read };
allow crack_t etc_t:dir r_dir_perms;
+allow crack_t fs_t:filesystem getattr;
+
dontaudit crack_t sysadm_home_dir_t:dir { getattr search };
diff -ru /tmp/policy/domains/program/crond.te policy/domains/program/crond.te
--- /tmp/policy/domains/program/crond.te 2002-12-03 15:56:39.000000000 +0100
+++ policy/domains/program/crond.te 2002-12-13 21:03:38.000000000 +0100
@@ -37,7 +37,7 @@
file_type_auto_trans(crond_t, var_log_t, cron_log_t)
# Use capabilities.
-allow crond_t crond_t:capability { setgid setuid net_bind_service };
+allow crond_t crond_t:capability { setgid setuid net_bind_service dac_override };
# Check entrypoint permission on crontab files.
allow crond_t security_t:security compute_av;
diff -ru /tmp/policy/domains/program/dpkg.te policy/domains/program/dpkg.te
--- /tmp/policy/domains/program/dpkg.te 2002-12-03 15:56:40.000000000 +0100
+++ policy/domains/program/dpkg.te 2002-12-13 21:04:23.000000000 +0100
@@ -25,7 +25,7 @@
can_exec(dpkg_t, init_exec_t)
file_type_auto_trans(dpkg_t, tmp_t, tmp_dpkg_t)
ifdef(`mta.te', `
-allow system_mail_t tmp_dpkg_t:file read;
+allow system_mail_t tmp_dpkg_t:file { getattr read };
')
allow dpkg_t random_device_t:chr_file read;
diff -ru /tmp/policy/domains/program/fsadm.te policy/domains/program/fsadm.te
--- /tmp/policy/domains/program/fsadm.te 2002-11-04 13:27:51.000000000 +0100
+++ policy/domains/program/fsadm.te 2002-12-13 21:54:24.000000000 +0100
@@ -22,6 +22,9 @@
type fsadm_tmp_t, file_type, sysadmfile, tmpfile;
file_type_auto_trans(fsadm_t, tmp_t, fsadm_tmp_t)
+# remount file system to apply changes
+allow fsadm_t fs_t:filesystem remount;
+
# Use capabilities.
allow fsadm_t fsadm_t:capability { sys_admin sys_rawio };
diff -ru /tmp/policy/domains/program/ftpd.te policy/domains/program/ftpd.te
--- /tmp/policy/domains/program/ftpd.te 2002-11-04 13:27:51.000000000 +0100
+++ policy/domains/program/ftpd.te 2002-12-13 21:05:01.000000000 +0100
@@ -18,7 +18,10 @@
ifdef(`inetd.te', `domain_auto_trans(inetd_t, ftpd_exec_t, ftpd_t)')
ifdef(`tcpd.te', `domain_auto_trans(tcpd_t, ftpd_exec_t, ftpd_t)')
-ifdef(`crond.te', `system_crond_entry(ftpd_exec_t, ftpd_t)')
+ifdef(`crond.te', `
+system_crond_entry(ftpd_exec_t, ftpd_t)
+can_exec(ftpd_t, { bin_t sbin_t })
+')
# Inherit and use descriptors from inetd.
allow ftpd_t inetd_t:fd use;
diff -ru /tmp/policy/domains/program/hotplug.te policy/domains/program/hotplug.te
--- /tmp/policy/domains/program/hotplug.te 2002-12-03 15:56:40.000000000 +0100
+++ policy/domains/program/hotplug.te 2002-12-13 21:05:01.000000000 +0100
@@ -47,6 +47,7 @@
domain_auto_trans(kmod_t, hotplug_exec_t, hotplug_t)
domain_auto_trans_read(hotplug_t, insmod_exec_t, insmod_t)
+allow hotplug_t insmod_exec_t:lnk_file read;
domain_auto_trans_read(hotplug_t, mount_exec_t, mount_t)
domain_auto_trans_read(hotplug_t, ifconfig_exec_t, ifconfig_t)
ifdef(`pump.te', `domain_auto_trans_read(hotplug_t, pump_exec_t, pump_t)')
diff -ru /tmp/policy/domains/program/postfix.te policy/domains/program/postfix.te
--- /tmp/policy/domains/program/postfix.te 2002-12-03 15:56:41.000000000 +0100
+++ policy/domains/program/postfix.te 2002-12-13 21:07:17.000000000 +0100
@@ -82,9 +82,9 @@
allow postfix_master_t postfix_private_t:fifo_file create_file_perms;
can_network(postfix_master_t)
allow postfix_master_t smtp_port_t:tcp_socket name_bind;
-allow postfix_master_t postfix_spool_maildrop_t:dir r_dir_perms;
+allow postfix_master_t postfix_spool_maildrop_t:dir rw_dir_perms;
+allow postfix_master_t postfix_spool_maildrop_t:file { rename getattr };
allow postfix_master_t postfix_prng_t:file getattr;
-allow postfix_master_t postfix_spool_maildrop_t:file getattr;
allow postfix_master_t privfd:fd use;
allow postfix_master_t etc_aliases_t:file r_file_perms;
create_dir_file(postfix_master_t, postfix_spool_flush_t)
@@ -241,7 +241,7 @@
type postfix_spool_bounce_t, file_type, sysadmfile;
create_dir_file(postfix_bounce_t, postfix_spool_bounce_t)
create_dir_file(postfix_bounce_t, postfix_spool_t)
-allow postfix_master_t postfix_spool_bounce_t:dir r_dir_perms;
+allow postfix_master_t postfix_spool_bounce_t:dir create_dir_perms;
allow postfix_bounce_t self:capability { dac_read_search };
allow postfix_bounce_t postfix_public_t:sock_file write;
allow postfix_bounce_t self:tcp_socket create_socket_perms;
diff -ru /tmp/policy/domains/program/quota.te policy/domains/program/quota.te
--- /tmp/policy/domains/program/quota.te 2002-12-03 15:56:42.000000000 +0100
+++ policy/domains/program/quota.te 2002-12-13 21:07:17.000000000 +0100
@@ -15,7 +15,7 @@
rw_dir_create_file(initrc_t, quota_flag_t)
allow quota_t fs_t:filesystem { getattr quotaget quotamod };
-allow quota_t home_root_t:dir getattr;
+allow quota_t { home_root_t var_t usr_t src_t }:dir getattr;
allow quota_t self:capability sys_admin;
allow quota_t file_t:file quotaon;
Only in /tmp/policy/domains: system
Only in /tmp/policy/domains: user
diff -ru /tmp/policy/file_contexts/program/fsadm.fc policy/file_contexts/program/fsadm.fc
--- /tmp/policy/file_contexts/program/fsadm.fc 2002-12-03 15:56:44.000000000 +0100
+++ policy/file_contexts/program/fsadm.fc 2002-12-13 21:56:43.000000000 +0100
@@ -4,6 +4,7 @@
/sbin/e2fsck system_u:object_r:fsadm_exec_t
/sbin/reiserfs(ck|tune) system_u:object_r:fsadm_exec_t
/sbin/mkreiserfs system_u:object_r:fsadm_exec_t
+/sbin/resize.*fs system_u:object_r:fsadm_exec_t
/sbin/e2label system_u:object_r:fsadm_exec_t
/sbin/mkfs system_u:object_r:fsadm_exec_t
/sbin/mke2fs system_u:object_r:fsadm_exec_t
@@ -12,6 +13,7 @@
/sbin/sfdisk system_u:object_r:fsadm_exec_t
/sbin/cfdisk system_u:object_r:fsadm_exec_t
/sbin/fdisk system_u:object_r:fsadm_exec_t
+/sbin/parted system_u:object_r:fsadm_exec_t
/sbin/tune2fs system_u:object_r:fsadm_exec_t
/sbin/dumpe2fs system_u:object_r:fsadm_exec_t
/sbin/swapon system_u:object_r:fsadm_exec_t
diff -ru /tmp/policy/file_contexts/program/initrc.fc policy/file_contexts/program/initrc.fc
--- /tmp/policy/file_contexts/program/initrc.fc 2002-10-28 22:56:00.000000000 +0100
+++ policy/file_contexts/program/initrc.fc 2002-12-13 21:08:39.000000000 +0100
@@ -11,3 +11,4 @@
/usr/local/selinux/sbin/open_init_pty system_u:object_r:initrc_exec_t
/usr/sbin/run_init system_u:object_r:run_init_exec_t
/usr/sbin/open_init_pty system_u:object_r:initrc_exec_t
+/etc/nologin.boot system_u:object_r:etc_runtime_t
diff -ru /tmp/policy/file_contexts/program/modutil.fc policy/file_contexts/program/modutil.fc
--- /tmp/policy/file_contexts/program/modutil.fc 2002-12-16 17:06:32.000000000 +0100
+++ policy/file_contexts/program/modutil.fc 2002-12-13 21:08:39.000000000 +0100
@@ -5,6 +5,6 @@
/sbin/depmod.* system_u:object_r:depmod_exec_t
/sbin/modprobe.* system_u:object_r:insmod_exec_t
/sbin/insmod.* system_u:object_r:insmod_exec_t
-/sbin/insmod.static system_u:object_r:insmod_exec_t
+/sbin/insmod_ksymoops_clean system_u:object_r:sbin_t
/sbin/rmmod.* system_u:object_r:insmod_exec_t
/sbin/update-modules system_u:object_r:update_modules_exec_t
diff -ru /tmp/policy/file_contexts/program/postgresql.fc policy/file_contexts/program/postgresql.fc
--- /tmp/policy/file_contexts/program/postgresql.fc 2002-08-23 20:44:20.000000000 +0200
+++ policy/file_contexts/program/postgresql.fc 2002-12-13 21:08:39.000000000 +0100
@@ -4,3 +4,4 @@
/var/run/postgresql(/.*)? system_u:object_r:var_run_postgresql_t
/etc/postgresql(/.*)? system_u:object_r:etc_postgresql_t
/var/log/postgres.log.* system_u:object_r:postgresql_log_t
+/var/log/postgresql(/.*)? system_u:object_r:postgresql_log_t
diff -ru /tmp/policy/file_contexts/program/slapd.fc policy/file_contexts/program/slapd.fc
--- /tmp/policy/file_contexts/program/slapd.fc 2002-07-12 17:19:44.000000000 +0200
+++ policy/file_contexts/program/slapd.fc 2002-12-13 21:54:50.000000000 +0100
@@ -3,3 +3,4 @@
/var/lib/ldap(/.*)? system_u:object_r:slapd_db_t
/var/lib/ldap/replog(/.*)? system_u:object_r:slapd_replog_t
/var/run/slapd.args system_u:object_r:var_run_slapd_t
+/etc/ldap/slapd.conf system_u:object_r:etc_slapd_t
diff -ru /tmp/policy/macros/program/ssh_macros.te policy/macros/program/ssh_macros.te
--- /tmp/policy/macros/program/ssh_macros.te 2002-10-23 21:38:26.000000000 +0200
+++ policy/macros/program/ssh_macros.te 2002-12-13 21:10:46.000000000 +0100
@@ -69,7 +69,7 @@
allow $1_ssh_t $1_devpts_t:chr_file rw_file_perms;
# Allow the user shell to signal the ssh program.
-allow $1_t $1_ssh_t:process signal;
+allow $1_t $1_ssh_t:process { signal setpgid };
# allow ps to show ssh
allow $1_t $1_ssh_t:dir { search getattr read };
allow $1_t $1_ssh_t:{ file lnk_file } { read getattr };
^ permalink raw reply
* Re: [PATCH] 2.4.20-rmap15b
From: Georg Nikodym @ 2002-12-16 16:10 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm, linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212122349520.17748-100000@imladris.surriel.com>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
On Thu, 12 Dec 2002 23:51:50 -0200 (BRST)
Rik van Riel <riel@conectiva.com.br> wrote:
> Many changes, mostly backported from 2.5 by Ben LaHaise and
> fixed up a bit more by myself. It all appears to work, but
> more testing is appropriate.
>
> The second maintenance release of the 15th version of the reverse
> mapping based VM is now available.
> This is an attempt at making a more robust and flexible VM
> subsystem, while cleaning up a lot of code at the same time.
> The patch is available from:
Is this kernel expected to fix the occassional brief pauses/hangs that
have been happening since going to 2.4.20-rmap*?
'cause it doesn't. I've just had several pauses.
My setup:
I8000 laptop with 512MB RAM and a big ieee1394 disk running:
Linux keller 2.4.20-rc4-rmap15b #1 Fri Dec 13 14:20:02 EST 2002 i686 i686 i386 GNU/Linux
My load:
I have 182 BK repositories containing >100K files. I've done a bunch of
repeated cloning operations and the like and I get pauses where the
system goes idle in spite of the huge workload. Often screen updates
still happen and music keeps playing, etc but sometimes even that stops
(and my keystrokes disappear). These pauses are between 5 and 30
seconds in duration.
Incidentally, a colleague claimed to have seem this behaviour on a
non-rmap 2.4.20.
So the questions are the usual:
1. Known behaviour?
2. Is there any data that I should be collecting that people are
interested in?
3. Or should I just go back to 2.4.19-rmap14b (which did not trouble me
in this way)?
-g
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Mailling list archive URL broken?
From: Peter Bieringer @ 2002-12-16 16:10 UTC (permalink / raw)
To: Maillist netdev
Hi,
some time ago I found this archive URL:
http://oss.sgi.com/projects/netdev/archive/
Unfortunately, it's broken (forbidden). Temp failure or is archive
moved? If second, pls. send me the new URL.
Thank you very much,
Peter
---
Dr. Peter Bieringer
mailto: pb at bieringer dot de
http://www.bieringer.de/pb/
Key 0x958F422D : B501 24F4 9418 23E2 C0F3 F833 7B57 AA7B 958F 422D
^ permalink raw reply
* Re: system hangs after reboot
From: Ray Olszewski @ 2002-12-16 16:07 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <atk49l$jvm$1@main.gmane.org>
Four questions about what you posted ...
1. In the "good init" sequence, what happens next? You're asking us to
compare a bad init to nothing (as regards the part that is bad).
2. When you say the system "hangs" and "freezes", how carefully have you
assessed that? How long have you waited before giving up? What happens if
you CRTL-C when the system is "hung"?
3. What is eth0 and how does it connect to the Internet? If the problem is
associated with a DHCP failure of some type, the details of the interface
it is using may matter.
4. Is the problem only associated with a soft ("shutdown -r") reboot? If
you do a power-down reboot, does the system boot and init properly?
At 09:53 AM 12/16/02 +0100, Arno Seitzinger wrote:
>Hi NG,
>
>for a couple of days, my Suse Linux 8.1 (2.4.19) on a HP Omnibook XE3 Laptop
>shows a strange behaviour: it hangs after a reboot (shutdown -r now od from
>KDE). First it starts as usual, but freezes after "switching to runlevel
>5", when initializing the random number generator and the network.
>I pasted the output of a good and a bad boot.msg below.
>
>My last actions, before I noticed it doesn't reboot anymore, were:
>- use the cellphone to access internet
>- create a new user because of OpenOffice store failure
>- clear tmp directory in single user mode (because of OpenOffice store
>failure - was this stupid?)
>- new (workstation) installation of OpenOffice
>
>Nayone around who can give me a clou where to look next?
>Arno
>
>***boot.msg when system hangs
>=============================
>[...]
>Master Resource Control: previous runlevel: N, switching to runlevel:
>5
>
>done<notice>killproc: kill(30,3)
>
>INIT: Entering runlevel: 5
>
><notice>/etc/init.d/rc5.d/S01isdn start
><notice>'/etc/init.d/rc5.d/S01isdn start' exits with status 0
><notice>/etc/init.d/rc5.d/S01random start
><notice>'/etc/init.d/rc5.d/S01random start' exits with status 0
><notice>/etc/init.d/rc5.d/S05network start
>
>***boot.msg normally
>====================
>[...]
>Master Resource Control: previous runlevel: N, switching to runlevel:
>5
>
>
>done<notice>killproc: kill(30,3)
>
>INIT: Entering runlevel: 5
>
>
><notice>/etc/init.d/rc5.d/S01isdn start
><notice>'/etc/init.d/rc5.d/S01isdn start' exits with status 0
><notice>/etc/init.d/rc5.d/S01random start
><notice>'/etc/init.d/rc5.d/S01random start' exits with status 0
><notice>/etc/init.d/rc5.d/S05network start
><notice>Initializing random number generator
>done
>
>Setting up network interfaces:
>
> lo
>done
>
> eth0 (DHCP) startproc: execve (/sbin/dhcpcd) [ /sbin/dhcpcd -H -D
>-N -Y -t 999999 -h esw44 eth0 ], [ CONSOLE=/dev/console TERM=linux
>SHELL=/bin/sh OLDPWD=/etc/sysconfig/network INIT_VERSION=sysvinit-2.82
>RUN_FROM_RC=yes REDIRECT=/dev/tty1 COLUMNS=106
>PATH=/sbin:/usr/sbin:/bin:/usr/bin:/etc/sysconfig/network/scripts vga=791
>RUNLEVEL=5 PWD=/etc/sysconfig/network PREVLEVEL=N LINES=34 HOME=/ SHLVL=4
>_=/sbin/startproc DAEMON=/sbin/dhcpcd ]
><notice>pidofproc: dhcpcd 347
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [Linux-ia64] Use of __ia64_syscall() - syscall interface
From: Joel GUILLET @ 2002-12-16 16:07 UTC (permalink / raw)
To: linux-ia64
Hello!
I tried to compile a C program using the sched_set/getaffinity interface
of the O(1) scheduler. (kernel 2.5.45 - ia64).
The problem is that the syscall is not implemented yet in the glibc (i'm
working with a 2.2.4, but I saw it wasn't either with 2.2.5).
Here is the way I _declared_ the syscall :
***********************************************
#ifndef _AFFINITY_H
#define _AFFINITY_H
#include <sched.h>
#include <unistd.h>
#include <linux/unistd.h>
#ifndef __NR_sched_setaffinity
#define __NR_sched_setaffinity 1231
#define __NR_sched_getaffinity 1232
_syscall3 (int, sched_setaffinity, pid_t, pid, unsigned int, len, unsigned long *, new_mask_ptr)
_syscall3 (int, sched_getaffinity, pid_t, pid, unsigned int *, user_len_ptr, unsigned long *, user_mask_ptr)
#endif /* __NR_sched_setaffinity */
#endif /* _AFFINITY_H */
***********************************************
This doesn't compile on a Itanium.
I got a "undefined reference to __ia64_syscall()"
So I found 2 ways to resolve my problem :
- Using _syscall3(). The problem is that there is a "define" in
/usr/include/asm/unistd.h that converts this call into a __ia64_syscall(),
which is not exported by the glibc. So I extracted sysdep.o from libc.a
and I compiled my program with it. This works fine.
But, this method doesn't seem to be very clean.
- I found an other way of compiling it :
As I saw in some mail-lists, we should use the syscall() interface, I
changed the "define" in the headers file of my system
/usr/include/asm/unistd.h so that the pre-processor replaces _syscall3()
with a call to syscall() instead of __ia64_syscall() function.
If this solution is better, the headers file (/asm/unistd.h)
should perhaps be modified (please see the following diff file)
Is this a problem coming from my program, the libc, or the kernel headers ?
Is there another solution "cleaner" than these ones ?
Should we update the header file ?
Use directly another function to be able to use the syscall, in my program ?
Thanks for your help.
Joel GUILLET
*********************************
--- unistd.h.ref Fri Dec 13 14:04:32 2002
+++ unistd.h Fri Dec 13 14:12:08 2002
@@ -208,7 +208,7 @@
#if !defined(__ASSEMBLY__) && !defined(ASSEMBLER)
-extern long __ia64_syscall (long a0, long a1, long a2, long a3, long a4, long nr);
+/*extern long int syscall (long int a0, long a1, long a2, long a3, long a4, long nr);*/
#define _syscall0(type,name) \
type \
@@ -220,7 +220,7 @@
register long dummy4 __asm__ ("out3"); \
register long dummy5 __asm__ ("out4"); \
\
- return __ia64_syscall(dummy1, dummy2, dummy3, dummy4, dummy5, \
+ return syscall(dummy1, dummy2, dummy3, dummy4, dummy5, \
__NR_##name); \
}
@@ -233,7 +233,7 @@
register long dummy4 __asm__ ("out3"); \
register long dummy5 __asm__ ("out4"); \
\
- return __ia64_syscall((long) arg1, dummy2, dummy3, dummy4, \
+ return syscall((long) arg1, dummy2, dummy3, dummy4, \
dummy5, __NR_##name); \
}
@@ -245,7 +245,7 @@
register long dummy4 __asm__ ("out3"); \
register long dummy5 __asm__ ("out4"); \
\
- return __ia64_syscall((long) arg1, (long) arg2, dummy3, dummy4, \
+ return syscall((long) arg1, (long) arg2, dummy3, dummy4, \
dummy5, __NR_##name); \
}
@@ -256,7 +256,7 @@
register long dummy4 __asm__ ("out3"); \
register long dummy5 __asm__ ("out4"); \
\
- return __ia64_syscall((long) arg1, (long) arg2, (long) arg3, \
+ return syscall((long) arg1, (long) arg2, (long) arg3, \
dummy4, dummy5, __NR_##name); \
}
@@ -266,7 +266,7 @@
{ \
register long dummy5 __asm__ ("out4"); \
\
- return __ia64_syscall((long) arg1, (long) arg2, (long) arg3, \
+ return syscall((long) arg1, (long) arg2, (long) arg3, \
(long) arg4, dummy5, __NR_##name); \
}
@@ -274,7 +274,7 @@
type \
name (type1 arg1, type2 arg2, type3 arg3, type4 arg4, type5 arg5) \
{ \
- return __ia64_syscall((long) arg1, (long) arg2, (long) arg3, \
+ return syscall((long) arg1, (long) arg2, (long) arg3, \
(long) arg4, (long) arg5, __NR_##name); \
}
^ permalink raw reply
* Re: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Andrew Kohlsmith @ 2002-12-16 16:05 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1040055593.13786.56.camel-MMxVpc8zpTQVh3rx8e9g/fyykp6/JSeS3vcXtXqGYxw@public.gmane.org>
> Intel want people to write valid AML. I don't think they'll ever succeed
> but trying doesn't hurt.
>
> Vendors want working laptops
I fail to see why writing valid AML is any more difficult than writing shitty
AML. Especially in cases like *PNP0101 vs PNP0101.
But I digress; I know I'm preaching to the converted. :-)
Regards,
Andrew
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [LARTC] newbie question
From: Del Riesgo, Christopher D @ 2002-12-16 15:58 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101480860824396@msgid-missing>
Can someone kick me in the right direction on this one?
I searched the archive and saw nothing. Google didn't help either.
Using tc, I get good results and flow control on a small network. I have an
old device that sends a 8808 pause frame back to the main linux router to
have it throttle back. But then instead of slowing down and allocating
bandwidth by the rules set up, it slows down the bandwidth and gives equal
time to all types of packets. Is there a reason it dumps tc control and
goes to interleaving flow control?
TIA
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: 823 Video Controller Driver - where ?
From: Wolfgang Denk @ 2002-12-16 15:52 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: Steve Rossi, Embedded Linux PPC List
In-Reply-To: <D73A25AA6E54D511AD74009027B1110F3C04C7@ORION>
In message <D73A25AA6E54D511AD74009027B1110F3C04C7@ORION> you wrote:
>
> We have Linux frame buffer drivers for our 823E(LITE DW) and our
> IBM405GP(EP405PC).
Where can I download the sources?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
How much net work could a network work, if a network could net work?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Peter Abel's assembly book.
From: fabio miranda @ 2002-12-16 15:50 UTC (permalink / raw)
To: linux-assembly
Hi, I am interested in learning about Linux/FreeBSD assembly programming
focused on vulnerability research.
It has been very difficult to find book about assembly in my country,
however, I found the Peter Abel's book about assembly on DOS.
Can I use it having in mind my goals?.
What others resources Do you suggest me ( != linuxassembly.org) ?
regards,
PLCR.
_________________________________________________________________
MSN. Más Útil Cada Día http://www.msn.es/intmap/
^ permalink raw reply
* Re: /proc/cpuinfo and hyperthreading
From: Andrew Theurer @ 2002-12-16 15:52 UTC (permalink / raw)
To: Brian Jackson, Scott Robert Ladd; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021216135453.3823.qmail@escalade.vistahp.com>
On Monday 16 December 2002 07:54, Brian Jackson wrote:
> You could always boot once with nosmp and run some benchmarks and then
> reboot (with smp) and run some more benchmarks, and see if there is a
> difference.
Yes, but wouldn't booting a UP kernel be a better comparison? After all, why
incur any possible overhead of an SMP kernel if you don't need to? Some
benchmarks may not show a difference, but some definitely will.
-Andrew Theurer
^ permalink raw reply
* [PATCH] rmap15b for 2.4.20-ac2
From: Paul P Komkoff Jr @ 2002-12-16 15:56 UTC (permalink / raw)
To: Linux Kernel Mailing List
It works for me (tm)
http://stingr.net/l/rmap15b-for-2.4.20-ac2.gz
arch/i386/config.in | 1
arch/i386/kernel/vm86.c | 8
arch/i386/mm/Makefile | 2
arch/i386/mm/fault.c | 2
arch/i386/mm/init.c | 56 -
arch/i386/mm/ioremap.c | 2
arch/i386/mm/pageattr.c | 2
arch/i386/mm/pgtable.c | 226 +++++++
drivers/char/drm/drm_proc.h | 3
drivers/sgi/char/graphics.c | 7
fs/buffer.c | 25
fs/exec.c | 7
fs/proc/array.c | 5
fs/proc/proc_misc.c | 12
include/asm-generic/rmap.h | 47 +
include/asm-i386/fixmap.h | 7
include/asm-i386/highmem.h | 14
include/asm-i386/kmap_types.h | 3
include/asm-i386/page.h | 8
include/asm-i386/pgalloc.h | 138 ----
include/asm-i386/pgtable-2level.h | 6
include/asm-i386/pgtable-3level.h | 13
include/asm-i386/pgtable.h | 37 +
include/asm-i386/rmap.h | 14
include/linux/brlock.h | 2
include/linux/highmem.h | 1
include/linux/list.h | 3
include/linux/mm.h | 92 ++-
include/linux/mm_inline.h | 188 +++++-
include/linux/mmzone.h | 20
include/linux/module.h | 5
include/linux/pagemap.h | 1
include/linux/swap.h | 20
mm/filemap.c | 60 +-
mm/memory.c | 182 ++++--
mm/mprotect.c | 6
mm/mremap.c | 79 ++
mm/page_alloc.c | 104 ++-
mm/rmap.c | 373 +++++++++----
mm/swap.c | 106 ++-
mm/swapfile.c | 5
mm/vmalloc.c | 4
mm/vmscan.c | 1080 ++++++++++++++++++++++++--------------
43 files changed, 2062 insertions(+), 914 deletions(-)
--
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
When you're invisible, the only one really watching you is you (my keychain)
^ permalink raw reply
* HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: Scott Robert Ladd @ 2002-12-16 15:44 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <yw1xr8cigfs4.fsf@lakritspipa.e.kth.se>
Måns Rullgård wrote:
> It's easy to write a program that displays any number of graphs
> vaguely related to the system load. How do we know that the
> performance meter isn't lying?
We don't.
All I can say is that the performance meter seems (note the weasel-word)
proper when running Win2K SMP on a dual PIII-933 box at one of my client
sites. However, such experience does *not* guarantee that WinXP is reporting
valid numbers for a P4 with HT.
Here's a little test I ran this morning, now that my new system is
operational. My benchmark is a full "make bootstrap" compile of gcc-3.2.1,
with and without the - j 2 make switch that enables two threads of
compilation. Using the 2.5.51 SMP kernel, I see the following compile times:
SMP w/o -j 2: 28m11s
"nosmp" with -j 2: 27m32s
SMP with -j 2: 24m21s
HT appears to give a very tiny benefit even without an SMP kernel -- and
*with* an SMP kernel, I get a 16% improvement in my compile time. That
pretty much matches my expectation (i.e., a HT processor is *not* equal to
dual processor, but it *is* better than a non-HT processor).
Just some food for collective thought.
..Scott
^ permalink raw reply
* Re: rmap and nvidia?
From: William Lee Irwin III @ 2002-12-16 15:42 UTC (permalink / raw)
To: O. Sezer; +Cc: linux-kernel
In-Reply-To: <20021216143446.KJIB19496.fep02@[212.252.122.46]>
On Mon, Dec 16, 2002 at 04:25:11PM +0200, O. Sezer wrote:
> The 2.5 patches at http://www.minion.de/nvidia.html
> may give some clue. They use pte_offset_map , yes,
> but no corresponding pte_unmap ...
That will BUG() with highmem debugging on. Put the pte_unmap() in the
appropriate place.
Bill
^ permalink raw reply
* Re: NFS oopses on smp servers
From: Trond Myklebust @ 2002-12-16 15:34 UTC (permalink / raw)
To: Bernhard Kaindl; +Cc: Peter Lojkin, nfs, Chris Mason
In-Reply-To: <Pine.LNX.4.33.0212161226020.8807-300000@wotan.suse.de>
>>>>> " " == Bernhard Kaindl <bk@suse.de> writes:
> The idea of the fix is to not to fput the file until the
> request is completely gone.
No. There's a very good reason for fputting the file ASAP, and that in
case of an open() for write, the struct file grabs a lease. If you
defer fputting the file until the request is gone, then you'll see
ETXTBSY errors when trying to execute a file immediately after
linking.
Try the appended patch instead:
Cheers,
Trond
--- linux-2.4.20-smp/fs/nfs/pagelist.c.orig Fri Nov 29 00:53:15 2002
+++ linux-2.4.20-smp/fs/nfs/pagelist.c Mon Dec 16 16:32:05 2002
@@ -126,6 +126,7 @@
{
/* Release struct file or cached credential */
if (req->wb_file) {
+ atomic_dec(&NFS_REQUESTLIST(req->wb_inode)->nr_requests);
fput(req->wb_file);
req->wb_file = NULL;
}
@@ -136,7 +137,6 @@
if (req->wb_page) {
page_cache_release(req->wb_page);
req->wb_page = NULL;
- atomic_dec(&NFS_REQUESTLIST(req->wb_inode)->nr_requests);
}
}
@@ -165,8 +165,6 @@
BUG();
if (NFS_WBACK_BUSY(req))
BUG();
- if (atomic_read(&NFS_REQUESTLIST(req->wb_inode)->nr_requests) < 0)
- BUG();
#endif
/* Release struct file or cached credential */
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Arctic-2 MTD driver
From: Tom Rini @ 2002-12-16 15:31 UTC (permalink / raw)
To: Marius Groeger; +Cc: David Gibson, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.40.0212161624180.10282-100000@mag.devdep.sysgo.de>
On Mon, Dec 16, 2002 at 04:28:06PM +0100, Marius Groeger wrote:
> On Mon, 16 Dec 2002, Tom Rini wrote:
>
> > On Mon, Dec 16, 2002 at 09:46:50AM +0100, Marius Groeger wrote:
> > >
> > > Hello David,
> > >
> > > On Mon, 16 Dec 2002, David Gibson wrote:
> > >
> > > > Having committed the core support code for the Arctic-2, here come
> > > > some drivers for it. Below is an MTD map for the Arctic-2, derived
> > > > from beech-mtd.c. Essentially all it does is provide suitable
> > > > hardwired partitions.
> > >
> > > Can you also post this to the linux-mtd folks?
> >
> > No point in doing that yet, as the underlying support code for the
> > Arctic-2 won't be making Marcelo's tree for a while yet.
>
> I don't see a point in NOT doing this. It will have to be done anyway,
> so David might as well do it now and be done with it.
Unusable, untestable code which may or may not need minor changes before
going upstream? (For example, I need to go and do similar changes to an
upstream version of maps/Config.in like I just did to the _devel ones).
There's no real advantage to doing it now or later, in other words. :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* IDE but no disks
From: Alan Cox @ 2002-12-16 16:16 UTC (permalink / raw)
To: Linux Kernel Mailing List
People seeing IDE controllers detected but no disks can you try the
following backport of Ivan's 2.5 PCI fix
--- drivers/pci/quirks.c~ 2002-12-16 16:01:08.000000000 +0000
+++ drivers/pci/quirks.c 2002-12-16 16:01:08.000000000 +0000
@@ -523,6 +523,56 @@
}
/*
+ * As per PCI spec, ignore base address registers 0-3 of the IDE controllers
+ * running in Compatible mode (bits 0 and 2 in the ProgIf for primary and
+ * secondary channels respectively). If the device reports Compatible mode
+ * but does use BAR0-3 for address decoding, we assume that firmware has
+ * programmed these BARs with standard values (0x1f0,0x3f4 and 0x170,0x374).
+ * Exceptions (if they exist) must be handled in chip/architecture specific
+ * fixups.
+ *
+ * Note: for non x86 people. You may need an arch specific quirk to handle
+ * moving IDE devices to native mode as well. Some plug in card devices power
+ * up in compatible mode and assume the BIOS will adjust them.
+ *
+ * Q: should we load the 0x1f0,0x3f4 into the registers or zap them as
+ * we do now ? We don't want is pci_enable_device to come along
+ * and assign new resources. Both approaches work for that.
+ */
+
+static void __devinit quirk_ide_bases(struct pci_dev *dev)
+{
+ struct resource *res;
+ int first_bar = 2, last_bar = 0;
+
+ if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
+ return;
+
+ res = &dev->resource[0];
+
+ /* primary channel: ProgIf bit 0, BAR0, BAR1 */
+ if (!(dev->class & 1) && (res[0].flags || res[1].flags)) {
+ res[0].start = res[0].end = res[0].flags = 0;
+ res[1].start = res[1].end = res[1].flags = 0;
+ first_bar = 0;
+ last_bar = 1;
+ }
+
+ /* secondary channel: ProgIf bit 2, BAR2, BAR3 */
+ if (!(dev->class & 4) && (res[2].flags || res[3].flags)) {
+ res[2].start = res[2].end = res[2].flags = 0;
+ res[3].start = res[3].end = res[3].flags = 0;
+ last_bar = 3;
+ }
+
+ if (!last_bar)
+ return;
+
+ printk(KERN_INFO "PCI: Ignoring BAR%d-%d of IDE controller %s\n",
+ first_bar, last_bar, dev->slot_name);
+}
+
+/*
* The main table of quirks.
*/
@@ -565,6 +615,7 @@
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, quirk_ali7101_acpi },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_2, quirk_piix3_usb },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_2, quirk_piix3_usb },
+ { PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID, quirk_ide_bases },
{ PCI_FIXUP_FINAL, PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_legacy },
#ifdef CONFIG_X86_IO_APIC
^ permalink raw reply
* Re: Arctic-2 MTD driver
From: Marius Groeger @ 2002-12-16 15:28 UTC (permalink / raw)
To: Tom Rini; +Cc: David Gibson, linuxppc-embedded
In-Reply-To: <20021216150123.GH6095@opus.bloom.county>
On Mon, 16 Dec 2002, Tom Rini wrote:
> On Mon, Dec 16, 2002 at 09:46:50AM +0100, Marius Groeger wrote:
> >
> > Hello David,
> >
> > On Mon, 16 Dec 2002, David Gibson wrote:
> >
> > > Having committed the core support code for the Arctic-2, here come
> > > some drivers for it. Below is an MTD map for the Arctic-2, derived
> > > from beech-mtd.c. Essentially all it does is provide suitable
> > > hardwired partitions.
> >
> > Can you also post this to the linux-mtd folks?
>
> No point in doing that yet, as the underlying support code for the
> Arctic-2 won't be making Marcelo's tree for a while yet.
I don't see a point in NOT doing this. It will have to be done anyway,
so David might as well do it now and be done with it.
Regards
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Dual Xeon w/ HT: Kernel can't find second CPU
From: Alan Cox @ 2002-12-16 16:13 UTC (permalink / raw)
To: Patrick R. McManus; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021216144243.GA9352@ducksong.com>
On Mon, 2002-12-16 at 14:42, Patrick R. McManus wrote:
> I can't build a kernel for my dual xeon e7500 board, with
> hyperthreading enabled, that sees 4 logical processors. I can boot the
> redhat 8 kernel and that sees 4, but my build of 2.4.20-ac2 gets me
> 'warning sibling not found' messages and just 2 cpus.
The -ac tree gets this wrong in some cases. Since Marcelo is merging
code that is newer and replaces the buggy bits I don't see any point in
fixing my -ac tree for this one as it is going to get dropped out anyway
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Paul Davis @ 2002-12-16 15:23 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Mark Knecht, martin-langer, Alsa-Devel, swpatrick
In-Reply-To: <s5h1y4it3qd.wl@alsa2.suse.de>
>> that reminds me. the last version of the alsasound script that i saw
>> did something very dangerous. it seemed to try to install *every*
>> snd-card module it could find. if you have a system with an ISA bus,
>> this can prove fatal to the system - many ISA device probes will kill
>> the machine if the device is not present.
>
>well, you can find that the alsasound script tries to load the modules
>aliased as "snd-card-[0-9]", not the all snd-card-* modules.
>remember that there is no module named as such. that means, if such a
>module is found, it was certainly configured by some means.
ah. sorry, i missed the -c on modprobe. i take it all back :(
--p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [offtopic] Documentation about the Classic GUS schematics
From: Takashi Iwai @ 2002-12-16 15:17 UTC (permalink / raw)
To: Juan Linietsky; +Cc: alsa-devel
In-Reply-To: <20021215094024.166dcdfa.coding@reduz.com.ar>
At Sun, 15 Dec 2002 09:40:24 -0300,
Juan Linietsky wrote:
>
> Hello!
>
> I am looking for documentation on the schematics and working of the
> Gravis Ultrasound Classic with the hopes to add support for it in
> DOSEMU. Unfortunatedly I failed to find information about it
> on the net. Does anyone here know where can i find
> such information?
don't the files on ftp://ftp.alsa-project.org/pub/manuals/gus
suffice?
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Requested: CMI8330 testers?
From: Takashi Iwai @ 2002-12-16 15:15 UTC (permalink / raw)
To: alsa-devel; +Cc: alsa-user
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
can anyone who owns the CMI8330 ISA test the attached patch?
the patch will change the pcm interface of this soundchip as a more
reasonable way. the playback and capture are combined into one pcm.
it's for the latest cvs version. not sure whether it's applicable to
rc6.
please check whether the full-duplex works. it's enough to run aplay
and arecord simultaneously.
thanks,
Takashi
[-- Attachment #2: cmi8330-pcm-fix.dif --]
[-- Type: application/octet-stream, Size: 11118 bytes --]
Index: alsa-kernel/core/pcm.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm.c,v
retrieving revision 1.20
diff -u -r1.20 pcm.c
--- alsa-kernel/core/pcm.c 4 Dec 2002 09:37:21 -0000 1.20
+++ alsa-kernel/core/pcm.c 16 Dec 2002 14:04:21 -0000
@@ -774,6 +774,7 @@
runtime->status->state = SNDRV_PCM_STATE_OPEN;
substream->runtime = runtime;
+ substream->private_data = pcm->private_data;
pstr->substream_opened++;
*rsubstream = substream;
return 0;
Index: alsa-kernel/include/ad1848.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/ad1848.h,v
retrieving revision 1.4
diff -u -r1.4 ad1848.h
--- alsa-kernel/include/ad1848.h 13 Aug 2002 16:17:06 -0000 1.4
+++ alsa-kernel/include/ad1848.h 16 Dec 2002 14:35:52 -0000
@@ -162,6 +162,7 @@
ad1848_t ** chip);
int snd_ad1848_pcm(ad1848_t * chip, int device, snd_pcm_t **rpcm);
+const snd_pcm_ops_t *snd_ad1848_get_pcm_ops(int direction);
int snd_ad1848_mixer(ad1848_t * chip);
void snd_ad1848_interrupt(int irq, void *dev_id, struct pt_regs *regs);
Index: alsa-kernel/include/pcm.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/pcm.h,v
retrieving revision 1.21
diff -u -r1.21 pcm.h
--- alsa-kernel/include/pcm.h 2 Dec 2002 09:25:18 -0000 1.21
+++ alsa-kernel/include/pcm.h 16 Dec 2002 14:03:06 -0000
@@ -50,7 +50,7 @@
typedef struct sndrv_pcm_mmap_control snd_pcm_mmap_control_t;
typedef struct sndrv_mask snd_mask_t;
-#define _snd_pcm_substream_chip(substream) ((substream)->pcm->private_data)
+#define _snd_pcm_substream_chip(substream) ((substream)->private_data)
#define snd_pcm_substream_chip(substream) snd_magic_cast1(chip_t, _snd_pcm_substream_chip(substream), return -ENXIO)
#define _snd_pcm_chip(pcm) ((pcm)->private_data)
#define snd_pcm_chip(pcm) snd_magic_cast1(chip_t, _snd_pcm_chip(pcm), return -ENXIO)
@@ -363,6 +363,7 @@
struct _snd_pcm_substream {
snd_pcm_t *pcm;
snd_pcm_str_t *pstr;
+ void *private_data; /* copied from pcm->private_data */
int number;
char name[32]; /* substream name */
int stream; /* stream (direction) */
Index: alsa-kernel/include/sb.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/sb.h,v
retrieving revision 1.7
diff -u -r1.7 sb.h
--- alsa-kernel/include/sb.h 9 Dec 2002 10:52:24 -0000 1.7
+++ alsa-kernel/include/sb.h 16 Dec 2002 14:36:01 -0000
@@ -305,6 +305,7 @@
/* sb16_init.c */
int snd_sb16dsp_pcm(sb_t *chip, int device, snd_pcm_t ** rpcm);
+const snd_pcm_ops_t *snd_sb16dsp_get_pcm_ops(int direction);
int snd_sb16dsp_configure(sb_t *chip);
/* sb16.c */
void snd_sb16dsp_interrupt(int irq, void *dev_id, struct pt_regs *regs);
Index: alsa-kernel/isa/cmi8330.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/cmi8330.c,v
retrieving revision 1.10
diff -u -r1.10 cmi8330.c
--- alsa-kernel/isa/cmi8330.c 22 Oct 2002 09:37:24 -0000 1.10
+++ alsa-kernel/isa/cmi8330.c 16 Dec 2002 15:01:19 -0000
@@ -147,6 +147,15 @@
struct isapnp_dev *cap;
struct isapnp_dev *play;
#endif
+ snd_card_t *card;
+ ad1848_t *wss;
+ sb_t *sb;
+
+ snd_pcm_t *pcm;
+ snd_pcm_ops_t playback_ops;
+ int (*playback_open)(snd_pcm_substream_t *);
+ snd_pcm_ops_t capture_ops;
+ int (*capture_open)(snd_pcm_substream_t *);
};
static snd_card_t *snd_cmi8330_cards[SNDRV_CARDS] = SNDRV_DEFAULT_PTR;
@@ -294,6 +303,79 @@
}
#endif
+/*
+ * PCM interface
+ *
+ * since we call the different chip interfaces for playback and capture
+ * directions, we need a trick.
+ *
+ * - copy the ops for each direction into a local record.
+ * - replace the open callback with the new one, which replaces the
+ * substream->private_data with the corresponding chip instance
+ * and calls again the original open callback of the chip.
+ *
+ */
+
+static int snd_cmi8330_playback_open(snd_pcm_substream_t * substream)
+{
+ struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
+
+ /* replace the private_data and call the original open callback */
+ substream->private_data = chip->sb;
+ return chip->playback_open(substream);
+}
+
+static int snd_cmi8330_capture_open(snd_pcm_substream_t * substream)
+{
+ struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
+
+ /* replace the private_data and call the original open callback */
+ substream->private_data = chip->wss;
+ return chip->capture_open(substream);
+}
+
+static void snd_cmi8330_pcm_free(snd_pcm_t *pcm)
+{
+ snd_pcm_lib_preallocate_free_for_all(pcm);
+}
+
+static int __init snd_cmi8330_pcm(snd_card_t *card, struct snd_cmi8330 *chip)
+{
+ snd_pcm_t *pcm;
+ const snd_pcm_ops_t *ops;
+ int err;
+
+ if ((err = snd_pcm_new(card, "CMI8330", 0, 1, 1, &pcm)) < 0)
+ return err;
+ strcpy(pcm->name, "CMI8330");
+ pcm->private_data = chip;
+ pcm->private_free = snd_cmi8330_pcm_free;
+
+ /* playback - SB16 */
+ ops = snd_sb16dsp_get_pcm_ops(SNDRV_PCM_STREAM_PLAYBACK);
+ chip->playback_ops = *ops;
+ chip->playback_open = ops->open;
+ chip->playback_ops.open = snd_cmi8330_playback_open;
+
+ /* capture - AD1848 */
+ ops = snd_ad1848_get_pcm_ops(SNDRV_PCM_STREAM_CAPTURE);
+ chip->capture_ops = *ops;
+ chip->capture_open = ops->open;
+ chip->capture_ops.open = snd_cmi8330_capture_open;
+
+ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->playback_ops);
+ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->capture_ops);
+
+ snd_pcm_lib_preallocate_isa_pages_for_all(pcm, 64*1024, 128*1024);
+ chip->pcm = pcm;
+
+ return 0;
+}
+
+
+/*
+ */
+
static void snd_cmi8330_free(snd_card_t *card)
{
struct snd_cmi8330 *acard = (struct snd_cmi8330 *)card->private_data;
@@ -309,12 +391,8 @@
{
snd_card_t *card;
struct snd_cmi8330 *acard;
- ad1848_t *chip_wss;
- sb_t *chip_sb;
unsigned long flags;
int i, err;
- snd_pcm_t *pcm, *wss_pcm, *sb_pcm;
- snd_pcm_str_t *pstr;
#ifdef __ISAPNP__
if (!isapnp[dev]) {
@@ -337,6 +415,7 @@
return -ENOMEM;
}
acard = (struct snd_cmi8330 *)card->private_data;
+ acard->card = card;
card->private_free = snd_cmi8330_free;
#ifdef __ISAPNP__
@@ -352,83 +431,60 @@
wssirq[dev],
wssdma[dev],
AD1848_HW_DETECT,
- &chip_wss)) < 0) {
+ &acard->wss)) < 0) {
snd_printk("(AD1848) device busy??\n");
snd_card_free(card);
return err;
}
- if (chip_wss->hardware != AD1848_HW_CMI8330) {
+ if (acard->wss->hardware != AD1848_HW_CMI8330) {
snd_printk("(AD1848) not found during probe\n");
snd_card_free(card);
return -ENODEV;
}
- if ((err = snd_ad1848_pcm(chip_wss, 0, &wss_pcm)) < 0) {
- snd_printk("(AD1848) no enough memory??\n");
- snd_card_free(card);
- return err;
- }
if ((err = snd_sbdsp_create(card, sbport[dev],
sbirq[dev],
snd_sb16dsp_interrupt,
sbdma8[dev],
sbdma16[dev],
- SB_HW_AUTO, &chip_sb)) < 0) {
+ SB_HW_AUTO, &acard->sb)) < 0) {
snd_printk("(SB16) device busy??\n");
snd_card_free(card);
return err;
}
- if ((err = snd_sb16dsp_pcm(chip_sb, 1, &sb_pcm)) < 0) {
- snd_printk("(SB16) no enough memory??\n");
- snd_card_free(card);
- return err;
- }
-
- if (chip_sb->hardware != SB_HW_16) {
+ if (acard->sb->hardware != SB_HW_16) {
snd_printk("(SB16) not found during probe\n");
snd_card_free(card);
return -ENODEV;
}
+ memcpy(&acard->wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
- memcpy(&chip_wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
+ spin_lock_irqsave(&acard->wss->reg_lock, flags);
+ snd_ad1848_out(acard->wss, AD1848_MISC_INFO, /* switch on MODE2 */
+ acard->wss->image[AD1848_MISC_INFO] |= 0x40);
+ spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
- spin_lock_irqsave(&chip_wss->reg_lock, flags);
- snd_ad1848_out(chip_wss, AD1848_MISC_INFO, /* switch on MODE2 */
- chip_wss->image[AD1848_MISC_INFO] |= 0x40);
- spin_unlock_irqrestore(&chip_wss->reg_lock, flags);
-
- if ((err = snd_cmi8330_mixer(card, chip_wss)) < 0) {
+ if ((err = snd_cmi8330_mixer(card, acard->wss)) < 0) {
snd_printk("failed to create mixers\n");
snd_card_free(card);
return err;
}
- spin_lock_irqsave(&chip_wss->reg_lock, flags);
+ spin_lock_irqsave(&acard->wss->reg_lock, flags);
for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
- snd_ad1848_out(chip_wss, i, chip_wss->image[i]);
- spin_unlock_irqrestore(&chip_wss->reg_lock, flags);
+ snd_ad1848_out(acard->wss, i, acard->wss->image[i]);
+ spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
- /*
- * KLUDGE ALERT
- * disable AD1848 playback
- * disable SB16 capture
- */
- pcm = wss_pcm;
- pstr = &pcm->streams[SNDRV_PCM_STREAM_PLAYBACK];
- snd_magic_kfree(pstr->substream);
- pstr->substream = 0;
- pstr->substream_count = 0;
-
- pcm = sb_pcm;
- pstr = &pcm->streams[SNDRV_PCM_STREAM_CAPTURE];
- snd_magic_kfree(pstr->substream);
- pstr->substream = 0;
- pstr->substream_count = 0;
+ if ((err = snd_cmi8330_pcm(card, acard)) < 0) {
+ snd_printk("failed to create pcms\n");
+ snd_card_free(card);
+ return err;
+ }
strcpy(card->driver, "CMI8330/C3D");
strcpy(card->shortname, "C-Media CMI8330/C3D");
sprintf(card->longname, "%s at 0x%lx, irq %d, dma %d",
- wss_pcm->name,
- chip_wss->port,
+ card->shortname,
+ acard->wss->port,
wssirq[dev],
wssdma[dev]);
Index: alsa-kernel/isa/ad1848/ad1848_lib.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/ad1848/ad1848_lib.c,v
retrieving revision 1.17
diff -u -r1.17 ad1848_lib.c
--- alsa-kernel/isa/ad1848/ad1848_lib.c 25 Nov 2002 10:13:55 -0000 1.17
+++ alsa-kernel/isa/ad1848/ad1848_lib.c 16 Dec 2002 14:35:39 -0000
@@ -936,6 +936,12 @@
return 0;
}
+const snd_pcm_ops_t *snd_ad1848_get_pcm_ops(int direction)
+{
+ return direction == SNDRV_PCM_STREAM_PLAYBACK ?
+ &snd_ad1848_playback_ops : &snd_ad1848_capture_ops;
+}
+
/*
* MIXER part
*/
@@ -1160,6 +1166,7 @@
EXPORT_SYMBOL(snd_ad1848_interrupt);
EXPORT_SYMBOL(snd_ad1848_create);
EXPORT_SYMBOL(snd_ad1848_pcm);
+EXPORT_SYMBOL(snd_ad1848_get_pcm_ops);
EXPORT_SYMBOL(snd_ad1848_mixer);
EXPORT_SYMBOL(snd_ad1848_info_single);
EXPORT_SYMBOL(snd_ad1848_get_single);
Index: alsa-kernel/isa/sb/sb16_main.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb16_main.c,v
retrieving revision 1.11
diff -u -r1.11 sb16_main.c
--- alsa-kernel/isa/sb/sb16_main.c 25 Nov 2002 10:13:56 -0000 1.11
+++ alsa-kernel/isa/sb/sb16_main.c 16 Dec 2002 14:35:02 -0000
@@ -887,7 +887,14 @@
return 0;
}
+const snd_pcm_ops_t *snd_sb16dsp_get_pcm_ops(int direction)
+{
+ return direction == SNDRV_PCM_STREAM_PLAYBACK ?
+ &snd_sb16_playback_ops : &snd_sb16_capture_ops;
+}
+
EXPORT_SYMBOL(snd_sb16dsp_pcm);
+EXPORT_SYMBOL(snd_sb16dsp_get_pcm_ops);
EXPORT_SYMBOL(snd_sb16dsp_configure);
EXPORT_SYMBOL(snd_sb16dsp_interrupt);
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-16 15:12 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <3DFA25F1.2000705@gmx.de>
At Fri, 13 Dec 2002 19:24:49 +0100,
Friedrich Ewaldt wrote:
>
> Takashi Iwai wrote:
>
> >>lspci -n output:
> >>
> >>00:0b.0 Class 0401: 1319:0801 (rev a0)
> >>00:0b.1 Class 0980: 1319:0801 (rev a0)
> >>
> >>
> >
> >thanks, could you try the attached patch?
> >at least, the weird messages for allocation of invalid i/o ports
> >should disappear. not sure whether this cures the lock-up problem,
> >though.
> >
> >
> >Takashi
> >
> >
> done. The error in /var/log/messages doesn't appear any longer (I only
> get these 'sharing IRQ ...' messages). Thanks! But the system still
> locks up when stopping playback :-(
to be sure, could you elaborate the symptom again and the detail of
your system (kernel version, applied patches, ALSA version)?
especially, please check the following:
- loading the module and unloading it immediately works?
- the port and irq number are correct, i.e. match with the resources
listed on lspci?
- playback (via aplay) works? does the system hang up at the start,
during the playback or at the stop?
- during the playback, does the count in /proc/interrupts increases?
(check with another terminal)
a typical reason of such a hang up is either the wrong spinlocks,
unexpected infinite loops in the driver code, or the interrupt
storms. if it's the interrupt storm, then it can be related with the
hardware, often motherboard chipset, or BIOS version.
or, could it be because of ACPI? did you apply it?
ciao,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Linux v2.5.52
From: Ben Collins @ 2002-12-16 15:16 UTC (permalink / raw)
To: Christoph Hellwig, Linus Torvalds, Kernel Mailing List
In-Reply-To: <20021216102639.A27589@infradead.org>
On Mon, Dec 16, 2002 at 10:26:40AM +0000, Christoph Hellwig wrote:
> On Sun, Dec 15, 2002 at 07:34:09PM -0800, Linus Torvalds wrote:
> > Ben Collins <bcollins@debian.org>:
> > o IEEE-1394/Firewire update
>
> This merge looks fishy. It seems to be yet another let's throw my CVS
> repo in merge and backs out Al's work yo get rid of lots of devfs crap.
Quit talking shit. I go through a lot of effort to merge in changes sent
to Linus' tree into the Linux1394 repo. I don't just dump changes for no
good reason.
How about pointing out some specifics? Maybe make my job easier by
getting me some patches directly. Trying to track two seperate source
tree's isn't as easy as you might think.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-16 15:08 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021216150442.GJ6095@opus.bloom.county>
On Mon, Dec 16, 2002 at 08:04:42AM -0700, Tom Rini wrote:
>
> On Sun, Dec 15, 2002 at 05:41:20PM -0700, Cort Dougan wrote:
>
> > } 4xx in particular is a problem because I'm not convinced about the
> > } approach that has been taken for some of the 4xx infrastructure. The
> > } ocp stuff seems a lot more complicated than it needs to be, for
> > } instance. There is no particular reason that I can see why the 8xx
> > } stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
> >
> > How about a linuxppc_2_4 that is a child of Marcelo's. Then a
> > linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
> > tree? It would make integration much much easier. Right now the
> > diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
> > I think it would be hard to arrest that growth without switching to a
> > Macelo based tree.
>
> I'm not sure how that would stop the growth of the '_devel' tree, it
> would just split it up into 4xx, and everything else. And my goal of
> the new few weeks is to try and move everything that's not 4xx that I
> can get my hands on to test into the _2_4 tree. I'm not sure just how
> much of that I'll actually be able to do, but I'm going to try.
... with the exception of the current gt64260 code, which will hopefully
get an update so that it could move up-and-out. But no promises there.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-16 15:04 UTC (permalink / raw)
To: Cort Dougan; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021215174120.E30568@duath.fsmlabs.com>
On Sun, Dec 15, 2002 at 05:41:20PM -0700, Cort Dougan wrote:
> } 4xx in particular is a problem because I'm not convinced about the
> } approach that has been taken for some of the 4xx infrastructure. The
> } ocp stuff seems a lot more complicated than it needs to be, for
> } instance. There is no particular reason that I can see why the 8xx
> } stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
>
> How about a linuxppc_2_4 that is a child of Marcelo's. Then a
> linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
> tree? It would make integration much much easier. Right now the
> diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
> I think it would be hard to arrest that growth without switching to a
> Macelo based tree.
I'm not sure how that would stop the growth of the '_devel' tree, it
would just split it up into 4xx, and everything else. And my goal of
the new few weeks is to try and move everything that's not 4xx that I
can get my hands on to test into the _2_4 tree. I'm not sure just how
much of that I'll actually be able to do, but I'm going to try.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.