Re: 2.6.11-mm3

2005-03-15 Thread Stefano Rivoir
Alle 12:42, sabato 12 marzo 2005, Andrew Morton ha scritto:

 - A new version of the acpi poweroff fix.  People who were having trouble
   with ACPI poweroff, please test and report.

Hi Andrew,

This does not work for me. The only difference since previous versions is that 
cursor stops blinking (don't know how meaningful can this be...), but the box 
hangs as usual.

Here attached .config and lscpi-v.

Bye

-- 
Stefano Rivoir
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mm3
# Mon Mar 14 09:12:55 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_CLEAR_PAGES=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODE is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y
CONFIG_SECCOMP=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_ASUS=m
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
CONFIG_ACPI_CONTAINER=m

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
# CONFIG_PCMCIA_LOAD_CIS is not set
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
# CONFIG_PD6729 is not set
# 

Re: [patch] del_timer_sync scalability patch

2005-03-15 Thread Christoph Lameter
How about this take on the problem?

When a potential periodic timer is deleted through timer_del_sync, all cpus
are scanned to determine if the timer is running on that cpu. In a NUMA
configuration doing so will cause NUMA interlink traffic which limits the
scalability of timers.

The following patch removes the magic in the timer_list structure (Andrew
suggested that we may not need it anymore) and replaces it with two u8
variables that give us some additional state of the timer

running - Set if the timer function is currently executing
shutdown- Set if del_timer_sync is running and the timer
   should not be rescheduled.

Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Shai Fultheim [EMAIL PROTECTED]

Index: linux-2.6.11/include/linux/timer.h
===
--- linux-2.6.11.orig/include/linux/timer.h 2005-03-14 14:17:51.671533904 
-0800
+++ linux-2.6.11/include/linux/timer.h  2005-03-14 14:41:49.640929328 -0800
@@ -13,22 +13,22 @@ struct timer_list {
unsigned long expires;

spinlock_t lock;
-   unsigned long magic;

void (*function)(unsigned long);
unsigned long data;

-   struct tvec_t_base_s *base;
+   struct tvec_t_base_s *base; /* ==NULL if timer not scheduled */
+   u8 running; /* function is currently executing */
+   u8 shutdown;/* do not schedule this timer */
 };

-#define TIMER_MAGIC0x4b87ad6e
-
 #define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires),  \
.data = (_data),\
.base = NULL,   \
-   .magic = TIMER_MAGIC,   \
+   .running = 0,   \
+   .shutdown = 0,  \
.lock = SPIN_LOCK_UNLOCKED, \
}

