* Re: [PATCH] set_cpus_allowed() for 2.4
From: Christoph Hellwig @ 2002-12-13 23:08 UTC (permalink / raw)
To: marcelo; +Cc: rml, linux-kernel
Hi Marcelo,
now that all vendors ship a backport of Ingo's O(1) scheduler, external
projects like XFS have to track those trees in addition to the mainline kernel.
Having the common new APIs available in mainline would be a very good thing
to have for us and others. Now that 2.4.20 already has a working yield()
the biggest missing part is set_cpus_allowed() to limit (kernel-)threads
to a specific CPU or set of CPUs.
--- linux/include/linux/sched.h~ Mon Sep 30 17:41:22 2002
+++ linux/include/linux/sched.h Tue Oct 1 18:35:28 2002
@@ -163,6 +164,12 @@
extern int start_context_thread(void);
extern int current_is_keventd(void);
+#if CONFIG_SMP
+extern void set_cpus_allowed(struct task_struct *p, unsigned long new_mask);
+#else
+# define set_cpus_allowed(p, new_mask) do { } while (0)
+#endif
+
/*
* The default fd array needs to be at least BITS_PER_LONG,
* as this is the granularity returned by copy_fdset().
--- linux/kernel/ksyms.c~ Mon Sep 30 17:41:22 2002
+++ linux/kernel/ksyms.c Tue Oct 1 18:34:41 2002
@@ -451,6 +451,9 @@
EXPORT_SYMBOL(interruptible_sleep_on_timeout);
EXPORT_SYMBOL(schedule);
EXPORT_SYMBOL(schedule_timeout);
+#if CONFIG_SMP
+EXPORT_SYMBOL(set_cpus_allowed);
+#endif
EXPORT_SYMBOL(yield);
EXPORT_SYMBOL(__cond_resched);
EXPORT_SYMBOL(jiffies);
--- linux/kernel/sched.c~ Mon Sep 30 17:41:22 2002
+++ linux/kernel/sched.c Tue Oct 1 18:54:49 2002
@@ -850,6 +850,45 @@
void scheduling_functions_end_here(void) { }
+#if CONFIG_SMP
+/**
+ * set_cpus_allowed() - change a given task's processor affinity
+ * @p: task to bind
+ * @new_mask: bitmask of allowed processors
+ *
+ * Upon return, the task is running on a legal processor. Note the caller
+ * must have a valid reference to the task: it must not exit() prematurely.
+ * This call can sleep; do not hold locks on call.
+ */
+void set_cpus_allowed(struct task_struct *p, unsigned long new_mask)
+{
+ new_mask &= cpu_online_map;
+ BUG_ON(!new_mask);
+
+ p->cpus_allowed = new_mask;
+
+ /*
+ * If the task is on a no-longer-allowed processor, we need to move
+ * it. If the task is not current, then set need_resched and send
+ * its processor an IPI to reschedule.
+ */
+ if (!(p->cpus_runnable & p->cpus_allowed)) {
+ if (p != current) {
+ p->need_resched = 1;
+ smp_send_reschedule(p->processor);
+ }
+
+ /*
+ * Wait until we are on a legal processor. If the task is
+ * current, then we should be on a legal processor the next
+ * time we reschedule. Otherwise, we need to wait for the IPI.
+ */
+ while (!(p->cpus_runnable & p->cpus_allowed))
+ schedule();
+ }
+}
+#endif /* CONFIG_SMP */
+
#ifndef __alpha__
/*
^ permalink raw reply
* Re: Memory Manager Subsystem
From: Rik van Riel @ 2002-12-13 15:55 UTC (permalink / raw)
To: Alexandre Pires; +Cc: linux-kernel
In-Reply-To: <094501c2a296$567b4af0$6400a8c0@sawamu>
On Fri, 13 Dec 2002, Alexandre Pires wrote:
> Somebody could indicate me some material about Memory Manager subsystem
> and Memory Map ?
http://linux-mm.org/
http://surriel.com/lectures/linux24-vm-freenix01.pdf
cheers,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://guru.conectiva.com/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ville Herva @ 2002-12-13 15:58 UTC (permalink / raw)
To: Terje Eggestad
Cc: J.A. Magallon, Mark Mielke, H. Peter Anvin, linux-kernel,
Dave Jones
In-Reply-To: <1039771270.29298.41.camel@pc-16.office.scali.no>
On Fri, Dec 13, 2002 at 10:21:11AM +0100, you [Terje Eggestad] wrote:
>
> Well, it does make sense if Intel optimized away rdtsc for more commonly
> used things, but even that don't seem to be the case. I'm measuring the
> overhead of doing a syscall on Linux (int 80) to be ~280 cycles on PIII,
> and Athlon, while it's 1600 cycles on P4.
Just out of interest, how much would sysenter (or syscall on amd) cost,
then? (Supposing it can be feasibly implemented.)
I think I heard WinXP (W2k too?) is using sysenter?
-- v --
v@iki.fi
^ permalink raw reply
* [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Ducrot Bruno @ 2002-12-13 15:53 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
Patch for 2.4.20 and acpi-20021205 for adding s4bios feature.
Cheers,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
[-- Attachment #2: s4bios-2.4.20-acpi-20021205.diff --]
[-- Type: text/plain, Size: 20422 bytes --]
arch/i386/kernel/acpi.c | 17 ++
drivers/acpi/hardware/hwsleep.c | 52 ++++++++
drivers/acpi/system.c | 235 ++++++++++++++++++++++++++++++++++++++--
include/asm-i386/acpi.h | 24 +++-
include/asm-i386/save_state.h | 219 +++++++++++++++++++++++++++++++++++++
5 files changed, 537 insertions(+), 10 deletions(-)
--- linux-2.4.20/include/asm-i386/acpi.h 2002/12/11 15:15:42 1.1
+++ linux-2.4.20/include/asm-i386/acpi.h 2002/12/11 19:50:08
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001 Paul Diefenbaugh <paul.s.diefenbaugh-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
* Copyright (C) 2001 Patrick Mochel <mochel-3NddpPZAyC0@public.gmane.org>
- *
+ *
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* This program is free software; you can redistribute it and/or modify
@@ -128,12 +128,34 @@
#ifdef CONFIG_ACPI_SLEEP
+extern unsigned long saved_eip;
+extern unsigned long saved_esp;
+extern unsigned long saved_ebp;
+extern unsigned long saved_ebx;
+extern unsigned long saved_esi;
+extern unsigned long saved_edi;
+
+static inline void acpi_save_register_state(unsigned long return_point)
+{
+ saved_eip = return_point;
+ asm volatile ("movl %%esp,(%0)" : "=m" (saved_esp));
+ asm volatile ("movl %%ebp,(%0)" : "=m" (saved_ebp));
+ asm volatile ("movl %%ebx,(%0)" : "=m" (saved_ebx));
+ asm volatile ("movl %%edi,(%0)" : "=m" (saved_edi));
+ asm volatile ("movl %%esi,(%0)" : "=m" (saved_esi));
+}
+
+#define acpi_restore_register_state() do {} while (0)
+
+
/* routines for saving/restoring kernel state */
extern int acpi_save_state_mem(void);
extern int acpi_save_state_disk(void);
extern void acpi_restore_state_mem(void);
extern unsigned long acpi_wakeup_address;
+
+extern void do_suspend_lowlevel_s4bios(int resume);
/* early initialization routine */
extern void acpi_reserve_bootmem(void);
--- /dev/null Thu Jan 1 01:00:00 1970
+++ linux-2.4.20/include/asm-i386/save_state.h Wed Dec 11 20:59:39 2002
@@ -0,0 +1,219 @@
+#ifndef __ASM_I386_SAVE_STATE_H
+#define __ASM_I386_SAVE_STATE_H
+
+/*
+ * Copyright 2001-2002 Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
+ * Based on code
+ * Copyright 2001 Patrick Mochel <mochel-3NddpPZAyC0@public.gmane.org>
+ */
+#include <asm/desc.h>
+#include <asm/i387.h>
+
+/* image of the saved processor state */
+struct saved_context {
+ u32 eax, ebx, ecx, edx;
+ u32 esp, ebp, esi, edi;
+ u16 es, fs, gs, ss;
+ u32 cr0, cr2, cr3, cr4;
+ u16 gdt_pad;
+ u16 gdt_limit;
+ u32 gdt_base;
+ u16 idt_pad;
+ u16 idt_limit;
+ u32 idt_base;
+ u16 ldt;
+ u16 tss;
+ u32 tr;
+ u32 safety;
+ u32 return_address;
+ u32 eflags;
+} __attribute__((packed));
+
+static struct saved_context saved_context;
+
+#define loaddebug(thread,register) \
+ __asm__("movl %0,%%db" #register \
+ : /* no output */ \
+ :"r" ((thread)->debugreg[register]))
+
+
+/*
+ * save_processor_context
+ *
+ * Save the state of the processor before we go to sleep.
+ *
+ * return_stack is the value of the stack pointer (%esp) as the caller sees it.
+ * A good way could not be found to obtain it from here (don't want to make _too_
+ * many assumptions about the layout of the stack this far down.) Also, the
+ * handy little __builtin_frame_pointer(level) where level > 0, is blatantly
+ * buggy - it returns the value of the stack at the proper location, not the
+ * location, like it should (as of gcc 2.91.66)
+ *
+ * Note that the context and timing of this function is pretty critical.
+ * With a minimal amount of things going on in the caller and in here, gcc
+ * does a good job of being just a dumb compiler. Watch the assembly output
+ * if anything changes, though, and make sure everything is going in the right
+ * place.
+ */
+static inline void save_processor_context (void)
+{
+ /*
+ * descriptor tables
+ */
+ asm volatile ("sgdt (%0)" : "=m" (saved_context.gdt_limit));
+ asm volatile ("sidt (%0)" : "=m" (saved_context.idt_limit));
+ asm volatile ("sldt (%0)" : "=m" (saved_context.ldt));
+ asm volatile ("str (%0)" : "=m" (saved_context.tr));
+
+ /*
+ * save the general registers.
+ * note that gcc has constructs to specify output of certain registers,
+ * but they're not used here, because it assumes that you want to modify
+ * those registers, so it tries to be smart and save them beforehand.
+ * It's really not necessary, and kinda fishy (check the assembly output),
+ * so it's avoided.
+ */
+ asm volatile ("movl %%esp, (%0)" : "=m" (saved_context.esp));
+ asm volatile ("movl %%eax, (%0)" : "=m" (saved_context.eax));
+ asm volatile ("movl %%ebx, (%0)" : "=m" (saved_context.ebx));
+ asm volatile ("movl %%ecx, (%0)" : "=m" (saved_context.ecx));
+ asm volatile ("movl %%edx, (%0)" : "=m" (saved_context.edx));
+ asm volatile ("movl %%ebp, (%0)" : "=m" (saved_context.ebp));
+ asm volatile ("movl %%esi, (%0)" : "=m" (saved_context.esi));
+ asm volatile ("movl %%edi, (%0)" : "=m" (saved_context.edi));
+
+ /*
+ * segment registers
+ */
+ asm volatile ("movw %%es, %0" : "=r" (saved_context.es));
+ asm volatile ("movw %%fs, %0" : "=r" (saved_context.fs));
+ asm volatile ("movw %%gs, %0" : "=r" (saved_context.gs));
+ asm volatile ("movw %%ss, %0" : "=r" (saved_context.ss));
+
+ /*
+ * control registers
+ */
+ asm volatile ("movl %%cr0, %0" : "=r" (saved_context.cr0));
+ asm volatile ("movl %%cr2, %0" : "=r" (saved_context.cr2));
+ asm volatile ("movl %%cr3, %0" : "=r" (saved_context.cr3));
+ asm volatile ("movl %%cr4, %0" : "=r" (saved_context.cr4));
+
+ /*
+ * eflags
+ */
+ asm volatile ("pushfl ; popl (%0)" : "=m" (saved_context.eflags));
+}
+
+static void fix_processor_context(void)
+{
+ int nr = smp_processor_id();
+ struct tss_struct * t = &init_tss[nr];
+
+ set_tss_desc(nr,t); /* This just modifies memory; should not be neccessary. But... This is neccessary, because 386 hardware has concept of busy tsc or some similar stupidity. */
+ gdt_table[__TSS(nr)].b &= 0xfffffdff;
+
+ load_TR(nr); /* This does ltr */
+
+ load_LDT(¤t->mm->context); /* This does lldt */
+
+ /*
+ * Now maybe reload the debug registers
+ */
+ if (current->thread.debugreg[7]){
+ loaddebug(¤t->thread, 0);
+ loaddebug(¤t->thread, 1);
+ loaddebug(¤t->thread, 2);
+ loaddebug(¤t->thread, 3);
+ /* no 4 and 5 */
+ loaddebug(¤t->thread, 6);
+ loaddebug(¤t->thread, 7);
+ }
+
+}
+
+static void
+do_fpu_end(void)
+{
+ /* restore FPU regs if necessary */
+ /* Do it out of line so that gcc does not move cr0 load to some stupid place */
+ kernel_fpu_end();
+}
+
+/*
+ * restore_processor_context
+ *
+ * Restore the processor context as it was before we went to sleep
+ * - descriptor tables
+ * - control registers
+ * - segment registers
+ * - flags
+ *
+ * Note that it is critical that this function is declared inline.
+ * It was separated out from restore_state to make that function
+ * a little clearer, but it needs to be inlined because we won't have a
+ * stack when we get here (so we can't push a return address).
+ */
+static inline void restore_processor_context (void)
+{
+ /*
+ * first restore %ds, so we can access our data properly
+ */
+ asm volatile (".align 4");
+ asm volatile ("movw %0, %%ds" :: "r" ((u16)__KERNEL_DS));
+
+
+ /*
+ * control registers
+ */
+ asm volatile ("movl %0, %%cr4" :: "r" (saved_context.cr4));
+ asm volatile ("movl %0, %%cr3" :: "r" (saved_context.cr3));
+ asm volatile ("movl %0, %%cr2" :: "r" (saved_context.cr2));
+ asm volatile ("movl %0, %%cr0" :: "r" (saved_context.cr0));
+
+ /*
+ * segment registers
+ */
+ asm volatile ("movw %0, %%es" :: "r" (saved_context.es));
+ asm volatile ("movw %0, %%fs" :: "r" (saved_context.fs));
+ asm volatile ("movw %0, %%gs" :: "r" (saved_context.gs));
+ asm volatile ("movw %0, %%ss" :: "r" (saved_context.ss));
+
+ /*
+ * the other general registers
+ *
+ * note that even though gcc has constructs to specify memory
+ * input into certain registers, it will try to be too smart
+ * and save them at the beginning of the function. This is esp.
+ * bad since we don't have a stack set up when we enter, and we
+ * want to preserve the values on exit. So, we set them manually.
+ */
+ asm volatile ("movl %0, %%esp" :: "m" (saved_context.esp));
+ asm volatile ("movl %0, %%ebp" :: "m" (saved_context.ebp));
+ asm volatile ("movl %0, %%eax" :: "m" (saved_context.eax));
+ asm volatile ("movl %0, %%ebx" :: "m" (saved_context.ebx));
+ asm volatile ("movl %0, %%ecx" :: "m" (saved_context.ecx));
+ asm volatile ("movl %0, %%edx" :: "m" (saved_context.edx));
+ asm volatile ("movl %0, %%esi" :: "m" (saved_context.esi));
+ asm volatile ("movl %0, %%edi" :: "m" (saved_context.edi));
+
+ /*
+ * now restore the descriptor tables to their proper values
+ */
+ asm volatile ("lgdt (%0)" :: "m" (saved_context.gdt_limit));
+ asm volatile ("lidt (%0)" :: "m" (saved_context.idt_limit));
+ asm volatile ("lldt (%0)" :: "m" (saved_context.ldt));
+
+#if 0
+ asm volatile ("ltr (%0)" :: "m" (saved_context.tr));
+#endif
+
+ fix_processor_context();
+
+ /*
+ * the flags
+ */
+ asm volatile ("pushl %0 ; popfl" :: "m" (saved_context.eflags));
+}
+
+#endif
+
--- linux-2.4.20/drivers/acpi/hardware/hwsleep.c 2002/12/11 13:47:03 1.1
+++ linux-2.4.20/drivers/acpi/hardware/hwsleep.c 2002/12/11 19:48:55
@@ -319,6 +319,53 @@
/******************************************************************************
*
+ * FUNCTION: Acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS: None
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ * THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (
+ void)
+{
+ u32 in_value;
+ acpi_status status;
+
+
+ ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+
+ acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+ acpi_hw_clear_acpi_status();
+
+ acpi_hw_disable_non_wakeup_gpes();
+
+ ACPI_FLUSH_CPU_CACHE();
+
+ status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+ do {
+ acpi_os_stall(1000);
+ status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+ if (ACPI_FAILURE (status)) {
+ return_ACPI_STATUS (status);
+ }
+ } while (!in_value);
+
+ printk(KERN_DEBUG "acpi: s4bios coming to live\n");
+
+ return_ACPI_STATUS (AE_OK);
+}
+
+
+/******************************************************************************
+ *
* FUNCTION: Acpi_leave_sleep_state
*
* PARAMETERS: Sleep_state - Which sleep state we just exited
@@ -340,6 +387,8 @@
ACPI_FUNCTION_TRACE ("Acpi_leave_sleep_state");
+ /* Be sure to have BM arbitration */
+ status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
/* Ensure Enter_sleep_state_prep -> Enter_sleep_state ordering */
@@ -371,9 +420,6 @@
if (ACPI_FAILURE (status)) {
return_ACPI_STATUS (status);
}
-
- /* Disable BM arbitration */
- status = acpi_set_register (ACPI_BITREG_ARB_DISABLE, 0, ACPI_MTX_LOCK);
return_ACPI_STATUS (status);
}
--- linux-2.4.20/drivers/acpi/system.c 2002/12/11 13:55:11 1.1
+++ linux-2.4.20/drivers/acpi/system.c 2002/12/11 19:54:51
@@ -35,6 +35,7 @@
#include <linux/pm.h>
#include <linux/compatmac.h>
#include <linux/proc_fs.h>
+#include <linux/pm.h>
#include <asm/uaccess.h>
#include <asm/acpi.h>
#include "acpi_bus.h"
@@ -99,6 +100,189 @@
#ifdef CONFIG_ACPI_SLEEP
/**
+ * acpi_system_restore_state - OS-specific restoration of state
+ * @state: sleep state we're exiting
+ *
+ * Note that if we're coming back from S4, the memory image should have
+ * already been loaded from the disk and is already in place. (Otherwise how
+ * else would we be here?).
+ */
+acpi_status
+acpi_system_restore_state(
+ u32 state)
+{
+ /*
+ * We should only be here if we're coming back from STR or STD.
+ * And, in the case of the latter, the memory image should have already
+ * been loaded from disk.
+ */
+ if (state > ACPI_STATE_S1) {
+ acpi_restore_state_mem();
+
+ /* wait for power to come back */
+ mdelay(1000);
+
+ /* turn all the devices back on */
+ pm_send_all(PM_RESUME, (void *)0);
+
+ /* Be really sure that irqs are disabled. */
+ ACPI_DISABLE_IRQS();
+
+ /* Wait a little again, just in case... */
+ mdelay(1000);
+
+ /* enable interrupts once again */
+ ACPI_ENABLE_IRQS();
+
+ }
+
+ return AE_OK;
+}
+
+
+/**
+ * acpi_system_save_state - save OS specific state and power down devices
+ * @state: sleep state we're entering.
+ *
+ * This handles saving all context to memory, and possibly disk.
+ * First, we call to the device driver layer to save device state.
+ * Once we have that, we save whatevery processor and kernel state we
+ * need to memory.
+ * If we're entering S4, we then write the memory image to disk.
+ *
+ * Only then it is safe for us to power down devices, since we may need
+ * the disks and upstream buses to write to.
+ */
+acpi_status
+acpi_system_save_state(
+ u32 state)
+{
+ int error = 0;
+
+ /* Send notification to devices that they will be suspended.
+ * If any device or driver cannot make the transition, either up
+ * or down, we'll get an error back.
+ */
+ if (state > ACPI_STATE_S1) {
+ error = pm_send_all(PM_SAVE_STATE, (void *)3);
+ if (error)
+ return AE_ERROR;
+ }
+
+ if (state < ACPI_STATE_S5) {
+ /* Tell devices to stop I/O and actually save their state.
+ * It is theoretically possible that something could fail,
+ * so handle that gracefully..
+ */
+ if (state > ACPI_STATE_S1) {
+ error = pm_send_all(PM_SUSPEND, (void *)3);
+ if (error) {
+ /* Tell devices to restore state if they have
+ * it saved and to start taking I/O requests.
+ */
+ pm_send_all(PM_RESUME, (void *)0);
+ return error;
+ }
+ }
+
+ /* flush caches */
+ ACPI_FLUSH_CPU_CACHE();
+
+ /* Do arch specific saving of state. */
+ if (state > ACPI_STATE_S1) {
+ error = acpi_save_state_mem();
+
+ /* TBD: if no s4bios, write codes for
+ * acpi_save_state_disk()...
+ */
+#if 0
+ if (!error && (state == ACPI_STATE_S4))
+ error = acpi_save_state_disk();
+#endif
+ if (error) {
+ pm_send_all(PM_RESUME, (void *)0);
+ return error;
+ }
+ }
+ }
+ /* disable interrupts
+ * Note that acpi_suspend -- our caller -- will do this once we return.
+ * But, we want it done early, so we don't get any suprises during
+ * the device suspend sequence.
+ */
+ ACPI_DISABLE_IRQS();
+
+ /* Unconditionally turn off devices.
+ * Obvious if we enter a sleep state.
+ * If entering S5 (soft off), this should put devices in a
+ * quiescent state.
+ */
+
+ if (state > ACPI_STATE_S1) {
+ error = pm_send_all(PM_SUSPEND, (void *)3);
+
+ /* We're pretty screwed if we got an error from this.
+ * We try to recover by simply calling our own restore_state
+ * function; see above for definition.
+ *
+ * If it's S5 though, go through with it anyway..
+ */
+ if (error && state != ACPI_STATE_S5)
+ acpi_system_restore_state(state);
+ }
+ return error ? AE_ERROR : AE_OK;
+}
+
+
+/****************************************************************************
+ *
+ * FUNCTION: acpi_system_suspend
+ *
+ * PARAMETERS: %state: Sleep state to enter.
+ *
+ * RETURN: acpi_status, whether or not we successfully entered and
+ * exited sleep.
+ *
+ * DESCRIPTION: Perform OS-specific action to enter sleep state.
+ * This is the final step in going to sleep, per spec. If we
+ * know we're coming back (i.e. not entering S5), we save the
+ * processor flags. [ We'll have to save and restore them anyway,
+ * so we use the arch-agnostic save_flags and restore_flags
+ * here.] We then set the place to return to in arch-specific
+ * globals using arch_set_return_point. Finally, we call the
+ * ACPI function to write the proper values to I/O ports.
+ *
+ ****************************************************************************/
+
+acpi_status
+acpi_system_suspend(
+ u32 state)
+{
+ acpi_status status = AE_ERROR;
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ /* kernel_fpu_begin(); */
+
+ switch (state) {
+ case ACPI_STATE_S1:
+ barrier();
+ status = acpi_enter_sleep_state(state);
+ break;
+ case ACPI_STATE_S4:
+ do_suspend_lowlevel_s4bios(0);
+ break;
+ }
+
+ /* kernel_fpu_end(); */
+ local_irq_restore(flags);
+
+ return status;
+}
+
+
+
+/**
* acpi_suspend - OS-agnostic system suspend/resume support (S? states)
* @state: state we're entering
*
@@ -110,27 +294,45 @@
acpi_status status;
/* only support S1 and S5 on kernel 2.4 */
- if (state != ACPI_STATE_S1 && state != ACPI_STATE_S5)
+ printk(KERN_DEBUG "acpi: acpi_suspend call %d\n", state);
+ if (state != ACPI_STATE_S1 && state != ACPI_STATE_S4
+ && state != ACPI_STATE_S5)
return AE_ERROR;
+
+ /* For s4bios, we need a wakeup address. */
+ if (state == ACPI_STATE_S4) {
+ if (!acpi_wakeup_address)
+ return AE_ERROR;
+ acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
+ }
+
acpi_enter_sleep_state_prep(state);
+ status = acpi_system_save_state(state);
+ if (!ACPI_SUCCESS(status))
+ return status;
+
/* disable interrupts and flush caches */
ACPI_DISABLE_IRQS();
ACPI_FLUSH_CPU_CACHE();
/* perform OS-specific sleep actions */
- status = acpi_enter_sleep_state(state);
+ status = acpi_system_suspend(state);
/* Even if we failed to go to sleep, all of the devices are in an suspended
* mode. So, we run these unconditionaly to make sure we have a usable system
* no matter what.
*/
+ acpi_system_restore_state(state);
acpi_leave_sleep_state(state);
/* make sure interrupts are enabled */
ACPI_ENABLE_IRQS();
+ /* reset firmware waking vector */
+ acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) 0);
+
return status;
}
@@ -465,8 +667,12 @@
goto end;
for (i = 0; i <= ACPI_STATE_S5; i++) {
- if (system->states[i])
+ if (system->states[i]) {
p += sprintf(p,"S%d ", i);
+ if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f &&
+ acpi_gbl_FADT->smi_cmd != 0)
+ p += sprintf(p, "S4bios ");
+ }
}
p += sprintf(p, "\n");
@@ -507,9 +713,17 @@
state = simple_strtoul(state_string, NULL, 0);
+ printk(KERN_DEBUG "acpi: sleep %d\n", state);
if (!system->states[state])
return_VALUE(-ENODEV);
+ printk(KERN_DEBUG "acpi: GO!\n", state);
+ /*
+ * If S4 is supported by the OS, then we should assume that
+ * echo 4b > /proc/acpi/sleep is for s4bios.
+ * Since we have only s4bios, we assume that acpi_suspend failed
+ * if no s4bios support.
+ */
status = acpi_suspend(state);
if (ACPI_FAILURE(status))
return_VALUE(-ENODEV);
@@ -1007,9 +1221,18 @@
for (i=0; i<ACPI_S_STATE_COUNT; i++) {
u8 type_a, type_b;
status = acpi_get_sleep_type_data(i, &type_a, &type_b);
- if (ACPI_SUCCESS(status)) {
- system->states[i] = 1;
- printk(" S%d", i);
+ switch (i) {
+ case ACPI_STATE_S4:
+ if (acpi_gbl_FACS->S4bios_f && 0 != acpi_gbl_FADT->smi_cmd) {
+ printk(" S4bios");
+ system->states[i] = 1;
+ }
+ /* no break */
+ default:
+ if (ACPI_SUCCESS(status)) {
+ system->states[i] = 1;
+ printk(" S%d", i);
+ }
}
}
printk(")\n");
--- linux-2.4.20/arch/i386/kernel/acpi.c 2002/12/11 22:01:51 1.1
+++ linux-2.4.20/arch/i386/kernel/acpi.c 2002/12/11 21:02:33
@@ -42,6 +42,8 @@
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/io_apic.h>
+#include <asm/acpi.h>
+#include <asm/save_state.h>
#define PREFIX "ACPI: "
@@ -559,6 +561,21 @@
acpi_wakeup_address = (unsigned long)alloc_bootmem_low(PAGE_SIZE);
printk(KERN_DEBUG "ACPI: have wakeup address 0x%8.8lx\n", acpi_wakeup_address);
}
+
+void do_suspend_lowlevel_s4bios(int resume)
+{
+ if (!resume) {
+ printk("Saving CPU context...\n");
+ save_processor_context();
+ acpi_save_register_state((unsigned long)&&acpi_sleep_done);
+ acpi_enter_sleep_state_s4bios();
+ return;
+ }
+acpi_sleep_done:
+ restore_processor_context();
+ printk("CPU context restored...\n");
+}
+
#endif /*CONFIG_ACPI_SLEEP*/
^ permalink raw reply
* Re: autodetect RAID
From: Steven Dake @ 2002-12-13 15:56 UTC (permalink / raw)
To: Anuradha Vaidyanathan; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.21.0212122229250.19885-100000@karl.cs.wisc.edu>
Anuradha,
Autodetect works in all kernel revs (atleast 2.4 and 2.5 kernel revs).
Just use fdisk to set the partition type to 0xfd (raid autostart) and
the RAID partitions will be autostarted on boot.
Anuradha Vaidyanathan wrote:
>hello, where can one obtain the patch for autodetecting and which versions
>of the kernel does this work on??
>
>thanks
>-a
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
>
^ permalink raw reply
* order of ip tables/chains?
From: Denis Vlasenko @ 2002-12-13 14:36 UTC (permalink / raw)
To: linux-kernel; +Cc: vda
Dunno if this mail and your replies will reach the list/me,
we have some DNS problems here...
I'm setting up a firewall. I want to understand precise order
in which a packet traverse a multitude of ip tables/chains
which exist in recent 2.4 (say 2.4.20). This is what I currently
placed at the top of my script:
### filter This is the default table (if no -t option is passed). It contains
### the built-in chains INPUT (for packets coming into the box itself),
### FORWARD (for packets being routed through the box), and OUTPUT (for
### locally-generated packets).
###
### nat This table is consulted when a packet that creates a new connection
### is encountered. It consists of three built-ins: PREROUTING (for
### altering packets as soon as they come in), OUTPUT (for altering
### locally-generated packets before routing), and POSTROUTING (for
### altering packets as they are about to go out).
###
### mangle This table is used for specialized packet alteration. Until kernel
### 2.4.17 it had two built-in chains: PREROUTING (for altering incoming
### packets before routing) and OUTPUT (for altering locally-generated
### packets before routing). Since kernel 2.4.18, three other built-in
### chains are also supported: INPUT (for packets coming into the box
### itself), FORWARD (for altering packets being routed through the
### box), and POSTROUTING (for altering packets as they are about to go
### out).
(above: taken directly from man iptables)
(below: this is how I understand it. Combined from Rusty's excellent docs
on NAT and filtering. Thanks Rusty! Anyone spot something wrong below?)
###
###
### ..iface....................................iface...
### | ^
### v |
### -NAT,mangle- -filter,mangle- -NAT,mangle--
### |PREROUTING|->[Routing ]-->|FORWARD |-->|POSTROUTING|
### ------------ [Decision] --------------- -------------
### | ^
### v |
### -filter,mangle- -filter,NAT,mangle-
### |INPUT | |OUTPUT |
### --------------- -------------------
### | ^
### v |
### ... Local Process...
### ....Local Process...
(below: basically this is what I ask)
### TODO: check order of each a,b
### check whether is OUTPUT drawn where it should be
### (or maybe different table's OUTPUTs must be in different places?)
--
vda
^ permalink raw reply
* Re: mcc support on mpc8260
From: Ing.Gianfranco Morandi @ 2002-12-13 16:04 UTC (permalink / raw)
To: acurtis, Omanakuttan, linuxppc-embedded
In-Reply-To: <NCBBIINEHIPFGJPLBEIFAEBDEAAA.acurtis@onz.com>
I mean that by using the revision A.1 You could have some troubles.
Main reason is related to the Global Underrun (GUN) that often occours when
many channels are active (we use continuosly 64 channels on one mcc). This
issue has been repored by Motorola in its document "mpc8260cesumm.pdf" and
finally soved in the revision C.2 (6K23A)
Second issue, is related to the possibility of having a bit rotation into a
time slot. This problem has never been reported by Motorola but it seems to
be any more present in revisione C.2.
Regards
Gianfranco
----- Original Message -----
From: "Allen Curtis" <acurtis@onz.com>
To: "Ing.Gianfranco Morandi" <gianfranco.morandi@euro-studio.it>;
"Omanakuttan" <omanakuttan@tataelxsi.co.in>;
<linuxppc-embedded@lists.linuxppc.org>
Sent: Friday, December 13, 2002 3:59 PM
Subject: RE: mcc support on mpc8260
>
> > Be aware do not use the mcc with the silicon revision older than B.1.
>
> Could you provide more information on this comment. There are lots of
> reasons not to use a rev A.1 chip. This is the first time that I heard
about
> using too new of a chip.
>
> THX
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: NVRAM/RTC
From: Aman @ 2002-12-13 16:05 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc embedded
In-Reply-To: <20021212145243.A5263@home.com>
Hi Matt
This might be a very basic question. By porting what do you mean?. As of now
I copied the ebony bsp to different location and did changes to boot on the
custom board. Till now it was booting without any problem. Once I changed
the EBC configuration to configure some other FPGA ,bcos of which linux
booting hangs at " Now Booting the kernel ".
I commented the ioremap of RTC, and the definitions of
ppc_md.set_rtc_time = todc_set_rtc_time;
ppc_md.get_rtc_time = todc_get_rtc_time;
still the same problem. Should I hv to do something else also.
Thanking you in advance
regards
Aman
----- Original Message -----
From: "Matt Porter" <porter@cox.net>
To: "Aman" <aman@mistralsoftware.com>
Cc: "linuxppc embedded" <linuxppc-embedded@lists.linuxppc.org>
Sent: Friday, December 13, 2002 3:22 AM
Subject: Re: NVRAM/RTC
>
> On Thu, Dec 12, 2002 at 11:50:23PM +0530, Aman wrote:
> >
> > Hi All
> >
> > I have customized board , which has PPC 440GP as its processor. In this
> > board there is no NVRAM/RTC as in the 440GP evalkit. In the Rom monitor,
> > configuration related to it NVRAM/RTC has been removed. Because of this
> > changes in the rom monitor code, the linux image is hanging after " Now
> > Booting the Kernel". If NVRAM/RTC EBC bank1 is enabled in rom monitor,
the
> > linux image is executing without any problem. Can anyone say , how to
> > disable the NVRAM/RTC option in the linux kernel.
>
> Are you trying to run an ebony image on this board? Sounds like it,
> and that would be the wrong thing to do. Make a new port, and
> in your <board>.c file, don't ioremap the RTC area (since you don't
> have one) and delete (or set NULL) all the time/nvram machdeps.
>
> Regards,
> --
> Matt Porter
> porter@cox.net
> This is Linux Country. On a quiet night, you can hear Windows reboot.
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* kernel +patches recommendation for NFS-Server
From: Emanuel.Quass @ 2002-12-13 16:07 UTC (permalink / raw)
To: nfs
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Hi all,
can anyone give me a recommendation for a NFS-Server which kernel +
patches to use?
Thanks in advance
Emanuel Quass
[-- Attachment #2: Type: text/html, Size: 489 bytes --]
^ permalink raw reply
* 823 Video Controller Driver - where ?
From: Steve Rossi @ 2002-12-13 16:07 UTC (permalink / raw)
To: Embedded Linux PPC List
I've seen some reference on the list regarding a driver for the 823
Video Controller -
i.e.
http://lists.linuxppc.org/results.html?restrict=linuxppc-embedded&words=vid823
however I've been unable to locate the source to vid823.c
apparently this question was asked before:
http://lists.linuxppc.org/linuxppc-embedded/200201/msg00164.html
and the answer was that its in the 2_4_devel tree, but I was unable to
find it in a recent snapshot of the tree (I'm unable to get the tree
from the bitkeeper repository due to a problem in bitkeeper 3.0 related
to http proxy with authentication - but thats another story!) so I got
the snapshot from http://ppckernel.org/tree.php?id=5
All I could find was the RPX framebuffer driver rpxfb.c for various LCD
panels using the LCD controller..
I'm looking for a driver for the video controller to output to an NTSC
encoder. Am I just missing something?
Anyone know where I can get vid823.c (or whatever it might be called
now) and whether its a true framebuffer driver?
Regards,
Steve
--
-------------------------------------------------------
Steven K. Rossi srossi@labs.mot.com
Principal Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Symlink indirection
From: Pete Zaitcev @ 2002-12-13 16:16 UTC (permalink / raw)
To: Marc-Christian Petersen; +Cc: linux-kernel
In-Reply-To: <mailman.1039792562.8768.linux-kernel2news@redhat.com>
>> Is the number of allowed levels of symlink indirection (if that is the
>> right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
>> kernel, or libc ? Where is it defined, and can it be changed?
>
> fs/namei.c
>
> if (current->link_count >= 5)
>
> change to a higher value.
This is vey, very misleading statement. The counter mentioned above
is there to protect stacks from overflow, but our symlink resolution
is largely non-recursive, and certainly not in case of a tail
recursion within the same directory.
Also, consider this message from Al:
----------------------------------------------------
From: Alexander Viro <aviro@redhat.com>
Date: Mon, 3 Jun 2002 13:01:16 -0400
On Mon, Jun 03, 2002 at 12:21:59PM -0400, Matt Wilson wrote:
> SUSv3:
>
> http://www.opengroup.org/onlinepubs/007904975/basedefs/limits.h.html
>
> {_POSIX_SYMLOOP_MAX} The number of symbolic links that can be
> traversed in the resolution of a pathname in the absence of a
> loop. Value: 8
... and that has nothing to said limit of 5. What we do have limited
is the number of nested symlinks. 4BSD and derived Unices limit the
total amount of symlinks traveresed in pathname resolution. Example:
if you have
/a -> b
/b/a -> b
/b/b/a -> b
/b/b/b/a -> b
/b/b/b/b/a -> b
/b/b/b/b/b/a -> b
/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/b/a -> b
the pathname
/a/a/a/a/a/a/a/a/a
will resolve to
/b/b/b/b/b/b/b/b/b
and there will be 9 symlink traversals done during the pathname resolution.
However, the depth (i.e. the thing we do limit) is 1 in that case. OTOH,
with
/1 -> 2/a
/2 -> 3/a
/3 -> 4/a
/4 -> 5/a
/5 -> 6/a
/6 -> 7/a
/1
will resolve to
/7/a/a/a/a/a/a
with 6 symlink traversals and depth 6. IOW, SuS limit is not an argument
for changing the Linux one - they limit different things. They are not
independent, of course, since depth of recursion can't be greater than
total amount of symlinks we had traversed, but that's a separate story.
Frankly, all cases when I had seen the nested symlink farms of that
depth would be better served by use of bindings - these are not subject
to any limits on nesting and avoid a lot of PITA inherent to symlink
farms. To put it another way, nested symlink farms grow from attempts
to work around the lack of bindings. It's not that you need to replace
all symlinks with bindings, of course - the crown of the tree is usually
OK, it's the trunk that acts as source of pain.
^ permalink raw reply
* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Petr Konecny @ 2002-12-13 16:17 UTC (permalink / raw)
To: Valdis.Kletnieks@vt.edu; +Cc: Alessandro Suardi, Arjan van de Ven, linux-kernel
In-Reply-To: <200212131345.gBDDjw27002677@turing-police.cc.vt.edu>
Arjan> interesting. BUT aren't we writing to the device 3 lines before
Arjan> where you add the pci_enable_device()? That sounds like a bad
Arjan> plan to me ;(
Valdis> I see why the if/continue was added - you don't want to be
Valdis> calling device_register()/pci_insert_device() if
Valdis> pci_enable_device() loses. I don't see why 2.5.50 moved the
Valdis> code up after pci_setup_device(). There's an outside chance
Valdis> that the concept of moving the call was correct, but that it
Valdis> should have been moved to between the calls to
Valdis> pci_assign_resource() and pci_readb(). If that's the case,
Valdis> then you're correct as well....
I can confirm that this indeed works. I moved the two lines before
pci_readb and the card works (every character you now read went through
it). Who shall submit a patch to Linus ?
Now I have to figure out, how to make it load without manual modprobe
xircom_cb. Oh the joys of new module loader.
Petr
--
Computers are like air conditioners. Both stop working, if you open
windows.
-- Adam Heath
^ permalink raw reply
* Re: Symlink indirection
From: James Antill @ 2002-12-13 16:17 UTC (permalink / raw)
To: root; +Cc: Marc-Christian Petersen, linux-kernel, Andrew Walrond
In-Reply-To: <Pine.LNX.3.95.1021213102838.2190B-100000@chaos.analogic.com>
"Richard B. Johnson" <root@chaos.analogic.com> writes:
> On Fri, 13 Dec 2002, Marc-Christian Petersen wrote:
>
> > On Friday 13 December 2002 16:06, Andrew Walrond wrote:
> >
> > Hi Andrew,
> >
> > > Is the number of allowed levels of symlink indirection (if that is the
> > > right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
> > > kernel, or libc ? Where is it defined, and can it be changed?
> >
> > fs/namei.c
> >
> > if (current->link_count >= 5)
> >
> > change to a higher value.
> >
> > So, the answer is: Kernel :)
> >
> > ciao, Marc
>
> No, that thing (whetever it is) is different.
>
> Script started on Fri Dec 13 10:26:30 2002
> # file *
> foo: symbolic link to ../foo
*sigh*, you are following one symlink at a time ... what is this
proving ?
> You can do this until you run out of string-space. Your "link-count"
> has something to do with something else.
The link count is for recursively following symlinks, as the original
question wanted to know ... and has been discussed on lkml numerous
times.
Andrew, one extra piece of information you might not know is that the
above value doesn't come into play when the new symlink is the last
element in the new path, then you get a higher value.
The full code...
if (current->link_count >= max_recursive_link)
goto loop;
if (current->total_link_count >= 40)
goto loop;
[...]
current->link_count++;
current->total_link_count++;
UPDATE_ATIME(dentry->d_inode);
err = dentry->d_inode->i_op->follow_link(dentry, nd);
current->link_count--;
...Ie. a link from /a -> /b/c where "b" is a symlink takes the
"max_recursive_link" value (5 on vanilla kernels) but if "/b/c" was a
symlink then you get to use the 40 value.
--
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null
^ permalink raw reply
* RE: roxio easy cd creator 5 and linux
From: Chen, Jyh-Shing @ 2002-12-13 16:10 UTC (permalink / raw)
To: 'dashielljt'; +Cc: linux-admin
Hi,
On slackware 8.0, there is cdrtools under the AP disks.
If you install that tool and make sure that the ide-scsi module
is either running or already compiled into the kernel, then you
should be able to use mkisofs to make ISO image and use cdrecord
to burn a CD for most IDE writers. I have used those tools for
some time now on a few IDE writers.
Jyh-shing
-----Original Message-----
From: dashielljt [mailto:dashielljt@gmpexpress.net]
Sent: Thursday, December 12, 2002 9:42 PM
To: linux-admin@vger.kernel.org
Subject: roxio easy cd creator 5 and linux
I have one of these cdrw drives and it's an ide connect nd it reads no
problem but doing the cd-writing howto that brand and model isn't listed
in my version of the howto file (need to update my howtos), and the script
to make devices and scan cdrw drives also fails to work. I'm wondering if
roxio has a driver on line that needs downloading. I haven't had a chance
to get sighted assistance reading the manuals for it yet since there's so
much junk mail tossed in my mailbox daily. If someone here has their
drive burning using linux I'd like to know I'm not alone out here. The
box had as one of its hardware requirements slackware 3.5 and I have
slackware 8.0 runnning over here so figured it should be possible to get
fully functional.
Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH]Re: [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-13 16:13 UTC (permalink / raw)
To: Alan Cox; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <1039641154.18412.28.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Среда 11 Декабрь 2002 13:12, Alan Cox wrote:
> On Wed, 2002-12-11 at 19:42, Fedor Karpelevitch wrote:
> > So I wonder what toggling those bits is supposed to change. I
> > would test that somehow then
>
> 6 channel audio mode
so here is the patch against 2.4.21-pre1 (I beleive it should equally
apply to 20-ac2)
It works for me and fixes all four occurences of that error in the
driver.
Fedor
[-- Attachment #2: patch-tridfix.txt --]
[-- Type: text/plain, Size: 1480 bytes --]
--- linux-2.4.21-pre1-tridfix/drivers/sound/trident.c.orig 2002-12-12 15:28:00.000000000 -0800
+++ linux-2.4.21-pre1-tridfix/drivers/sound/trident.c 2002-12-12 15:30:48.000000000 -0800
@@ -3368,15 +3368,17 @@
pci_dev = pci_find_device(PCI_VENDOR_ID_AL,PCI_DEVICE_ID_AL_M1533, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
- pci_write_config_byte(pci_dev, 0x59, ~temp);
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp &= ~0x80;
+ pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
- pci_write_config_byte(pci_dev, 0xB8, ~temp);
+ pci_read_config_byte(pci_dev, 0xB8, &temp);
+ temp &= ~0x20;
+ pci_write_config_byte(pci_dev, 0xB8, temp);
return 0;
}
@@ -3390,13 +3392,15 @@
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x80;
+ pci_read_config_byte(pci_dev, 0x59, &temp);
+ temp |= 0x80;
pci_write_config_byte(pci_dev, 0x59, temp);
pci_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M7101, pci_dev);
if (pci_dev == NULL)
return -1;
- temp = 0x20;
+ pci_read_config_byte(pci_dev, (int)0xB8, &temp);
+ temp |= 0x20;
pci_write_config_byte(pci_dev, (int)0xB8,(u8) temp);
if (chan_nums == 6) {
dwValue = inl(TRID_REG(card, ALI_SCTRL)) | 0x000f0000;
^ permalink raw reply
* Re: PATCH: Four function buttons on DELL Latitude X200
From: Jan-Benedict Glaw @ 2002-12-13 16:22 UTC (permalink / raw)
To: linux-kernel; +Cc: michael
In-Reply-To: <3DF7BF10.7030204@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
On Wed, 2002-12-11 14:41:20 -0800, H. Peter Anvin <hpa@zytor.com>
wrote in message <3DF7BF10.7030204@zytor.com>:
> Pavel Machek wrote:
> >
> > Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> > prefix, too. I think there are really *weird* keyboards out there.
> >
>
> True enough, although very few things are going to recognize them at all.
A co-worker of me once developed some patch to handle some weired
Point of Sale keyboards (with magnetic stripe reader and some lock and
so on). He did it by allowing additional modules to parse everything
what is coming from keyboard controller (through additionally hooked
modules) before sending "normal" keycaps events to userspace. An
application willing to get the extra data could fetch that from some
/dev/ice node. This could be generalized to send input API events. I'll
CC him to allow him to speak up.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur
fuer einen Freien Staat voll Freier Bürger" | im Internet!
Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Nils Faerber @ 2002-12-13 16:14 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213155309.GG4327-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
On Fri, 13 Dec 2002 16:53:09 +0100
Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> Patch for 2.4.20 and acpi-20021205 for adding s4bios feature.
Hey, that sounds great!
Just a little question: How do I use it :)
Don't think I am stupid...
I know that a echo 1 > /proc/acpi/sleep should do the trick, i.e.
suspend to disk. But how do I configure that suspend partition? Or where
does it suspend? I know for Phoenix BIOSes there is a tool on the net to
create that partition. I have a Asus L3800C notebook which has AFAIK an
AWARD BIOS. And AFAIK there is no tool available from ASUS or AWARD to
create such a partition.
But I want to suspend!
Grmpf...
Any idea?
Help?
BTW: This is great work! Using BIOS S4 should be included into standard
ACPI code and maybe made an option so that swsusp can be used in
parallel...
Anyway, great and thanks!
> Cheers,
> Ducrot Bruno
CU
nils faerber
--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen D1 : +49-170-2729106
--
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-13 16:24 UTC (permalink / raw)
To: root; +Cc: Marc-Christian Petersen, linux-kernel
In-Reply-To: <Pine.LNX.3.95.1021213102838.2190B-100000@chaos.analogic.com>
No, I think marc was right...
daedalus@bob sym $ ls -l
total 4
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:19 a -> b
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:19 b -> c
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:20 c -> d
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:20 d -> e
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:20 e -> f
lrwxrwxrwx 1 daedalus users 1 Dec 13 16:20 f -> g
lrwxrwxrwx 1 daedalus users 4 Dec 13 16:21 g -> test
-rw-r--r-- 1 daedalus users 6 Dec 13 16:18 test
daedalus@bob sym $ cat a
cat: a: Too many levels of symbolic links
daedalus@bob sym $ cat b
cat: b: Too many levels of symbolic links
daedalus@bob sym $ cat c
Hello
^ permalink raw reply
* Re: Symlink indirection
From: Jesse Pollard @ 2002-12-13 16:26 UTC (permalink / raw)
To: root, Marc-Christian Petersen; +Cc: linux-kernel, Andrew Walrond
In-Reply-To: <Pine.LNX.3.95.1021213102838.2190B-100000@chaos.analogic.com>
On Friday 13 December 2002 09:30 am, Richard B. Johnson wrote:
> On Fri, 13 Dec 2002, Marc-Christian Petersen wrote:
> > On Friday 13 December 2002 16:06, Andrew Walrond wrote:
> >
> > Hi Andrew,
> >
> > > Is the number of allowed levels of symlink indirection (if that is the
> > > right phrase; I mean symlink -> symlink -> ... -> file) dependant on
> > > the kernel, or libc ? Where is it defined, and can it be changed?
> >
> > fs/namei.c
> >
> > if (current->link_count >= 5)
> >
> > change to a higher value.
> >
> > So, the answer is: Kernel :)
> >
> > ciao, Marc
>
> No, that thing (whetever it is) is different.
>
> Script started on Fri Dec 13 10:26:30 2002
> # file *
> foo: symbolic link to ../foo
> typescript: empty
> # pwd
> /root/foo
> # cd *
> # cd *
> # cd *
> # cd *
> # cd *
> # cd *
> # pwd
> /root/foo/foo/foo/foo/foo/foo/foo
> # cd *
> # cd *
> # cd *
> # pwd
> /root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
> # cd *
> # cd *
> # cd *
> # pwd
> /root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
> # exit
> exit
>
> Script done on Fri Dec 13 10:27:21 2002
>
>
> You can do this until you run out of string-space. Your "link-count"
> has something to do with something else.
Example isn't the same thing:
[pollard@merlin ~/test]$ echo "test" >target
[pollard@merlin ~/test]$ ln -s target a - 1 link
[pollard@merlin ~/test]$ ln -s a b - 2 links
[pollard@merlin ~/test]$ ln -s b c - 3
[pollard@merlin ~/test]$ ln -s c d - 4
[pollard@merlin ~/test]$ cat d
test
[pollard@merlin ~/test]$ ln -s d e -5
[pollard@merlin ~/test]$ cat e
test
[pollard@merlin ~/test]$ ln -s e f -6
[pollard@merlin ~/test]$ cat f
cat: f: Too many levels of symbolic links
This catches problem situations like:
[pollard@merlin ~/test]$ ln -s loop loop
[pollard@merlin ~/test]$ ls -l loop
lrwxrwxrwx 1 pollard NA0101 4 Dec 13 10:24 loop -> loop
[pollard@merlin ~/test]$ cat loop
cat: loop: Too many levels of symbolic links
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
^ permalink raw reply
* RE: [PATCH] Add CONFIG_ACPI_RELAXED_AML option
From: Moore, Robert @ 2002-12-13 16:22 UTC (permalink / raw)
To: 'Herbert Nachtnebel', NoZizzing OrDripping,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Therien, Guy, Grover, Andrew
I must agree that this is a really bad idea. Once we start allowing these
kinds of errors to slip by, there is potentially no end to it. It's a very
slippery slope that will potentially plunge everyone into the same kind of
BIOS abyss that ACPI was intended to solve in the first place.
Worse, there are situations where the AML interpreter cannot "guess" what
the ASL/AML (BIOS) coder actually intended, i.e., there are multiple
solutions to the problem.
What is really being proposed here is for Linux ACPI to be bug-for-bug
compatible with Microsoft. This is impossible to do deterministically
because the MS interpreter is closed source. The only standard that we have
that we can code to is the ACPI specification, and this has to be the last
word on the matter.
We have a good opportunity here to help drive the industry to proper BIOS
and ACPI implementations by following the specification and developing tools
(such as the iASL compiler) that help enforce conformance to the ACPI
specification -- and also giving feedback to the BIOS vendors about their
broken ASL code.
Bob Moore
-----Original Message-----
From: Herbert Nachtnebel [mailto:Herbert.Nachtnebel-8zxNtbQCHXIjuwv8T7myQQ@public.gmane.org]
Sent: Friday, December 13, 2002 1:30 AM
To: NoZizzing OrDripping; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: AW: [ACPI] [PATCH] Add CONFIG_ACPI_RELAXED_AML option
That's a really bad idea! This size checks are identented to assure, that
important data which accidently follows the buffer can't be overridden by
brain dead bios coders. Now you allow buffer overflow injection into linux
from the bios!
These are serious bios faults, in my DSDT I had to extend a buffer by 128
bytes to avoid a buffer overflow!
The situation doesn't get better if we ignore such errors. We have to urge
the manufacturers to correct the DSDT's. And the best way to do this is to
recognise the faults and blame them.
Herbert.
> -----Ursprüngliche Nachricht-----
> Von: NoZizzing OrDripping [mailto:nozizzingordripping-/E1597aS9LQAvxtiuMwx3w@public.gmane.org]
> Gesendet: Freitag, 13. Dezember 2002 05:48
> An: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Betreff: [ACPI] [PATCH] Add CONFIG_ACPI_RELAXED_AML option
>
>
> The patch adds a new configuration option,
> CONFIG_ACPI_RELAXED_AML. When turned on,
> the ACPI code will become forgiving of minor
> errors in the AML code.
>
> For this first cut, the patch and option will ignore
> region size errors. An off-by-one error is often
> found in the AML shipped with Toshiba laptops,
> even new models. This minor error prevents the
> AC module from operating without this patch.
>
> I urge the adoption of this patch (or something
> similar) into the ACPI code. This will make it
> much easier to install and proliferate Linux on
> a large category of laptops.
>
> Rick Richardson
> rickr-EySxSuIQeMUAvxtiuMwx3w@public.gmane.org
> [Sorry, have to use my Yahoo account to post to this list)
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* RE: Unauthorized Activity Detection using IPTables
From: Vagner Machado @ 2002-12-13 16:25 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
See <http://www.psionic.com/products/portsentry.html>
http://www.psionic.com/products/portsentry.html
-----Original Message-----
From: Amit Kumar Gupta [mailto:amitkumar.gupta@wipro.com]
Sent: sexta-feira, 13 de dezembro de 2002 11:44
To: netfilter@lists.netfilter.org
Subject: Unauthorized Activity Detection using IPTables
Hi,
I want to know how to detect unauthorized activities in firewall using
IPtables.
If any user tries for some unauthorized service, I should be able to log it
and drop it.
Please give suggestions.
Thanks & Regards.
Amit
[-- Attachment #2: Type: text/html, Size: 5827 bytes --]
^ permalink raw reply
* Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Nils Faerber @ 2002-12-13 16:27 UTC (permalink / raw)
To: Nils Faerber
Cc: ducrot-kk6yZipjEM5g9hUCZPvPmw, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213171431.045233f0.nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org>
On Fri, 13 Dec 2002 17:14:31 +0100
Nils Faerber <nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org> wrote:
> On Fri, 13 Dec 2002 16:53:09 +0100
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > Patch for 2.4.20 and acpi-20021205 for adding s4bios feature.
> Don't think I am stupid...
Oh sorry, I am stupid...
> I know that a echo 1 > /proc/acpi/sleep should do the trick, i.e.
> suspend to disk. But how do I configure that suspend partition? Or
It should read echo 4 > ... of course :(
> > Cheers,
> > Ducrot Bruno
CU
nils faerber
--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen D1 : +49-170-2729106
--
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-13 16:34 UTC (permalink / raw)
To: James Antill; +Cc: linux-kernel
In-Reply-To: <m3bs3pao5m.fsf@code.and.org>
Hi James.
Thanks for the info; my application is now entirely plausible :)
And apologies for asking an FAQ. (Google didn't throw up anything useful)
BTW is documented anywhere except the code?
Andrew
>
> The link count is for recursively following symlinks, as the original
> question wanted to know ... and has been discussed on lkml numerous
> times.
>
> Andrew, one extra piece of information you might not know is that the
> above value doesn't come into play when the new symlink is the last
> element in the new path, then you get a higher value.
> The full code...
>
> if (current->link_count >= max_recursive_link)
> goto loop;
> if (current->total_link_count >= 40)
> goto loop;
> [...]
> current->link_count++;
> current->total_link_count++;
> UPDATE_ATIME(dentry->d_inode);
> err = dentry->d_inode->i_op->follow_link(dentry, nd);
> current->link_count--;
>
> ...Ie. a link from /a -> /b/c where "b" is a symlink takes the
> "max_recursive_link" value (5 on vanilla kernels) but if "/b/c" was a
> symlink then you get to use the 40 value.
>
^ permalink raw reply
* Re: 2.4.20-ac1 KT400 AGP support
From: Dave Jones @ 2002-12-13 16:36 UTC (permalink / raw)
To: BoehmeSilvio; +Cc: linux-kernel
In-Reply-To: <2F4E8F809920D611B0B300508BDE95FE294452@AFB91>
On Fri, Dec 13, 2002 at 11:18:39AM +0100, BoehmeSilvio wrote:
> I don't need the AGP 8X mode, but is it possible,
> to get this setup running in whatever agp mode ?
You misunderstand. You have an AGP 3.0 bridge.
Various things are done differently to how they were in previous
revisions of the standard. For example, the aperture size is now
a 16 bit field (which is why people are getting that
"can't determine aperture size" error).
I'm working on merging the Intel patches posted here a while
ago, and bending the generic bits into something that *might*
work (I don't have a board to test -- I'll shout when I have
something I want people to test with), note that I'm doing this
for 2.5 however. 2.4 is going to have to wait.
> Currently it is only possible to start X with VESA support,
> because all other drivers need agpgart.
X should start, but you'll get no accelerated 3d.
None of the X drivers _need_ agpgart except for maybe the
i810 with shared memory.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-13 16:29 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <3DF9C1CD.3090205@gmx.de>
At Fri, 13 Dec 2002 12:17:33 +0100,
Friedrich Ewaldt wrote:
>
> >>you can check this also via lspci command.
> >>
> >>
> >
> >lspcidrake -v will give him the module too
> >
> >
> I already attached my lspci -v outputs in two previous mails, but to be
> sure they get to where they should ...
>
> 00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
> [FM801] (rev a0)
> Subsystem: Fortemedia, Inc: Unknown device 1319
> Flags: bus master, medium devsel, latency 40, IRQ 10
> I/O ports at ec00 [size=128]
> Capabilities: [dc] Power Management version 1
>
> 00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
> (rev a0)
> Subsystem: Fortemedia, Inc: Unknown device 1319
> Flags: bus master, medium devsel, latency 40, IRQ 11
> Capabilities: [dc] Power Management version 1
i need the pci vendor/device id for them.
could you give me the output of "lspci -n" for two devices above?
the audio chip should be 0x1319:0x0801.
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
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.