* [PATCH 2.4-ac] Via 8233 Sound not working
From: Nathaniel Russell @ 2002-12-12 20:08 UTC (permalink / raw)
To: alan; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 251 bytes --]
I needed this patch to compile so i just commented the
synchronize_irq bit out. I have included the patch and the error message.
This is a temp fix i don't know if this is correct or not.
Nathaniel
CC me at reddog83@chartermi.net as im not subscribed
[-- Attachment #2: Via 8233 --]
[-- Type: TEXT/PLAIN, Size: 421 bytes --]
diff -urN linux-ac/drivers/sound/via82cxxx_audio.c linux/drivers/sound/via82cxxx_audio.c
--- linux-ac/drivers/sound/via82cxxx_audio.c 2002-12-12 03:21:04.000000000 -0500
+++ linux/drivers/sound/via82cxxx_audio.c 2002-12-12 14:54:36.000000000 -0500
@@ -885,7 +885,7 @@
spin_unlock_irq (&card->lock);
- synchronize_irq(card->pdev->irq);
+/* synchronize_irq(card->pdev->irq); */
DPRINTK ("EXIT\n");
}
[-- Attachment #3: Error Message from Compile --]
[-- Type: TEXT/PLAIN, Size: 468 bytes --]
via82cxxx_audio.c:888:40: macro "synchronize_irq" passed 1 arguments, but takes just 0
via82cxxx_audio.c: In function `via_chan_free':
via82cxxx_audio.c:888: `synchronize_irq' undeclared (first use in this function)
via82cxxx_audio.c:888: (Each undeclared identifier is reported only once
via82cxxx_audio.c:888: for each function it appears in.)
make[2]: *** [via82cxxx_audio.o] Error 1
make[1]: *** [_modsubdir_sound] Error 2
make: *** [_mod_drivers] Error 2
^ permalink raw reply
* Re: slram and buffer cache
From: Jochen Schaeuble @ 2002-12-12 20:28 UTC (permalink / raw)
To: Tobias Otto-Adamczak; +Cc: linux-mtd
In-Reply-To: <Pine.LNX.4.31.0212112004250.12431-100000@www.optixsoft.de>
Hi,
I haven't used mtdblock for a while now so I'm not absolutely sure if
this is correct. The "cache_size" of the mtdblock driver is initialized
with the erasesize specified in the slram driver (0x10000 if you haven't
changed anything). If you want uncached operation you should set this
value to
(*curmtd)->mtdinfo->erasesize = 0x0; (slram.c line 180).
I had no time to check this but from reading the source I think this is
correct. Please let me know if this works for you. If so it might be a
good idea to make this size configurable.
Greets,
Jochen
On Wed, Dec 11, 2002 at 08:23:02PM +0100, Tobias Otto-Adamczak wrote:
> Hi,
>
> I have a custom board with 32MB SDRAM, 16MB Flash and 512K SRAM here. I
> use the slram driver to access the SRAM (which isn't used otherwise by
> the kernel). I created an 512K ext2 fs image and copied it to the SRAM
> using an mtd char dev. I was able to mount this SRAM area as a mtd block
> device (using mtdblock_ro) and read/write files to the ext2 fs.
>
> My problem is the buffer cache for the block devices. I do not want
> write operations to the SRAM being delayed. What can I do to avoid that
> ? I searched for some hours today but to no avail.
>
> [maybe OT for this list]
> How is this problem solved for "normal" ram disks ?
>
> Regards
> Tobias
>
^ permalink raw reply
* Re: [Linux-ia64] [PATCH] fix /proc/.../vm_info
From: David Mosberger @ 2002-12-12 19:56 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805552@msgid-missing>
>>>>> On Thu, 12 Dec 2002 14:49:10 +0100, Christian Hildner <christian.hildner@hob.de> said:
Christian> Hi, in vm_info the information about the supported memory
Christian> attributes is wrong. The patch is based on 2.4.18, but it
Christian> should also work for 2.4.20 and 2.5.x. Please apply.
I'd like to keep the output a bit more concise. How about the attached
patch (untested)?
--david
=== arch/ia64/kernel/palinfo.c 1.7 vs edited ==--- 1.7/arch/ia64/kernel/palinfo.c Sun Dec 1 22:17:31 2002
+++ edited/arch/ia64/kernel/palinfo.c Thu Dec 12 11:54:24 2002
@@ -101,26 +101,15 @@
#define RSE_HINTS_COUNT (sizeof(rse_hints)/sizeof(const char *))
-/*
- * The current revision of the Volume 2 (July 2000) of
- * IA-64 Architecture Software Developer's Manual is wrong.
- * Table 4-10 has invalid information concerning the ma field:
- * Correct table is:
- * bit 0 - 001 - UC
- * bit 4 - 100 - UC
- * bit 5 - 101 - UCE
- * bit 6 - 110 - WC
- * bit 7 - 111 - NatPage
- */
static const char *mem_attrib[]={
- "Write Back (WB)", /* 000 */
- "Uncacheable (UC)", /* 001 */
- "Reserved", /* 010 */
- "Reserved", /* 011 */
- "Uncacheable (UC)", /* 100 */
- "Uncacheable Exported (UCE)", /* 101 */
- "Write Coalescing (WC)", /* 110 */
- "NaTPage" /* 111 */
+ "WB", /* 000 */
+ "UC", /* 001 */
+ "010", /* 010 */
+ "011", /* 011 */
+ "UC", /* 100 */
+ "UCE", /* 101 */
+ "WC", /* 110 */
+ "NaTPage" /* 111 */
};
/*
@@ -315,6 +304,7 @@
pal_vm_info_2_u_t vm_info_2;
pal_tc_info_u_t tc_info;
ia64_ptce_info_t ptce;
+ const char *sep;
int i, j;
s64 status;
@@ -339,7 +329,14 @@
if (ia64_pal_mem_attrib(&attrib) != 0) return 0;
- p += sprintf(p, "Supported memory attributes : %s\n", mem_attrib[attrib&0x7]);
+ p += sprintf(p, "Supported memory attributes : ");
+ sep = "";
+ for (i = 0; i < 8; i++) {
+ if (attrib & (1 << i)) {
+ p += sprintf(p, "%s%s\n", sep, mem_attrib[i]);
+ sep = ", ";
+ }
+ }
if ((status=ia64_pal_vm_page_size(&tr_pages, &vw_pages)) !=0) {
printk("ia64_pal_vm_page_size=%ld\n", status);
^ permalink raw reply
* Re: Kernel bug handling TCP_RTO_MAX?
From: David S. Miller @ 2002-12-12 19:58 UTC (permalink / raw)
To: stefano.andreani.ap; +Cc: linux-kernel, linux-net
In-Reply-To: <047ACC5B9A00D741927A4A32E7D01B73D66176@RMEXC01.h3g.it>
From: "Andreani Stefano" <stefano.andreani.ap@h3g.it>
Date: Thu, 12 Dec 2002 20:15:42 +0100
Problem: I need to change the max value of the TCP retransmission
timeout.
Why? There should be zero reason to change this value.
^ permalink raw reply
* [PATCH] C99 initializers for kernel/sysctl.c
From: Stephen Hemminger @ 2002-12-12 20:01 UTC (permalink / raw)
To: Kernel List; +Cc: Linus Torvalds
Here is a patch for sysctl.c that converts it to use C99 initializers.
This patch is against 2.5.51
--- linux-2.5/kernel/sysctl.c 2002-12-02 09:39:02.000000000 -0800
+++ linux-2.5-new/kernel/sysctl.c 2002-12-12 11:17:22.000000000 -0800
@@ -105,8 +105,10 @@
void *buffer, size_t *lenp);
static ctl_table root_table[];
-static struct ctl_table_header root_table_header =
- { root_table, LIST_HEAD_INIT(root_table_header.ctl_entry) };
+static struct ctl_table_header root_table_header = {
+ .ctl_table = root_table,
+ .ctl_entry = LIST_HEAD_INIT(root_table_header.ctl_entry),
+};
static ctl_table kern_table[];
static ctl_table vm_table[];
@@ -145,120 +147,305 @@
/* The default sysctl tables: */
static ctl_table root_table[] = {
- {CTL_KERN, "kernel", NULL, 0, 0555, kern_table},
- {CTL_VM, "vm", NULL, 0, 0555, vm_table},
+ { .ctl_name = CTL_KERN,
+ .procname = "kernel",
+ .mode = 0555,
+ .child = kern_table, },
+ { .ctl_name = CTL_VM,
+ .procname = "vm",
+ .mode = 0555,
+ .child = vm_table, },
#ifdef CONFIG_NET
- {CTL_NET, "net", NULL, 0, 0555, net_table},
+ { .ctl_name = CTL_NET,
+ .procname = "net",
+ .mode = 0555,
+ .child = net_table, },
#endif
- {CTL_PROC, "proc", NULL, 0, 0555, proc_table},
- {CTL_FS, "fs", NULL, 0, 0555, fs_table},
- {CTL_DEBUG, "debug", NULL, 0, 0555, debug_table},
- {CTL_DEV, "dev", NULL, 0, 0555, dev_table},
+ { .ctl_name = CTL_PROC,
+ .procname = "proc",
+ .mode = 0555,
+ .child = proc_table, },
+ { .ctl_name = CTL_FS,
+ .procname = "fs",
+ .mode = 0555,
+ .child = fs_table, },
+ { .ctl_name = CTL_DEBUG,
+ .procname = "debug",
+ .mode = 0555,
+ .child = debug_table, },
+ { .ctl_name = CTL_DEV,
+ .procname = "dev",
+ .mode = 0555,
+ .child = dev_table, },
{0}
};
static ctl_table kern_table[] = {
- {KERN_OSTYPE, "ostype", system_utsname.sysname, 64,
- 0444, NULL, &proc_doutsstring, &sysctl_string},
- {KERN_OSRELEASE, "osrelease", system_utsname.release, 64,
- 0444, NULL, &proc_doutsstring, &sysctl_string},
- {KERN_VERSION, "version", system_utsname.version, 64,
- 0444, NULL, &proc_doutsstring, &sysctl_string},
- {KERN_NODENAME, "hostname", system_utsname.nodename, 64,
- 0644, NULL, &proc_doutsstring, &sysctl_string},
- {KERN_DOMAINNAME, "domainname", system_utsname.domainname, 64,
- 0644, NULL, &proc_doutsstring, &sysctl_string},
- {KERN_PANIC, "panic", &panic_timeout, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_CORE_USES_PID, "core_uses_pid", &core_uses_pid, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_CORE_PATTERN, "core_pattern", core_pattern, 64,
- 0644, NULL, &proc_dostring, &sysctl_string},
- {KERN_TAINTED, "tainted", &tainted, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t),
- 0600, NULL, &proc_dointvec_bset},
+ { .ctl_name = KERN_OSTYPE,
+ .procname = "ostype",
+ .data = system_utsname.sysname,
+ .maxlen = 64,
+ .mode = 0444,
+ .proc_handler = &proc_doutsstring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_OSRELEASE,
+ .procname = "osrelease",
+ .data = system_utsname.release,
+ .maxlen = 64,
+ .mode = 0444,
+ .proc_handler = &proc_doutsstring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_VERSION,
+ .procname = "version",
+ .data = system_utsname.version,
+ .maxlen = 64,
+ .mode = 0444,
+ .proc_handler = &proc_doutsstring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_NODENAME,
+ .procname = "hostname",
+ .data = system_utsname.nodename,
+ .maxlen = 64,
+ .mode = 0644,
+ .proc_handler = &proc_doutsstring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_DOMAINNAME,
+ .procname = "domainname",
+ .data = system_utsname.domainname,
+ .maxlen = 64,
+ .mode = 0644,
+ .proc_handler = &proc_doutsstring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_PANIC,
+ .procname = "panic",
+ .data = &panic_timeout,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_CORE_USES_PID,
+ .procname = "core_uses_pid",
+ .data = &core_uses_pid,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_CORE_PATTERN,
+ .procname = "core_pattern",
+ .data = core_pattern,
+ .maxlen = 64,
+ .mode = 0644,
+ .proc_handler = &proc_dostring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_TAINTED,
+ .procname = "tainted",
+ .data = &tainted,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_CAP_BSET,
+ .procname = "cap-bound",
+ .data = &cap_bset,
+ .maxlen = sizeof(kernel_cap_t),
+ .mode = 0600,
+ .proc_handler = &proc_dointvec_bset, },
#ifdef CONFIG_BLK_DEV_INITRD
- {KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_REALROOTDEV,
+ .procname = "real-root-dev",
+ .data = &real_root_dev,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
#ifdef __sparc__
- {KERN_SPARC_REBOOT, "reboot-cmd", reboot_command,
- 256, 0644, NULL, &proc_dostring, &sysctl_string },
- {KERN_SPARC_STOP_A, "stop-a", &stop_a_enabled, sizeof (int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_SPARC_REBOOT,
+ .procname = "reboot-cmd",
+ .data = reboot_command,
+ .maxlen = 256,
+ .mode = 0644,
+ .proc_handler = &proc_dostring,
+ .strategy = &sysctl_string, },
+ { .ctl_name = KERN_SPARC_STOP_A,
+ .procname = "stop-a",
+ .data = &stop_a_enabled,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
#if defined(CONFIG_PPC32) && defined(CONFIG_6xx)
- {KERN_PPC_POWERSAVE_NAP, "powersave-nap", &powersave_nap, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_PPC_L2CR, "l2cr", NULL, 0,
- 0644, NULL, &proc_dol2crvec},
+ { .ctl_name = KERN_PPC_POWERSAVE_NAP,
+ .procname = "powersave-nap",
+ .data = &powersave_nap,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_PPC_L2CR,
+ .procname = "l2cr",
+ .mode = 0644,
+ .proc_handler = &proc_dol2crvec, },
#endif
- {KERN_CTLALTDEL, "ctrl-alt-del", &C_A_D, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_PRINTK, "printk", &console_loglevel, 4*sizeof(int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_CTLALTDEL,
+ .procname = "ctrl-alt-del",
+ .data = &C_A_D,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_PRINTK,
+ .procname = "printk",
+ &console_loglevel, 4*sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#ifdef CONFIG_KMOD
- {KERN_MODPROBE, "modprobe", &modprobe_path, 256,
- 0644, NULL, &proc_dostring, &sysctl_string },
+ { .ctl_name = KERN_MODPROBE,
+ .procname = "modprobe",
+ .data = &modprobe_path,
+ .maxlen = 256,
+ .mode = 0644,
+ .proc_handler = &proc_dostring,
+ .strategy = &sysctl_string, },
#endif
#ifdef CONFIG_HOTPLUG
- {KERN_HOTPLUG, "hotplug", &hotplug_path, 256,
- 0644, NULL, &proc_dostring, &sysctl_string },
+ { .ctl_name = KERN_HOTPLUG,
+ .procname = "hotplug",
+ .data = &hotplug_path,
+ .maxlen = 256,
+ .mode = 0644,
+ .proc_handler = &proc_dostring,
+ .strategy = &sysctl_string, },
#endif
#ifdef CONFIG_CHR_DEV_SG
- {KERN_SG_BIG_BUFF, "sg-big-buff", &sg_big_buff, sizeof (int),
- 0444, NULL, &proc_dointvec},
+ { .ctl_name = KERN_SG_BIG_BUFF,
+ .procname = "sg-big-buff",
+ .data = &sg_big_buff,
+ .maxlen = sizeof (int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
#endif
#ifdef CONFIG_BSD_PROCESS_ACCT
- {KERN_ACCT, "acct", &acct_parm, 3*sizeof(int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_ACCT,
+ .procname = "acct",
+ .data = &acct_parm,
+ .maxlen = 3*sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
- {KERN_RTSIGNR, "rtsig-nr", &nr_queued_signals, sizeof(int),
- 0444, NULL, &proc_dointvec},
- {KERN_RTSIGMAX, "rtsig-max", &max_queued_signals, sizeof(int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_RTSIGNR,
+ .procname = "rtsig-nr",
+ .data = &nr_queued_signals,
+ .maxlen = sizeof(int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_RTSIGMAX,
+ .procname = "rtsig-max",
+ .data = &max_queued_signals,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#ifdef CONFIG_SYSVIPC
- {KERN_SHMMAX, "shmmax", &shm_ctlmax, sizeof (size_t),
- 0644, NULL, &proc_doulongvec_minmax},
- {KERN_SHMALL, "shmall", &shm_ctlall, sizeof (size_t),
- 0644, NULL, &proc_doulongvec_minmax},
- {KERN_SHMMNI, "shmmni", &shm_ctlmni, sizeof (int),
- 0644, NULL, &proc_dointvec},
- {KERN_MSGMAX, "msgmax", &msg_ctlmax, sizeof (int),
- 0644, NULL, &proc_dointvec},
- {KERN_MSGMNI, "msgmni", &msg_ctlmni, sizeof (int),
- 0644, NULL, &proc_dointvec},
- {KERN_MSGMNB, "msgmnb", &msg_ctlmnb, sizeof (int),
- 0644, NULL, &proc_dointvec},
- {KERN_SEM, "sem", &sem_ctls, 4*sizeof (int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_SHMMAX,
+ .procname = "shmmax",
+ .data = &shm_ctlmax,
+ .maxlen = sizeof (size_t),
+ .mode = 0644,
+ .proc_handler = &proc_doulongvec_minmax, },
+ { .ctl_name = KERN_SHMALL,
+ .procname = "shmall",
+ .data = &shm_ctlall,
+ .maxlen = sizeof (size_t),
+ .mode = 0644,
+ .proc_handler = &proc_doulongvec_minmax, },
+ { .ctl_name = KERN_SHMMNI,
+ .procname = "shmmni",
+ .data = &shm_ctlmni,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_MSGMAX,
+ .procname = "msgmax",
+ .data = &msg_ctlmax,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_MSGMNI,
+ .procname = "msgmni",
+ .data = &msg_ctlmni,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_MSGMNB,
+ .procname = "msgmnb",
+ .data = &msg_ctlmnb,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_SEM,
+ .procname = "sem",
+ .data = &sem_ctls,
+ .maxlen = 4*sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
#ifdef CONFIG_MAGIC_SYSRQ
- {KERN_SYSRQ, "sysrq", &sysrq_enabled, sizeof (int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = KERN_SYSRQ,
+ .procname = "sysrq",
+ .data = &sysrq_enabled,
+ .maxlen = sizeof (int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
- {KERN_CADPID, "cad_pid", &cad_pid, sizeof (int),
- 0600, NULL, &proc_dointvec},
- {KERN_MAX_THREADS, "threads-max", &max_threads, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {KERN_RANDOM, "random", NULL, 0, 0555, random_table},
- {KERN_OVERFLOWUID, "overflowuid", &overflowuid, sizeof(int), 0644,
NULL,
- &proc_dointvec_minmax, &sysctl_intvec, NULL,
- &minolduid, &maxolduid},
- {KERN_OVERFLOWGID, "overflowgid", &overflowgid, sizeof(int), 0644,
NULL,
- &proc_dointvec_minmax, &sysctl_intvec, NULL,
- &minolduid, &maxolduid},
+ { .ctl_name = KERN_CADPID,
+ .procname = "cad_pid",
+ .data = &cad_pid,
+ .maxlen = sizeof (int),
+ .mode = 0600,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_MAX_THREADS,
+ .procname = "threads-max",
+ .data = &max_threads,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = KERN_RANDOM,
+ .procname = "random",
+ .mode = 0555,
+ .child = random_table, },
+ { .ctl_name = KERN_OVERFLOWUID,
+ .procname = "overflowuid",
+ .data = &overflowuid,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &minolduid, .extra2 = &maxolduid, },
+ { .ctl_name = KERN_OVERFLOWGID,
+ .procname = "overflowgid",
+ .data = &overflowgid,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &minolduid, .extra2 = &maxolduid, },
+
#ifdef CONFIG_ARCH_S390
#ifdef CONFIG_MATHEMU
- {KERN_IEEE_EMULATION_WARNINGS,"ieee_emulation_warnings",
-
&sysctl_ieee_emulation_warnings,sizeof(int),0644,NULL,&proc_dointvec},
+ { .ctl_name = KERN_IEEE_EMULATION_WARNINGS,
+ .procname = "ieee_emulation_warnings",
+ .data = &sysctl_ieee_emulation_warnings,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
- {KERN_S390_USER_DEBUG_LOGGING,"userprocess_debug",
- &sysctl_userprocess_debug,sizeof(int),0644,NULL,&proc_dointvec},
+ { .ctl_name = KERN_S390_USER_DEBUG_LOGGING,
+ .procname = "userprocess_debug",
+ .data = &sysctl_userprocess_debug,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
#endif
- {KERN_PIDMAX, "pid_max", &pid_max, sizeof (int),
- 0600, NULL, &proc_dointvec},
+ { .ctl_name = KERN_PIDMAX,
+ .procname = "pid_max",
+ .data = &pid_max,
+ .maxlen = sizeof (int),
+ .mode = 0600,
+ .proc_handler = &proc_dointvec, },
{0}
};
@@ -270,23 +457,47 @@
static ctl_table vm_table[] = {
- {VM_OVERCOMMIT_MEMORY, "overcommit_memory", &sysctl_overcommit_memory,
- sizeof(sysctl_overcommit_memory), 0644, NULL, &proc_dointvec},
- {VM_OVERCOMMIT_RATIO, "overcommit_ratio",
- &sysctl_overcommit_ratio, sizeof(sysctl_overcommit_ratio), 0644,
- NULL, &proc_dointvec},
- {VM_PAGE_CLUSTER, "page-cluster",
- &page_cluster, sizeof(int), 0644, NULL, &proc_dointvec},
- {VM_DIRTY_BACKGROUND, "dirty_background_ratio",
- &dirty_background_ratio, sizeof(dirty_background_ratio),
- 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL,
- &zero, &one_hundred },
- {VM_DIRTY_RATIO, "dirty_ratio", &vm_dirty_ratio,
- sizeof(vm_dirty_ratio), 0644, NULL, &proc_dointvec_minmax,
- &sysctl_intvec, NULL, &zero, &one_hundred },
- {VM_DIRTY_WB_CS, "dirty_writeback_centisecs",
- &dirty_writeback_centisecs, sizeof(dirty_writeback_centisecs), 0644,
- NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL,
+ { .ctl_name = VM_OVERCOMMIT_MEMORY,
+ .procname = "overcommit_memory",
+ .data = &sysctl_overcommit_memory,
+ .maxlen = sizeof(sysctl_overcommit_memory),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = VM_OVERCOMMIT_RATIO,
+ .procname = "overcommit_ratio",
+ .data = &sysctl_overcommit_ratio,
+ .maxlen = sizeof(sysctl_overcommit_ratio),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = VM_PAGE_CLUSTER,
+ .procname = "page-cluster",
+ .data = &page_cluster,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = VM_DIRTY_BACKGROUND,
+ .procname = "dirty_background_ratio",
+ .data = &dirty_background_ratio,
+ .maxlen = sizeof(dirty_background_ratio),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero, .extra2 = &one_hundred, },
+ { .ctl_name = VM_DIRTY_RATIO,
+ .procname = "dirty_ratio",
+ .data = &vm_dirty_ratio,
+ .maxlen = sizeof(vm_dirty_ratio),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero, .extra2 = &one_hundred, },
+ { .ctl_name = VM_DIRTY_WB_CS,
+ .procname = "dirty_writeback_centisecs",
+ .data = &dirty_writeback_centisecs,
+ .maxlen = sizeof(dirty_writeback_centisecs),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
/* Here, we define the range of possible values for
dirty_writeback_centisecs.
@@ -299,18 +510,34 @@
some nicely documented throttling code in wb_kupdate().
There is no maximum legal value for dirty_writeback. */
- &one , NULL},
- {VM_DIRTY_EXPIRE_CS, "dirty_expire_centisecs",
- &dirty_expire_centisecs, sizeof(dirty_expire_centisecs), 0644,
- NULL, &proc_dointvec},
- { VM_NR_PDFLUSH_THREADS, "nr_pdflush_threads",
- &nr_pdflush_threads, sizeof nr_pdflush_threads,
- 0444 /* read-only*/, NULL, &proc_dointvec},
- {VM_SWAPPINESS, "swappiness", &vm_swappiness, sizeof(vm_swappiness),
- 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL, &zero,
- &one_hundred },
+ .extra1 = &one, .extra2 = NULL, },
+ { .ctl_name = VM_DIRTY_EXPIRE_CS,
+ .procname = "dirty_expire_centisecs",
+ .data = &dirty_expire_centisecs,
+ .maxlen = sizeof(dirty_expire_centisecs),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = VM_NR_PDFLUSH_THREADS,
+ .procname = "nr_pdflush_threads",
+ .data = &nr_pdflush_threads,
+ .maxlen = sizeof nr_pdflush_threads,
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = VM_SWAPPINESS,
+ .procname = "swappiness",
+ .data = &vm_swappiness,
+ .maxlen = sizeof(vm_swappiness),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &zero, .extra2 = &one_hundred, },
#ifdef CONFIG_HUGETLB_PAGE
- {VM_HUGETLB_PAGES, "nr_hugepages", &htlbpage_max, sizeof(int), 0644,
NULL, &hugetlb_sysctl_handler},
+ { .ctl_name = VM_HUGETLB_PAGES,
+ .procname = "nr_hugepages",
+ .data = &htlbpage_max,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &hugetlb_sysctl_handler, },
#endif
{0}
};
@@ -320,28 +547,70 @@
};
static ctl_table fs_table[] = {
- {FS_NRINODE, "inode-nr", &inodes_stat, 2*sizeof(int),
- 0444, NULL, &proc_dointvec},
- {FS_STATINODE, "inode-state", &inodes_stat, 7*sizeof(int),
- 0444, NULL, &proc_dointvec},
- {FS_NRFILE, "file-nr", &files_stat, 3*sizeof(int),
- 0444, NULL, &proc_dointvec},
- {FS_MAXFILE, "file-max", &files_stat.max_files, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {FS_DENTRY, "dentry-state", &dentry_stat, 6*sizeof(int),
- 0444, NULL, &proc_dointvec},
- {FS_OVERFLOWUID, "overflowuid", &fs_overflowuid, sizeof(int), 0644,
NULL,
- &proc_dointvec_minmax, &sysctl_intvec, NULL,
- &minolduid, &maxolduid},
- {FS_OVERFLOWGID, "overflowgid", &fs_overflowgid, sizeof(int), 0644,
NULL,
- &proc_dointvec_minmax, &sysctl_intvec, NULL,
- &minolduid, &maxolduid},
- {FS_LEASES, "leases-enable", &leases_enable, sizeof(int),
- 0644, NULL, &proc_dointvec},
- {FS_DIR_NOTIFY, "dir-notify-enable", &dir_notify_enable,
- sizeof(int), 0644, NULL, &proc_dointvec},
- {FS_LEASE_TIME, "lease-break-time", &lease_break_time, sizeof(int),
- 0644, NULL, &proc_dointvec},
+ { .ctl_name = FS_NRINODE,
+ .procname = "inode-nr",
+ .data = &inodes_stat,
+ .maxlen = 2*sizeof(int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_STATINODE,
+ .procname = "inode-state",
+ .data = &inodes_stat,
+ .maxlen = 7*sizeof(int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_NRFILE,
+ .procname = "file-nr",
+ .data = &files_stat,
+ .maxlen = 3*sizeof(int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_MAXFILE,
+ .procname = "file-max",
+ .data = &files_stat.max_files,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_DENTRY,
+ .procname = "dentry-state",
+ .data = &dentry_stat,
+ .maxlen = 6*sizeof(int),
+ .mode = 0444,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_OVERFLOWUID,
+ .procname = "overflowuid",
+ .data = &fs_overflowuid,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &minolduid, .extra2 = &maxolduid, },
+ { .ctl_name = FS_OVERFLOWGID,
+ .procname = "overflowgid",
+ .data = &fs_overflowgid,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec_minmax,
+ .strategy = &sysctl_intvec,
+ .extra1 = &minolduid, .extra2 = &maxolduid, },
+ { .ctl_name = FS_LEASES,
+ .procname = "leases-enable",
+ .data = &leases_enable,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_DIR_NOTIFY,
+ .procname = "dir-notify-enable",
+ .data = &dir_notify_enable,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
+ { .ctl_name = FS_LEASE_TIME,
+ .procname = "lease-break-time",
+ .data = &lease_break_time,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec, },
{0}
};
^ permalink raw reply
* RE: 2.5.51 nanosleep fails
From: Fleischer, Julie N @ 2002-12-12 19:59 UTC (permalink / raw)
To: 'jim.houston@attbi.com', Marco d'Itri, linux-kernel
Jim Houston wrote:
> Marco d'Itri wrote:
> > nanosleep fails after being interrupted:
> >
> > [...]
> > nanosleep({1, 0},
> > [1]+ Stopped strace tail -f /var/log/uucp/Log
> > md@wonderland:~$ fg
> > strace tail -f /var/log/uucp/Log
> > <unfinished ...>
> > --- SIGCONT (Continued) ---
> > <... nanosleep resumed> 0) = -1 ENOSYS
> (Function not implemented)>
> >
> > This can be reliably reproduced.
> I was able to reproduce this issue. It happens on all the
> kernels I tried including a stock Redhat kernel. This is just
> an idiosyncrasy of strace. In this case both the strace and
> tail are sent a SIGTSTP when they are put into the background.
> Its not suprising that this might confuse strace.
I'm not sure this helps or is irrelevant (or already known), but I did try a
similar thing on a 2.5.50 kernel with the high-res-timers patches (all 4),
and it worked. That same test did fail (as described above) in 2.5.51 (no
patches).
I have a feeling I may be missing something as I think (?) similar things
were discussed in the "[PATCH] compatibility syscall layer (lets try again)"
thread, but I know I didn't keep up. I also may have misinterpreted the
original report.
In my test case, I set up a nanosleep to sleep for 5 seconds while I
interrupted it after 1 second with SIGSTOP and then SIGCONT.
On 2.5.50 w/HRT, it output:
nanosleep() returned success [i.e., exitted w/no errors]
Start 1039720777 sec; End 1039720782 sec
Test PASSED
On 2.5.51 w/no HRT, it output:
nanosleep() did not return success [i.e., exitted w/-1 and set errno]
Start 1039721052 sec; End 1039721053 sec
nanosleep() did not sleep long enough
>From strace of the 2.5.51 run:
nanosleep({1, 0}, {1, 0}) = 0
kill(1233, SIGSTOP) = 0
--- SIGCHLD (Child exited) ---
kill(1233, SIGCONTnanosleep() did not return success
) = 0
--- SIGCHLD (Child exited) ---
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 1], 0, NULL) = 1233
gettimeofday({1039721104, 153936}, NULL) = 0
The test case was a variant of nanosleep/3-2.c on posixtest.sf.net.
- Julie
**These views are not necessarily those of my employer.**
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Sam Ravnborg @ 2002-12-12 19:52 UTC (permalink / raw)
To: John Bradford, Kai Germaschewski; +Cc: Sam Ravnborg, perex, linux-kernel
In-Reply-To: <200212111347.gBBDl0Pd007751@darkstar.example.net>
On ons, dec 11, 2002 at 01:47:00 +0000, John Bradford wrote:
> > kbuild in 2.5.51 requires that there exist one variable named obj-*
> > before built-in.o is generated.
> > In the Makefile for sound/synth/emux the variables obj-* is only set if
> > CONFIG_SND_SEQUENCER is set to y or m.
> >
> > The best approach may be a derived bool defined in Kconfig, but
> > an alterneative solution is to rearrange the Makefile a bit.
> >
> > Try the following (untested) patch.
>
> Same error I'm afraid :-/
Yep, sorry.
kbuild check if any obj-* value has been assigned a value,
so an empty assignment does not help.
I have made a patch that works this time.
Kai, any ideas how to do this in a better way?
- I have considered a derived symbol in sound/isa/Kconfig,
something like:
bool SND_EMUX_SYNTH
depends on SND && SND_SEQUENCER && SND_SBAWE
and then in the Makefile:
obj-$(CONFIG_SND_EMUX_SYNTH) := snd-emux-synth.o
That would make the Makefile trivial, but sound/ did not use any derived
symbols in the Kconfig file, so I did not test this approach.
I'm prepared to clean up all sound/ makefiles if this approach is
considered better than what is used today.
Sam
===== sound/synth/emux/Makefile 1.4 vs edited =====
--- 1.4/sound/synth/emux/Makefile Tue Jun 18 11:16:20 2002
+++ edited/sound/synth/emux/Makefile Thu Dec 12 20:38:42 2002
@@ -5,16 +5,13 @@
export-objs := emux.o
+snd-emux-synth-objs-$(CONFIG_SND_SEQUENCER_OSS) := emux_oss.o
snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
- emux_effect.o emux_proc.o soundfont.o
-ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
- snd-emux-synth-objs += emux_oss.o
-endif
+ emux_effect.o emux_proc.o soundfont.o \
+ $(snd-emux-synth-objs-y)
# Toplevel Module Dependency
-ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
- obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
- obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
-endif
+seq := $(filter m y,$(CONFIG_SND_SEQUENCER))
+obj-$(if $(seq),$(CONFIG_SND_SBAWE)) += snd-emux-synth.o
+obj-$(if $(seq),$(CONFIG_SND_EMU10K1)) += snd-emux-synth.o
-include $(TOPDIR)/Rules.make
^ permalink raw reply
* [PATCH] kill __GFP_HIGHIO
From: Hugh Dickins @ 2002-12-12 19:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jens Axboe, linux-kernel
Just noticed that __GFP_HIGHIO has played no real part since bounce
buffering was converted to mempool in 2.5.12: so this patch (over
2.5.51-mm2) removes it and GFP_NOHIGHIO and SLAB_NOHIGHIO.
Also removes GFP_KSWAPD, in 2.5 same as GFP_KERNEL; leaves GFP_USER,
which can be a useful comment, even though in 2.5 same as GFP_KERNEL.
One anomaly needs comment: strictly, if there's no __GFP_HIGHIO, then
GFP_NOHIGHIO translates to GFP_NOFS; but GFP_NOFS looks wrong in the
block layer, and if you follow them down, you find that GFP_NOFS and
GFP_NOIO behave the same way in mempool_alloc - so I've used the
less surprising GFP_NOIO to replace GFP_NOHIGHIO.
Hugh
--- 2.5.51-mm2/drivers/block/ll_rw_blk.c Thu Dec 12 12:30:32 2002
+++ linux/drivers/block/ll_rw_blk.c Thu Dec 12 17:02:25 2002
@@ -284,7 +284,7 @@
init_emergency_isa_pool();
q->bounce_gfp = GFP_NOIO | GFP_DMA;
} else
- q->bounce_gfp = GFP_NOHIGHIO;
+ q->bounce_gfp = GFP_NOIO;
/*
* keep this for debugging for now...
--- 2.5.51-mm2/include/linux/blkdev.h Thu Dec 12 12:30:33 2002
+++ linux/include/linux/blkdev.h Thu Dec 12 17:02:25 2002
@@ -302,7 +302,7 @@
#define BLK_BOUNCE_ISA (ISA_DMA_THRESHOLD)
extern int init_emergency_isa_pool(void);
-inline void blk_queue_bounce(request_queue_t *q, struct bio **bio);
+extern void blk_queue_bounce(request_queue_t *q, struct bio **bio);
#define rq_for_each_bio(bio, rq) \
if ((rq->bio)) \
--- 2.5.51-mm2/include/linux/gfp.h Thu Dec 12 12:30:33 2002
+++ linux/include/linux/gfp.h Thu Dec 12 17:02:25 2002
@@ -14,20 +14,17 @@
/* Action modifiers - doesn't change the zoning */
#define __GFP_WAIT 0x10 /* Can wait and reschedule? */
#define __GFP_HIGH 0x20 /* Should access emergency pools? */
-#define __GFP_IO 0x40 /* Can start low memory physical IO? */
-#define __GFP_HIGHIO 0x80 /* Can start high mem physical IO? */
-#define __GFP_FS 0x100 /* Can call down to low-level FS? */
-#define __GFP_COLD 0x200 /* Cache-cold page required */
-#define __GFP_NOWARN 0x400 /* Suppress page allocation failure warning */
+#define __GFP_IO 0x40 /* Can start physical IO? */
+#define __GFP_FS 0x80 /* Can call down to low-level FS? */
+#define __GFP_COLD 0x100 /* Cache-cold page required */
+#define __GFP_NOWARN 0x200 /* Suppress page allocation failure warning */
-#define GFP_NOHIGHIO ( __GFP_WAIT | __GFP_IO)
-#define GFP_NOIO ( __GFP_WAIT)
-#define GFP_NOFS ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO)
#define GFP_ATOMIC (__GFP_HIGH)
-#define GFP_USER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS | __GFP_HIGHMEM)
-#define GFP_KERNEL ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_KSWAPD ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
+#define GFP_NOIO (__GFP_WAIT)
+#define GFP_NOFS (__GFP_WAIT | __GFP_IO)
+#define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
+#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS)
+#define GFP_HIGHUSER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HIGHMEM)
/* Flag - indicates that the buffer will be suitable for DMA. Ignored on some
platforms, used as appropriate on others */
--- 2.5.51-mm2/include/linux/slab.h Thu Dec 12 12:30:33 2002
+++ linux/include/linux/slab.h Thu Dec 12 17:02:25 2002
@@ -17,13 +17,12 @@
/* flags for kmem_cache_alloc() */
#define SLAB_NOFS GFP_NOFS
#define SLAB_NOIO GFP_NOIO
-#define SLAB_NOHIGHIO GFP_NOHIGHIO
#define SLAB_ATOMIC GFP_ATOMIC
#define SLAB_USER GFP_USER
#define SLAB_KERNEL GFP_KERNEL
#define SLAB_DMA GFP_DMA
-#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_HIGHIO|__GFP_FS|__GFP_COLD|__GFP_NOWARN)
+#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|__GFP_COLD|__GFP_NOWARN)
#define SLAB_NO_GROW 0x00001000UL /* don't grow a cache */
/* flags to pass to kmem_cache_create().
--- 2.5.51-mm2/mm/highmem.c Tue Nov 5 11:31:54 2002
+++ linux/mm/highmem.c Thu Dec 12 17:02:25 2002
@@ -366,7 +366,7 @@
return 0;
}
-void __blk_queue_bounce(request_queue_t *q, struct bio **bio_orig, int bio_gfp,
+static void __blk_queue_bounce(request_queue_t *q, struct bio **bio_orig,
mempool_t *pool)
{
struct page *page;
@@ -387,7 +387,7 @@
* irk, bounce it
*/
if (!bio)
- bio = bio_alloc(bio_gfp, (*bio_orig)->bi_vcnt);
+ bio = bio_alloc(GFP_NOIO, (*bio_orig)->bi_vcnt);
to = bio->bi_io_vec + i;
@@ -447,10 +447,9 @@
*bio_orig = bio;
}
-inline void blk_queue_bounce(request_queue_t *q, struct bio **bio_orig)
+void blk_queue_bounce(request_queue_t *q, struct bio **bio_orig)
{
mempool_t *pool;
- int bio_gfp;
BUG_ON((*bio_orig)->bi_idx);
@@ -462,20 +461,16 @@
if (!(q->bounce_gfp & GFP_DMA)) {
if (q->bounce_pfn >= blk_max_pfn)
return;
-
- bio_gfp = GFP_NOHIGHIO;
pool = page_pool;
} else {
BUG_ON(!isa_page_pool);
-
- bio_gfp = GFP_NOIO;
pool = isa_page_pool;
}
/*
* slow path
*/
- __blk_queue_bounce(q, bio_orig, bio_gfp, pool);
+ __blk_queue_bounce(q, bio_orig, pool);
}
#if defined(CONFIG_DEBUG_HIGHMEM) && defined(CONFIG_HIGHMEM)
--- 2.5.51-mm2/mm/vmscan.c Thu Dec 12 12:30:33 2002
+++ linux/mm/vmscan.c Thu Dec 12 17:02:25 2002
@@ -887,9 +887,9 @@
max_scan = to_reclaim * 2;
if (max_scan < SWAP_CLUSTER_MAX)
max_scan = SWAP_CLUSTER_MAX;
- to_free -= shrink_zone(zone, max_scan, GFP_KSWAPD,
+ to_free -= shrink_zone(zone, max_scan, GFP_KERNEL,
to_reclaim, &nr_mapped, ps, priority);
- shrink_slab(max_scan + nr_mapped, GFP_KSWAPD);
+ shrink_slab(max_scan + nr_mapped, GFP_KERNEL);
if (zone->all_unreclaimable)
continue;
if (zone->pages_scanned > zone->present_pages * 2)
^ permalink raw reply
* Re: [PATCH] s390 (8/8): export sys_wait4.
From: Pete Zaitcev @ 2002-12-12 19:26 UTC (permalink / raw)
To: linux-kernel
> +EXPORT_SYMBOL(sys_wait4);
Martin, hold on just a second. Last I checked, sys_wait4 was
used ONLY by a moronic code in ipvs, _and_ there was a comment
by the author above it "we are too lazy to do it properly".
Do you have a better reason to export it?
-- Pete
^ permalink raw reply
* Re: [Linux-ia64] fpswa logging redux
From: David Mosberger @ 2002-12-12 19:14 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>
Jesse> How about something like this then? It just prints out the
Jesse> isr in addition to the ip for the case of printk, and decodes
Jesse> the right si_code for signals. If this approach looks ok, I
Jesse> can add trap decoding too.
Basically OK with me, however:
o What's the point of declaring fp_fault_info in a header file? It's
used only in one place.
o si_code is NOT a bitmask; it makes no sense at all for
fp_fault_si_code() to OR multiple values together; this makes me
highly suspicious that there is a misunderstanding somewhere...
o Who defined FP_SWASST and FPE_DENORM? I don't recall seeing them
in the ia64 psABI and they definitely look ia64-specific, so their
names should at least be prefixed by a double-underscore
(siginfo.h).
o If you add stuff to asm/siginfo.h, don't forget to update glibc (in
sysdeps/unix/sysv/linux/ia64/bits/siginfo.h).
--david
^ permalink raw reply
* RE: bandwidth
From: Rob Sterenborg @ 2002-12-12 19:14 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3DF8CED1.8030509@corp.lcom.net>
> There are a couple of situations where I need to limit
> bandwidth on some of my machines. Can anyone share some
> solutions they have used? Here are a couple of examples of
HTB with iproute2 tc utility.
http://luxik.cdi.cz/~devik/qos/htb/
Works just fine, easy to configure.
Rob
^ permalink raw reply
* Re: 2.4.20-ac1 KT400 AGP support
From: Dave Jones @ 2002-12-12 19:20 UTC (permalink / raw)
To: BoehmeSilvio; +Cc: linux-kernel
In-Reply-To: <2F4E8F809920D611B0B300508BDE95FE29444E@AFB91>
On Thu, Dec 12, 2002 at 07:04:02PM +0100, BoehmeSilvio wrote:
> Hi !
>
> Hopefully I'm right here.....
>
> I have some trouble to get agpgart working in kernel 2.4.20-ac1.
>
> My setup:
> - ASUS A7V8X with VIA KT400 Chip (AGP 8X)
> - ATI Radeon 9700 PRO (also AGP 8X)
>
> The original 2.4.20 kernel doesn't know this chipset, so I tried the
> 2.4.20-ac1, which has some patches for the KT400.
>
> With 2.4.20-ac1 I get the following error:
>
> agpgart: Maximum main memory to use for agp memory: 690M
> agpgart: Detected Via Apollo KT-400 chipset
> agpgart: unable to determine aperture size
Currently AGPGART doesn't support AGP 3.0 (which is needed for X8 mode)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Adventure - the answer to what went wrong?
From: Richard Wallman @ 2002-12-12 19:11 UTC (permalink / raw)
To: Linux 8086
In-Reply-To: <1039651196.1847.43.camel@Castle.goembel>
Gave it a bit of thought today, and I think I know what happened.
Looking at the libc sources, it looks like the strcmp and strncmp
functions assume that both strings are in the same 64Kb segment. (There
may be other functions that make this assumption as well, but I haven't
really looked).
Looking at the file sizes, the "advent" program is 84Kb when compiled
using bcc.
I put forward the theory that it fails because the two strings are not
in the same 64Kb segment. The reason no-one has found this problem
before is that so far all of the binaries have been <64Kb in size.
Still, looks like it's been fixed now, but if anyone was wondering why
their port of their favourite app failed, that may be the reason.
--
Richard Wallman
http://www.murkygoth.uklinux.net/elks
^ permalink raw reply
* Kernel bug handling TCP_RTO_MAX?
From: Andreani Stefano @ 2002-12-12 19:15 UTC (permalink / raw)
To: linux-kernel, linux-net
Problem: I need to change the max value of the TCP retransmission timeout.
Background: According to Karn's exponential backoff algorithm, when the receiver doesn't acknowledge packets for a while, the sender should retransmit the latest not acknowledged packet several times increasing the delay (RTO) since this delay reaches the Max Retransmission Timeout Value.
Testing environment: Red Hat Linux release 7.2 (Enigma), Kernel 2.4.7-10 on an i686, Kernel 2.4.7-10.
Test details: I supposed this timeout in Linux was TCP_RTO_MAX, so I changed in /include/net/tcp.h the following line:
#define TCP_RTO_MAX ((unsigned)(6*HZ)) //It was: ((unsigned)(120*HZ))
Then I recompiled the kernel, rebooted the machine and tested the solution. The result I obtained was the same I had before this modification.
I'm confident there isn't an error in the testing procedure because I already tested with a Solaris server the same procedure (changing the tcp_rexmit_interval_max variable) and it works. I'm just trying to reproduce the modification of that parameter in Linux.
Could it be a bug on the RTO calculation algorithm, or there is something I mistook?
This is the first time I get into the linux kernel, so please be patient!
Thanks,
Stefano.
-------------------------------
Stefano Andreani
Freelance ICT Consultant
H3G IOT Team - Italy
tel. +39 347 8215965
stefano.andreani.ap@h3g.it
^ permalink raw reply
* [PATCH RESEND] memory leak in ndisc_router_discovery
From: Krishna Kumar @ 2002-12-12 19:05 UTC (permalink / raw)
To: kuznet, davem; +Cc: netdev, linux-kernel
Hi,
I had sent this earlier, there is a bug in router advertisement handling code,
where the reference (and memory) to an inet6_dev pointer can get leaked (this
leak can happen atmost once for each interface on a system which receives
invalid RA's). Below is the patch against 2.5.51 to fix it.
thanks,
- KK
-------------------------------------------------------------------------------
diff -ruN linux.org/net/ipv6/ndisc.c linux/net/ipv6/ndisc.c
--- linux.org/net/ipv6/ndisc.c Fri Nov 7 10:02:11 2002
+++ linux/net/ipv6/ndisc.c Fri Nov 8 14:37:27 2002
@@ -871,6 +871,7 @@
}
if (!ndisc_parse_options(opt, optlen, &ndopts)) {
+ in6_dev_put(in6_dev);
if (net_ratelimit())
ND_PRINTK2(KERN_WARNING
"ICMP6 RA: invalid ND option, ignored.\n");
-------------------------------------------------------------------------------
^ permalink raw reply
* Re: using 2 TB in real life
From: Bryan O'Sullivan @ 2002-12-12 19:03 UTC (permalink / raw)
To: Anders Henke; +Cc: linux-kernel, peter
In-Reply-To: <20021212174814.GA18993@schlund.de>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Thu, 2002-12-12 at 09:48, Anders Henke wrote:
> Peter's patch is not necessary for a 1.9TB device, but (from a quick
> glance at the source) should fix the display problem I mentioned.
No, my point was precisely that Peter's patch changes the display
problem into a different display problem. It will report a 1.9TB
filesystem as a 300MB filesystem, because some of the bit-shuffling is
wrong.
I've attached a patch which illustrates a fix to the SCSI device size
reporting problem in Peter's 2TB patch (the fix was found by HJ Lu). It
probably won't apply cleanly due to version drift (and of course it
definitely won't apply to a stock kernel), but it indicates what's
wrong.
<b
[-- Attachment #2: Type: text/plain, Size: 762 bytes --]
--- linux-pchubb/drivers/scsi/sd.c Thu Dec 12 10:58:29 2002
+++ linux/drivers/scsi/sd.c Thu Dec 12 10:58:29 2002
@@ -1002,8 +1002,8 @@
*/
int m;
unsigned hard_sector = sector_size;
- sector_t sz = rscsi_disks[i].capacity * (hard_sector/256);
- sector_t mb = sz >>= 1;
+ sector_t sz = ((sector_t) rscsi_disks[i].capacity) * ((sector_t) (hard_sector/256));
+ sector_t mb = sz >> 1;
sector_div(sz, 1250);
mb -= sz - 974;
@@ -1015,9 +1015,9 @@
}
printk("SCSI device %s: "
- "%u %u-byte hdwr sectors (%u MB)\n",
+ "%u %u-byte hdwr sectors (%llu MB)\n",
nbuff, rscsi_disks[i].capacity,
- hard_sector, sz);
+ hard_sector, mb);
}
/* Rescale capacity to 512-byte units */
^ permalink raw reply
* Re: Move 405LP RTC support from beech.c into ibm405lp.c
From: Todd Poynor @ 2002-12-12 18:49 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-embedded
In-Reply-To: <20021212035459.GF4631@zax.zax>
David Gibson wrote:
> The RTC support (written by Todd Poynor) for the Beech is actually in
> the 405LP chip itself, not just on the Beech board. This patch moves
> the code into ibm405lp.c so that it's more easily accessible for
> non-Beech 405LP boards (there aren't any of these in the tree at the
> moment, but I expect to commit one within the week).
>
> If there are no objections, I will commit this to linuxppc_2_4_devel.
By all means... I realized shortly afterwards that I had "Beech on the
brain" and it was really a 405LP onchip device, so this was on my to-do
list anyhow. (And credit to Bishop Brock for the original code.)
--
Todd
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [FBDEV]: Framebuffer driver for Intel 810/815 chipsets
From: James Simmons @ 2002-12-12 18:45 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
In-Reply-To: <1039603490.1147.80.camel@localhost.localdomain>
Applied !!!!
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@users.sf.net] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
On 11 Dec 2002, Antonino Daplas wrote:
> James,
>
> It seems the fbdev framework is stable enough, and already in the
> development tree. So, I'm submitting a driver for the Intel 810/815 for
> review and perhaps inclusion to your tree (to get more testing), and
> hopefully merge with Linus's tree.
>
> The patch is against linux-2.5.51, but will not work yet because of 2
> reasons:
>
> 1. agpgart is not working for the i810
> 2. support for early agp initialization needs to be added.
>
> Once #1 is fixed, the driver should work as a module. And once #2 gets
> included, the driver can be compiled statically. Dave Jones (thanks for
> the help, by the way) has already #2 in his tree (tested and works), and
> is currently working on #1 (I have a hacked version at home).
>
> The driver should be compliant with fbdev-2.5, and should support most
> if not all features that are to be expected (modularity, state saving
> and restoring, full hardware support, etc). One thing also that's very
> important for many people is that the driver will work with XFree86 with
> its native i810 drivers without further modification, and quite stably
> too.
>
> The patch is at
> http://i810fb.sourceforge.net/linux-2.5.51-i810fb.diff.gz
>
> Thanks,
>
> Tony
>
>
>
>
>
^ permalink raw reply
* Re: [patch 2.5.51] add wait_event() to <linux/completion.h>
From: David Brownell @ 2002-12-12 18:53 UTC (permalink / raw)
To: Milton D. Miller II; +Cc: linux-kernel
In-Reply-To: <200212120746.gBC7kR482233@sullivan.realtime.net>
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
Milton D. Miller II wrote:
> __remove_wait_queue(&x->wait, &wait);
>
> should be under
> spin_lock_irq(&x->wait.lock);
Duh! Updated patch is attached.
- Dave
[-- Attachment #2: sched2.patch --]
[-- Type: text/plain, Size: 1724 bytes --]
--- ./include/linux-dist/completion.h Mon Dec 9 23:49:44 2002
+++ ./include/linux/completion.h Tue Dec 10 09:35:57 2002
@@ -28,6 +28,7 @@
}
extern void FASTCALL(wait_for_completion(struct completion *));
+extern int FASTCALL(wait_timeout(struct completion *, signed long jiffies));
extern void FASTCALL(complete(struct completion *));
extern void FASTCALL(complete_all(struct completion *));
--- ./kernel-dist/ksyms.c Thu Dec 12 10:24:44 2002
+++ ./kernel/ksyms.c Tue Dec 10 09:35:57 2002
@@ -404,7 +404,9 @@ EXPORT_SYMBOL(autoremove_wake_function);
/* completion handling */
EXPORT_SYMBOL(wait_for_completion);
+EXPORT_SYMBOL(wait_timeout);
EXPORT_SYMBOL(complete);
+EXPORT_SYMBOL(complete_all);
/* The notion of irq probe/assignment is foreign to S/390 */
--- ./kernel-dist/sched.c Thu Dec 12 10:24:44 2002
+++ ./kernel/sched.c Thu Dec 12 10:15:56 2002
@@ -1204,6 +1204,11 @@ void complete_all(struct completion *x)
void wait_for_completion(struct completion *x)
{
+ (void) wait_timeout (x, MAX_SCHEDULE_TIMEOUT);
+}
+
+int wait_timeout(struct completion *x, signed long timeout)
+{
might_sleep();
spin_lock_irq(&x->wait.lock);
if (!x->done) {
@@ -1214,13 +1219,18 @@ void wait_for_completion(struct completi
do {
__set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(&x->wait.lock);
- schedule();
+ timeout = schedule_timeout(timeout);
spin_lock_irq(&x->wait.lock);
- } while (!x->done);
+ } while (!x->done && timeout != 0);
__remove_wait_queue(&x->wait, &wait);
}
- x->done--;
+ if (x->done) {
+ timeout = 1;
+ x->done--;
+ }
spin_unlock_irq(&x->wait.lock);
+ /* nonzero return means we timed out */
+ return timeout == 0;
}
#define SLEEP_ON_VAR \
^ permalink raw reply
* Re: [LARTC] htb version 3.7 in kernel 2.4.20?
From: Martin Devera @ 2002-12-12 18:35 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103970026925933@msgid-missing>
Bug fixes only. Think about it like 3.6 was beta and 3.7 is final.
On Thu, 12 Dec 2002, Julio E. Gonzalez P. wrote:
> When you use HTB with a stock linux kernel 2.4.20, in /var/log/messages
> say it is version 3.7.
> Anyone know something about this?
> The HTB home page only mentions HTB version 3.6.
> What changes it have?
>
> Julio.
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [LARTC] HTB and theory
From: Stef Coene @ 2002-12-12 18:32 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103945416224487@msgid-missing>
On Thursday 12 December 2002 12:19, Abraham van der Merwe wrote:
> Hi Stef!
>
> > I did some small tests :
>
> [snip]
>
> > Conclusion : if you want to know how traffic will be shaped, you have to
> > follow some basic rules.
> > I will update docum.org tonight.
>
> You're right. I did some tests this weekend as well and realised that you
> have to stick with the basics. The problem was that it was not so clear to
> me how HTB behaves when the child's rates/ceil exceed the parent's.
>
> Some other questions I'd like to ask you while I'm at it:
>
> 1) if you have:
>
> 1:1
> / \
> / \
> 1:2 1:3
> / \ / \
> / \ / \
> 1:4 1:5 1:6 1:7
>
> If
>
> 1:2 = prio 1
> 1:3 = prio 2
>
> 1:4 = prio 10
> 1:5 = prio 11
>
> 1:6 = prio 5
> 1:7 = prio 6
>
> Is 1:4, 1:5 evaluated first or 1:6, 1:7? Iow, does HTB start at the root
> node, prioritize its children and, subprioritize their children, etc. or
> is only the leaf nodes' priorities important (i.e. 1:6, 1:7, 1:4, 1:5)
I don't know. But I think only the leaf nodes are important. I have some
work to do tonight, but I hope to test it this evening.
> 2) if a class is evaluated and there is some bandwidth available to borrow,
> is the first non-congested child given all bandwidth that is available and
> then the next is given the rest and so on or is each child given a quantum
> of bandwidth, then if there is some bandwidth left, a second round and so
> on?
If each class received his rate and the parent has some bandwidth left, the
bandwidth is distributed in a round robin so each class can send quantum
bytes.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: PROCESS IMIGRATION
From: ciriso @ 2002-12-12 18:41 UTC (permalink / raw)
To: Breno; +Cc: linux-kernel
In-Reply-To: <001801c2a20c$387fc4c0$8be1a7c8@bsb.virtua.com.br>
d> César
>
> OpenMosix do this operation ?
Well ,I have tree Pentium(200mmx , 166 & 120 ) running
with Mosix .This is a patch for the kernel, i have 2.4.19 and
several user progs for admin.
Now , the node #3 is running setiathome owned for the node #1.
Basicly the nodes balance yours loads.
http://www.mosix.org
http://www.openmosix.org
Sorry for my english :)
> thanks
> ----- Original Message -----
> From: <ciriso@retena.com>
> To: "Breno" <breno_silva@bandnet.com.br>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Thursday, December 12, 2002 4:21 PM
> Subject: Re: PROCESS IMIGRATION
>
>
> > d> Hi
> > >
> > > I saw something about one project of FreeBSD and this is about
> > > imigration of
> > > processes between two machines.
> > > The kernel Linux has something about this , or some project like
> that ?
> >
> > Hi .
> > Perhaps are you finding OpenMosix ?
> >
> > César
> >
> >
>
>
^ permalink raw reply
* Re: Is the preemptive kernel patch unsafe for 8xx/PPC?
From: Eugene Surovegin @ 2002-12-12 18:28 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <IGEFJKJNHJDCBKALBJLLGEMDFIAA.joakim.tjernlund@lumentis.se>
At 04:56 AM 12/12/2002, you wrote:
>I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
>I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?
I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.
Eugene Surovegin <mailto:ebs@innocent.com>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: "bio too big" error
From: Wil Reichert @ 2002-12-12 18:34 UTC (permalink / raw)
To: Joe Thornber; +Cc: linux-kernel
In-Reply-To: <20021212120836.GA5717@reti>
Yeah, ditching patch 5 makes my lvm functional again. Things are
definately better now. I haven't attempted to stress it, but the entire
hanging console / zombie process bit has gone away. Everything appears
to work normally. A couple test cp's shows nothing abnormal, but
playing an ogg still results in the following.
Dec 12 13:32:20 darwin kernel: bio too big device ide2(33,0) (256 > 255)
Dec 12 13:32:51 darwin last message repeated 3 times
Dec 12 13:33:55 darwin last message repeated 6 times
Any other tests I should do?
Wil
On Thu, 2002-12-12 at 07:08, Joe Thornber wrote:
> On Tue, Dec 10, 2002 at 09:17:45PM -0500, Wil Reichert wrote:
> > Hi,
> >
> > I'm getting a "bio too big" error with 2.5.50. I've got a 330G lvm2
> > partition formatted with ext3 using the -T largefile4 parameter.
> > Everything seems ok at first, but any sort of access will die very
> > unhappily with said error messsage after about 10 seconds of operation
> > or so. The only google search results are the patch submission. Eeek.
>
> Could you try the patchset below please ? (you may need to knock out
> patch 5 until we get to the bottom of that particular bug).
>
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-2.tar.bz2
>
> - Joe
--
Wil Reichert <wilreichert@yahoo.com>
^ permalink raw reply
* Re: [Linux-ia64] fpswa logging redux
From: Jesse Barnes @ 2002-12-12 18:25 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
On Wed, Dec 11, 2002 at 03:42:52PM -0800, David Mosberger wrote:
> >>>>> On Wed, 11 Dec 2002 14:25:14 -0800, Jesse Barnes <jbarnes@sgi.com> said:
>
> Jesse> I'd like to fully decode the information in the isr about
> Jesse> what type of fault occured (whether it be a software assist
> Jesse> fault, some sort of IEEE filter fault, etc.) and print it
> Jesse> along with the ip when faults occur. While I'm at it, I may
> Jesse> as well the proper SIGFPE subcode into si_info in case of
> Jesse> signal delivery is selected.
>
> Like Keith, I'd like to keep the amount of decoding in the kernel as
> minimal as possible. We already have si_isr in the siginfo structure,
> so apps/libraries can decode things themselves. Having said that, we
> ought to decode things sufficiently so that si_code can be set to the
> correct value (where this makes sense). Hopefully, that won't add
> tons of code and it would help application portability.
How about something like this then? It just prints out the isr in
addition to the ip for the case of printk, and decodes the right si_code
for signals. If this approach looks ok, I can add trap decoding too.
Thanks,
Jesse
[-- Attachment #2: fpswa-si_code-decode-2.4.19-ia64.patch --]
[-- Type: text/plain, Size: 3059 bytes --]
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/arch/ia64/kernel/traps.c linux-2.4.19-ia64-fpswa/arch/ia64/kernel/traps.c
--- linux-2.4.19-ia64/arch/ia64/kernel/traps.c Thu Dec 12 10:15:57 2002
+++ linux-2.4.19-ia64-fpswa/arch/ia64/kernel/traps.c Thu Dec 12 10:23:25 2002
@@ -45,6 +45,34 @@
static fpswa_interface_t *fpswa_interface;
+/*
+ * fp fault isr.code <-> siginfo.si_code mapping
+ */
+struct fp_fault_info fp_fault_info[] = {
+ { 1<<0, FPE_FLTINV },
+ { 1<<1, FPE_DENORM },
+ { 1<<2, FPE_FLTDIV },
+ { 1<<3, FPE_SWASST },
+ { 1<<4, FPE_FLTINV },
+ { 1<<5, FPE_DENORM },
+ { 1<<6, FPE_FLTDIV },
+ { 1<<7, FPE_SWASST },
+};
+
+static inline int
+fp_fault_si_code(__u64 isr)
+{
+ int i, ret = 0;
+ int nr_entries;
+ nr_entries = sizeof(fp_fault_info)/sizeof(struct fp_fault_info);
+
+ for (i = 0; i < nr_entries; i++) {
+ if (isr & fp_fault_info[i].isr_code_bit)
+ ret |= fp_fault_info[i].si_code;
+ }
+ return ret;
+}
+
void __init
trap_init (void)
{
@@ -336,8 +364,9 @@
fpu_swa_count = 0;
if ((++fpu_swa_count < 5) && !(current->thread.flags & IA64_THREAD_FPEMU_NOPRINT)) {
last_time = jiffies;
- printk(KERN_WARNING "%s(%d): floating-point assist fault at ip %016lx\n",
- current->comm, current->pid, regs->cr_iip + ia64_psr(regs)->ri);
+ printk(KERN_WARNING "%s(%d): floating-point assist %s ",
+ current->comm, current->pid, fp_fault ? "fault:" : "trap");
+ printk("ip=%016lx, isr=%16lx\n", regs->cr_iip + ia64_psr(regs)->ri, isr);
}
exception = fp_emulate(fp_fault, bundle, ®s->cr_ipsr, ®s->ar_fpsr, &isr, ®s->pr,
@@ -556,6 +585,8 @@
siginfo.si_signo = SIGFPE;
siginfo.si_errno = 0;
siginfo.si_code = FPE_FLTINV;
+ if (vector == 32) /* decode fault into si_code */
+ siginfo.si_code = fp_fault_si_code(isr);
siginfo.si_addr = (void *) (regs->cr_iip + ia64_psr(regs)->ri);
siginfo.si_flags = __ISR_VALID;
siginfo.si_isr = isr;
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/include/asm-ia64/fpu.h linux-2.4.19-ia64-fpswa/include/asm-ia64/fpu.h
--- linux-2.4.19-ia64/include/asm-ia64/fpu.h Sun Feb 6 18:42:40 2000
+++ linux-2.4.19-ia64-fpswa/include/asm-ia64/fpu.h Thu Dec 12 10:11:45 2002
@@ -54,6 +54,11 @@
# ifndef __ASSEMBLY__
+struct fp_fault_info {
+ unsigned long isr_code_bit;
+ int si_code; /* SIGFPE si_code */
+};
+
struct ia64_fpreg {
union {
unsigned long bits[2];
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/include/asm-ia64/siginfo.h linux-2.4.19-ia64-fpswa/include/asm-ia64/siginfo.h
--- linux-2.4.19-ia64/include/asm-ia64/siginfo.h Thu Dec 12 10:15:59 2002
+++ linux-2.4.19-ia64-fpswa/include/asm-ia64/siginfo.h Thu Dec 12 10:19:47 2002
@@ -172,6 +172,8 @@
#define __FPE_DECERR (__SI_FAULT|11) /* packed decimal error */
#define __FPE_INVASC (__SI_FAULT|12) /* invalid ASCII digit */
#define __FPE_INVDEC (__SI_FAULT|13) /* invalid decimal digit */
+#define FPE_SWASST (__SI_FAULT|14) /* software assist fault */
+#define FPE_DENORM (__SI_FAULT|15) /* denormal/unnormal operand */
#define NSIGFPE 13
/*
^ 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.