@@ -42,7 +42,8 @@ struct timer_list {
 static inline void init_timer(struct timer_list * timer)
 {
timer-base = NULL;
-   timer-magic = TIMER_MAGIC;
+   timer-running = 0;
+   timer-shutdown = 0;
spin_lock_init(timer-lock);
 }

Index: linux-2.6.11/kernel/timer.c
===
--- linux-2.6.11.orig/kernel/timer.c2005-03-14 14:17:51.671533904 -0800
+++ linux-2.6.11/kernel/timer.c 2005-03-14 14:57:24.613791848 -0800
@@ -89,31 +89,6 @@ static inline void set_running_timer(tve
 /* Fake initialization */
 static DEFINE_PER_CPU(tvec_base_t, tvec_bases) = { SPIN_LOCK_UNLOCKED };

-static void check_timer_failed(struct timer_list *timer)
-{
-   static int whine_count;
-   if (whine_count  16) {
-   whine_count++;
-   printk(Uninitialised timer!\n);
-   printk(This is just a warning.  Your computer is OK\n);
-   printk(function=0x%p, data=0x%lx\n,
-   timer-function, timer-data);
-   dump_stack();
-   }
-   /*
-* Now fix it up
-*/
-   spin_lock_init(timer-lock);
-   timer-magic = TIMER_MAGIC;
-}
-
-static inline void check_timer(struct timer_list *timer)
-{
-   if (timer-magic != TIMER_MAGIC)
-   check_timer_failed(timer);
-}
-
-
 static void internal_add_timer(tvec_base_t *base, struct timer_list *timer)
 {
unsigned long expires = timer-expires;
@@ -164,8 +139,6 @@ int __mod_timer(struct timer_list *timer

BUG_ON(!timer-function);

-   check_timer(timer);
-
spin_lock_irqsave(timer-lock, flags);
new_base = __get_cpu_var(tvec_bases);
 repeat:
@@ -208,8 +181,10 @@ repeat:
ret = 1;
}
timer-expires = expires;
-   internal_add_timer(new_base, timer);
-   timer-base = new_base;
+   if (!timer-shutdown) {
+   internal_add_timer(new_base, timer);
+   timer-base = new_base;
+   }

if (old_base  (new_base != old_base))
spin_unlock(old_base-lock);
@@ -235,7 +210,8 @@ void add_timer_on(struct timer_list *tim

BUG_ON(timer_pending(timer) || !timer-function);

-   check_timer(timer);
+   if (timer-shutdown)
+   return;

spin_lock_irqsave(base-lock, flags);
internal_add_timer(base, timer);
@@ -267,8 +243,6 @@ int mod_timer(struct timer_list *timer,
 {
BUG_ON(!timer-function);

-   check_timer(timer);
-
/*
 * This is a common optimization triggered by the
 * networking code - if the timer is re-modified
@@ -298,8 +272,6 @@ int del_timer(struct timer_list *timer)
unsigned long flags;
tvec_base_t *base;

-   check_timer(timer);
-
 repeat:
base = timer-base;
if (!base)
@@ -337,35 

Re: [patch] del_timer_sync scalability patch

2005-03-15 Thread Oleg Nesterov
Christoph Lameter wrote:

 On Sun, 13 Mar 2005, Oleg Nesterov wrote:

  I suspect that del_timer_sync() in its current form is racy.
 
...snip...
  next timer interrupt, __run_timers() picks
  this timer again, sets timer-base = NULL
  ^^^
 
  if (timer_pending(timer))   
  // no, timer-base == NULL

 timer-base is != NULL because the timer has rescheduled itself.
 __mod_timer sets timer-bBase

Christoph, please look again. Yes, __mod_timer sets timer-base,
but it is cleared in the _next_ timer interrupt on CPU 0.

Andrew, Ingo, what do you think?

Oleg.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/5] I8K driver facelift

2005-03-15 Thread Valdis . Kletnieks
On Sat, 12 Mar 2005 20:41:14 MST, Frank Sorenson said:

 These patches look pretty good.  A few comments (with a patch--tested on
 my Inspiron 9200):

I tested your patch on top of Dmitry's on a Dell Latitude C840, seems to work.

 - - Some of the Dell motherboards provide more than 1 temperature sensor.
 ~ How about a generic i8k_get_temp function, and i8k_get_cpu_temp just
 calls that with sensor 0.
 
 - - Also, I've added detection of the number of temperature sensors and
 fans at init time.  This way, we aren't hardcoded to 1 sensor and 2
 fans.  I couldn't figure out how to set up the sysfs entries
 dynamically, but that probably should happen too.

According to your patch, the C840 has 2 temp sensors. I'll have to figure
out what the second one is (prob either the GPU or the disk drive?)


pgp3OjiePzAAX.pgp
Description: PGP signature


Re: [ACPI] Re: Call for help: list of machines with working S3

2005-03-15 Thread Li Shaohua
Hi,
On Mon, 2005-03-14 at 16:00, Pavel Machek wrote:
 Hi!
 
* MySQL (hinders the actual suspension process and kicks the pc
 back to 
  where it was)
 
 Try this patch...
 Pavel
 
 --- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
 +++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
 @@ -,6 +,7 @@
 ret = -EINTR;
 }
  
 +   try_to_freeze(1);
 return ret;
  }
I also encounter a similar issue. syslogd can't be stopped. It's waiting
for kjournald to flush some works but kjournald is stopped first. Looks
like the kernel thread should be stopped later than user thread just
like Nigel's suspend2 patch does.

Thanks,
Shaohua

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Repeatable IDE Oops for 2.6.11 (ide-scsi vs ide-cdrom)

2005-03-15 Thread Bartlomiej Zolnierkiewicz
On Mon, 14 Mar 2005, Alan Cox wrote:
On Llu, 2005-03-14 at 06:55, Paul wrote:
# cat driver
ide-cdrom version 4.61
# echo ide-scsi  driver
# cat driver
This has always been unsafe. Its something I suggested was removed a
long time ago because the locking for it is unfixable.
Locking is fixed in ide-dev-2.6 tree
(at the moment seem to be dropped from -mm?).
[ the FIXME comment left in ide-proc.c is also applicable to
  modprobe/rmmod case as the issue is not /proc/.../driver specific ]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][1/2] SquashFS

2005-03-15 Thread Paul Jackson
In the overall kernel (Linus's bk tree) I count:

733 lines matching 'for *( *; *; *)'
718 lines matching 'while *( *1 *)'

In the kernel/*.c files, I count 15 of the 'for(;;)' style and 1 of the
'while(1)' style.

Certainly the 'for(;;)' style is acceptable, and even slightly to
substantially dominant, depending on which piece of code you're in.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: oom with 2.6.11

2005-03-15 Thread Mauricio Lin
Hi Christian,

On Fri, 11 Mar 2005 16:09:24 +0100, Christian Kujau [EMAIL PROTECTED] wrote:
 Mauricio Lin wrote:
  Hi Christian,
 
  I would like to know what are the kernel versions this problem happened.
 
  Did this problem start from 2.6.11-rc2-bk10?
 
 i noticed it first at 2.6.11, then again with 2.6.11-rc5-bk2. suspecting
 pppd to be the culprit to chew up all RAM after being terminated by my ISP
 once a day - i just have to wait (must be around 2a.m.).

Have you tried with 2.6.10 in order to check this problem?

BR,

Mauricio Lin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [ACPI] [PATCH] Panasonic ACPI driver

2005-03-15 Thread Timo Hoenig
Hi,

On Tue, 2005-03-15 at 14:03 +0800, Yu, Luming wrote:
Basically, this driver just call some specific AML method for hotkey function, 
that can be 
achieved through generic hotkey driver filed at 
http://bugzilla.kernel.org/show_bug.cgi?id=3887.
So I don't think this driver is needed.

OK. I will give it a try to merge the driver it into your generic hotkey
driver.

See you,

   -- Timo

..
Timo Hönig thoenig at suse dot de
..:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066


signature.asc
Description: This is a digitally signed message part


Re: [PATCH] x86-64 kprobes: handle %RIP-relative addressing mode

2005-03-15 Thread Roland McGrath
 Can you turn these two arrays into a bitmap please? 

Ok.

 This shouldn't be opencoded here. Instead make a utility function
 like vmalloc_range() that takes a start and end address and
 make the module allocation use it too.
 
 Also you should fix up asm-x86_64/page.h and Documentation/x86_64/mm.txt
 with the new fixed allocation.
[...]
 I think Andrea has just changed that and the patch went into
 mainline. Be careful with merging.

Since __get_vm_area has been changed to make it harder to avoid the guard
page, I decided just to punt and use module_alloc instead.  This works
either with or without the -mm patches that clean it up to use __vmalloc_area.
There is enough address space in the module area that I'm not going to
worry about each page kprobes uses wasting a second page of address space.

Here is a new version of the patch that addresses your comments.


Thanks,
Roland


Signed-off-by: Roland McGrath [EMAIL PROTECTED]

--- linux-2.6/arch/x86_64/kernel/kprobes.c
+++ linux-2.6/arch/x86_64/kernel/kprobes.c
@@ -25,6 +25,8 @@
  * interface to access function arguments.
  * 2004-OctJim Keniston [EMAIL PROTECTED] and Prasanna S Panchamukhi
  * [EMAIL PROTECTED] adapted for x86_64
+ * 2005-MarRoland McGrath [EMAIL PROTECTED]
+ * Fixed to handle %rip-relative addressing mode correctly.
  */
 
 #include linux/config.h
@@ -34,7 +36,7 @@
 #include linux/string.h
 #include linux/slab.h
 #include linux/preempt.h
-#include linux/vmalloc.h
+#include linux/moduleloader.h
 
 #include asm/pgtable.h
 #include asm/kdebug.h
@@ -86,9 +88,132 @@ int arch_prepare_kprobe(struct kprobe *p
return 0;
 }
 
+/*
+ * Determine if the instruction uses the %rip-relative addressing mode.
+ * If it does, return the address of the 32-bit displacement word.
+ * If not, return null.
+ */
+static inline s32 *is_riprel(u8 *insn)
+{
+#define W(row,b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf)   \
+   (((b0##UL  0x0)|(b1##UL  0x1)|(b2##UL  0x2)|(b3##UL  0x3) |   \
+ (b4##UL  0x4)|(b5##UL  0x5)|(b6##UL  0x6)|(b7##UL  0x7) |   \
+ (b8##UL  0x8)|(b9##UL  0x9)|(ba##UL  0xa)|(bb##UL  0xb) |   \
+ (bc##UL  0xc)|(bd##UL  0xd)|(be##UL  0xe)|(bf##UL  0xf))\
+ (row % 64))
+   static const u64 onebyte_has_modrm[256 / 64] = {
+   /*  0 1 2 3 4 5 6 7 8 9 a b c d e f */
+   /*  --- */
+   W(0x00, 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0)| /* 00 */
+   W(0x10, 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0)| /* 10 */
+   W(0x20, 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0)| /* 20 */
+   W(0x30, 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0), /* 30 */
+   W(0x40, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* 40 */
+   W(0x50, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* 50 */
+   W(0x60, 0,0,1,1,0,0,0,0,0,1,0,1,0,0,0,0)| /* 60 */
+   W(0x70, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), /* 70 */
+   W(0x80, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* 80 */
+   W(0x90, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* 90 */
+   W(0xa0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* a0 */
+   W(0xb0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), /* b0 */
+   W(0xc0, 1,1,0,0,1,1,1,1,0,0,0,0,0,0,0,0)| /* c0 */
+   W(0xd0, 1,1,1,1,0,0,0,0,1,1,1,1,1,1,1,1)| /* d0 */
+   W(0xe0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* e0 */
+   W(0xf0, 0,0,0,0,0,0,1,1,0,0,0,0,0,0,1,1)  /* f0 */
+   /*  --- */
+   /*  0 1 2 3 4 5 6 7 8 9 a b c d e f */
+   };
+   static const u64 twobyte_has_modrm[256 / 64] = {
+   /*  0 1 2 3 4 5 6 7 8 9 a b c d e f */
+   /*  --- */
+   W(0x00, 1,1,1,1,0,0,0,0,0,0,0,0,0,1,0,1)| /* 0f */
+   W(0x10, 1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0)| /* 1f */
+   W(0x20, 1,1,1,1,1,0,1,0,1,1,1,1,1,1,1,1)| /* 2f */
+   W(0x30, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0), /* 3f */
+   W(0x40, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* 4f */
+   W(0x50, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* 5f */
+   W(0x60, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* 6f */
+   W(0x70, 1,1,1,1,1,1,1,0,0,0,0,0,1,1,1,1), /* 7f */
+   W(0x80, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)| /* 8f */
+   W(0x90, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* 9f */
+   W(0xa0, 0,0,0,1,1,1,1,1,0,0,0,1,1,1,1,1)| /* af */
+   W(0xb0, 1,1,1,1,1,1,1,1,0,0,1,1,1,1,1,1), /* bf */
+   W(0xc0, 1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0)| /* cf */
+   W(0xd0, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* df */
+   W(0xe0, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)| /* ef */
+   W(0xf0, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0)  /* ff */
+   /*  

Re: spin_lock error in arch/i386/kernel/time.c on APM resume

2005-03-15 Thread George Anzinger
Pavel Machek wrote:
Hi!

I agree.  Still in all that follows, no one has addressed the apparent 
race described above.  The reason the system reported the errors that 
started this thread is that the APM restore code was trying to read the 
cmos clock (I assume to set the xtime clock) WHILE the timer interrupt 
code what trying to set the cmos clock from xtime.  In other words, it is 
destroying the time it is trying to read.  I repeat Possibly the APM 
code should change time_status to STA_UNSYNC on the way into the sleep.  
I am not sure how ntp is supposed to react to the resume but I suspect 
that the system time is rather out of sync...

It needs to work without NTP, too. You don't get NTP on plane (etc)
where suspend is most usefull.
We have CMOS clock, it should be possible to get time from there
without resorting to NTP..
Eh... sure, but... the bug was reported because the system was attempting 
to update the cmos clock (which it does every ~11 min.) during APM exit.   
It does this IF AND ONLY IF the system is synced to an external source as 
indicated by the STA_UNSYNC bit being cleared in the time_state.  Now, I 
don't know what or how APM and NTP are supposed to play together, but I 
suspect that on entry to APM time is no longer synced, thus my comment.

As to your comment, the bug would never have shown its ugly face if the 
system wasn't using NTP.

Uh, ok, you are right. We should set time to STA_UNSYNC so that we do
not write back to CMOS during/shortly after resume. I did not realize
what STA_UNSYNC means. Perhaps you have patch to  do that somewhere?
;-
Zwane has convinced me that the real problem is doing the right thing (tm) in 
the APM code, i.e. not allowing the timer interrupt until after reading the cmos 
clock, for which he has a patch tendered.

--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] smbfs bug fix

2005-03-15 Thread Pavel Fedin
 Current smbfs has a bug: you can't supply user, noauto flags for it
in /etc/fstab. smbmount tool expands this to noexec, nosuid, nodev,
user, noauto and smbfs rejects all arguments because it doesn't know
any of these keywords.
 This patch fixes it. It introduces these arguments to the smbfs which
will silently ignore them in the same way as cifs does.
 The patch is made for 2.6.11.1 kernel.

-- 
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- linux-2.6.11.1/fs/smbfs/inode.c.orig2005-03-04 12:26:29.0 
-0500
+++ linux-2.6.11.1/fs/smbfs/inode.c 2005-03-15 11:57:52.0 -0500
@@ -351,6 +351,11 @@
{ iocharset,  0, 'i' },
{ codepage,   0, 'c' },
{ ttl,0, 't' },
+   { noexec, SMB_MOUNT_IGNORE, 1},
+   { nosuid, SMB_MOUNT_IGNORE, 1},
+   { nodev,  SMB_MOUNT_IGNORE, 1},
+   { user,   SMB_MOUNT_IGNORE, 1},
+   { noauto, SMB_MOUNT_IGNORE, 1},
{ NULL, 0, 0}
 };
 
--- linux-2.6.11.1/include/linux/smb_mount.h.orig   2005-03-04 
12:26:27.0 -0500
+++ linux-2.6.11.1/include/linux/smb_mount.h2005-03-15 11:38:28.0 
-0500
@@ -42,6 +42,7 @@
 #define SMB_MOUNT_GID  0x0040  /* Use user specified gid */
 #define SMB_MOUNT_FMODE0x0080  /* Use user specified file mode 
*/
 #define SMB_MOUNT_DMODE0x0100  /* Use user specified dir mode 
*/
+#define SMB_MOUNT_IGNORE   0x8000  /* Dummy flag */
 
 struct smb_mount_data_kernel {
int version;


Re: [PATCH] Per cpu irq stat

2005-03-15 Thread Christoph Hellwig
On Mon, Mar 14, 2005 at 10:32:34PM -0800, Christoph Lameter wrote:
 The definition of the irq_stat as an array means that the individual
 elements of the irq_stat array are located on one NUMA node requiring
 internode traffic to access irq_stat from other nodes. This patch makes
 irq_stat a per_cpu variable which allows most accesses to be local.

There's architectures accessing it from assemly.

But furthermore there's absolutely not point for the irq_stat structure
at all anymore now that we have the per_cpu infrastructure.  so kill it
completely and let every architecture just provide a local_softirq_pending
macro.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] del_timer_sync scalability patch

2005-03-15 Thread Oleg Nesterov
Christoph Lameter wrote:

 @@ -476,6 +454,7 @@ repeat:
   }
   }
   spin_lock_irq(base-lock);
 + timer-running = 0;
^^
   goto repeat;
   }
   }

This is imho wrong. The timer probably don't exist when
timer_list-function returns.

I mean, timer_list-function could deallocate timer's memory.

Oleg.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.11-mm3: SIS5513 DMA problem (set_drive_speed_status)

2005-03-15 Thread Martin Zwickel
On Mon, 14 Mar 2005 21:17:55 -0800
Andrew Morton [EMAIL PROTECTED] bubbled:

 Martin Zwickel [EMAIL PROTECTED] wrote:
 
  Hi,
  
  just tried the 2.6.11-mm3 and at boot-time my start scripts try to
  enable DMA on my disk (hdparm -m16 -c1 -u1 -X69 /dev/hda).
  
  But while running hdparm, the kernel waits many seconds and gives me
  some DMA warnings/errors:
 
  ...
 
  hda: set_drive_speed_status: status=0xd0 { Busy }
  
  ide: failed opcode was: unknown
  hda: dma_timer_expiry: dma status == 0x41
  hda: DMA timeout error
  hda: dma timeout error: status=0xd0 { Busy }
  ...
  
  That happened also with 2.6.11-rc3 since I thought I should switch
  away from my 2.6.8-rc2-mm1 (the best kernel ever ;)).
 
 Could you please check whether 2.6.11-rc1 does this?  It should be
 released mid-week.  Thanks.

Hi Andrew,

you mean 2.6.12-rc1, right?

Regards,
Martin

-- 
MyExcuse:
it has Intel Inside

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgp8rmvuQpJcc.pgp
Description: PGP signature


Re: huge filesystems

2005-03-15 Thread Barry K. Nathan
On Mon, Mar 14, 2005 at 11:41:37AM -0500, Andreas Dilger wrote:
  What about the LBD patches - what limits are involved there, and have
  they been rolled into a Linus kernel, or one or more vendor kernels?
 
 These are part of stock 2.6 kernels.  The caveat here is that there have
 been some problems reported (with ext3 at least) for filesystems  2TB
 so I don't think it has really been tested very much.

FWIW Red Hat appears to officially support 8TB ext3 filesystems on
Red Hat Enterprise Linux 4:

Ext3 scalability: Dynamic file system expansion and file system sizes
up to 8TB are now supported.

http://www.redhat.com/software/rhel/features/

-Barry K. Nathan [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] del_timer_sync scalability patch

2005-03-15 Thread Ingo Molnar

* Christoph Lameter [EMAIL PROTECTED] wrote:

 The following patch removes the magic in the timer_list structure
 (Andrew suggested that we may not need it anymore) and replaces it
 with two u8 variables that give us some additional state of the timer

The 'remove the magic' observation is not a 'backdoor' to introduce new
fields 'for free'. So please dont mix the two things into one patch.

 +   u8 running; /* function is currently executing */
 +   u8 shutdown;/* do not schedule this timer */

it may as well be cleaner to do the timer-base_running thing after all,
and to do this in __run_timers():

timer-base = NULL;
timer-base_running = base;

note that we cannot clear -base_running in __run_timers() [we dont own
any access to the timer anymore, it may be kfree()d, etc.], so
del_timer_sync() has to make sure that the timer-base_running info is
not stale - it is a hint only. But it looks doable, and it should solve
the NUMA scalability problem.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.11-bk10: ATA trouble

2005-03-15 Thread Prakash Punnoor
Hi,

today I got into some major trouble with the disk. nothing worked anymore and
I had to reboot with magic-sysrq. This was found in the log:

Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:20 tachyon ATA: abnormal status 0xD0 on port 0xF0806087
Mar 15 10:27:50 tachyon ata1: command 0x35 timeout, stat 0x50 host_stat 0x61

What does it mean? I rebooted the machine now and everything is fine again. I
never had above problem before.

Here dmesg output and .config:

Linux version 2.6.11-bk10 ([EMAIL PROTECTED]) (gcc-Version 4.0.0-beta20050312
(Gentoo Linux 4.0.0_beta20050312)) #17 Mon Mar 14 21:24:58 CET 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f400 (usable)
 BIOS-e820: 0009f400 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 3fff (usable)
 BIOS-e820: 3fff - 3fff3000 (ACPI NVS)
 BIOS-e820: 3fff3000 - 4000 (ACPI data)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820:  - 0001 (reserved)
1023MB LOWMEM available.
On node 0 totalpages: 262128
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 258032 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia) @ 0x000f6b00
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fff79c0
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010d) @ 0x
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 4000 (gap: 4000:bec0)
Built 1 zonelists
Kernel command line: root=/dev/md1 tsc quiet elevator=cfq hdb=none sdb=none
idle=halt acpi_skip_timer_override psmouse.rate=200 vga=0x51A video=mtrr,ypan
splash=verbose,theme:own
ide_setup: hdb=none
using halt in idle threads.
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2205.234 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1032848k/1048512k available (3254k kernel code, 14992k reserved, 1130k
data, 188k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 4358.14 BogoMIPS (lpj=2179072)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1c3fbff  
  
CPU: After vendor identify, caps: 0383fbff c1c3fbff   
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff  0020 
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm)  stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=0 pin2=-1
checking if image is initramfs... it is
Freeing initrd memory: 359k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: nForce2 C1 Halt Disconnect fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link 

RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Andrey Volkov
Hello, all
I look through code of exist CANbus drivers, and have, may be strange, 
next question:

Anyone could told me, why everyone, who wrote CANbus driver (peak, 
kvaser etc) always use char dev, but not netdev for it? May be exist 
some global pitfall, which I couldn't see, which prevent to use netdev?

--
Regards
Andrey Volkov.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

* Andrew Morton [EMAIL PROTECTED] wrote:

 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  My point is simply:
  
   The help text for an option you need only under very specific 
   circumstances shouldn't sound as if this option was nearly was 
   mandatory.
 
 I think the sort of sell-your-cycles service which this patch enables is a
 neat idea, and one which is worth supporting, especially as the kernel
 patch is so tiny.  So we want as many machines as possible to support it. 
 So people don't need a special kernel just to join in.
 
 Others may disagree, although nobody has.
 
 And the patch is tiny.

see my earlier counter-arguments in the thread starting at:

  http://marc.theaimsgroup.com/?l=linux-kernelm=110630922022462w=2

end result of the thread: seccomp is completely unnecessary code-bloat
and can be equivalently implemented via ptrace. I cannot believe this
made it into -BK ...

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


what is actually syncronized update of filesystem

2005-03-15 Thread Somenath Ghosh
sir,
   i will give a presentation on j.f.s. . i read that at the time of 
asynchronous update the update of transactions are made maintaining an 
ordering, but i read that it is not so simple if the updation is 
synchronous. and i also don't know how the situation is handled.
  i request to inform me about that syncrhonous update so that i can get 
understand what the actual problem is and how the situation is handled.

 somenath

Somenath Ghosh
Chennai Mathematical Institute
14, Sathyapuri street, West Mambalam.
Ph. 044-2474-7328, 
Other E-mail adresses:= [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

we at a minimum need the patch below.

Ingo

Signed-off-by: Ingo Molnar [EMAIL PROTECTED]

--- linux/arch/i386/Kconfig.orig
+++ linux/arch/i386/Kconfig
@@ -909,7 +909,6 @@ config REGPARM
 config SECCOMP
bool Enable seccomp to safely compute untrusted bytecode
depends on PROC_FS
-   default y
help
  This kernel feature is useful for number crunching applications
  that may need to compute untrusted bytecode during their
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Intel Ethernet PRO 100

2005-03-15 Thread shafa.hidee
Hi All,
Where we can find specs for writing driver for Intel PRO 100 card.


Regards
Shafahidee



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: nvidia fb licensing issue.

2005-03-15 Thread Dave Airlie

On Sun, 13 Mar 2005, Jon Smirl wrote:

 All of the files in drivers/char/drm really should have an explicit
 dual MIT/GPL license on them too. The DRM project has been taking
 patches back into DRM from LKML without making it clear that DRM is
 MIT licensed. It might be construed that doing this has made DRM GPL
 without that being the intention.

They all have explicit MIT licenses on them, these files are only
dual-licensed by the fact that they are shipped with the kernel, but they
are MIT licensed and I would consider any changes to them to be MIT
licensed unless someone explicitly states it..

Similiar to the reiser notice on top of those files.. I think MIT license
is explicit enough...

Some files are GPL licensed like drm_sysfs as it is obivously derived from
GPL code,

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


drm lockups since 2.6.11-bk2

2005-03-15 Thread Dave Airlie

Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..

This leads me to think the AGP multi-bridge patches are at fault... (for
once my laziness in merging late instead of early gave a good gap in the
patches...)

I'm offline in sense of I can write this mail and respond but have not
access to a Linux system, my bitkeeper trees, ssh keys for anywhere of
interest.. and am in the wrong country, it'll be the 23rd/24th before I am
back at my desks...

I might get time to do a code review, my main worry is that all the
problems reported with those patches in -mm made it into the patchset that
went into Linus.. mainly things like forgetting to memset certain
structures to 0 and sillies like that...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


x86: spin_unlock(), spin_unlock_irq() others are out of line ?

2005-03-15 Thread Eric Dumazet
Hi all
I noticed that in current linux kernel versions (2.6.11), some basic 
functions are out of line (not inlined)

Example of a call to spin_unlock(somelock)
c01069fa:   b8 e8 7b 35 c0  mov$0xc0357be8,%eax
c01069ff:   e8 3c e4 1f 00  call   c0304e40 _spin_unlock
c0304e40 _spin_unlock:
c0304e40:   c6 00 01movb   $0x1,(%eax)
c0304e43:   c3  ret
Same problem for _write_unlock(), _read_unlock(), _spin_unlock_irq(), ...
That seems odd, and I fail to see the reason for that. (It's OK for 
complex functions, but not for very short ones...)

Is it a regression, or is it needed ?
configuration :
- SMP
- Processor family (Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon)
- No Generic x86 support
Thank you
Eric Dumazet
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Problem with 2.6.11-bk[3456]

2005-03-15 Thread Dave Airlie
 Got a problem here with the last few Linus -bk releases.
 
 2.6.11-bk2 is running fine.
 
 2.6.11-bk3 - 2.6.11-bk6 has the following problem:
 
 Everything is fine while the machine is booting. However as soon as X
 starts up the screen goes blank as normal but stays blank, no gdm login
 screen and the hard disk and floppy drive lights are on continuously.
 The machine is now locked up solid and needs a hard reset.
 
 I tried a serial console but get nothing after the kernel messages and
 the agetty login.
 
 The machine is question is an UP Athlon 1800+ XP with 768MB RAM, the
 graphics card is an AGP ATI Radeon 9200SE using the kernel AGP/DRM
 drivers and the Xorg radeon driver.
 
 It's running FC3.
 
 I've put 2.6.11-bk2 and 2.6.11-bk6 config's, dmesg's and an lspc -vv up
 on the web.
 
 http://digital-domain.net/kernel/2.6.11-bk2.config
 http://digital-domain.net/kernel/2.6.11-bk6.config
 http://digital-domain.net/kernel/2.6.11-bk2.dmesg
 http://digital-domain.net/kernel/2.6.11-bk6.dmesg
 http://digital-domain.net/kernel/lspci-vv
 
 When looking at this the other day I did get a message on the serial
 console after X started and the machine locked, about uhci host
 controller being disabled or something. Unfortunately I didn't make a
 note of it and didn't get it today for when I was preparing this report.
 
 Looking at the two dmesg's there is some difference in the usb messages.
 
 Anyway, thanks for your time and if you need any more info just let me
 know.

This is the same problem as i just mailed everyone about.. more
information here...

Dave.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Jonathan Sambrook
Xen, UML, VM, VMware, separate computers
http://linux-vserver.org/ would also seem to be an excellent match.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Problem with 2.6.11-bk[3456]

2005-03-15 Thread Andrew Clayton
On Tue, 2005-03-15 at 10:50 +, Dave Airlie wrote:
  Got a problem here with the last few Linus -bk releases.
  
  2.6.11-bk2 is running fine.
  
  2.6.11-bk3 - 2.6.11-bk6 has the following problem:
  
  Everything is fine while the machine is booting. However as soon as X
  starts up the screen goes blank as normal but stays blank, no gdm login
  screen and the hard disk and floppy drive lights are on continuously.
  The machine is now locked up solid and needs a hard reset.
  

2.6.11-bk10 is a slight improvement in that the machine isn't completely
dead and I can ctrl+alt+delete it...

 This is the same problem as i just mailed everyone about.. more
 information here...
 
 Dave.
 

Cheers,

Andrew


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/5] I8K driver facelift

2005-03-15 Thread Giuseppe Bilotta
 According to your patch, the C840 has 2 temp sensors. I'll have to figure
 out what the second one is (prob either the GPU or the disk drive?)

If it runs over 40 C easily it's probably the GPU :)

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: swsusp_restore crap

2005-03-15 Thread Pavel Machek
On Út 15-03-05 14:31:56, Benjamin Herrenschmidt wrote:
 On Tue, 2005-03-15 at 14:24 +1100, Benjamin Herrenschmidt wrote:
  Hi Pavel !
  
  Please kill that swsusp_restore() call that itself calls
  flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
  arch specific, and that's all swsusp_restore() does. Then, the asm just
  calls this before returning to C code, so it makes no sense to have a
  hook there. The x86 asm can have it's own call to some arch stuff if it
  wants or just do the tlb flush in asm...
 
 Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
 doesn't exist on ppc, thus breaks compile, and that has nothing to do in
 the generic code imho, it should be clearly defined as the
 responsibility of the asm code).

x86-64 needs this, too Otherwise it looks okay.



 --
 
 This patch removes the quite x86-specific swsusp_restore() hook from the
 generic swsusp code and moves it to arch/i386. This also fixes build on
 ppc with swsusp enabled.
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 
 Index: linux-work/arch/i386/power/swsusp.S
 ===
 --- linux-work.orig/arch/i386/power/swsusp.S  2005-03-15 11:56:17.0 
 +1100
 +++ linux-work/arch/i386/power/swsusp.S   2005-03-15 14:29:09.0 
 +1100
 @@ -58,5 +58,5 @@
   movl saved_context_edi, %edi
  
   pushl saved_context_eflags ; popfl
 - call swsusp_restore
 + call __swsusp_flush_tlb
   ret
 Index: linux-work/arch/i386/power/cpu.c
 ===
 --- linux-work.orig/arch/i386/power/cpu.c 2005-03-15 11:56:17.0 
 +1100
 +++ linux-work/arch/i386/power/cpu.c  2005-03-15 14:28:26.0 +1100
 @@ -147,6 +147,15 @@
   __restore_processor_state(saved_context);
  }
  
 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + BUG_ON (nr_copy_pages_check != nr_copy_pages);
 + 
 + /* Even mappings of global things (vmalloc) need to be fixed */
 + __flush_tlb_global();
 + return 0;
 +}
 +
  /* Needed by apm.c */
  EXPORT_SYMBOL(save_processor_state);
  EXPORT_SYMBOL(restore_processor_state);
 Index: linux-work/kernel/power/swsusp.c
 ===
 --- linux-work.orig/kernel/power/swsusp.c 2005-03-15 12:00:13.0 
 +1100
 +++ linux-work/kernel/power/swsusp.c  2005-03-15 14:29:19.0 +1100
 @@ -907,15 +907,6 @@
  }
  
  
 -asmlinkage int swsusp_restore(void)
 -{
 - BUG_ON (nr_copy_pages_check != nr_copy_pages);
 - 
 - /* Even mappings of global things (vmalloc) need to be fixed */
 - __flush_tlb_global();
 - return 0;
 -}
 -
  int swsusp_resume(void)
  {
   int error;
 

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Benedikt Spranger

 Anyone could told me, why everyone, who wrote CANbus driver (peak, 
 kvaser etc) always use char dev, but not netdev for it? May be exist 
 some global pitfall, which I couldn't see, which prevent to use netdev?

Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff

Bene

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: nvidia fb licensing issue.

2005-03-15 Thread Arjan van de Ven
On Tue, 2005-03-15 at 10:32 +, Dave Airlie wrote:
 On Sun, 13 Mar 2005, Jon Smirl wrote:
 
  All of the files in drivers/char/drm really should have an explicit
  dual MIT/GPL license on them too. The DRM project has been taking
  patches back into DRM from LKML without making it clear that DRM is
  MIT licensed. It might be construed that doing this has made DRM GPL
  without that being the intention.
 
 They all have explicit MIT licenses on them, these files are only
 dual-licensed by the fact that they are shipped with the kernel, but they
 are MIT licensed and I would consider any changes to them to be MIT
 licensed unless someone explicitly states it..

this is actually a bit of a legal iffy point here. People submit patches
to the kernel (which is GPL). In addition, while patches to gpl code are
gpl (by the gpl derived works clause), the MIT license has no such
requirement or even assumption on derived works so it's all quite iffy.
I strongly suggest you put the dual license header in those files to get
rid of the ambiguity..  as you said it's not really a big deal in that
the code already is dual licensed in effect; please consider making it
explicit, it solves a lot of ambiguity.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 see my earlier counter-arguments in the thread starting at:
 
   http://marc.theaimsgroup.com/?l=linux-kernelm=110630922022462w=2
 
 end result of the thread: seccomp is completely unnecessary code-bloat
 and can be equivalently implemented via ptrace. I cannot believe this
 made it into -BK ...

let me moderate my initial reaction somewhat:

the point i see in seccomp is that while it cannot be trusted right now
(not because of any known factor but simply because it doesnt have
enough review, yet), it might at a certain point (in many years) become
more trustable than TRACE_SYSCALLS.

It doesnt use a 'server' process to control syscall execution,
everything is enforced by the kernel. It is also intentionally simple,
and hence maybe even provably secure from a Comp-Sci POV. (assuming
sys_read()/sys_write() and hardware-irq processing itself is secure,
which quite likely wont be provable in the foreseeable future).

Also, while the technological arguments i raised in support of ptrace
are true, ptrace has a perception issue: it is perceived as insecure -
even if PTRACE_TRACE itself is not affected. And when building trust in
a processing platform, perception is just as important as raw security.

this combination of arguments i think tips the balance in favor of
seccomp, but still, i hate the fact that the anti-ptrace sentiment was
used as a vehicle to get this feature into the kernel.

technical comment: seccomp goes outside the audit/selinux framework,
which i believe is a bug. Andrea?

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ACPI] Re: Call for help: list of machines with working S3

2005-03-15 Thread Nigel Cunningham
Hi.

On Tue, 2005-03-15 at 19:10, Li Shaohua wrote:
 Hi,
 On Mon, 2005-03-14 at 16:00, Pavel Machek wrote:
  Hi!
  
 * MySQL (hinders the actual suspension process and kicks the pc
  back to 
   where it was)
  
  Try this patch...
  Pavel
  
  --- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
  +++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
  @@ -,6 +,7 @@
  ret = -EINTR;
  }
   
  +   try_to_freeze(1);
  return ret;
   }
 I also encounter a similar issue. syslogd can't be stopped. It's waiting
 for kjournald to flush some works but kjournald is stopped first. Looks
 like the kernel thread should be stopped later than user thread just
 like Nigel's suspend2 patch does.

Pavel, do you have any kernel/power/process.c changes in? If not, I'll
submit those refrigerator changes.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt


I've realized that my previous patch had too many problems with the way
the journaling system works.  So I went back to my first approach but
added the journal_head lock as one global lock to keep the buffer head
size smaller. I only added the state lock to the buffer head. I've tested
this for some time now, and it works well (for the test at least). I'll
recompile it with PREEMPT_DESKTOP to see if that works too.


-- Steve



diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/buffer.c 
linux-2.6.11-final-V0.7.40-00/fs/buffer.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/buffer.c  2005-03-02 
02:38:10.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/fs/buffer.c   2005-03-15 03:41:15.0 
-0500
@@ -3003,6 +3003,9 @@
preempt_disable();
__get_cpu_var(bh_accounting).nr++;
recalc_bh_state();
+#ifdef CONFIG_PREEMPT_RT
+   spin_lock_init(ret-b_jstate_lock);
+#endif
preempt_enable();
}
return ret;
diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 
linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 2005-03-02 
02:37:49.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c  2005-03-15 
03:49:10.0 -0500
@@ -82,6 +82,8 @@

 static int journal_convert_superblock_v1(journal_t *, journal_superblock_t *);

+spinlock_t journal_head_lock = SPIN_LOCK_UNLOCKED;
+
 /*
  * Helper function used to manage commit timeouts
  */
diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/buffer_head.h 
linux-2.6.11-final-V0.7.40-00/include/linux/buffer_head.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/buffer_head.h  
2005-03-02 02:37:45.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/buffer_head.h   2005-03-15 
03:42:22.0 -0500
@@ -62,6 +62,13 @@
bh_end_io_t *b_end_io;  /* I/O completion */
void *b_private;/* reserved for b_end_io */
struct list_head b_assoc_buffers; /* associated with another mapping */
+
+#ifdef CONFIG_PREEMPT_RT
+   /*
+* Fixme: This should be in the journal code.
+*/
+   spinlock_t b_jstate_lock;   /* lock for journal state. */
+#endif
 };

 /*
diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h 
linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/jbd.h  2005-03-02 
02:38:19.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/jbd.h   2005-03-15 
03:45:33.0 -0500
@@ -314,6 +314,13 @@
 TAS_BUFFER_FNS(RevokeValid, revokevalid)
 BUFFER_FNS(Freed, freed)

+#ifdef CONFIG_PREEMPT_RT
+extern spinlock_t journal_head_lock;
+#define PICK_SPIN_LOCK(otype,bit,name) spin_##otype(bh-b_##name##_lock)
+#else
+#define PICK_SPIN_LOCK(otype,bit,name) bit_spin_##otype(bit,bh-b_state);
+#endif
+
 static inline struct buffer_head *jh2bh(struct journal_head *jh)
 {
return jh-b_bh;
@@ -326,24 +333,36 @@

 static inline void jbd_lock_bh_state(struct buffer_head *bh)
 {
-   bit_spin_lock(BH_State, bh-b_state);
+   PICK_SPIN_LOCK(lock,BH_State,jstate);
 }

 static inline int jbd_trylock_bh_state(struct buffer_head *bh)
 {
-   return bit_spin_trylock(BH_State, bh-b_state);
+   return PICK_SPIN_LOCK(trylock,BH_State,jstate);
 }

 static inline int jbd_is_locked_bh_state(struct buffer_head *bh)
 {
-   return bit_spin_is_locked(BH_State, bh-b_state);
+   return PICK_SPIN_LOCK(is_locked,BH_State,jstate);
 }

 static inline void jbd_unlock_bh_state(struct buffer_head *bh)
 {
-   bit_spin_unlock(BH_State, bh-b_state);
+   PICK_SPIN_LOCK(unlock,BH_State,jstate);
+}
+#undef PICK_SPIN_LOCK
+
+#ifdef CONFIG_PREEMPT_RT
+static inline void jbd_lock_bh_journal_head(struct buffer_head *bh)
+{
+   spin_lock(journal_head_lock);
 }

+static inline void jbd_unlock_bh_journal_head(struct buffer_head *bh)
+{
+   spin_unlock(journal_head_lock);
+}
+#else /* !CONFIG_PREEMPT_RT */
 static inline void jbd_lock_bh_journal_head(struct buffer_head *bh)
 {
bit_spin_lock(BH_JournalHead, bh-b_state);
@@ -353,6 +372,7 @@
 {
bit_spin_unlock(BH_JournalHead, bh-b_state);
 }
+#endif /* CONFIG_PREEMPT_RT */

 struct jbd_revoke_table_s;

diff -ur linux-2.6.11-final-V0.7.40-00.orig/include/linux/spinlock.h 
linux-2.6.11-final-V0.7.40-00/include/linux/spinlock.h
--- linux-2.6.11-final-V0.7.40-00.orig/include/linux/spinlock.h 2005-03-14 
06:00:54.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/include/linux/spinlock.h  2005-03-15 
03:40:31.0 -0500
@@ -774,6 +774,10 @@
 }))


+#ifndef CONFIG_PREEMPT_RT
+
+/* These are just plain evil! */
+
 /*
  *  bit-based spin_lock()
  *
@@ -789,10 +793,15 @@
 * busywait with less bus contention for a good time to
 * attempt to acquire the lock bit.
 */
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) || 
defined(CONFIG_PREEMPT)
-   while 

Re: swsusp_restore crap

2005-03-15 Thread Rafael J. Wysocki
Hi,

On Tuesday, 15 of March 2005 12:03, Pavel Machek wrote:
 On t 15-03-05 14:31:56, Benjamin Herrenschmidt wrote:
  On Tue, 2005-03-15 at 14:24 +1100, Benjamin Herrenschmidt wrote:
   Hi Pavel !
   
   Please kill that swsusp_restore() call that itself calls
   flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
   arch specific, and that's all swsusp_restore() does. Then, the asm just
   calls this before returning to C code, so it makes no sense to have a
   hook there. The x86 asm can have it's own call to some arch stuff if it
   wants or just do the tlb flush in asm...
  
  Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
  doesn't exist on ppc, thus breaks compile, and that has nothing to do in
  the generic code imho, it should be clearly defined as the
  responsibility of the asm code).
 
 x86-64 needs this, too Otherwise it looks okay.

It breaks compilation on i386 either, because nr_copy_pages_check
is static in swsusp.c.  May I propose the following patch instead (tested on
x86-64 and i386)?

Greets,
Rafael

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/cpu.c 
linux-2.6.11-bk10-b/arch/i386/power/cpu.c
--- linux-2.6.11-bk10-a/arch/i386/power/cpu.c   2005-03-15 09:20:53.0 
+0100
+++ linux-2.6.11-bk10-b/arch/i386/power/cpu.c   2005-03-15 12:16:57.0 
+0100
@@ -147,6 +147,15 @@ void restore_processor_state(void)
__restore_processor_state(saved_context);
 }
 
+asmlinkage int __swsusp_flush_tlb(void)
+{
+   swsusp_restore_check();
+
+   /* Even mappings of global things (vmalloc) need to be fixed */
+   __flush_tlb_global();
+   return 0;
+}
+
 /* Needed by apm.c */
 EXPORT_SYMBOL(save_processor_state);
 EXPORT_SYMBOL(restore_processor_state);
diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/swsusp.S 
linux-2.6.11-bk10-b/arch/i386/power/swsusp.S
--- linux-2.6.11-bk10-a/arch/i386/power/swsusp.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/i386/power/swsusp.S2005-03-15 
12:16:28.0 +0100
@@ -58,5 +58,6 @@ done:
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
+   call__swsusp_flush_tlb
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S2005-03-15 
12:14:47.0 +0100
@@ -89,5 +89,6 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
+   call__swsusp_flush_tlb
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend.c 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend.c
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend.c2005-03-02 
08:38:09.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend.c2005-03-15 
12:15:25.0 +0100
@@ -154,4 +154,11 @@ void fix_processor_context(void)
 
 }
 
+int __swsusp_flush_tlb(void)
+{
+   swsusp_restore_check();
 
+   /* Even mappings of global things (vmalloc) need to be fixed */
+   __flush_tlb_global();
+   return 0;
+}
diff -Nrup linux-2.6.11-bk10-a/include/linux/suspend.h 
linux-2.6.11-bk10-b/include/linux/suspend.h
--- linux-2.6.11-bk10-a/include/linux/suspend.h 2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/include/linux/suspend.h 2005-03-15 12:20:06.0 
+0100
@@ -68,6 +68,8 @@ static inline void disable_nonboot_cpus(
 static inline void enable_nonboot_cpus(void) {}
 #endif
 
+void swsusp_restore_check(void);
+
 void save_processor_state(void);
 void restore_processor_state(void);
 struct saved_context;
diff -Nrup linux-2.6.11-bk10-a/kernel/power/swsusp.c 
linux-2.6.11-bk10-b/kernel/power/swsusp.c
--- linux-2.6.11-bk10-a/kernel/power/swsusp.c   2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/kernel/power/swsusp.c   2005-03-15 12:18:36.0 
+0100
@@ -906,14 +906,9 @@ int swsusp_suspend(void)
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
+void swsusp_restore_check(void)
 {
BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of global things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
 }
 
 int swsusp_resume(void)

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: RFC: CANbus subsytem for 2.6 kernel (char or netdev)

2005-03-15 Thread Andrey Volkov
Hi Benedikt,
Yes, thanks, very close to what about I thinking :),
but are you measure overhead of netdev (it disturb me)?
Andrey
Benedikt Spranger wrote:
Anyone could told me, why everyone, who wrote CANbus driver (peak, 
kvaser etc) always use char dev, but not netdev for it? May be exist 
some global pitfall, which I couldn't see, which prevent to use netdev?

Maybe you try out:
http://www.linutronix.de/data/linux-2.6.11-can.diff
Bene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Ingo Molnar

* Steven Rostedt [EMAIL PROTECTED] wrote:

 I've realized that my previous patch had too many problems with the
 way the journaling system works.  So I went back to my first approach
 but added the journal_head lock as one global lock to keep the buffer
 head size smaller. I only added the state lock to the buffer head.
 I've tested this for some time now, and it works well (for the test at
 least). I'll recompile it with PREEMPT_DESKTOP to see if that works
 too.

good progress - but the global lock may be a scalability worry on
upstream though. Would it be possible to just mirror much of the current
lock logic, but with spinlocks instead of bitlocks? And there should be
no #ifdefs on PREEMPT_RT.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: swsusp_restore crap

2005-03-15 Thread Pavel Machek
Hi!

Please kill that swsusp_restore() call that itself calls
flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
arch specific, and that's all swsusp_restore() does. Then, the asm just
calls this before returning to C code, so it makes no sense to have a
hook there. The x86 asm can have it's own call to some arch stuff if it
wants or just do the tlb flush in asm...
   
   Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
   doesn't exist on ppc, thus breaks compile, and that has nothing to do in
   the generic code imho, it should be clearly defined as the
   responsibility of the asm code).
  
  x86-64 needs this, too Otherwise it looks okay.
 
 It breaks compilation on i386 either, because nr_copy_pages_check
 is static in swsusp.c.  May I propose the following patch instead (tested on
 x86-64 and i386)?


 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + swsusp_restore_check();

Someone will certainly forget this one, and it is probably
nicer/easier to just move BUG_ON into swsusp_suspend(), just after
restore_processor_state() or something like that...
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ACPI] Re: Call for help: list of machines with working S3

