CONFIG_X86_UP_APIC undocumented
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
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
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
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/
KERN_ERR for missing codecs?
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
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
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
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/
Cannot unmount ramfs after chmod
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/
Re: [PATCH] 2.4.1ac12 mkdep -I support - take 2
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
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
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
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
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/
Re: [patch] 2.4 add suffix for uname -r
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
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
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
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
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/
Re: VIA/PDC/Athlon
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?
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?
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
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)
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)
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/
[PATCH] Initial permissions on ramfs
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
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
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
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/
[PATCH] 2.4.4-ac3 +IPX -SYSCTL compile fix
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
> +#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
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
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/
YMF PCI - thanks, glitches, patches (fwd)
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)
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)
> > 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)
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
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
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)
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?
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
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
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/
Weird hidden /dev/audio on devfs
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
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: 2.4.1-ac10 compile error
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/
ACPI + Promise IDE = disk corruption :-(((
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
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/
