* NFS as a Cluster File System.
From: Lorn Kay @ 2003-01-09 19:39 UTC (permalink / raw)
To: nfs, linux-ha
Is NFS a viable CFS? (I'm cross posting this due to a discussion on the the
linux-ha list recently.)
NFS has a bad reputation probably due to (at least) the following:
It has been used in networking environments where different server hardware
configurations (NICS, drivers, etc.) running different operating systems
have connected to each other (in many-to-many configurations).
It “grew up” on networks that were perhaps unstable, or immature
(“Someone’s kicked the token ring coax cable laying on the floor again”)
long before switches were common place, and the network was loaded down with
all kinds of network traffic.
It wasn’t understood very well. Since the default mount options worked,
system administrators often didn’t fully understand the ramifications of
their NFS client mount option choices.
It relied on UDP, which is susceptible to huge retransmission efforts on
noisy or lossy networks.
NFS was used over many-hop WAN connections.
NFS servers were often used for many other tasks, not just NFS.
A cluster configuration, however, offers several advantages over the typical
NFS configuration:
All NFS clients (the cluster nodes) run the same operating system (Linux).
All clients run the same version of NFS and the kernel.
All clients use the same network tuned configuration.
A physical network can be dedicated to NFS. (Using a high quality switch,
with short data-center-only cable runs.)
All clients connect to one NFS server.
The NFS server is a high-quality dedicated machine (Net App, EMC, etc.)
Only one mount point need be used with one set of mount options.
Linux clients can use TCP instead of UDP.
Except for the vagaries of the load placed on the cluster nodes, this sounds
like a test lab environment. If NFS can’t work in this environment where
will it ever work?
--K
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: rotation.
From: James Simmons @ 2003-01-09 19:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Fbdev development list, Linux Kernel Mailing List
In-Reply-To: <Pine.GSO.4.21.0301081120540.21171-100000@vervain.sonytel.be>
> Where are you going to implement the rotation? At the fbcon or fbdev level?
We already have a hook for hardware acceleration in struct fb_ops.
> Fbcon has the advantage that it'll work for all frame buffer devices.
The fbdev level will have the functionalty but fbcon is the one that needs
it.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Grant Grundler @ 2003-01-09 19:52 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Linus Torvalds, Alan Cox, Paul Mackerras, Benjamin Herrenschmidt,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030109204626.A2007@jurassic.park.msu.ru>
On Thu, Jan 09, 2003 at 08:46:26PM +0300, Ivan Kokshaysky wrote:
> As discussed, this patch splits PCI probing into 2 phases.
Like david, both parts of the patch look good but i haven't tested
on either parisc or ia64. I don't have time right now to work on
2.5.x issues :^(
I looked at 2.5.54 to check if everything was ok and found
another nit:
grundler <510>fgrep pci_scan_bus *.[ch]
probe.c:struct pci_bus * __devinit pci_scan_bus_parented(struct device *parent, int bus, struct pci_ops *ops, void *sysdata)
probe.c:EXPORT_SYMBOL(pci_scan_bus);
and :
grundler <514>fgrep pci_scan_bus include/linux/*h
include/linux/pci.h:struct pci_bus *pci_scan_bus_parented(struct device *parent, int bus, struct pci_ops *ops, void *sysdata);
include/linux/pci.h:static inline struct pci_bus *pci_scan_bus(int bus, struct pci_ops *ops, void *sysdata)
include/linux/pci.h: return pci_scan_bus_parented(NULL, bus, ops, sysdata);
Can the EXPORT_SYMBOL(pci_scan_bus) be removed now?
BTW, thanks to whoever introduced pci_scan_bus_parented().
It's exactly what parisc code needed (lba_pci.c and dino.c use it).
I think just go ahead with your patches and we'll fix up the arch specific
stuff to follow. I'm convinced it's the right direction.
thanks,
grant
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: James Simmons @ 2003-01-09 19:45 UTC (permalink / raw)
To: Sven Luther
Cc: Geert Uytterhoeven, Linux Fbdev development list,
Linux Kernel Mailing List
In-Reply-To: <20030108104817.GA10165@iliana>
> > Fbcon has the advantage that it'll work for all frame buffer devices.
>
> But you could also provide driver hooks for the chips which have such a
> rotation feature included (don't know if such exist, but i suppose they
> do, or may in the future).
Hooks already exist in struct fb_ops.
> So, we also support fbcon for not left to righ locales ?
That will happen in the core console code.
^ permalink raw reply
* [PATCH] tiny ens1370.c warning fix, bk 2.5.52]
From: carbonated beverage @ 2003-01-09 19:51 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Hi all,
Resend of a patch
__devinitdata is in the wrong location in ens1370.c, so it's
apparently ignored by gcc and the struct isn't freed. Here's a small
patch to fix that.
Linus, please apply.
-- DN
Daniel
--- ens1370.c.orig Fri Dec 20 02:03:24 2002
+++ ens1370.c Fri Dec 20 14:54:24 2002
@@ -1431,7 +1431,7 @@
unsigned short vid; /* vendor ID */
unsigned short did; /* device ID */
unsigned char rev; /* revision */
-} __devinitdata es1371_spdif_present[] = {
+} es1371_spdif_present[] __dev_initdata = {
{ .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_CT5880, .rev = CT5880REV_CT5880_C },
{ .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_CT5880, .rev = CT5880REV_CT5880_D },
{ .vid = PCI_VENDOR_ID_ENSONIQ, .did = PCI_DEVICE_ID_ENSONIQ_CT5880, .rev = CT5880REV_CT5880_E },
^ permalink raw reply
* [PATCH] Use %ebp rather than %ebx for thread_info pointer
From: Luca Barbieri @ 2003-01-09 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux-Kernel ML
[-- Attachment #1: Type: text/plain, Size: 5191 bytes --]
This patch changes assembly code that accesses thread_info to use %ebp
rather than %ebx.
This allows me to take advantage of the fact that %ebp is restored by
user mode in the sysenter register pop removal patch.
diff --exclude-from=/home/ldb/src/exclude -urNdp linux-2.5.54-preldb/arch/i386/kernel/entry.S linux-2.5.54-ldb/arch/i386/kernel/entry.S
--- linux-2.5.54-preldb/arch/i386/kernel/entry.S 2003-01-06 16:01:40.000000000 +0100
+++ linux-2.5.54-ldb/arch/i386/kernel/entry.S 2003-01-06 04:54:58.000000000 +0100
@@ -145,16 +145,16 @@ ENTRY(lcall7)
# gates, which has to be cleaned up later..
pushl %eax
SAVE_ALL
- movl %esp, %ebx
- pushl %ebx
+ movl %esp, %ebp
+ pushl %ebp
pushl $0x7
do_lcall:
- movl EIP(%ebx), %eax # due to call gates, this is eflags, not eip..
- movl CS(%ebx), %edx # this is eip..
- movl EFLAGS(%ebx), %ecx # and this is cs..
- movl %eax,EFLAGS(%ebx) #
- movl %edx,EIP(%ebx) # Now we move them to their "normal" places
- movl %ecx,CS(%ebx) #
+ movl EIP(%ebp), %eax # due to call gates, this is eflags, not eip..
+ movl CS(%ebp), %edx # this is eip..
+ movl EFLAGS(%ebp), %ecx # and this is cs..
+ movl %eax,EFLAGS(%ebp) #
+ movl %edx,EIP(%ebp) # Now we move them to their "normal" places
+ movl %ecx,CS(%ebp) #
#
# Call gates don't clear TF and NT in eflags like
@@ -166,8 +166,8 @@ do_lcall:
pushl %eax
popfl
- andl $-8192, %ebx # GET_THREAD_INFO
- movl TI_EXEC_DOMAIN(%ebx), %edx # Get the execution domain
+ andl $-8192, %ebp # GET_THREAD_INFO
+ movl TI_EXEC_DOMAIN(%ebp), %edx # Get the execution domain
call *4(%edx) # Call the lcall7 handler for the domain
addl $4, %esp
popl %eax
@@ -178,8 +178,8 @@ ENTRY(lcall27)
# gates, which has to be cleaned up later..
pushl %eax
SAVE_ALL
- movl %esp, %ebx
- pushl %ebx
+ movl %esp, %ebp
+ pushl %ebp
pushl $0x27
jmp do_lcall
@@ -187,7 +187,7 @@ ENTRY(lcall27)
ENTRY(ret_from_fork)
# NOTE: this function takes a parameter but it's unused on x86.
call schedule_tail
- GET_THREAD_INFO(%ebx)
+ GET_THREAD_INFO(%ebp)
jmp syscall_exit
/*
@@ -202,7 +202,7 @@ ENTRY(ret_from_fork)
ret_from_exception:
preempt_stop
ret_from_intr:
- GET_THREAD_INFO(%ebx)
+ GET_THREAD_INFO(%ebp)
movl EFLAGS(%esp), %eax # mix EFLAGS and CS
movb CS(%esp), %al
testl $(VM_MASK | 3), %eax
@@ -211,7 +211,7 @@ ENTRY(resume_userspace)
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
- movl TI_FLAGS(%ebx), %ecx
+ movl TI_FLAGS(%ebp), %ecx
andl $_TIF_WORK_MASK, %ecx # is there any work to be done on
# int/exception return?
jne work_pending
@@ -219,18 +219,18 @@ ENTRY(resume_userspace)
#ifdef CONFIG_PREEMPT
ENTRY(resume_kernel)
- cmpl $0,TI_PRE_COUNT(%ebx) # non-zero preempt_count ?
+ cmpl $0,TI_PRE_COUNT(%ebp) # non-zero preempt_count ?
jnz restore_all
need_resched:
- movl TI_FLAGS(%ebx), %ecx # need_resched set ?
+ movl TI_FLAGS(%ebp), %ecx # need_resched set ?
testb $_TIF_NEED_RESCHED, %cl
jz restore_all
testl $IF_MASK,EFLAGS(%esp) # interrupts off (execption path) ?
jz restore_all
- movl $PREEMPT_ACTIVE,TI_PRE_COUNT(%ebx)
+ movl $PREEMPT_ACTIVE,TI_PRE_COUNT(%ebp)
sti
call schedule
- movl $0,TI_PRE_COUNT(%ebx)
+ movl $0,TI_PRE_COUNT(%ebp)
cli
jmp need_resched
#endif
@@ -262,21 +262,21 @@ ENTRY(sysenter_entry)
pushl %eax
SAVE_ALL
- GET_THREAD_INFO(%ebx)
+ GET_THREAD_INFO(%ebp)
cmpl $(NR_syscalls), %eax
jae syscall_badsys
- testb $_TIF_SYSCALL_TRACE,TI_FLAGS(%ebx)
+ testb $_TIF_SYSCALL_TRACE,TI_FLAGS(%ebp)
jnz syscall_trace_entry
call *sys_call_table(,%eax,4)
movl %eax,EAX(%esp)
cli
- movl TI_FLAGS(%ebx), %ecx
+ movl TI_FLAGS(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx
jne syscall_exit_work
RESTORE_INT_REGS
@@ -286,11 +286,11 @@ ENTRY(sysenter_entry)
ENTRY(system_call)
pushl %eax # save orig_eax
SAVE_ALL
- GET_THREAD_INFO(%ebx)
+ GET_THREAD_INFO(%ebp)
cmpl $(NR_syscalls), %eax
jae syscall_badsys
# system call tracing in operation
- testb $_TIF_SYSCALL_TRACE,TI_FLAGS(%ebx)
+ testb $_TIF_SYSCALL_TRACE,TI_FLAGS(%ebp)
jnz syscall_trace_entry
syscall_call:
call *sys_call_table(,%eax,4)
@@ -299,7 +299,7 @@ syscall_exit:
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
- movl TI_FLAGS(%ebx), %ecx
+ movl TI_FLAGS(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx # current->work
jne syscall_exit_work
restore_all:
@@ -315,7 +315,7 @@ work_resched:
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
- movl TI_FLAGS(%ebx), %ecx
+ movl TI_FLAGS(%ebp), %ecx
andl $_TIF_WORK_MASK, %ecx # is there any work to be done other
# than syscall tracing?
jz restore_all
@@ -370,7 +370,7 @@ syscall_exit_work:
syscall_fault:
pushl %eax # save orig_eax
SAVE_ALL
- GET_THREAD_INFO(%ebx)
+ GET_THREAD_INFO(%ebp)
movl $-EFAULT,EAX(%esp)
jmp resume_userspace
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Remove all register pops before sysexit
From: Luca Barbieri @ 2003-01-09 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux-Kernel ML
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
This patch, which depends on the previous %ebx -> %ebp patch, removes
all pop instruction in the sysenter return path.
This leaks the thread_info address to user mode but this shouldn't be
a security problem.
This is what happens to the various registers:
%eax: return value from system call: already in place
%ebx, %esi, %edi: saved by the C compiler
%ecx, %edx, %ebp: restored by user mode
%esp, eip: copied to %ecx/%edx and restored by sysexit
%ds, %es: initialized to __USER_DS on kernel entry
%cs, %ss: restored by sysexit based on msr
%fs, %gs: not modified by the kernel (saved around context switch)
eflags: not preserved
FP, XMM: any code that modifies them must save/restore them
Note that while it is possible to change %ebx, %esi, %edi, %ecx, %edx
or %ebp via struct pt_regs, anything that does should set TIF_IRET or
another work flag (and it hopefully already does).
diff --exclude-from=/home/ldb/src/exclude -urNdp linux-2.5.54-preldb/arch/i386/kernel/entry.S linux-2.5.54-ldb/arch/i386/kernel/entry.S
--- linux-2.5.54-preldb/arch/i386/kernel/entry.S 2003-01-06 16:01:40.000000000 +0100
+++ linux-2.5.54-ldb/arch/i386/kernel/entry.S 2003-01-06 04:54:58.000000000 +0100
@@ -276,9 +276,9 @@ ENTRY(sysenter_entry)
movl TI_FLAGS(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx
jne syscall_exit_work
- RESTORE_INT_REGS
- movl 12(%esp),%edx
- movl 24(%esp),%ecx
+/* if something modifies registers it must also disable sysexit */
+ movl EIP(%esp), %edx
+ movl OLDESP(%esp), %ecx
sti
sysexit
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: rotation.
From: James Simmons @ 2003-01-09 19:59 UTC (permalink / raw)
To: Helge Hafting; +Cc: Sven Luther, linux-kernel
In-Reply-To: <3E1D4837.7558538B@aitel.hist.no>
> > So, we also support fbcon for not left to righ locales ?
> This looks like a high-level thing to me.
> Ideally something like ansi escape sequences to switch between
> left-to-right, right-to-left, and up-to-down advancing of
> the cursor. Then the same multilingual apps will work with
> fbdev, xterm, and other terminals and emulators that
> implement those operations.
Yeap. Such things are supported on the console level. ISO6429 support.
^ permalink raw reply
* Re: [Linux-fbdev-devel] rotation.
From: James Simmons @ 2003-01-09 19:54 UTC (permalink / raw)
To: Antonino Daplas
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
Geert Uytterhoeven
In-Reply-To: <1042044916.1003.144.camel@localhost.localdomain>
> However, as Geert mentioned, if you want to support rotation
> generically, then you have to do it in the fbcon level. The driver need
> not know if the display is rotated or not. All it needs to do is fill a
> region with color, color expand a bitmap and move blocks of data, and
> optionally 'pan' the window. Fbcon will pass the correct (ie, oriented)
> information for the driver.
Yes. Hardware rotation shouldn't also not effect the way accel
operatations are done.
> This will not be too processor intensive as long as some data is
> prepared beforehand, like a rotated fontdata.
Yeap!! The only thing is we could end up with 4 times the amount of data.
> The main difficulty with this approach is how do you tell the console to
> rotate the display? We cannot use fbset because the changes will not be
> visible to fbcon.
I think it should video fbcon=rotate:90 command line for example.
> I submitted a patch before (see fbdev archives for "Console Rotation"
> thread) that rotates the console this way. I had vga16fb, vesafb, and
I seen it and even have it still.
^ permalink raw reply
* detecting hyperthreading in linux 2.4.19
From: Jason Lunz @ 2003-01-09 20:02 UTC (permalink / raw)
To: linux-kernel
Is there a way for a userspace program running on linux 2.4.19 to tell
the difference between a single hyperthreaded xeon P4 with HT enabled
and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
for the two cases are indistinguishable.
Jason
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Anders Gustafsson @ 2003-01-09 20:04 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Joshua Kwan, linux-kernel
In-Reply-To: <20030108095253.B23278@ucw.cz>
On Wed, Jan 08, 2003 at 09:52:53AM +0100, Vojtech Pavlik wrote:
>
> That I'd like to know, too. In the worst case, we can make the timeout
> be half a second, or more - it'd just mean that for a resync you would
> have to not touch the mouse this long if really a byte is lost.
Still havn't misbehaved here with the extended timeout. So it seems that it
really helped.
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
^ permalink raw reply
* [PATCH][TRIVIAL] checksum.h header fixes for 2.4
From: Eric Weigle @ 2003-01-09 20:06 UTC (permalink / raw)
To: Marcelo Tosatti, Trivial Patch Monkey; +Cc: Linux kernel mailing list
All-
I'm making a loadable module that will send IP packets; and need to do IP
checksums. Unfortunately a simple #include of checksum.h fails because that
file does not itself include the headers required to compile correctly.
Several of the arch-specific files are this way.
* Some files use VERIFY_READ, VERIFY_WRITE, access_ok from uaccess.h but do
not include uaccess.h
* Some files have an IPv6 checksum with struct in6_addr, but do not include
linux/in6.h. x86_64 just defines the structure instead of including the
file. Either way works, but it's inconsistent. I've moved them all to the
#include, but they could all go to the struct in6_addr way too.
These need both linux/in6.h, and uaccess.h
File name VERIFY_ in6_addr | headers
asm-i386/checksum.h Y Y | -
asm-sh/checksum.h Y Y | config
These need just linux/in6.h
File name VERIFY_ in6_addr | headers
asm-mips/checksum.h N Y | uaccess
asm-mips64/checksum.h N Y | uaccess
asm-alpha/checksum.h N Y | -
asm-arm/checksum.h N Y | -
asm-m68k/checksum.h N Y | -
asm-parisc/checksum.h N Y | -
asm-x86_64/checksum.h N Y | uaccess/compiler/byteorder
The remainder are fine:
File name VERIFY_ in6_addr | headers
asm-sparc/checksum.h Y Y | uaccess/in6/cprefix
asm-sparc64/checksum.h N Y | uaccess/in6
asm-s390/checksum.h N N | uaccess
asm-s390x/checksum.h N N | uaccess
asm-cris/checksum.h N N | -
asm-ia64/checksum.h N N | -
asm-ppc/checksum.h N N | -
asm-ppc64/checksum.h N N | -
--------------------------------------------------------------------------------
--- linux/include/asm-i386/checksum.h.bak 2003-01-09 12:26:05.000000000 -0700
+++ linux/include/asm-i386/checksum.h 2003-01-09 12:52:01.000000000 -0700
@@ -1,6 +1,8 @@
#ifndef _I386_CHECKSUM_H
#define _I386_CHECKSUM_H
+#include <linux/in6.h>
+#include <asm/uaccess.h>
/*
* computes the checksum of a memory block at buff, length len,
--- linux/include/asm-sh/checksum.h.bak 2003-01-09 12:26:11.000000000 -0700
+++ linux/include/asm-sh/checksum.h 2003-01-09 12:52:02.000000000 -0700
@@ -1,6 +1,9 @@
#ifndef __ASM_SH_CHECKSUM_H
#define __ASM_SH_CHECKSUM_H
+#include <linux/in6.h>
+#include <asm/uaccess.h>
+
/*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
--- linux/include/asm-mips/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-mips/checksum.h 2003-01-09 12:52:02.000000000 -0700
@@ -8,6 +8,7 @@
#ifndef _ASM_CHECKSUM_H
#define _ASM_CHECKSUM_H
+#include <linux/in6.h>
#include <asm/uaccess.h>
/*
--- linux/include/asm-mips64/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-mips64/checksum.h 2003-01-09 12:52:02.000000000 -0700
@@ -11,6 +11,7 @@
#ifndef _ASM_CHECKSUM_H
#define _ASM_CHECKSUM_H
+#include <linux/in6.h>
#include <asm/uaccess.h>
/*
--- linux/include/asm-alpha/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-alpha/checksum.h 2003-01-09 12:52:03.000000000 -0700
@@ -1,6 +1,7 @@
#ifndef _ALPHA_CHECKSUM_H
#define _ALPHA_CHECKSUM_H
+#include <linux/in6.h>
/*
* This is a version of ip_compute_csum() optimized for IP headers,
--- linux/include/asm-arm/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-arm/checksum.h 2003-01-09 12:52:03.000000000 -0700
@@ -9,6 +9,8 @@
#ifndef __ASM_ARM_CHECKSUM_H
#define __ASM_ARM_CHECKSUM_H
+#include <linux/in6.h>
+
/*
* computes the checksum of a memory block at buff, length len,
* and adds in "sum" (32-bit)
--- linux/include/asm-m68k/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-m68k/checksum.h 2003-01-09 12:52:03.000000000 -0700
@@ -1,6 +1,8 @@
#ifndef _M68K_CHECKSUM_H
#define _M68K_CHECKSUM_H
+#include <linux/in6.h>
+
/*
* computes the checksum of a memory block at buff, length len,
* and adds in "sum" (32-bit)
--- linux/include/asm-parisc/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ linux/include/asm-parisc/checksum.h 2003-01-09 12:52:04.000000000 -0700
@@ -1,6 +1,8 @@
#ifndef _PARISC_CHECKSUM_H
#define _PARISC_CHECKSUM_H
+#include <linux/in6.h>
+
/*
* computes the checksum of a memory block at buff, length len,
* and adds in "sum" (32-bit)
--- ./linux/include/asm-x86_64/checksum.h.bak 2003-01-09 12:50:34.000000000 -0700
+++ ./linux/include/asm-x86_64/checksum.h 2003-01-09 12:59:58.000000000 -0700
@@ -1,6 +1,8 @@
#ifndef _X86_64_CHECKSUM_H
#define _X86_64_CHECKSUM_H
+#include <linux/in6.h>
+
/*
* Checksums for x86-64
* Copyright 2002 by Andi Kleen, SuSE Labs
@@ -171,9 +173,6 @@
* into UDP/TCP packets and contains some link layer information.
* Returns the unfolded 32bit checksum.
*/
-
-struct in6_addr;
-
#define _HAVE_ARCH_IPV6_CSUM 1
extern unsigned short
csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr,
--------------------------------------------------------------------------------
Marcelo, please apply.
-Eric
--
------------------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Use %ebp rather than %ebx for thread_info pointer
From: Richard B. Johnson @ 2003-01-09 20:09 UTC (permalink / raw)
To: Luca Barbieri; +Cc: Linus Torvalds, Linux-Kernel ML
In-Reply-To: <20030109194935.GA2098@ldb>
On Thu, 9 Jan 2003, Luca Barbieri wrote:
> This patch changes assembly code that accesses thread_info to use %ebp
> rather than %ebx.
>
> This allows me to take advantage of the fact that %ebp is restored by
> user mode in the sysenter register pop removal patch.
If you use EBP as an index register, i.e., "movl (%ebp), %eax", it
will be relative to the SS, not ES or DS. Is this what you want?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: limit rule on sparc-linux
From: Harald Welte @ 2003-01-09 20:00 UTC (permalink / raw)
To: Christian Birchinger; +Cc: netfilter-devel
In-Reply-To: <20030109085840.GA1086@netswarm.net>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Thu, Jan 09, 2003 at 09:58:40AM +0100, Christian Birchinger wrote:
> Hello
> Is there a known patch for the non-working limit rule on
> sparc/linux? The last version Kernel i've tested is 2.4.20
> and it still refuses limit rules.
yes, patch has been posted very recently on this list. However, I'm
still not sure that this is the solution we will finally implement.
btw: please always indicate that you are talking about sparc64 linux.
sparc32 should work straight ahead.
> --
> Christian Birchinger
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* WARNING: unexpected IO-APIC
From: Anderson Oliveira da Silva @ 2003-01-09 20:04 UTC (permalink / raw)
To: linux-smp; +Cc: suporte
Hi,
We are running kernel-smp-2.4.18-19 on a Dual Intel Xeon 2.4GHz for Thunder
i860 - S2603 motherboard. As our system is hanging sometimes, I looked for
some clue in the kerrnel message log. I found the following messages:
Jan 8 13:12:47 exu kernel: ENABLING IO-APIC IRQs
Jan 8 13:12:47 exu kernel: Setting 2 in the phys_id_present_map
Jan 8 13:12:47 exu kernel: ...changing IO-APIC physical APIC ID to 2 ... ok.
Jan 8 13:12:47 exu kernel: Setting 3 in the phys_id_present_map
Jan 8 13:12:47 exu kernel: ...changing IO-APIC physical APIC ID to 3 ... ok.
Jan 8 13:12:47 exu kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Jan 8 13:12:47 exu kernel: testing the IO APIC.......................
Jan 8 13:12:47 exu kernel:
Jan 8 13:12:47 exu kernel: WARNING: unexpected IO-APIC, please mail
Jan 8 13:12:47 exu kernel: to linux-smp@vger.kernel.org
Jan 8 13:12:47 exu kernel:
Jan 8 13:12:47 exu kernel: .................................... done.
Jan 8 13:12:47 exu kernel: Using local APIC timer interrupts.
Jan 8 13:12:47 exu kernel: calibrating APIC timer ...
Jan 8 13:12:47 exu kernel: ..... CPU clock speed is 2393.1518 MHz.
Jan 8 13:12:47 exu kernel: ..... host bus clock speed is 99.1446 MHz.
Can you help us to solve this problem?
Thanks in advance,
Anderson Oliveira da Silva
Computer Science Department
Catholic University - Rio de Janeiro - RJ - Brazil
===================================
Tel: 55-21-3114-1500 ext. 3305
Fax: 55-21-3114-1530
===================================
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Carsten Langgaard @ 2003-01-09 20:10 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Mike Uhler, Maciej W. Rozycki, Dominic Sweetman, linux-mips
In-Reply-To: <20030108204408.A27888@linux-mips.org>
Ralf Baechle wrote:
> On Wed, Jan 08, 2003 at 11:33:01AM -0800, Mike Uhler wrote:
>
> > > They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> > > patch.
> >
> > This is precisely what we use for our internal testing (which is also
> > exported to MIPS32 and MIPS64 architecture licensees) to initialize the
> > TLB. I have not yet seen a case where this fails, and would be interested
> > in hearing about any case where it does fail.
>
> We used to use just KSEG0 instead of KSEG0+entry*0x2000. That was running
> fine over years but had to be changed for the sake of two CPUs afair. There
> was some discussion on this list about this and I accepted the change by that
> time because Kevin imho correctly argued that the spec left it unspecified
> if an implementation is feeding addresses in an unmapped address space
> though the TLB.
>
All MIPS's CPUs need these unique TLB entries otherwise you get a machine check
error.
Inspired by Kevin Kissell's changes to openBSD, I made the above change
(KSEG0+entry*0x2000) to the TLB routine in linux. It was done when we first tried
to boot linux on the MIPS 4Kc CPU, a couple of years ago.
>
> Ralf
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Andrew Morton @ 2003-01-09 20:18 UTC (permalink / raw)
To: Chris Wood, William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <3E1DAEAC.4060904@xmission.com>
Chris Wood wrote:
>
> ..
> The server ran fine for 3 days, so it took a bit to get this info.
Is appreciated, thanks.
> Is there a list of which patches I can apply if I don't want to apply
> the entire 2.4.20aa1? I'm nervous about breaking other things, but may
> give it a try anyway.
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.20aa1/05_vm_16_active_free_zone_bhs-1
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.20aa1/10_inode-highmem-2
The former is the most important and, alas, has dependencies on
earlier patches.
hm, OK. I've pulled all Andrea's VM changes and the inode-highmem fix
into a standalone diff. I'll beat on that a bit tonight before unleashing
it.
> Thanks for the help!
>
> Here is a /proc/meminfo when it is running fine:
These numbers are a little odd. You seem to have only lost 200M of
lowmem to buffer_heads. Bill, what's your take on this?
Maybe we're looking at the wrong thing. Are any of your applications
using mlock(), mlockall(), etc?
^ permalink raw reply
* Re: [PATCH] Use %ebp rather than %ebx for thread_info pointer
From: Linus Torvalds @ 2003-01-09 20:18 UTC (permalink / raw)
To: Luca Barbieri; +Cc: Linux-Kernel ML
In-Reply-To: <20030109194935.GA2098@ldb>
On Thu, 9 Jan 2003, Luca Barbieri wrote:
>
> This patch changes assembly code that accesses thread_info to use %ebp
> rather than %ebx.
>
> This allows me to take advantage of the fact that %ebp is restored by
> user mode in the sysenter register pop removal patch.
Hmm.. Did you check what fork/execve/vm86 do? I know at least the vm86()
stuff sets up %ebx before calling the asm functions in entry.S, I bet
those need to be changed to use %ebp too with something like this.
Linus
^ permalink raw reply
* Re: [PATCH] Use %ebp rather than %ebx for thread_info pointer
From: Linus Torvalds @ 2003-01-09 20:20 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Luca Barbieri, Linux-Kernel ML
In-Reply-To: <Pine.LNX.3.95.1030109150728.27501A-100000@chaos.analogic.com>
On Thu, 9 Jan 2003, Richard B. Johnson wrote:
>
> If you use EBP as an index register, i.e., "movl (%ebp), %eax", it
> will be relative to the SS, not ES or DS. Is this what you want?
That's fine, both SS and DS are 32-bit flat segments everywhere in the
kernel (they have different descriptors - __KERNEL_DS vs __USER_DS, but
they do the same thing)
Linus
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: jlnance @ 2003-01-09 20:21 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030109194019.GH26010@boardwalk>
On Thu, Jan 09, 2003 at 12:40:19PM -0700, Val Henson wrote:
> P.S. For extra credit (but no ThinkGeek certificate) you can look up
> the following women in computer science, some of whom are mothers:
> Mary Baker, Margo Seltzer, Monica Lam, Ellen Spertus, Carla Ellis, and
> Barbara Simons.
Am I the first person to tell you you left off Ada Lovelace? She was
way ahead of her time.
Thanks,
Jim
^ permalink raw reply
* Re: [BK PATCH] USB changes for 2.5.55
From: Linus Torvalds @ 2003-01-09 20:21 UTC (permalink / raw)
To: Greg KH; +Cc: Kernel Mailing List, linux-usb-devel
In-Reply-To: <20030109191756.GF12325@kroah.com>
On Thu, 9 Jan 2003, Greg KH wrote:
> Hm, looks like you didn't get the USB changes I sent :)
I did, but they got applied after 2.5.55 was released (they're part of the
current BK tree).
Linus
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Adam Belay @ 2003-01-09 15:26 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: greg, linux-kernel
In-Reply-To: <59522031471.20030109183512@wr.miee.ru>
On Thu, Jan 09, 2003 at 06:35:12PM +0300, Ruslan U. Zakirov wrote:
> 1) As I've understood we need to free all reserved resources when
> remove function called, am I right?
Yes, all resources must be freed or the device will not work if it is
attached to the driver a second time. This is becuase the driver will
think the device is busy when actually the resources were just never
freed from the previous session. Also the resources must be freed to
safetly disable the device.
> 2) Who decide card is accessible at some time or not?
This is determined by both the pnp layer and the driver model. Becuase a
card is a group of devices the individual devices must also not be matched
to more than one driver. PnP Card Services have a few bugs in this area,
all of which have been resolved in the patch I released last week. Greg,
could you please forward that to Linus.
> 3) And the last, where is the place of ISA not PnP cards in the device
> lists? As I think, they are fit with PnP bus, but their resources
> static(not configurable) or it's just lays under ALSA, apears in
> /proc/asound only and ALSA internals?
Currently the pnp layer does not support legacy non PnP devices. I plan
to add support for them soon. This support should achieve two objectives.
1.) Reserve resources used by the legacy devices
a.) if the resources match an existing pnp devices, bind to that
device
b.) if they conflict but do not match exactly return an error
c.) otherwise reserve the resources and prevent pnp devices from
using them.
2.) Represent these legacy devices in sysfs. Maybe the current legacy dir
could be used or I may have to create "pnp_legacy". Needs more research.
Regards,
Adam
^ permalink raw reply
* Re: [Linux-ia64] Re: disabling nics using boot options.
From: Roy Dragseth @ 2003-01-09 20:16 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805657@msgid-missing>
On Thursday 09 January 2003 18:01, Bill Nottingham wrote:
> So, it works post-install, but not in the installer? Hm. The dhcp client
> code is different in the two cases, but not in a way that should
> significantly affect this case.
Well, it doesn't work during a normal bootup either. If I remove the cached
info in /etc/dhcpc/ and reboots, the network initialization fails:
Setting network parameters: [ OK ]
Bringing up interface lo: [ OK ]
Bringing up interface eth2: dhcpcd[536]: timed out waiting for a valid DHCP
server response
Determining IP information for eth2... failed.
[FAILED]
If I log in and run /etc/init.d/network start everything works ok:
root@compute-1-1 root]# /etc/init.d/network start
Setting network parameters: [ OK ]
Bringing up interface lo: [ OK ]
Bringing up interface eth2: [ OK ]
I cannot see what it is different when init starts the network from when root
is doing it.
r.
--
The Computer Center, University of Tromsø, N-9037 TROMSØ, Norway.
phone:+47 77 64 41 07, fax:+47 77 64 41 00
Roy Dragseth, High Performance Computing System Administrator
Direct call: +47 77 64 62 56. email: royd@cc.uit.no
^ permalink raw reply
* Re: [Linux-fbdev-devel] Radeonfb in 2.5.54bk (now 2.5.55)
From: Joshua Kwan @ 2003-01-09 20:19 UTC (permalink / raw)
To: James Simmons; +Cc: linux-fbdev-devel, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301091816340.5660-100000@phoenix.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
Same problem. 2.5.55bk with pulled fbdev-2.5 and -dj
Regards
Josh
Rabid cheeseburgers forced James Simmons <jsimmons@infradead.org> to
write this on Thu, 9 Jan 2003 18:17:08 +0000 (GMT):
>
> > Latest patch? If it's the one you pushed to BK a day or two ago,
> > that is what I used in the compilation of my kernel. Hence it
> > doesn't quite work.
> >
> > (to be precise, i issued:
> > bk clone http://linux.bkbits.net:8080/linux-2.5
> > bk -r get
> > bk pull http://fbdev.bkbits.net:8080/fbdev-2.5)
> >
> > Anything wrong there? Do I have to bk -r get again?
> >
> > Looks like I am subscribing to this list then. Sigh... too many
> > lists to take care of!! :(
>
> More changes happened. Can you try another pull.
>
>
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Valdis.Kletnieks @ 2003-01-09 20:30 UTC (permalink / raw)
To: jlnance; +Cc: linux-kernel
In-Reply-To: <20030109202144.GA6434@ncsu.edu>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Thu, 09 Jan 2003 15:21:44 EST, jlnance@unity.ncsu.edu said:
> On Thu, Jan 09, 2003 at 12:40:19PM -0700, Val Henson wrote:
>
> > P.S. For extra credit (but no ThinkGeek certificate) you can look up
> > the following women in computer science, some of whom are mothers:
> > Mary Baker, Margo Seltzer, Monica Lam, Ellen Spertus, Carla Ellis, and
> > Barbara Simons.
>
> Am I the first person to tell you you left off Ada Lovelace? She was
> way ahead of her time.
I think Ada Lovelace and Grace Hopper were left off as "too easy"....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.