2005-03-15 Thread Pavel Machek
Hi!


  * MySQL (hinders the actual suspension process and kicks the pc
   back to 
where it was)
   
   Try this patch...
   Pavel
   
   --- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
   +++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
   @@ -,6 +,7 @@
   ret = -EINTR;
   }

   +   try_to_freeze(1);
   return ret;
}
  I also encounter a similar issue. syslogd can't be stopped. It's waiting
  for kjournald to flush some works but kjournald is stopped first. Looks
  like the kernel thread should be stopped later than user thread just
  like Nigel's suspend2 patch does.
 
 Pavel, do you have any kernel/power/process.c changes in? If not, I'll
 submit those refrigerator changes.

No, process.c was left unchanged for quite a long time.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


enabling IOAPIC on C3 processor?

2005-03-15 Thread jerome lacoste
I have a VIA Epia M1 board that crashes very badly (and pretty
often, especially when using DMA). I want to fix that.

Serial console + magic SysRQ didn't help so I am going the nmi
watchdog way. But in order to have nmi watchdog I need APIC, right?

The C3 processor seems to support IOAPIC.
(http://www.via.com.tw/en/products/processors/c3/specs.jsp)

But:
- I don't see anything in the BIOS related to APIC. 
- grep APIC /lib/modules/`uname -r`/build/.config shows me that all
APIC options are 'y'.
- dmesg | grep APIC tells me no local APIC present or hardware disabled.
- adding lapic kernel parameter doesn't change that. 
- and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in /proc/interrupts.

Did I miss something when it comes to enabling IOAPIC support on C3 processor?

Note: I also see a lot an increasing ERR count in /proc/interrupts,
especially when I put my box in conditions that make it also more
unstable (i.e. sending files on the network while using the PVR-350
using mythtv). Not sure if it is related.

Jerome

[EMAIL PROTECTED]:~$ dmesg | grep APIC
No local APIC present or hardware disabled
mapped APIC to d000 (013c1000)

[EMAIL PROTECTED]:~$ grep APIC /lib/modules/`uname -r`/build/.config 
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

Grub options
[...]
kernel  /vmlinuz-2.6.11-medios1 root=/dev/hda1 ro 
console=ttyS0,57600n8 console=tty0 nmi_watchdog=1 lapic
[...]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] kill drivers/cdrom/mcd.c

2005-03-15 Thread Adrian Bunk
As described in my patch that marked this obsolete driver as BROKEN,
this patch completely removes it.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 Documentation/cdrom/mcd  |4 
 Documentation/cdrom/mcdx |   17 
 drivers/cdrom/Kconfig|   56 -
 drivers/cdrom/Makefile   |1 
 drivers/cdrom/mcd.c  | 1565 ---
 drivers/cdrom/mcd.h  |  106 --
 6 files changed, 6 insertions(+), 1743 deletions(-)

--- linux-2.6.11-mm3-full/drivers/cdrom/Kconfig.old 2005-03-15 
04:14:03.0 +0100
+++ linux-2.6.11-mm3-full/drivers/cdrom/Kconfig 2005-03-15 04:20:07.0 
+0100
@@ -103,60 +103,14 @@
  To compile this driver as a module, choose M here: the
  module will be called sbpcd.
 
-config MCD
-   tristate Mitsumi (standard) [no XA/Multisession] CDROM support
-   depends on CD_NO_IDESCSI  BROKEN
-   ---help---
- This is the older of the two drivers for the older Mitsumi models
- LU-005, FX-001 and FX-001D. This is not the right driver for the
- FX-001DE and the triple or quad speed models (all these are
- IDE/ATAPI models). Please also the file
- file:Documentation/cdrom/mcd.
-
- With the old LU-005 model, the whole drive chassis slides out for cd
- insertion. The FX-xxx models use a motorized tray type mechanism.
- Note that this driver does not support XA or MultiSession CDs
- (PhotoCDs). There is a new driver (next question) which can do
- this. If you want that one, say N here.
-
- If you say Y here, you should also say Y or M to ISO 9660 CD-ROM
- file system support below, because that's the file system used on
- CD-ROMs.
-
- To compile this driver as a module, choose M here: the
- module will be called mcd.
-
-config MCD_IRQ
-   int MCD IRQ
-   depends on MCD
-   default 11
-   help
- This allows you to specify the default value of the IRQ used by the
- driver. This setting can be overridden by passing the mcd=
- parameter to the kernel at boot time (or at module load time if you
- said M to Standard Mitsumi CD-ROM support).
-
-config MCD_BASE
-   hex MCD I/O base
-   depends on MCD
-   default 300
-   help
- This allows you to specify the default value of the I/O base address
- used by the driver. This setting can be overridden by passing the
- mcd= parameter to the kernel at boot time (or at module load time
- if you said M to Standard Mitsumi CD-ROM support).
-
 config MCDX
-   tristate Mitsumi [XA/MultiSession] CDROM support
+   tristate Mitsumi CDROM support
depends on CD_NO_IDESCSI
---help---
- Use this driver if you want to be able to read XA or MultiSession
- CDs (PhotoCDs) as well as ordinary CDs with your Mitsumi LU-005,
- FX-001 or FX-001D CD-ROM drive. In addition, this driver uses much
- less kernel memory than the old one, if that is a concern. This
- driver is able to support more than one drive, but each drive needs
- a separate interface card. Please read the file
- file:Documentation/cdrom/mcdx.
+ Use this driver if you want to be able to use your Mitsumi LU-005,
+ FX-001 or FX-001D CD-ROM drive.
+
+ Please read the file file:Documentation/cdrom/mcdx.
 
  If you say Y here, you should also say Y or M to ISO 9660 CD-ROM
  file system support below, because that's the file system used on
--- linux-2.6.11-mm3-full/drivers/cdrom/Makefile.old2005-03-15 
04:14:34.0 +0100
+++ linux-2.6.11-mm3-full/drivers/cdrom/Makefile2005-03-15 
04:14:43.0 +0100
@@ -15,7 +15,6 @@
 obj-$(CONFIG_CM206)+= cm206.o  cdrom.o
 obj-$(CONFIG_GSCD) += gscd.o
 obj-$(CONFIG_ISP16_CDI)+= isp16.o
-obj-$(CONFIG_MCD)  += mcd.ocdrom.o
 obj-$(CONFIG_MCDX) += mcdx.o   cdrom.o
 obj-$(CONFIG_OPTCD)+= optcd.o
 obj-$(CONFIG_SBPCD)+= sbpcd.o  cdrom.o
--- linux-2.6.11-mm3-full/Documentation/cdrom/mcdx.old  2005-03-15 
04:21:07.0 +0100
+++ linux-2.6.11-mm3-full/Documentation/cdrom/mcdx  2005-03-15 
04:21:40.0 +0100
@@ -1,16 +1,3 @@
-This is a first attempt to create an `improved' driver for the Mitsumi drives.
-It is able to live together with mcd.c, if you have at least two Mitsumi
-drives: each driver can use its own drive.
-
-To allow this coexistence as long as mcdx.c is not a superset of mcd.c,
-this driver has to use its own device files. We use MAJOR 20 for it. So,
-you have to do
-
- # mknod /dev/mcdx0 b 20 0
- # mknod /dev/mcdx1 b 20 1
-
-and so on, one entry for each drive to support, once.
-
 If you are using the driver as a module, you can specify your ports and IRQs
 like
 
@@ -25,9 +12,7 @@
 ordinary CDs;
 o   supports up to 5 drives (of 

[2.6 patch] fix bridge - ATM compile error

2005-03-15 Thread Adrian Bunk
This patch fixes the following compile error with CONFIG_BRIDGE=y and 
CONFIG_ATM_LANE=m:

--  snip  --

...
  LD  .tmp_vmlinux1
net/built-in.o(.init.text+0x3ad1): In function `br_init':
: undefined reference to `br_fdb_get_hook'
net/built-in.o(.init.text+0x3adb): In function `br_init':
: undefined reference to `br_fdb_put_hook'
net/built-in.o(.exit.text+0xa2): In function `br_deinit':
: undefined reference to `br_fdb_get_hook'
net/built-in.o(.exit.text+0xac): In function `br_deinit':
: undefined reference to `br_fdb_put_hook'
make: *** [.tmp_vmlinux1] Error 1

--  snip  --

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 net/bridge/br.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.11-mm3-modular/net/bridge/br.c.old2005-03-15 
03:23:10.0 +0100
+++ linux-2.6.11-mm3-modular/net/bridge/br.c2005-03-15 03:24:05.0 
+0100
@@ -22,7 +22,7 @@
 
 #include br_private.h
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
 #include ../atm/lec.h
 #endif
 
@@ -39,7 +39,7 @@
brioctl_set(br_ioctl_deviceless_stub);
br_handle_frame_hook = br_handle_frame;
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
br_fdb_get_hook = br_fdb_get;
br_fdb_put_hook = br_fdb_put;
 #endif
@@ -60,7 +60,7 @@
 
synchronize_net();
 
-#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE)
+#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE)  
defined(MODULE))
br_fdb_get_hook = NULL;
br_fdb_put_hook = NULL;
 #endif

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Helge Hafting
2.6.11-mm1 and earlier: mouse appear as /dev/input/mouse0
2.6.11-mm3: mouse appear as /dev/input/mouse1
No big problem, one change to xorg.conf and I got the mouse back.
I guess it wasn't supposed to change like that though?
This is a mouse connected to the ps2 port, also appearing as /dev/psaux
Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] net/802/fc.c: remove fc_type_trans

2005-03-15 Thread Adrian Bunk
On Mon, Mar 14, 2005 at 09:49:40PM -0800, David S. Miller wrote:
 On Sun, 6 Mar 2005 21:57:54 +0100
 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in 
  2.6 and removed in -mm.
  
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 That driver isn't in Linus's tree any longer either.  Just delete
 the thing altogether instead of #if 0'ing it.
...

Updated patch:


--  snip  --


The only user of fc_type_trans (drivers/net/fc/iph5526.c) is removed in 
Linus' tree.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

 include/linux/fcdevice.h |2 --
 net/802/fc.c |   34 --
 2 files changed, 36 deletions(-)

--- linux-2.6.11-mm1-full/include/linux/fcdevice.h.old  2005-03-06 
21:40:36.0 +0100
+++ linux-2.6.11-mm1-full/include/linux/fcdevice.h  2005-03-06 
21:41:07.0 +0100
@@ -24,12 +24,10 @@
 #define _LINUX_FCDEVICE_H
 
 
 #include linux/if_fc.h
 
 #ifdef __KERNEL__
-extern unsigned short  fc_type_trans(struct sk_buff *skb, struct net_device 
*dev); 
-
 extern struct net_device *alloc_fcdev(int sizeof_priv);
 #endif
 
 #endif /* _LINUX_FCDEVICE_H */
--- linux-2.6.11-mm3-full/net/802/fc.c.old  2005-03-15 13:02:13.0 
+0100
+++ linux-2.6.11-mm3-full/net/802/fc.c  2005-03-15 13:02:34.0 +0100
@@ -97,40 +97,6 @@
 #endif
 }
 
-unsigned short
-fc_type_trans(struct sk_buff *skb, struct net_device *dev)
-{
-   struct fch_hdr *fch = (struct fch_hdr *)skb-data;
-   struct fcllc *fcllc;
-
-   skb-mac.raw = skb-data;
-   fcllc = (struct fcllc *)(skb-data + sizeof (struct fch_hdr) + 2);
-   skb_pull(skb, sizeof (struct fch_hdr) + 2);
-
-   if (*fch-daddr  1) {
-   if (!memcmp(fch-daddr, dev-broadcast, FC_ALEN))
-   skb-pkt_type = PACKET_BROADCAST;
-   else
-   skb-pkt_type = PACKET_MULTICAST;
-   } else if (dev-flags  IFF_PROMISC) {
-   if (memcmp(fch-daddr, dev-dev_addr, FC_ALEN))
-   skb-pkt_type = PACKET_OTHERHOST;
-   }
-
-   /*
-* Strip the SNAP header from ARP packets since we don't pass
-* them through to the 802.2/SNAP layers.
-*/
-   if (fcllc-dsap == EXTENDED_SAP 
-   (fcllc-ethertype == ntohs(ETH_P_IP) ||
-fcllc-ethertype == ntohs(ETH_P_ARP))) {
-   skb_pull(skb, sizeof (struct fcllc));
-   return fcllc-ethertype;
-   }
-
-   return ntohs(ETH_P_802_2);
-}
-
 static void fc_setup(struct net_device *dev)
 {
dev-hard_header= fc_header;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.11-mm3: BUG: atomic counter underflow at: rpcauth_destroy

2005-03-15 Thread Martin Zwickel
Hi there!

I got some atomic counter underflows in the nfs code:

Mar 14 17:19:15 phoebee rpc.statd[6890]: Received erroneous SM_UNMON request
 from phoebee for 192.168.0.1
Mar 14 17:19:15 phoebee BUG: atomic counter underflow at:
Mar 14 17:19:15 phoebee [c03b51d1] rpcauth_destroy+0x41/0x50
Mar 14 17:19:15 phoebee [c03afcac] rpc_destroy_client+0x9c/0xf0
Mar 14 17:19:15 phoebee [c03b4698] rpc_free+0x18/0x40
Mar 14 17:19:15 phoebee [c03b49ad] rpc_release_task+0xad/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c03b1580] xprt_init_autodisconnect+0x0/0xd0
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03af9e7] rpc_create_client+0x167/0x240
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03afefa] rpc_call_sync+0x5a/0xa0
Mar 14 17:19:15 phoebee [c0203874] nsm_mon_unmon+0xb4/0xe0
Mar 14 17:19:15 phoebee [c0203936] nsm_unmonitor+0x26/0x70
Mar 14 17:19:15 phoebee [c02007e8] nlm_gc_hosts+0x168/0x190
Mar 14 17:19:15 phoebee [c0200056] nlm_lookup_host+0x46/0x270
Mar 14 17:19:15 phoebee [c01fffd1] nlmclnt_lookup_host+0x11/0x20
Mar 14 17:19:15 phoebee [c01ff1da] nlmclnt_proc+0x4a/0x310
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c034955e] kernel_sendmsg+0x2e/0x40
Mar 14 17:19:15 phoebee [c03bb029] xdr_sendpages+0xc9/0x270
Mar 14 17:19:15 phoebee [c013a11c] mempool_free+0x4c/0xa0
Mar 14 17:19:15 phoebee [c03afd4b] rpc_release_client+0x4b/0x90
Mar 14 17:19:15 phoebee [c03b49a6] rpc_release_task+0xa6/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03aff05] rpc_call_sync+0x65/0xa0
Mar 14 17:19:15 phoebee [c01cbe93] nfs3_rpc_wrapper+0x63/0x70
Mar 14 17:19:15 phoebee [c01cc113] nfs3_proc_setattr+0x93/0xd0
Mar 14 17:19:15 phoebee [c01ca38c] nfs_scan_commit+0x2c/0x70
Mar 14 17:19:15 phoebee [c01c3500] nfs_setattr+0xd0/0x1c0
Mar 14 17:19:15 phoebee [c013642c] __filemap_fdatawrite_range+0xbc/0xc0
Mar 14 17:19:15 phoebee [c01ca38c] nfs_scan_commit+0x2c/0x70
Mar 14 17:19:15 phoebee [c01cbc6f] nfs_commit_inode+0x3f/0xc0
Mar 14 17:19:15 phoebee [c01cbd44] nfs_sync_inode+0x54/0x70
Mar 14 17:19:15 phoebee [c01c1e37] do_setlk+0x77/0x170
Mar 14 17:19:15 phoebee [c01c1f30] nfs_lock+0x0/0x130
Mar 14 17:19:15 phoebee [c016947b] fcntl_setlk64+0x25b/0x2b0
Mar 14 17:19:15 phoebee [c0169e4e] dput+0x1e/0x250
Mar 14 17:19:15 phoebee [c0160790] path_release+0x10/0x60
Mar 14 17:19:15 phoebee [c01528a9] sys_chown+0x49/0x50
Mar 14 17:19:15 phoebee [c0164e74] sys_fcntl64+0x44/0x90
Mar 14 17:19:15 phoebee [c0103071] syscall_call+0x7/0xb
Mar 14 17:19:15 phoebee BUG: atomic counter underflow at:
Mar 14 17:19:15 phoebee [c03b51d1] rpcauth_destroy+0x41/0x50
Mar 14 17:19:15 phoebee [c03afcac] rpc_destroy_client+0x9c/0xf0
Mar 14 17:19:15 phoebee [c03b4698] rpc_free+0x18/0x40
Mar 14 17:19:15 phoebee [c03b49ad] rpc_release_task+0xad/0x120
Mar 14 17:19:15 phoebee [c03b4563] __rpc_execute+0x2e3/0x360
Mar 14 17:19:15 phoebee [c03b1580] xprt_init_autodisconnect+0x0/0xd0
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03af9e7] rpc_create_client+0x167/0x240
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c03afefa] rpc_call_sync+0x5a/0xa0
Mar 14 17:19:15 phoebee [c0203874] nsm_mon_unmon+0xb4/0xe0
Mar 14 17:19:15 phoebee [c028118f] extract_entropy+0x4f/0xa0
Mar 14 17:19:15 phoebee [c02038c6] nsm_monitor+0x26/0x70
Mar 14 17:19:15 phoebee [c01ffa9b] nlmclnt_lock+0x2b/0xd0
Mar 14 17:19:15 phoebee [c01ff397] nlmclnt_proc+0x207/0x310
Mar 14 17:19:15 phoebee [c012c9e0] autoremove_wake_function+0x0/0x50
Mar 14 17:19:15 phoebee [c01c1e37] do_setlk+0x77/0x170
Mar 14 17:19:15 phoebee [c01c1f30] nfs_lock+0x0/0x130
Mar 14 17:19:15 phoebee [c016947b] fcntl_setlk64+0x25b/0x2b0
Mar 14 17:19:15 phoebee [c0169e4e] dput+0x1e/0x250
Mar 14 17:19:15 phoebee [c0160790] path_release+0x10/0x60
Mar 14 17:19:15 phoebee [c01528a9] sys_chown+0x49/0x50
Mar 14 17:19:15 phoebee [c0164e74] sys_fcntl64+0x44/0x90
Mar 14 17:19:15 phoebee [c0103071] syscall_call+0x7/0xb


Regardless of the erroneous SM_UNMON request, the atomic counter
should not underflow ;)


Regards,
Martin

-- 
MyExcuse:
The kernel license has expired

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgpjIB6KQ4Gc8.pgp
Description: PGP signature


Re: enabling IOAPIC on C3 processor?

2005-03-15 Thread Mikael Pettersson
jerome lacoste writes:
  I have a VIA Epia M1 board that crashes very badly (and pretty
  often, especially when using DMA). I want to fix that.
  
  Serial console + magic SysRQ didn't help so I am going the nmi
  watchdog way. But in order to have nmi watchdog I need APIC, right?
  
  The C3 processor seems to support IOAPIC.
  (http://www.via.com.tw/en/products/processors/c3/specs.jsp)
  
  But:
  - I don't see anything in the BIOS related to APIC. 
  - grep APIC /lib/modules/`uname -r`/build/.config shows me that all
  APIC options are 'y'.
  - dmesg | grep APIC tells me no local APIC present or hardware disabled.
  - adding lapic kernel parameter doesn't change that. 
  - and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in 
  /proc/interrupts.
  
  Did I miss something when it comes to enabling IOAPIC support on C3 
  processor?

Unless you have a pre-release engineering part for a future product,
then your C3 has no local APIC, and hence no I/O APIC functionality.

I know some C3 specs pages list I/O APIC support, but if you look in
the datasheets for current products you find zero APIC support.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

2005-03-15 Thread jerome lacoste
On Tue, 15 Mar 2005 13:34:55 +0100, Mikael Pettersson [EMAIL PROTECTED] wrote:
 jerome lacoste writes:
   I have a VIA Epia M1 board that crashes very badly (and pretty
   often, especially when using DMA). I want to fix that.
  
   Serial console + magic SysRQ didn't help so I am going the nmi
   watchdog way. But in order to have nmi watchdog I need APIC, right?
  
   The C3 processor seems to support IOAPIC.
   (http://www.via.com.tw/en/products/processors/c3/specs.jsp)
  
   But:
   - I don't see anything in the BIOS related to APIC.
   - grep APIC /lib/modules/`uname -r`/build/.config shows me that all
   APIC options are 'y'.
   - dmesg | grep APIC tells me no local APIC present or hardware disabled.
   - adding lapic kernel parameter doesn't change that.
   - and of course, nmi_watchdog=1 or 2 gives me NMI count 0 in 
 /proc/interrupts.
  
   Did I miss something when it comes to enabling IOAPIC support on C3 
 processor?
 
 Unless you have a pre-release engineering part for a future product,
 then your C3 has no local APIC, and hence no I/O APIC functionality.
 
 I know some C3 specs pages list I/O APIC support, but if you look in
 the datasheets for current products you find zero APIC support.

My board is 2 years old (May 2003).

I've checked the specs [2] and they say (page 17 out of 83)
APIC will be available in future steppings.  Yeah right...

Mine is stepping 1 according to /proc/cpuinfo.

So if I don't have APIC, that means I cannot use nmi_watchdog to
investigate the problem, right?

Do I have any alternative to investigate this hang or should I just
give up and smash my board?

Cheers,

Jerome

[2] http://www.via.com.tw/en/downloads/datasheets/processors/c3_nehemiah.zip
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch trivial] as-iosched fix path to Documentation

2005-03-15 Thread maximilian attems
On Tue, 15 Mar 2005, Adrian Bunk wrote:

 On Thu, Mar 10, 2005 at 12:42:23AM +0100, maximilian attems wrote:
 
  From: Klaus Ita [EMAIL PROTECTED]
  
  subject says all, patch still applies.
 ...
 
 Fix is already in -mm for some time.
 
 cu
 Adrian

yup saw it lately. great.
thanks for your mail.

--
maks

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

2005-03-15 Thread Mikael Pettersson
jerome lacoste writes:
  So if I don't have APIC, that means I cannot use nmi_watchdog to
  investigate the problem, right?

Correct.

  Do I have any alternative to investigate this hang or should I just
  give up and smash my board?

I can't help you with that one.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Andrea Arcangeli
On Tue, Mar 15, 2005 at 12:27:12PM +0100, Ingo Molnar wrote:
 this combination of arguments i think tips the balance in favor of
 seccomp, but still, i hate the fact that the anti-ptrace sentiment was
 used as a vehicle to get this feature into the kernel.

Why should I use excuses to get this feature into the kernel if this
wasn't the best way to reach my goal? Do you think I'm shooting myself
in the foot and that I'd be better off using ptrace?

One other reason of using seccomp that you didn't mention is how simple
it is for me to code everything using seccomp (and this also makes me
much more confortable about its security, regardless of ptrace). Seccomp
is an arch indipendent API, ptrace is not.

It's not just the security of ptrace that is less desiderable, but it's
also the API itself that is much less desiderable, since it's so
lowlevel.

 which quite likely wont be provable in the foreseeable future).

Please mention a _single_ bug that could allow you to escape the seccomp
jail in linux since 2.4.0 on x86 and x86-64 (and with escape I don't
mean sniffing data with mmx not being backwards compatible, or f00f DoS,
I mean executing code into the host as user nobody). I'm not aware of a
_single_ seccomp bug that could allow you to escape the seccomp jail
since 2.4.0 and probably much earlier.

Either you answer the above or you may want to stop spreading FUD about
seccomp (and in turn about Cpushare security).

You know that a seccomp security bug is guaranteed to be a _major_
security bug for linux at large, not just for Cpushare, so I don't see
why you claim it's not provable to be secure, since what you're really
saying is that it's not provable that Linux is secure in multiuser
environment.

Personally I'm very confortable that linux security is ok in
read/write/signal/exit syscalls/irqs. At least as far as the software is
concerned.

It's not like there was no auditing, since those code paths are the most
heavily executed and if people go search into mremap is not because they
wouldn't get any benefit in exploiting read(2) or write(2) instead of
mremap. They look into mremap because they didn't find anything
expoitable in read/write.

There have been positive comments from people about seccomp not just for
my private project, so perhaps it will be used by others too.

In large grid environments security is important too, not just for
Cpushare. In a large grid environment if one of those nodes is
compromised by one user during his computations, this user may see and
alter the results for the other computations of the other users and at
least Cpushare is designed to detect and react to those conditions since
the first place.

Infact once I add trusted computing to Cpushare, it might become more
secure and reliable than a supercomputer for rent that is missing the
trusted computing in the hardware.

 technical comment: seccomp goes outside the audit/selinux framework,
 which i believe is a bug. Andrea?

I intentionally left it out of audit/selinux. To the less dependencies
it has on other parts of the kernel and the simpler it is, the better
IMHO. Seccomp should be fixed in stone, people shouldn't go hack on it
every day.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt


On Tue, 15 Mar 2005, Ingo Molnar wrote:


 * Steven Rostedt [EMAIL PROTECTED] wrote:

  I've realized that my previous patch had too many problems with the
  way the journaling system works.  So I went back to my first approach
  but added the journal_head lock as one global lock to keep the buffer
  head size smaller. I only added the state lock to the buffer head.
  I've tested this for some time now, and it works well (for the test at
  least). I'll recompile it with PREEMPT_DESKTOP to see if that works
  too.

 good progress - but the global lock may be a scalability worry on
 upstream though. Would it be possible to just mirror much of the current
 lock logic, but with spinlocks instead of bitlocks? And there should be
 no #ifdefs on PREEMPT_RT.


The first patch I had just converted the bit spinlocks to spinlocks but I
thought that adding two spinlocks was too much for every buffer head, even
if it wasn't in the ext3 file system. The journal head spinlock is just
used to add and remove the journal heads from the buffer heads, so I'm not
sure how much contention is on them. I only have a dual smp system, so I
can't test the system on large number of CPUs. What do you think, should
we sacrafice memory for speed?

What should we use instead of #ifdef PREEMPT_RT? Or should we just keep it
the same for both.  Since this fix is only to fix spinlocks that schedule,
I figured that it would be better not to waste the memory of those not
using PREEMPT_RT.  Should I use the opposite PREEMPT_DESKTOP?

Thanks,

-- Steve

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Repeatable IDE Oops for 2.6.11 (ide-scsi vs ide-cdrom)

2005-03-15 Thread Alan Cox
On Maw, 2005-03-15 at 08:19, Bartlomiej Zolnierkiewicz wrote:
 On Mon, 14 Mar 2005, Alan Cox wrote:
 Locking is fixed in ide-dev-2.6 tree
 (at the moment seem to be dropped from -mm?).

Excellent - I'm looking forward to dropping the -ac IDE locking patches 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-03-15 Thread Kenan Esau
Here is a new version of the patch:
- minimal changes
- reintroduced DMI-probing

I had a look at the synaptic-sources to see how the pass-through-mode is
implemented. We'll see if something similar to this also works with the
lifebook.

I received a request from a user who has a Panasonic CF-29. It also
seems to have the same Touchscreen hardware like the lifebook. But it
doesn't seem to work as expected. Can someone get hold of a CF-29 and
test the psmouse-patch with it?
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.c linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c
--- linux-2.6.11.3/drivers/input/mouse/lifebook.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.c	2005-03-15 10:04:34.0 +0100
@@ -0,0 +1,126 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik [EMAIL PROTECTED]
+ * Copyright (c) 2005 Kenan Esau [EMAIL PROTECTED]
+ *
+ * TouchScreen detection, absolute mode setting and packet layout is taken from
+ * Harald Hoyer's description of the device.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/input.h
+#include linux/serio.h
+#include linux/libps2.h
+#include linux/dmi.h
+
+#include psmouse.h
+#include lifebook.h
+
+static int max_y = 1024;
+
+
+static struct dmi_system_id lifebook_dmi_table[] = {
+   {
+   .ident = Fujitsu Siemens Lifebook B-Sereis,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, LIFEBOOK B Series),
+   },
+   },
+   { }
+};
+
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
+{
+	unsigned char *packet = psmouse-packet;
+	struct input_dev *dev = psmouse-dev;
+
+	if ( psmouse-pktcnt != 3 )
+		return PSMOUSE_GOOD_DATA;
+
+	input_regs(dev, regs);
+
+	/* calculate X and Y */
+	if ((packet[0]  0x08) == 0x00) {
+		input_report_abs(dev, ABS_X,
+ (packet[1] | ((packet[0]  0x30)  4)));
+		input_report_abs(dev, ABS_Y,
+ max_y - (packet[2] | ((packet[0]  0xC0)  2)));
+	} else {
+		input_report_rel(dev, REL_X, 
+((packet[0]  0x10) ? packet[1]-256 : packet[1]));
+		input_report_rel(dev, REL_Y, 
+(- (int)((packet[0]  0x20) ? packet[2]-256 : packet[2])));
+	}
+
+	input_report_key(dev, BTN_LEFT, packet[0]  0x01);
+	input_report_key(dev, BTN_RIGHT, packet[0]  0x02);
+	input_report_key(dev, BTN_TOUCH, packet[0]  0x04);
+
+	input_sync(dev);
+
+	return PSMOUSE_FULL_PACKET;
+}
+
+static int lifebook_initialize(struct psmouse *psmouse)
+{
+	struct ps2dev *ps2dev = psmouse-ps2dev;
+	unsigned char param;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_DISABLE))
+		return -1;
+
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_BAT))
+		return -1;
+
+	/* 
+	   Enable absolute output -- ps2_command fails always but if
+	   you leave this call out the touchsreen will never send
+	   absolute coordinates
+	*/ 
+	param = 0x07;
+	ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
+
+	psmouse-set_rate(psmouse, psmouse-rate);
+	psmouse-set_resolution(psmouse, psmouse-resolution);
+	
+	if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE))
+		return -1;
+
+	return 0;
+}
+
+static void lifebook_disconnect(struct psmouse *psmouse)
+{
+	psmouse_reset(psmouse);
+}
+
+int lifebook_detect(struct psmouse *psmouse, unsigned int max_proto, 
+int set_properties)
+{
+if (!dmi_check_system(lifebook_dmi_table)  
+(max_proto != PSMOUSE_LIFEBOOK) )
+return -1;
+
+	if (set_properties) {
+		psmouse-vendor = Fujitsu Lifebook;
+		psmouse-name = TouchScreen;
+		psmouse-dev.evbit[0] = BIT(EV_ABS) | BIT(EV_KEY) | BIT(EV_REL);
+		psmouse-dev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT) | BIT(BTN_MIDDLE) | BIT(BTN_RIGHT);
+		psmouse-dev.keybit[LONG(BTN_TOUCH)] = BIT(BTN_TOUCH);
+		psmouse-dev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
+		input_set_abs_params(psmouse-dev, ABS_X, 0, 1024, 0, 0);
+		input_set_abs_params(psmouse-dev, ABS_Y, 0, 1024, 0, 0);
+
+		psmouse-protocol_handler = lifebook_process_byte;
+		psmouse-disconnect = lifebook_disconnect;
+		psmouse-reconnect  = lifebook_initialize;
+		psmouse-pktsize = 3;
+	}
+
+return lifebook_initialize(psmouse);
+}
diff -X dontdiff -Naur linux-2.6.11.3/drivers/input/mouse/lifebook.h linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h
--- linux-2.6.11.3/drivers/input/mouse/lifebook.h	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11.3-kenan/drivers/input/mouse/lifebook.h	2005-03-14 10:01:57.0 +0100
@@ -0,0 +1,17 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.

Re: swsusp_restore crap

2005-03-15 Thread Benjamin Herrenschmidt

 It breaks compilation on i386 either, because nr_copy_pages_check
 is static in swsusp.c.  May I propose the following patch instead (tested on
 x86-64 and i386)?
 
 Greets,
 Rafael
 
 Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
 
 diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/cpu.c 
 linux-2.6.11-bk10-b/arch/i386/power/cpu.c
 --- linux-2.6.11-bk10-a/arch/i386/power/cpu.c 2005-03-15 09:20:53.0 
 +0100
 +++ linux-2.6.11-bk10-b/arch/i386/power/cpu.c 2005-03-15 12:16:57.0 
 +0100
 @@ -147,6 +147,15 @@ void restore_processor_state(void)
   __restore_processor_state(saved_context);
  }
  
 +asmlinkage int __swsusp_flush_tlb(void)
 +{
 + swsusp_restore_check();
 +

Do we really need that check there ? Can't it be moved elsewhere ?

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: bad pgd/pmd in latest BK on ia64

2005-03-15 Thread Martin Hicks

On Mon, Mar 14, 2005 at 02:34:42PM -0800, David S. Miller wrote:
 On Mon, 14 Mar 2005 14:06:09 -0800
 Luck, Tony [EMAIL PROTECTED] wrote:
 
  Trying to boot a build of the latest BK on ia64 I see
  a series of messages like this:
  
  mm/memory.c:99: bad pgd e001feba4000.
  mm/memory.c:99: bad pgd e001febac000.
  mm/memory.c:99: bad pgd e001febc0d10.
 
 Things are similarly busted on sparc64 for me as well.
 Things instantly reboot right after the kernel tries
 to open an initial console.

It's also busted on ia64 in 2.6.11-mm3 if that narrows thing down.

mh

-- 
Martin Hicks   ||   Silicon Graphics Inc.   ||   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: swsusp_restore crap

2005-03-15 Thread Benjamin Herrenschmidt

 
  +asmlinkage int __swsusp_flush_tlb(void)
  +{
  +   swsusp_restore_check();
 
 Someone will certainly forget this one, and it is probably
 nicer/easier to just move BUG_ON into swsusp_suspend(), just after
 restore_processor_state() or something like that...

Agreed.

Ben.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)

2005-03-15 Thread Alan Cox
On Maw, 2005-03-15 at 04:32, Lee Revell wrote:
 This seems sufficient for the simplest devices, that just have an
 IRQ_PENDING and an IRQ_ACK register.  But what about a device like the
 emu10k1 where you have a half loop and loop interrupt for each of 64
 channels, plus about 10 other interrupt sources?  The IPR just tells you
 there's a channel loop interrupt pending, in order to properly ACK it
 you need to set a bit in one of 4 registers depending on whether it's a
 loop or half loop interrupt, and whether the channel is 0-31 or 32-64.

Do we need to solve it for all such devices in one go and can we write
custom code for the hard cases. Peter solved the simple unshared-IRQ
case. I'd like to solve the simple shared IRQ cases too (because X can
use this).

I'm wondering where the right line is ?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Ingo Molnar

* Steven Rostedt [EMAIL PROTECTED] wrote:

  good progress - but the global lock may be a scalability worry on
  upstream though. Would it be possible to just mirror much of the current
  lock logic, but with spinlocks instead of bitlocks? And there should be
  no #ifdefs on PREEMPT_RT.
 
 The first patch I had just converted the bit spinlocks to spinlocks
 but I thought that adding two spinlocks was too much for every buffer
 head, even if it wasn't in the ext3 file system. The journal head
 spinlock is just used to add and remove the journal heads from the
 buffer heads, so I'm not sure how much contention is on them. I only
 have a dual smp system, so I can't test the system on large number of
 CPUs. What do you think, should we sacrafice memory for speed?

there are two bad effects of global spinlocks: 1) contention 2)
cacheline bouncing. It's #2 that would affect this spinlock. While i'm
not sure this would show up in usual benchmarks, we should rather err on
the side of more scalability. Two spinlocks are just two more machine
words on most architectures, so i dont think it matters all that much,
while it removes a major wart - as long as the two extra locks are for
ext3 buffer-heads only.

 What should we use instead of #ifdef PREEMPT_RT? Or should we just
 keep it the same for both.  Since this fix is only to fix spinlocks
 that schedule, I figured that it would be better not to waste the
 memory of those not using PREEMPT_RT.  Should I use the opposite
 PREEMPT_DESKTOP?

i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
would simplify things, besides making PREEMPT_RT simpler as well. The
memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
on x86)

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


how to read gateways ips from routing table in module?

2005-03-15 Thread cranium2003
Hello,
 I require a kernel module that will print
gateway IP addresses in routing table as well as it
should not print Gateways that appear to be the same
interface ip addresses of that linux machine.
 e.g. If my eth1 is 172.16.x.x and if same
appear in routing table for any entry having
172.16.x.x as Gateway then it should not appear in
output.
regards,
cranium




__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] w6692 eliminate bad section references

2005-03-15 Thread maximilian attems
On Mon, 14 Mar 2005, Randy.Dunlap wrote:

 maximilian attems wrote:
 Fix w6692 section references:
   convert __initdata to __devinitdata.
 
 Error: ./drivers/isdn/hisax/w6692.o .text refers to 002f R_386_32
 .init.data
 
 I think the correct fix is to make W6692Version() be __init ...
 What do you think of that?
 
 -- 
 ~Randy

thanks a lot for your review!
you are right much better, added __init to W6692Version().

#Signed-off-by: maximilian attems [EMAIL PROTECTED]

diff -pruN -X dontdiff linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c
linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c
--- linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c 2005-03-02 08:38:25.0 
+0100
+++ linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c 2005-03-15 
14:01:14.0 +0100
@@ -49,7 +49,7 @@ static char *W6692Ver[] __initdata =
 {W6692 V00, W6692 V01, W6692 V10,
  W6692 V11};
 
-static void
+static void __init
 W6692Version(struct IsdnCardState *cs, char *s)
 {
int val;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] reduce __deprecated spew

2005-03-15 Thread Josh Boyer
On Tue, 2005-03-15 at 08:16 +0100, Arjan van de Ven wrote:
  (The intermodule_register and pm_register stuff has been hanging around for
  so long that one wonders if we need sterner stimuli, not lesser).
 
 intermodule can just about go (one user left).. we could start by making
 the intermodule.c file only build when that one user is selected (that
 user is a corner case) to avoid others from accidentally starting to use
 it again ...

It might be a corner case on PCs, but MTD used quite heavily in embedded
environments.  Perhaps it's time it just got fixed.  I remember seeing a
patch from Rusty a while ago that was a first run at doing this.  Is
that still hanging around somewhere?

josh

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.11-mm3 breaks compile of drivers/char/esp.c

2005-03-15 Thread Alan Cox
On Maw, 2005-03-15 at 04:33, Andrew Morton wrote:
 --- 25/include/linux/hayesesp.h~esp-build-fix 2005-03-14 20:31:18.0 
 -0800
 +++ 25-akpm/include/linux/hayesesp.h  2005-03-14 20:31:30.0 -0800
 @@ -77,6 +77,7 @@ struct hayes_esp_config {
  
  struct esp_struct {
   int magic;
 + spinlock_t  lock;
   int port;
   int irq;
   int flags;  /* defined in tty.h */

 I didn't pick this up because ESPSERIAL is still BROKEN_ON_SMP.  Alan,
 should we remove that now?

I think so yes. Needs a bit more testing to be totally sure

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


ocf-linux-20050315 - Asynchronous Crypto support for linux

2005-03-15 Thread David McCullough

Hi all,

The latest release of ocf-linux (20050315) is available for download
from the project page:

http://ocf-linux.sourceforge.net/

This release includes the following changes:

* Hifn PLL bug fixes
* Makefile fixes for 2.6 builds
* 2.6.11 and 2.4.29 patches
* cleanups for x86 builds

OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework
(OCF). This port aims to bring full asynchronous HW/SW crypto
acceleration to the Linux kernel and applications running under Linux.
Results have shown improvements of up to 7 times that of software crypto
for bulk crypto throughput using OpenSSL.

At this point in time OCF-Linux provides acceleration for OpenSSL,
OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing
applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key
operations with plans to include Random Number generators and more. This
project is being actively developed as a high performance crypto
solution for embedded devices but also applies equally well to any linux
based server or desktop.

Cheers,
Davidm

-- 
David McCullough, [EMAIL PROTECTED]  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Capabilities across execve

2005-03-15 Thread Alexander Nyberg
  This makes it possible for a root-task to pass capabilities to
  nonroot-task across execve. The root-task needs to change it's
  cap_inheritable mask and set prctl(PR_SET_KEEPCAPS, 1) to pass on
  capabilities. 
 
 This overloads keepcaps, which could surprise to existing users.

current-keep_capabilities is set to 0 at each execve, however the
inheritable mask is passed on and therefor also the allowed effective +
permitted. I think this is very necessery if there's ever going to be a
real use of it. It's not worth anything getting a shell with every
capability if every new process you run afterwards will have its
capabilities dropped. If we do like this it will only be useful in
special circumstances when wanting to run _one_ application with some
special capability. The scope can be much more general. How about having
users that can run all the way CAP_SYS_NICE, would give every audio man
his realtime applications. This is certainly possible with capabilities
across execve and pam_cap (using a few caps myself right now).

  At execve time the capabilities will be passed on to the new
  nonroot-task and any non-inheritable effective and permitted
  capabilities will be masked out.
  The effective capability of the new nonroot-task will be set to the
  maximum permitted.
 
 What happens to eff on setuid() to non-root 

If KEEPCAPS is set the permitted and inheritable capabilities are still
there, the effective capabilities are cleared either way. 

 or restore to uid 0?

Full capabilities restored.

 What happens if you exec a setuid-root binary, 

Sets full permitted  effective, inheritable left as is.
This means that if the setuid-root binary does an execve to another
program cap_inheritable will take effect and the capabilities will be
the same as before calling the setuid-root binary. I doubt this is
common scenario however.

 or a setuid-nonroot binary?

capabilities unchanged

 How about ptrace?

I'll look into this part, but I don't see it changing anything here
right now. 

However I'm sure there are cases I've missed and I'm looking for them
right now. This patch is going to need a few good eyes.

 Here's the tests I use.

I've looked at some cases in this test suite but as It doesn't say much
more than begin test 37 I have no idea of how to parse the output.

Updated patch.

= security/commoncap.c 1.15 vs edited =
--- 1.15/security/commoncap.c   2005-01-11 02:29:23 +01:00
+++ edited/security/commoncap.c 2005-03-15 14:45:36 +01:00
@@ -111,13 +111,19 @@ void cap_capset_set (struct task_struct 
 
 int cap_bprm_set_security (struct linux_binprm *bprm)
 {
-   /* Copied from fs/exec.c:prepare_binprm. */
-
-   /* We don't have VFS support for capabilities yet */
-   cap_clear (bprm-cap_inheritable);
-   cap_clear (bprm-cap_permitted);
-   cap_clear (bprm-cap_effective);
+   struct task_struct *p = current;
 
+   /*
+* Mask out the non-inheritable capabilities.
+* Note: init has a zero mask of cap_inheritable, so a root-task will 
not
+* pass on any capabilities unless explicitly told to do so. If a 
non-zero
+* inheritable mask is passed to a positive uid task it will then pass 
on 
+* its inheritable mask to all children unless told otherwise.
+*/
+   bprm-cap_permitted = cap_intersect(p-cap_permitted, 
p-cap_inheritable);
+   bprm-cap_effective = cap_intersect(p-cap_effective, 
p-cap_inheritable);
+   bprm-cap_inheritable = p-cap_inheritable;
+   
/*  To support inheritance of root-permissions and suid-root
 *  executables under compatibility mode, we raise all three
 *  capability sets for the file.
@@ -127,7 +133,7 @@ int cap_bprm_set_security (struct linux_
 */
 
if (!issecure (SECURE_NOROOT)) {
-   if (bprm-e_uid == 0 || current-uid == 0) {
+   if (bprm-e_uid == 0 || p-uid == 0) {
cap_set_full (bprm-cap_inheritable);
cap_set_full (bprm-cap_permitted);
}
@@ -139,13 +145,9 @@ int cap_bprm_set_security (struct linux_
 
 void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
 {
-   /* Derived from fs/exec.c:compute_creds. */
-   kernel_cap_t new_permitted, working;
+   kernel_cap_t new_permitted;
 
new_permitted = cap_intersect (bprm-cap_permitted, cap_bset);
-   working = cap_intersect (bprm-cap_inheritable,
-current-cap_inheritable);
-   new_permitted = cap_combine (new_permitted, working);
 
if (bprm-e_uid != current-uid || bprm-e_gid != current-gid ||
!cap_issubset (new_permitted, current-cap_permitted)) {
@@ -166,14 +168,15 @@ void cap_bprm_apply_creds (struct linux_
current-suid = current-euid = current-fsuid = bprm-e_uid;
current-sgid = current-egid = current-fsgid = bprm-e_gid;
 
-   /* For init, we want to retain the capabilities set
-* in the 

Re: Repeatable IDE Oops for 2.6.11 (ide-scsi vs ide-cdrom)

2005-03-15 Thread Bartlomiej Zolnierkiewicz
On Tue, 15 Mar 2005, Alan Cox wrote:
On Maw, 2005-03-15 at 08:19, Bartlomiej Zolnierkiewicz wrote:
On Mon, 14 Mar 2005, Alan Cox wrote:
Locking is fixed in ide-dev-2.6 tree
(at the moment seem to be dropped from -mm?).
Excellent - I'm looking forward to dropping the -ac IDE locking patches
There is still one thing TODO:
* fixing device drivers to refcount driver specific /proc/ide/ entries
  (infrastructure is in-place now)
so don't drop your locking patches yet. :-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-15 Thread Steven Rostedt


On Tue, 15 Mar 2005, Ingo Molnar wrote:


 * Steven Rostedt [EMAIL PROTECTED] wrote:


  What should we use instead of #ifdef PREEMPT_RT? Or should we just
  keep it the same for both.  Since this fix is only to fix spinlocks
  that schedule, I figured that it would be better not to waste the
  memory of those not using PREEMPT_RT.  Should I use the opposite
  PREEMPT_DESKTOP?

 i'd go for removing bit-spinlocks altogether, in the upstream kernel. It
 would simplify things, besides making PREEMPT_RT simpler as well. The
 memory overhead is not a big issue i believe. (8 more bytes per ext3 bh,
 on x86)


The problem here is that it's not ext3 bh's only. They're still the normal
buffer head.  The problem arrises because the ext3 journal head is
allocated within these bit spin locks. I tried to monkey with putting the
locks in the journal heads and have checks to see when to free them, but
it wasn't that simple. I started having problems with some of the freeing
transactions, I might have assumed too much.

I'll give it one more try to get it into the journal heads, but after
that, (if I fail) I'll let someone who understands the ext3 system better
handle this.

-- Steve

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH][2.6.11] drivers/char/isicom.c gcc4 fix

2005-03-15 Thread Mikael Pettersson
Fix two array-of-incomplete-type errors from gcc4 in isicom.c.

/Mikael

--- linux-2.6.11/drivers/char/isicom.c.~1~  2005-03-02 19:24:15.0 
+0100
+++ linux-2.6.11/drivers/char/isicom.c  2005-03-15 11:37:03.0 +0100
@@ -151,9 +151,6 @@ MODULE_DEVICE_TABLE(pci, isicom_pci_tbl)
 static int prev_card = 3;  /*  start servicing isi_card[0] */
 static struct tty_driver *isicom_normal;
 
-static struct isi_board isi_card[BOARD_COUNT];
-static struct isi_port  isi_ports[PORT_COUNT];
-
 static struct timer_list tx;
 static char re_schedule = 1;
 #ifdef ISICOM_DEBUG
@@ -210,6 +207,9 @@ struct  isi_port {
int xmit_cnt;
 };
 
+static struct isi_board isi_card[BOARD_COUNT];
+static struct isi_port  isi_ports[PORT_COUNT];
+
 /*
  * Locking functions for card level locking. We need to own both
  * the kernel lock for the card and have the card in a position that
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH][2.6.11] drivers/net/arcnet/arcnet.c gcc4 fixes

2005-03-15 Thread Mikael Pettersson
Fix

drivers/net/arcnet/arcnet.c: In function 'release_arcbuf':
drivers/net/arcnet/arcnet.c:256: warning: operation on 'i' may be undefined
drivers/net/arcnet/arcnet.c: In function 'get_arcbuf':
drivers/net/arcnet/arcnet.c:292: warning: operation on 'i' may be undefined

warnings from gcc4 in arcnet.c.

/Mikael

--- linux-2.6.11/drivers/net/arcnet/arcnet.c.~1~2005-03-02 
19:24:16.0 +0100
+++ linux-2.6.11/drivers/net/arcnet/arcnet.c2005-03-15 14:32:49.0 
+0100
@@ -253,7 +253,7 @@ static void release_arcbuf(struct net_de
BUGLVL(D_DURING) {
BUGMSG(D_DURING, release_arcbuf: freed #%d; buffer queue is 
now: ,
   bufnum);
-   for (i = lp-next_buf; i != lp-first_free_buf; i = ++i % 5)
+   for (i = lp-next_buf; i != lp-first_free_buf; i = (i+1) % 5)
BUGMSG2(D_DURING, #%d , lp-buf_queue[i]);
BUGMSG2(D_DURING, \n);
}
@@ -289,7 +289,7 @@ static int get_arcbuf(struct net_device 
 
BUGLVL(D_DURING) {
BUGMSG(D_DURING, get_arcbuf: got #%d; buffer queue is now: , 
buf);
-   for (i = lp-next_buf; i != lp-first_free_buf; i = ++i % 5)
+   for (i = lp-next_buf; i != lp-first_free_buf; i = (i+1) % 5)
BUGMSG2(D_DURING, #%d , lp-buf_queue[i]);
BUGMSG2(D_DURING, \n);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] blockdev: fix for racing mount/umount

2005-03-15 Thread Jeff Mahoney
This patch is another take at fixing the race between mount and umount
resetting the blocksize and causing buffer errors, infinite loops in
__getblk_slow, and possibly other undiscovered effects.

It adds possible flags to bd_claim such that the caller can request
exclusive access and/or wait until the device becomes available. Since bd_claim
already allows/denies access based on the holder, the BD_EXCL flag operates
under the assumption that all callers of bd_claim for a particular holder will
use the flag. This is currently true. BD_WAIT places the request on a wait
queue until access can be granted. It uses a global wait queue, which isn't a
contention point since bd_claim/bd_release both operate under the global
bdev_lock anyway.

Filesystems (via get_sb_bdev) now use BD_EXCL|BD_WAIT to ensure the previous
mount has completely shut down and closed the device before re-opening it
for a new mount. 

It's ugly, and I'm open to suggestions, but it seems to be the only way to
stop this race reliably.

Signed-off-by: Jeff Mahoney [EMAIL PROTECTED]

diff -ruNpX dontdiff linux-2.6.11/fs/block_dev.c linux-2.6.11.bs/fs/block_dev.c
--- linux-2.6.11/fs/block_dev.c 2005-03-14 21:25:20.0 -0500
+++ linux-2.6.11.bs/fs/block_dev.c  2005-03-14 22:17:16.0 -0500
@@ -238,6 +238,7 @@ static int block_fsync(struct file *filp
  */
 
 static  __cacheline_aligned_in_smp DEFINE_SPINLOCK(bdev_lock);
+static DECLARE_WAIT_QUEUE_HEAD(bdev_wq);
 static kmem_cache_t * bdev_cachep;
 
 static struct inode *bdev_alloc_inode(struct super_block *sb)
@@ -443,20 +444,33 @@ void bd_forget(struct inode *inode)
spin_unlock(bdev_lock);
 }
 
-int bd_claim(struct block_device *bdev, void *holder)
+/*
+ * flags:
+ * BD_NONE: No special behavior.
+ * BD_EXCL: Must have sole access to device, even if holder is the same.
+ *  This is really enforced by the holder always using BD_EXCL.
+ * BD_WAIT: Wait until access is available before returning.
+ */
+int __bd_claim(struct block_device *bdev, void *holder, int flags)
 {
int res;
+   DEFINE_WAIT (wait);
+
+retry:
spin_lock(bdev_lock);
+   prepare_to_wait (bdev_wq, wait, TASK_UNINTERRUPTIBLE);
 
/* first decide result */
-   if (bdev-bd_holder == holder)
+   if (bdev-bd_holder == holder) {
res = 0; /* already a holder */
-   else if (bdev-bd_holder != NULL)
+   if (flags  BD_EXCL)
+   res = -EBUSY;
+   } else if (bdev-bd_holder != NULL)
res = -EBUSY;/* held by someone else */
else if (bdev-bd_contains == bdev)
res = 0; /* is a whole device which isn't held */
 
-   else if (bdev-bd_contains-bd_holder == bd_claim)
+   else if (bdev-bd_contains-bd_holder == __bd_claim)
res = 0; /* is a partition of a device that is being 
partitioned */
else if (bdev-bd_contains-bd_holder != NULL)
res = -EBUSY;/* is a partition of a held device */
@@ -470,15 +484,21 @@ int bd_claim(struct block_device *bdev, 
 * be set to bd_claim before being set to holder
 */
bdev-bd_contains-bd_holders ++;
-   bdev-bd_contains-bd_holder = bd_claim;
+   bdev-bd_contains-bd_holder = __bd_claim;
bdev-bd_holders++;
bdev-bd_holder = holder;
+   } else if (flags  BD_WAIT) {
+   spin_unlock (bdev_lock);
+   schedule();
+   goto retry;
}
+
+   finish_wait (bdev_wq, wait);
spin_unlock(bdev_lock);
return res;
 }
 
-EXPORT_SYMBOL(bd_claim);
+EXPORT_SYMBOL(__bd_claim);
 
 void bd_release(struct block_device *bdev)
 {
@@ -488,6 +508,7 @@ void bd_release(struct block_device *bde
if (!--bdev-bd_holders)
bdev-bd_holder = NULL;
spin_unlock(bdev_lock);
+   wake_up_all (bdev_wq);
 }
 
 EXPORT_SYMBOL(bd_release);
@@ -876,7 +897,8 @@ fail:
  * Open the blockdevice described by the special file at @path, claim it
  * for the @holder.
  */
-struct block_device *open_bdev_excl(const char *path, int flags, void *holder)
+struct block_device *__open_bdev_excl(const char *path, int flags,
+  void *holder, int bdflags)
 {
struct block_device *bdev;
mode_t mode = FMODE_READ;
@@ -894,7 +916,7 @@ struct block_device *open_bdev_excl(cons
error = -EACCES;
if (!(flags  MS_RDONLY)  bdev_read_only(bdev))
goto blkdev_put;
-   error = bd_claim(bdev, holder);
+   error = __bd_claim(bdev, holder, bdflags);
if (error)
goto blkdev_put;
 
@@ -905,7 +927,7 @@ blkdev_put:
return ERR_PTR(error);
 }
 
-EXPORT_SYMBOL(open_bdev_excl);
+EXPORT_SYMBOL(__open_bdev_excl);
 
 /**
  * close_bdev_excl  -  release a blockdevice openen by open_bdev_excl()
diff -ruNpX dontdiff linux-2.6.11/fs/super.c 

Re: Intel Ethernet PRO 100

2005-03-15 Thread Laurent CARON
shafa.hidee wrote:
Hi All,
   Where we can find specs for writing driver for Intel PRO 100 card.
Regards
Shafahidee
 

already supported.
isn't it?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Dmitry Torokhov
On Tue, 15 Mar 2005 13:25:12 +0100, Helge Hafting
[EMAIL PROTECTED] wrote:
 2.6.11-mm1 and earlier: mouse appear as /dev/input/mouse0
 2.6.11-mm3: mouse appear as /dev/input/mouse1
 
 No big problem, one change to xorg.conf and I got the mouse back.
 I guess it wasn't supposed to change like that though?


Vojtech activated scroll handling in keyboard code by default so now
your keyboard is mapped to the mouse0 and the mouse moved to mouse1.

Vojtech, is is possible to detect whether a keyboard has scroll
wheel(s) by its ID?

 This is a mouse connected to the ps2 port, also appearing as /dev/psaux
 

I'd recommend using /dev/input/mice unless you want to _exclude_ some
of your input devices. It will get data from all you mice at once and
is always available.

-- 
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Bodo Eggert
(snipped the CC list - hope that's ok)

On Mon, 14 Mar 2005, Albert Cahalan wrote:
 On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
  On Mon, 14 Mar 2005, Albert Cahalan wrote:
   On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:

  NACK, the admin (and with the new inherited capabilities all users with 
  cap_???_override) can see all processes. Only users who don't need to know
  won't see the other user's processes.
 
 Capabilities are too broken for most people to use.

That's being fixed, the new semantics will allow a wrapper.

   Note that the admin hopefully does not normally run as root.
  
  su1 and sudo exist.
 
 This is a pain.

mv ps ps.bin # -+ or just ln -s /usr/bin/us1 ~admin/bin/ps instead
ln -s su1 ps # /
echo $'\nask never\nalias ps /bin/ps\nallow admin prefix ps'  /etc/su1.priv
# ore use * instead of admin, if all users are supposed to see everyone.

Or use the sysctl I described. It won't hurt more than the originally 
suggested flag, and it's much more powerfull.

 Now every user will need sudo access,
 and the sudoers file will have to disable requesting
 passwords so that scripts will work without hassle.

Is sudo _that_ bad? Seems it was a good decision to avoid sudo.

   Even if the admin were not running as a normal user, it is
   expected that normal users can keep tabs on each other.
   The admin may be sleeping. Social pressure is important to
   prevent one user from sucking up all the memory and CPU time.
  
  Privacy is important, too. Imagine each user can see the CEO (or the
  admin) executing ee nakedgirl.jpg.
 
 Obviously, he likes to have users see him do this.
 He'd use a private machine if he wanted privacy.

UNIX and linux are supposed to be a multi-user-systems unlike Win98.
Information leakage is usurally considered {\HUGE BAD}, and some security 
models demand closing all information leakages from privileged users to 
less privileged users. Restricted proc is one more step towards secure 
systems, unless you're depending on peer review.

 Note: I'm the procps (ps, top, w, etc.) maintainer.
 
 Probably I'd have to make /bin/ps run setuid root
 to deal with this. (minor changes needed) The same
 goes for /usr/bin/top, which I know is currently
 unsafe and difficult to fix.
  
  I used unpatched procps 3.1.11, and it worked for me, except pstree.
 
 It does not work correctly.
 
 Look, patches with this feature are called rootkits.
 Think of the headlines: Linux now with built-in rootkit.

Using another PC will hide the processes. Therefore using another PC is 
like using a rootkit. NOT.

Maybe you'll want to print a note about inaccessible proc entries, but 
that's a different issue.

Why do ps and top need to be setuid root to deal with a resticted 
/proc? 
What information in /proc/pid needs to be available to any and 
all 
users?
   
   Anything provided by traditional UNIX and BSD systems
   should be available.
  
  e.g. the buffer overflow in sendmail? Or all the open relays? :)
  
  The demands to security and privacy have increased. Linux should be able 
  to provide the requested privacy.
 
 This really isn't about security.

Information leakage is a security aspect.

 Privacy may be undesirable.

May. That's why I suggested the min/max sysctl.

 With privacy comes anti-social behavior.

With anti-social behavior comes the admin and his LART.

BTW: If the users want to be anti-social, they'll just rename setiathome 
to something like -bash or soffice.

 Supposing that the
 users do get privacy, perhaps because the have paid for it:

Vservers,
 Xen, UML, VM, VMware, separate computers
 
 Going with separate computers is best.

If you like wasting space and energy. If the user's demands don't exceed 
one percent of a historic PC, there is no point in buying more hardware.

 Don't forget to use
 network traffic control to keep users from being able to
 detect the network activity of other users.

Like that:?

$ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
/proc/net/tcp: Permission denied

   Users who want privacy can get their
   own computer. So, these need to work:
   
   ps [...]
   w
   top
  
  Works as intended. Only pstree breaks, if init isn't visible.
 
 They work like they do with a rootkit installed.
 Traditional behavior has been broken.

They are as broken as finger or ls are if the home directory is chmodded.
-- 
Top 100 things you don't want the sysadmin to say:
13. Ooohh, lovely, it runs SVR4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] PPC64 iSeries: cleanup viopath

2005-03-15 Thread Hollis Blanchard
On Mar 14, 2005, at 9:34 PM, Stephen Rothwell wrote:
Since you brought this file to my attention, I figured I might as well 
do
some simple cleanups.  This patch does:
	- single bit int bitfields are a bit suspect and Anndrew pointed
	  out recently that they are probably slower to access than ints

--- linus/arch/ppc64/kernel/viopath.c	2005-03-13 04:07:42.0 
+1100
+++ linus-cleanup.1/arch/ppc64/kernel/viopath.c	2005-03-15 
14:02:48.0 +1100
@@ -56,8 +57,8 @@
  * But this allows for other support in the future.
  */
 static struct viopathStatus {
-	int isOpen:1;		/* Did we open the path?*/
-	int isActive:1;		/* Do we have a mon msg outstanding */
+	int isOpen;		/* Did we open the path?*/
+	int isActive;		/* Do we have a mon msg outstanding */
 	int users[VIO_MAX_SUBTYPES];
 	HvLpInstanceId mSourceInst;
 	HvLpInstanceId mTargetInst;
Why not use a byte instead of a full int (reordering the members for 
alignment)?

--
Hollis Blanchard
IBM Linux Technology Center
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.11-mm3 mouse oddity

2005-03-15 Thread Vojtech Pavlik
On Tue, Mar 15, 2005 at 09:25:45AM -0500, Dmitry Torokhov wrote:

 Vojtech activated scroll handling in keyboard code by default so now
 your keyboard is mapped to the mouse0 and the mouse moved to mouse1.
 
 Vojtech, is is possible to detect whether a keyboard has scroll
 wheel(s) by its ID?

If it were, I'd already have used it.

  This is a mouse connected to the ps2 port, also appearing as /dev/psaux
 
 I'd recommend using /dev/input/mice unless you want to _exclude_ some
 of your input devices. It will get data from all you mice at once and
 is always available.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: drm lockups since 2.6.11-bk2

2005-03-15 Thread Dave Jones
On Tue, Mar 15, 2005 at 10:38:30AM +, Dave Airlie wrote:
  
  Hi all,
   Andrew Clayton reported lockups on the dri list issues since -bk2
  and bug 4337 on bugzilla.kernel.org looks like it might be the same
  thing..
  
  This leads me to think the AGP multi-bridge patches are at fault... (for
  once my laziness in merging late instead of early gave a good gap in the
  patches...)
  
  I'm offline in sense of I can write this mail and respond but have not
  access to a Linux system, my bitkeeper trees, ssh keys for anywhere of
  interest.. and am in the wrong country, it'll be the 23rd/24th before I am
  back at my desks...
  
  I might get time to do a code review, my main worry is that all the
  problems reported with those patches in -mm made it into the patchset that
  went into Linus.. mainly things like forgetting to memset certain
  structures to 0 and sillies like that...

I saw one report where the recent drm security hole fix broke dri
for one user.  Whilst it seems an isolated incident, could this have
more impact than we first realised ?

Worse case scenario we can drop out the multi-bridge support for now
if it needs work. Mike left SGI now, so we'll need to find someone else
with access to a Prism to make sure it still works correctly on a
real multi-gart system.

Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] net/bluetooth/rfcomm/core.: make a variable static

2005-03-15 Thread Adrian Bunk
This patch makes a needlessly global variable static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c.old   2005-03-15 
13:21:50.0 +0100
+++ linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c   2005-03-15 
13:22:03.0 +0100
@@ -68,7 +68,7 @@
 #define rfcomm_lock()  down(rfcomm_sem);
 #define rfcomm_unlock()up(rfcomm_sem);
 
-unsigned long rfcomm_event;
+static unsigned long rfcomm_event;
 
 static LIST_HEAD(session_list);
 static atomic_t terminate, running;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: enabling IOAPIC on C3 processor? (how to investigate hangs without nmi watchdog)

2005-03-15 Thread Dave Jones
On Tue, Mar 15, 2005 at 01:52:47PM +0100, jerome lacoste wrote:

  Do I have any alternative to investigate this hang or should I just
  give up and smash my board?

If you have the longhaul cpufreq driver enabled, turn it off.
It's currently broken for some reason, and I've not had time to
figure out why.

Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

* Andrea Arcangeli [EMAIL PROTECTED] wrote:

  technical comment: seccomp goes outside the audit/selinux framework,
  which i believe is a bug. Andrea?
 
 I intentionally left it out of audit/selinux. To the less dependencies
 it has on other parts of the kernel and the simpler it is, the better
 IMHO. Seccomp should be fixed in stone, people shouldn't go hack on it
 every day.

let me put it another way: this is a security hole. seccomp is now a way
to evade the auditing of read/write syscalls done to an opened file. 
Please fix this.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: swsusp_restore crap

2005-03-15 Thread Rafael J. Wysocki
Hi,

On Tuesday, 15 of March 2005 13:02, Pavel Machek wrote:
 Hi!
 
 Please kill that swsusp_restore() call that itself calls
 flush_tlb_global(), it's junk. First, the flush_tlb_global() thing is
 arch specific, and that's all swsusp_restore() does. Then, the asm 
 just
 calls this before returning to C code, so it makes no sense to have a
 hook there. The x86 asm can have it's own call to some arch stuff if 
 it
 wants or just do the tlb flush in asm...

Better, here is a patch... (note: flush_tlb_global() is an x86'ism,
doesn't exist on ppc, thus breaks compile, and that has nothing to do in
the generic code imho, it should be clearly defined as the
responsibility of the asm code).
   
   x86-64 needs this, too Otherwise it looks okay.
  
  It breaks compilation on i386 either, because nr_copy_pages_check
  is static in swsusp.c.  May I propose the following patch instead (tested on
  x86-64 and i386)?
 
 
  +asmlinkage int __swsusp_flush_tlb(void)
  +{
  +   swsusp_restore_check();
 
 Someone will certainly forget this one, and it is probably
 nicer/easier to just move BUG_ON into swsusp_suspend(), just after
 restore_processor_state() or something like that...

... in which case __swsusp_flush_tlb() would only contain a call to
__flush_tlb_global(), but this is a macro on both x86-64 and i386, so we can
drop the __swsusp_flush_tlb() altogether and do it in assembly (before the
GPRs are restored, perhaps).  Patch follows.

Greets,
Rafael


Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

diff -Nrup linux-2.6.11-bk10-a/arch/i386/power/swsusp.S 
linux-2.6.11-bk10-b/arch/i386/power/swsusp.S
--- linux-2.6.11-bk10-a/arch/i386/power/swsusp.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/i386/power/swsusp.S2005-03-15 
15:37:25.0 +0100
@@ -51,6 +51,15 @@ copy_loop:
.p2align 4,,7
 
 done:
+   /* Flush TLB, including global things (vmalloc) */
+   movlmmu_cr4_features, %eax
+   movl%eax, %edx
+   andl$~(17), %edx;  # PGE
+   movl%edx, %cr4;  # turn off PGE
+   movl%cr3, %ecx;  # flush TLB
+   movl%ecx, %cr3
+   movl%eax, %cr4;  # turn PGE back on
+
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_ebx, %ebx
@@ -58,5 +67,5 @@ done:
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
ret
diff -Nrup linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S 
linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.11-bk10-a/arch/x86_64/kernel/suspend_asm.S2005-03-15 
09:20:53.0 +0100
+++ linux-2.6.11-bk10-b/arch/x86_64/kernel/suspend_asm.S2005-03-15 
15:36:29.0 +0100
@@ -69,6 +69,14 @@ loop:
movqpbe_next(%rdx), %rdx
jmp loop
 done:
+   /* Flush TLB, including global things (vmalloc) */
+   movq%rax, %rdx;  # mmu_cr4_features(%rip)
+   andq$~(17), %rdx;  # PGE
+   movq%rdx, %cr4;  # turn off PGE
+   movq%cr3, %rcx;  # flush TLB
+   movq%rcx, %cr3
+   movq%rax, %cr4;  # turn PGE back on
+
movl$24, %eax
movl%eax, %ds
 
@@ -89,5 +97,5 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
ret
diff -Nrup linux-2.6.11-bk10-a/kernel/power/swsusp.c 
linux-2.6.11-bk10-b/kernel/power/swsusp.c
--- linux-2.6.11-bk10-a/kernel/power/swsusp.c   2005-03-15 09:21:23.0 
+0100
+++ linux-2.6.11-bk10-b/kernel/power/swsusp.c   2005-03-15 15:35:44.0 
+0100
@@ -900,22 +900,13 @@ int swsusp_suspend(void)
error = swsusp_arch_suspend();
/* Restore control flow magically appears here */
restore_processor_state();
+   BUG_ON (nr_copy_pages_check != nr_copy_pages);
restore_highmem();
device_power_up();
local_irq_enable();
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
-{
-   BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of global things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
-}
-
 int swsusp_resume(void)
 {
int error;

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/4] sparsemem intro patches

2005-03-15 Thread Martin J. Bligh
  The following four patches provide the last needed changes before the
  introduction of sparsemem.  For a more complete description of what this
  will do, please see this patch:
 
  
 http://www.sr71.net/patches/2.6.11/2.6.11-bk7-mhp1/broken-out/B-sparse-150-sparsemem.patch
 
 I don't know what to think about this.  Can you describe sparsemem a little
 further, differentiate it from discontigmem and tell us why we want one? 
 Is it for memory hotplug?  If so, how does it support hotplug?
 
 To which architectures is this useful, and what is the attitude of the
 relevant maintenance teams?

This isn't just for hotplug by any means. Andy wrote it to get rid of a whole
bunch of different problems, roughly based on some previous work by Dan Phillips
and Dave McCracken (I've added a cc to the actual authors of these patches). 
This is the major part of what used to be called CONFIG_NONLINEAR, which we 
discussed at last year's kernel summit, and people were pretty enthusiastic 
about. 

 Quoting from the above patch:
 
 Sparsemem replaces DISCONTIGMEM when enabled, and it is hoped that
 it can eventually become a complete replacement.
 ...
 This patch introduces CONFIG_FLATMEM.  It is used in almost all
 cases where there used to be an #ifndef DISCONTIG, because
 SPARSEMEM and DISCONTIGMEM often have to compile out the same areas
 of code.
 
 Would I be right to worry about increasing complexity, decreased
 maintainability and generally increasing mayhem?

Not really - it cleans up the current mess where discontigmem means, and
is used for, two distinct things: 1. the memory is significantly non-contig
in the physical layout. 2. NUMA support.

It also allows us to support discontiguous memory *within* a NUMA node, which
is important for some systems - we can scrap the added complexity of ia64s
vmemmap stuff, for instance. 

Whatever your opinions are on mem hotplug, I think we want CONFIG_SPARSEMEM
to clean up the existing mess of discontig - with or without hotplug. I've 
wanted this for a very long time, and was dicussing it with Andy at OLS last 
year; he came up with a much better, cleaner way to implement it than I had.

It also makes a lot of sense as a foundation for hotplug, which multiple 
people seem to want for virtualization stuff.

Anyway, that's what I want it for ;-)

 If a competent kernel developer who is not familiar with how all this code
 hangs together wishes to acquaint himself with it, what steps should he
 take?

Andy, can you explain that further? Maybe also worth checking these are the
correct version of your patches.

M.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] net/ipv4/inetpeer.c: make a struct static

2005-03-15 Thread Adrian Bunk
This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/ipv4/inetpeer.c.old   2005-03-15 
13:29:32.0 +0100
+++ linux-2.6.11-mm3-full/net/ipv4/inetpeer.c   2005-03-15 13:30:13.0 
+0100
@@ -92,9 +92,9 @@
 int inet_peer_minttl = 120 * HZ;   /* TTL under high load: 120 sec */
 int inet_peer_maxttl = 10 * 60 * HZ;   /* usual time to live: 10 min */
 
+static struct inet_peer *inet_peer_unused_head;
 /* Exported for inet_putpeer inline function.  */
-struct inet_peer *inet_peer_unused_head,
-   **inet_peer_unused_tailp = inet_peer_unused_head;
+struct inet_peer **inet_peer_unused_tailp = inet_peer_unused_head;
 DEFINE_SPINLOCK(inet_peer_unused_lock);
 #define PEER_MAX_CLEANUP_WORK 30
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] net/ipv6/ndisc.c: make a function static

2005-03-15 Thread Adrian Bunk
This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/ipv6/ndisc.c.old  2005-03-15 13:33:29.0 
+0100
+++ linux-2.6.11-mm3-full/net/ipv6/ndisc.c  2005-03-15 13:34:03.0 
+0100
@@ -1594,10 +1594,11 @@
return ret;
 }
 
-int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name, int nlen,
-void __user *oldval, size_t __user *oldlenp,
-void __user *newval, size_t newlen,
-void **context)
+static int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name,
+   int nlen, void __user *oldval,
+   size_t __user *oldlenp,
+   void __user *newval, size_t newlen,
+   void **context)
 {
struct net_device *dev = ctl-extra1;
struct inet6_dev *idev;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] net/core/pktgen.c: make a function static

2005-03-15 Thread Adrian Bunk
pktgen_xmit is already inline but not static.

This doesn't make much sense - especially since there's no external user 
of this function.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

--- linux-2.6.11-mm3-full/net/core/pktgen.c.old 2005-03-15 13:25:04.0 
+0100
+++ linux-2.6.11-mm3-full/net/core/pktgen.c 2005-03-15 13:25:20.0 
+0100
@@ -2587,7 +2587,7 @@
 thread_unlock();
 }
 
-__inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev)
+static inline void pktgen_xmit(struct pktgen_dev *pkt_dev)
 {
struct net_device *odev = NULL;
__u64 idle_start = 0;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Andrea Arcangeli
On Tue, Mar 15, 2005 at 03:44:28PM +0100, Ingo Molnar wrote:
 let me put it another way: this is a security hole. seccomp is now a way
 to evade the auditing of read/write syscalls done to an opened file. 
 Please fix this.

This is not true, the auditing of read/write will work fine on the
seccomp task too. I guess you overlooked something in the code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

* Andrea Arcangeli [EMAIL PROTECTED] wrote:

 This is not true, the auditing of read/write will work fine on the
 seccomp task too. I guess you overlooked something in the code.

yeah, you are right - it's there. You are driving seccomp off
do_syscall_trace(), which does audit_syscall_entry().

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [-mm patch] seccomp: don't say it was more or less mandatory

2005-03-15 Thread Ingo Molnar

* Andrea Arcangeli [EMAIL PROTECTED] wrote:

  which quite likely wont be provable in the foreseeable future).
 
 Please mention a _single_ bug that could allow you to escape the
 seccomp jail in linux since 2.4.0 on x86 and x86-64 (and with escape I
 don't mean sniffing data with mmx not being backwards compatible, or
 f00f DoS, I mean executing code into the host as user nobody). I'm not
 aware of a _single_ seccomp bug that could allow you to escape the
 seccomp jail since 2.4.0 and probably much earlier.

ugh? Where do i claim any such thing?

while we are at it, please mention a single ptrace bug in the same
timeframe that could allow a bytecode 'client' to escape a ptrace
TRACE_SYSCALL jail at will.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.11-mm3: megaraid_sas.c: stack usage

2005-03-15 Thread Adrian Bunk
On Sat, Mar 12, 2005 at 03:42:22AM -0800, Andrew Morton wrote:
...
 All 606 patches:
...
 megaraid_sas-announcing-new-module-for.patch
   megaraid_sas: Announcing new module for LSI Logic's SAS based MegaRAID 
 controllers
...

Enormous stack usage:
- megasas_init_mfi (due to ctrl_info)

Big stack usage:
- megasas_mgmt_ioctl (due to uioc and dv)
- megasas_mgmt_fw_ioctl (due to uioc)

Please fix this.
 
cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: 2.6.11-mm3: megaraid_sas.c: stack usage

2005-03-15 Thread Bagalkote, Sreenivas
On Sat, Mar 12, 2005 at 03:42:22AM -0800, Andrew Morton wrote:
...
 All 606 patches:
...
 megaraid_sas-announcing-new-module-for.patch
   megaraid_sas: Announcing new module for LSI Logic's SAS 
based MegaRAID controllers
...

Enormous stack usage:
- megasas_init_mfi (due to ctrl_info)

Big stack usage:
- megasas_mgmt_ioctl (due to uioc and dv)
- megasas_mgmt_fw_ioctl (due to uioc)

Please fix this.
 

Will do.

Thanks,
Sreenivas
LSI Logic Corporation
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Rene Scharfe
Albert Cahalan wrote:
Note that the admin hopefully does not normally run as root.
The admin should be using a normal user account most of the
time, to reduce the damage caused by his accidents.
Openwall and GrSecurity solved this by having a special group that can 
see everything, just like root.  E.g. we could add a proc.gid kernel 
boot option for that purpose.

Even if the admin were not running as a normal user, it is
expected that normal users can keep tabs on each other.
The admin may be sleeping. Social pressure is important to
prevent one user from sucking up all the memory and CPU time.
IANAL, but creating a user profile (who ran what when, used how many 
resources etc.) without the user's consent is illegal at least here in 
Germany.  As an admin I'd like to be able to prevent a user from even 
trying to spy on another user.

Anything provided by traditional UNIX and BSD systems
should be available. Users who want privacy can get their
own computer. So, these need to work:
ps -ef
ps -el
ps -ej
ps axu
ps axl
ps axj
ps axv
w
top
If with work you mean show info about all users then the patch 
becomes pointless.  The programs work in the sense that they do *not* 
should cloaked processes, which is intended. :)

OK, I understand that you need to be able to turn this feature off and I 
also don't want non-root admins to suddenly go blind.  Would adding a 
proc.gid kernel parameter and an off-switch be sufficient for you?

Thanks,
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ES7000 Legacy Mappings Update

2005-03-15 Thread Jason Davis
See below.
On Mon, 14 Mar 2005, Andrew Morton wrote:
You triggered my trivia twitch.
Jason Davis [EMAIL PROTECTED] wrote:
 -	 * ES7000 has no legacy identity mappings
 +	 * Older generations of ES7000 have no legacy identity mappings
  	 */
 -	if (es7000_plat)
 +	if (es7000_plat  es7000_plat  2) 
  		return;
Why not
if (es7000_plat == 1)
?
Looks like I never learned to apply the concept of reducing fractions :). 
Thanks for catching this.
  	/* 
 diff -Naurp linux-2.6.11.3/arch/i386/mach-es7000/es7000plat.c linux-2.6.11.3-legacy/arch/i386/mach-es7000/es7000plat.c
 --- linux-2.6.11.3/arch/i386/mach-es7000/es7000plat.c	2005-03-13 01:44:41.0 -0500
 +++ linux-2.6.11.3-legacy/arch/i386/mach-es7000/es7000plat.c	2005-03-14 11:52:44.0 -0500
 @@ -138,7 +138,14 @@ parse_unisys_oem (char *oemptr, int oem_
  		es7000_plat = 0;
  	} else {
  		printk(\nEnabling ES7000 specific features...\n);
 -		es7000_plat = 1;
 +		/*
 +		 * Check to see if this is a x86_64 ES7000 machine.
 +		 */
 +		if (!(boot_cpu_data.x86 = 15  boot_cpu_data.x86_model = 2))
 +			es7000_plat = 2;
 +		else
 +			es7000_plat = 1;
 +
Perhaps some nice enumerated identifiers here, rather than magic numbers?
Initially, I was going to take this approach but that would require some specific 
platform defines to be thrown into a global header file (mpparse.c would need to see them 
as well). I didn't think it would be appropriate to mix code like that. I'll be glad to 
revise the patch to include enumerated identifiers but would it be more acceptable to 
comment on the semantics of the es7000_plat var in the platform specific 
es7000plat.c file?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Paul Jackson
 (snipped the CC list - hope that's ok)

No - it's not ok.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: current linus bk, error mounting root

2005-03-15 Thread Jon Smirl
Is this problem still being tracked?

I have figured out a work around of adding a 1 second pause in nash
after the ata_piix driver is loaded. Something has changed in the
driver initialization timing such that later stages of boot try to
access the driver before the driver has created the device without the
pause.

I am using Fedora Core 3 un modified except for the addition of the 1
second pause.

On Thu, 10 Mar 2005 17:29:19 +0100, Jens Axboe [EMAIL PROTECTED] wrote:
 On Thu, Mar 10 2005, Jon Smirl wrote:
  On Thu, 10 Mar 2005 17:01:55 +0100, Jens Axboe [EMAIL PROTECTED] wrote:
   what are the major/minor numbers of /dev/root?
 
 
  If I boot on a working system it is 8,5
 
 I see no /dev/sda detected in your system from the dmesg. Ahh this is
 where it panics on loading ata_piix I suppose, can't you capture that
 panic with the serial console as well?
 
 --
 Jens Axboe
 
 


-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] w6692 eliminate bad section references

2005-03-15 Thread Randy.Dunlap
maximilian attems wrote:
thanks a lot for your review!
you are right much better, added __init to W6692Version().
#Signed-off-by: maximilian attems [EMAIL PROTECTED]
Acked-by: Randy Dunlap [EMAIL PROTECTED]
diff -pruN -X dontdiff linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c
linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c
--- linux-2.6.11-bk8/drivers/isdn/hisax/w6692.c	2005-03-02 08:38:25.0 +0100
+++ linux-2.6.11-bk8-max/drivers/isdn/hisax/w6692.c	2005-03-15 14:01:14.0 +0100
@@ -49,7 +49,7 @@ static char *W6692Ver[] __initdata =
 {W6692 V00, W6692 V01, W6692 V10,
  W6692 V11};
 
-static void
+static void __init
 W6692Version(struct IsdnCardState *cs, char *s)
 {
 	int val;

--
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] new timeofday core subsystem (v. A3)

2005-03-15 Thread Albert Cahalan
On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
 On Mon, 14 Mar 2005, Albert Cahalan wrote:
 
  When the vsyscall page is created, copy the one needed function
  into it. The kernel is already self-modifying in many places; this
  is nothing new.
 
 AFAIK this will only works on ia32 and x86_64 and not definitely not
 on ia64. Who knows about the other platforms 

I'll bet it does work fine on IA-64. If it didn't, you would
be unable to load the kernel or load an executable.

I know it works for PowerPC. You'll need an isync instruction
of course. You may also want a sync instruction and some code
to invalidate the cache.

Setting up the page content should be a 1-time operation done
at boot. Check your processor manuals as needed.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: current linus bk, error mounting root

2005-03-15 Thread Jens Axboe
On Tue, Mar 15 2005, Jon Smirl wrote:
 Is this problem still being tracked?
 
 I have figured out a work around of adding a 1 second pause in nash
 after the ata_piix driver is loaded. Something has changed in the
 driver initialization timing such that later stages of boot try to
 access the driver before the driver has created the device without the
 pause.
 
 I am using Fedora Core 3 un modified except for the addition of the 1
 second pause.

If the /dev showup timing is a problem, you were just lucky that it
worked before and I don't consider it a kernel issue.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Intel Ethernet PRO 100

2005-03-15 Thread Randy.Dunlap
Laurent CARON wrote:
shafa.hidee wrote:
Hi All,
   Where we can find specs for writing driver for Intel PRO 100 card.
Regards
Shafahidee
 

already supported.
isn't it?
Yes, it is.
You can find a developer's manual for the 8255x NIC at
http://sourceforge.net/project/showfiles.php?group_id=42302
--
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] new timeofday core subsystem (v. A3)

2005-03-15 Thread Chris Friesen
Albert Cahalan wrote:
I know it works for PowerPC. You'll need an isync instruction
of course. You may also want a sync instruction and some code
to invalidate the cache.
For PPC you'll want to flush the dcache, then invalidate the icache. 
This will ensure that it works on all processors.

Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] PPC64 iSeries: cleanup viopath

2005-03-15 Thread Stephen Rothwell
On Tue, 15 Mar 2005 08:32:27 -0600 Hollis Blanchard [EMAIL PROTECTED] wrote:

 On Mar 14, 2005, at 9:34 PM, Stephen Rothwell wrote:
 
  Since you brought this file to my attention, I figured I might as well 
  do
  some simple cleanups.  This patch does:
  - single bit int bitfields are a bit suspect and Anndrew pointed
out recently that they are probably slower to access than ints
 
  --- linus/arch/ppc64/kernel/viopath.c   2005-03-13 04:07:42.0 
  +1100
  +++ linus-cleanup.1/arch/ppc64/kernel/viopath.c 2005-03-15 
  14:02:48.0 +1100
  @@ -56,8 +57,8 @@
* But this allows for other support in the future.
*/
   static struct viopathStatus {
  -   int isOpen:1;   /* Did we open the path?*/
  -   int isActive:1; /* Do we have a mon msg outstanding */
  +   int isOpen; /* Did we open the path?*/
  +   int isActive;   /* Do we have a mon msg outstanding */
  int users[VIO_MAX_SUBTYPES];
  HvLpInstanceId mSourceInst;
  HvLpInstanceId mTargetInst;
 
 Why not use a byte instead of a full int (reordering the members for 
 alignment)?

Because classical boleans are ints.

Because I don't know the relative speed of accessing single byte variables.

Because it was easy.

Because we only allocate 32 of these structures.  Changing them really
only adds four bytes per structure.  I guess using bytes and rearranging
the structure could actually save 4 bytes per structure.

I originally changed them to unsigned int single bit bitfields, but
changed my mind - would that be better?

It really makes little difference, I was just trying to get rid of the
silly signed single bit bitfields ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpiOyePlq9GL.pgp
Description: PGP signature


  1   2   3   4   >