Re: [PATCH] be more verbose in gen-devlist

2005-03-13 Thread Olaf Hering
 On Sat, Mar 12, Greg KH wrote:

 Why #if this?  Why not just always do this?

Because it always triggers with current sf.net snapshot.
-
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-13 Thread Arjan van de Ven
On Sat, 2005-03-12 at 21:59 -0800, Andrew Morton wrote:
 Dave Jones [EMAIL PROTECTED] wrote:
 
  The nvidia framebuffer code added recently is marked as
   MODULE_LICENSE(GPL), but some things seem a little odd to me..
  
   1. The boilerplate at the top of drivers/video/nvidia/nv_dma.h,
  drivers/video/nvidia/nv_local.h, and drivers/video/nvidia/nv_hw.c
  doesn't seem to be a GPL-compatible license. It seems to be an nvidia
  specific license with an advertising clause, and something that
  adds restrictions on rights of U.S. Govt end users.
  
   2. Some of these files clearly came from XFree86 judging from
  the CVS idents in the source.  Was this XFree86 code
  dual-licensed by its original authors ? If so, it isn't clear.
 
 Does
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm3/broken-out/fbdev-nvidia-licensing-clarification.patch
 
 clear things up?

somewhat; it would even make sense to consider dual licensing that thing
(like most other not-originally-gpl code in the kernel) to clarify the
legal status for real. Otherwise if you merge it with GPL it sort of
becomes GPL only.. (due to the freedom of MIT and the viral nature of
GPL) and I suspect the intention of the author was to keep allowing MIT
use...

-
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] break_lock forever broken

2005-03-13 Thread Arjan van de Ven
   \
 + if ((lock)-break_lock) \
 + (lock)-break_lock = 0; \
  }\
if it really worth an conditional there? the cacheline of the lock is
made dirty anyway on unlock, so writing an extra 0 is like almost free
(maybe half a cycle) while a conditional jump can be 100+


-
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: More trouble with i386 EFLAGS and ptrace

2005-03-13 Thread Roland McGrath
This patch further cleans up the appearance of TF in eflags when ptrace is
involved.  With this, PTRACE_SINGLESTEP will not cause TF to appear in
eflags as seen by PTRACE_GETREGS and the like, when the instruction faulted
for some reason other than the single-step trap.

This moves the check added by Dan's patch from setup_sigcontext to
handle_signal.  This is a cosmetic difference, but I think it makes more
sense to consolidate all the reset registers to canonical state work in
the same place (i.e. put it with the syscall rollback code), separate from
the signal handler setup.  The change that matters is moving the similar
check out of do_debug, where it only covers the case of a single-step trap.
Instead, it goes into the ptrace_signal_deliver macro, which is called
before the ptrace stop for whatever signal results from whatever kind of
fault in that instruction (or asynchronous signal).  With that, the
handle_signal check is still needed only for the case of PTRACE_SINGLESTEP
with a handled signal.


Thanks,
Roland


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

--- linux-2.6/arch/i386/kernel/signal.c
+++ linux-2.6/arch/i386/kernel/signal.c
@@ -277,18 +277,6 @@ setup_sigcontext(struct sigcontext __use
 {
int tmp, err = 0;
 
-   /*
-* If TF is set due to a debugger (PT_DTRACE), clear the TF
-* flag so that register information in the sigcontext is
-* correct.
-*/
-   if (unlikely(regs-eflags  TF_MASK)) {
-   if (likely(current-ptrace  PT_DTRACE)) {
-   current-ptrace = ~PT_DTRACE;
-   regs-eflags = ~TF_MASK;
-   }
-   }
-
tmp = 0;
__asm__(movl %%gs,%0 : =r(tmp): 0(tmp));
err |= __put_user(tmp, (unsigned int __user *)sc-gs);
@@ -569,6 +557,16 @@ handle_signal(unsigned long sig, siginfo
}
}
 
+   /*
+* If TF is set due to a debugger (PT_DTRACE), clear the TF flag so
+* that register information in the sigcontext is correct.
+*/
+   if (unlikely(regs-eflags  TF_MASK)
+likely(current-ptrace  PT_DTRACE)) {
+   current-ptrace = ~PT_DTRACE;
+   regs-eflags = ~TF_MASK;
+   }
+
/* Set up the stack frame */
if (ka-sa.sa_flags  SA_SIGINFO)
setup_rt_frame(sig, ka, info, oldset, regs);
--- linux-2.6/arch/i386/kernel/traps.c
+++ linux-2.6/arch/i386/kernel/traps.c
@@ -707,8 +707,6 @@ fastcall void do_debug(struct pt_regs * 
/*
 * Single-stepping through TF: make sure we ignore any events in
 * kernel space (but re-enable TF when returning to user mode).
-* And if the event was due to a debugger (PT_DTRACE), clear the
-* TF flag so that register information is correct.
 */
if (condition  DR_STEP) {
/*
@@ -718,11 +716,6 @@ fastcall void do_debug(struct pt_regs * 
 */
if ((regs-xcs  3) == 0)
goto clear_TF_reenable;
-
-   if (likely(tsk-ptrace  PT_DTRACE)) {
-   tsk-ptrace = ~PT_DTRACE;
-   regs-eflags = ~TF_MASK;
-   }
}
 
/* Ok, finally something we can handle */
--- linux-2.6/include/asm-i386/signal.h
+++ linux-2.6/include/asm-i386/signal.h
@@ -223,7 +223,14 @@ static __inline__ int sigfindinword(unsi
 
 struct pt_regs;
 extern int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
-#define ptrace_signal_deliver(regs, cookie) do { } while (0)
+
+#define ptrace_signal_deliver(regs, cookie)\
+   do {\
+   if (current-ptrace  PT_DTRACE) {  \
+   current-ptrace = ~PT_DTRACE;  \
+   (regs)-eflags = ~TF_MASK; \
+   }   \
+   } while (0)
 
 #endif /* __KERNEL__ */
 
-
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] be more verbose in gen-devlist

2005-03-13 Thread Greg KH
On Sun, Mar 13, 2005 at 09:17:09AM +0100, Olaf Hering wrote:
  On Sat, Mar 12, Greg KH wrote:
 
  Why #if this?  Why not just always do this?
 
 Because it always triggers with current sf.net snapshot.

Someone said they were going to submit those shorter strings that the
kernel has, back to sf.net.  Guess that didn't happen yet, and is the
main reason I can't just sync up all the time with that repository.

Oh well, we'll be dropping support for the pci.ids file by the end of
the year or so, so it's not that big of a deal.

thanks,

greg k-h
-
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] be more verbose in gen-devlist

2005-03-13 Thread Olaf Hering
 On Sun, Mar 13, Greg KH wrote:

 On Sun, Mar 13, 2005 at 09:17:09AM +0100, Olaf Hering wrote:
   On Sat, Mar 12, Greg KH wrote:
  
   Why #if this?  Why not just always do this?
  
  Because it always triggers with current sf.net snapshot.
 
 Someone said they were going to submit those shorter strings that the
 kernel has, back to sf.net.  Guess that didn't happen yet, and is the
 main reason I can't just sync up all the time with that repository.

I did update the database a few days ago.
-
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: inconsistent kallsyms data [2.6.11-mm2]

2005-03-13 Thread Sam Ravnborg
On Thu, Mar 10, 2005 at 12:12:22PM +, Paulo Marques wrote:
 Paulo Marques wrote:
 [...]
 A simple and robust way is to do the sampling on a list of symbols 
 sorted by symbol name. This way, even if the symbol positions that are 
 given to scripts/kallsyms change, the symbols sampled will be the same.
 
 I'll do the patch to do this and send it ASAP.
 
 Ok, here it is.
 
 Dominik can you try the attached patch and see if it solves the problem?
Hi Paulo.

Alexander Stohr had similar problems with down and __sched_text_start.

I figured out that what was causing the troubles was the fact that the
linker generated symbol __sched_text_start changed value from pass 1 to
pass 2. The reason for this was the alingment used within that section.

My stamp on this is attached.

I never came around submitting this since I do not know what the correct
number for function alignment is on different paltforms.

Sam


= include/asm-generic/vmlinux.lds.h 1.16 vs edited =
--- 1.16/include/asm-generic/vmlinux.lds.h  2004-10-06 18:45:06 +02:00
+++ edited/include/asm-generic/vmlinux.lds.h2004-11-06 21:56:11 +01:00
@@ -6,6 +6,11 @@
 #define VMLINUX_SYMBOL(_sym_) _sym_
 #endif
 
+/* Aling functions to a 8 byte boundary.
+ * This prevents lables defined to mark start/end of section to differ
+ * during pass 1 and pass 2 when generating System.map */
+#define ALIGN_FUNCTION()  . = ALIGN(8)
+
 #define RODATA \
.rodata   : AT(ADDR(.rodata) - LOAD_OFFSET) {   \
*(.rodata) *(.rodata.*) \
@@ -77,11 +82,13 @@
}
 
 #define SCHED_TEXT \
+   ALIGN_FUNCTION();   \
VMLINUX_SYMBOL(__sched_text_start) = .; \
*(.sched.text)  \
VMLINUX_SYMBOL(__sched_text_end) = .;
 
 #define LOCK_TEXT  \
+   ALIGN_FUNCTION();   \
VMLINUX_SYMBOL(__lock_text_start) = .;  \
*(.spinlock.text)   \
VMLINUX_SYMBOL(__lock_text_end) = .;

-
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] Fix scripts/mkuboot.sh to return status

2005-03-13 Thread Sam Ravnborg
On Thu, Mar 03, 2005 at 04:16:41PM -0500, George G. Davis wrote:
 Sam,
 
 If `mkimage` is either not found in search path or returns non-zero status,
 `make uImage` succeeds when it should fail. This changes scripts/mkuboot.sh
 to return status so build succeeds or fails as appropriate.


As per mail from Tom Roni I dropped this patch.

Sam
-
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: Strange Linking Problem

2005-03-13 Thread Matthias-Christian Ott
linux-os wrote:
On Sat, 12 Mar 2005, Matthias-Christian Ott wrote:
Hi!
I hope I'm right here. I've the following assembler code:
SECTION .DATA
  hello: db 'Hello world!',10
  helloLen:  equ $-hello
SECTION .TEXT
  GLOBAL main
main:

  ; Write 'Hello world!' to the screen
  mov eax,4; 'write' system call
  mov ebx,1; file descriptor 1 = screen
  mov ecx,hello; string to write
  mov edx,helloLen ; length of string to write
  int 80h  ; call the kernel
  ; Terminate program
  mov eax,1; 'exit' system call
  mov ebx,0; exit with error code 0
  int 80h  ; call the kernel
Then I run:
nasm -f elf hello.asm
I link it with ld and run it:
ld -s -o hello hello.o
./hello
segmentation fault
I link it with the gcc and run it:
gcc hello.o -o hello
./hello
Hello world!
What's wrong with the ld?
Nothing at all. Where is _start: ?
Remove the 'main' label and substitute _start:
It is 'C' convention that programs start with main(). They
really don't. With the Linux API, they start at _start: and
do some housekeeping before calling main. That's what the
crt.o file that the 'C' tool-chain uses, does.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
Ofcourse you have to edit it, but this is not the problem (the linker 
will give an error message if you don't change it). Why does it cause a 
segementation fault?

Matthias-Christian Ott
-
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] break_lock forever broken

2005-03-13 Thread Hugh Dickins
On Sun, 13 Mar 2005, Arjan van de Ven wrote:
  \
  +   if ((lock)-break_lock) \
  +   (lock)-break_lock = 0; \
   }  \
 if it really worth an conditional there? the cacheline of the lock is
 made dirty anyway on unlock, so writing an extra 0 is like almost free
 (maybe half a cycle) while a conditional jump can be 100+

I wondered the same, I don't know and would defer to those who do:
really I was just following the style of where break_lock is set above,
which follows soon (unless preempted) after a _raw_whatever_trylock.

Hugh
-
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] x86-64 kprobes: handle %RIP-relative addressing mode

2005-03-13 Thread Roland McGrath
The existing x86-64 kprobes implementation doesn't cope with the
%RIP-relative addressing mode.  Kprobes work by single-stepping a copy of
an instruction overwritten by a breakpoint.  When a probe is inserted on an
instruction that uses the %RIP-relative data addressing mode, the copy run
in a different location gets different data and so the presence of that
probe causes the probed code to read or write the wrong memory location.
Without this problem fixed, it is woefully unsafe to use the current
kprobes code on x86-64 unless you are sure the instruction you instrument
is not one that accesses global data using the %RIP addressing mode.

This patch fixes the problem by recognizing the %RIP-relative addressing
mode in an instruction when it's being copied to insert the kprobe, and
adjusting its displacement so that it finds the right data.  Taking this
approach requires that the copied instruction's %RIP value be within 2GB of
the virtual address of the data, i.e. the text/data areas of the kernel
code and loaded modules.  To satisfy this need the patch also replaces the
use of vmalloc for getting instruction pages with lower-level calls to use
a different part of the address space, the area at the top of the address
space just above where modules are loaded.  I left one page of red zone at
the top, and the 1MB-4KB thus available allows for at most 69632 kprobes.
(If we ever need to overcome that limit, we can change this to add a hook
into the arch/x86_64/kernel/modules.c code and allocate pages inside the
module area loading area instead.)


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
@@ -86,9 +88,124 @@ 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)
+{
+   static const unsigned char onebyte_has_modrm[256] = {
+   /*   0 1 2 3 4 5 6 7 8 9 a b c d e f*/
+   /*   ---*/
+   /* 00 */ 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0, /* 00 */
+   /* 10 */ 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0, /* 10 */
+   /* 20 */ 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0, /* 20 */
+   /* 30 */ 1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0, /* 30 */
+   /* 40 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 40 */
+   /* 50 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 50 */
+   /* 60 */ 0,0,1,1,0,0,0,0,0,1,0,1,0,0,0,0, /* 60 */
+   /* 70 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 70 */
+   /* 80 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* 80 */
+   /* 90 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 90 */
+   /* a0 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* a0 */
+   /* b0 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* b0 */
+   /* c0 */ 1,1,0,0,1,1,1,1,0,0,0,0,0,0,0,0, /* c0 */
+   /* d0 */ 1,1,1,1,0,0,0,0,1,1,1,1,1,1,1,1, /* d0 */
+   /* e0 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* e0 */
+   /* f0 */ 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 unsigned char twobyte_has_modrm[256] = {
+   /*   0 1 2 3 4 5 6 7 8 9 a b c d e f*/
+   /*   ---*/
+   /* 00 */ 1,1,1,1,0,0,0,0,0,0,0,0,0,1,0,1, /* 0f */
+   /* 10 */ 1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0, /* 1f */
+   /* 20 */ 1,1,1,1,1,0,1,0,1,1,1,1,1,1,1,1, /* 2f */
+   /* 30 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 3f */
+   /* 40 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* 4f */
+   /* 50 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* 5f */
+   /* 60 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* 6f */
+   /* 70 */ 1,1,1,1,1,1,1,0,0,0,0,0,1,1,1,1, /* 7f */
+   /* 80 */ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* 8f */
+   /* 90 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* 9f */
+   /* a0 */ 0,0,0,1,1,1,1,1,0,0,0,1,1,1,1,1, /* af */
+   /* b0 */ 1,1,1,1,1,1,1,1,0,0,1,1,1,1,1,1, /* bf */
+   /* c0 */ 1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0, /* cf */
+   /* d0 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* df */
+   /* e0 */ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* ef */
+

Re: ancient portmap segfault

2005-03-13 Thread Andi Kleen
Mark Studebaker [EMAIL PROTECTED] writes:

 I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap 
 from 1994 that's been running without complaint
 on kernels for 11 years now consistently segfaults.

 I upgraded to a version 4 RPM (circa 2002) and that fixed it.

 If some compatibility was broken on purpose, that's fine, although I couldn't 
 find anything in the kernel docs.
 I know, I should upgrade everything, but that can break a lot of things too...
 Thought I'd mention it though in case it's a bug or somebody else has the 
 same problem.

It's probably a bug, but your bug report doesn't have enough details
to track it down. Do you have a a.out strace and could send an strace log
with the segfault and the last tens of system calls before it?

-Andi
-
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: RFD: Kernel release numbering

2005-03-13 Thread Jan Rychter
 Andrew == Andrew Morton [EMAIL PROTECTED] writes:
 Andrew Linus Torvalds [EMAIL PROTECTED] wrote:
 
  Now, I haven't actually gotten any complaints about 2.6.11 (apart
  from gcc4 still has problems with fairly trivial solutions)

 Andrew There have been quite a few.  Mainly driver stuff again:
[...]
 Andrew The biggest problem is the new ACPI-based i8042 probing on
 Andrew Dells.  I'm kicking myself over that because we *knew* the damn
 Andrew thing was busted, and people kept on having to add
 Andrew i8042.noacpi=1.  We now have a three-line
 Andrew work-around-it-until-we-fix-it-for-real patch.

FWIW, this minor regression also occurs on other laptops, such as my
Sharp Mebius.

--J.

-
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/


ide0=ata66 doesn't seem obsolete

2005-03-13 Thread David Liontooth
On my laptop, idebus=66 or nothing gets me this:
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=65535/16/63, UDMA(33)
In contrast, ide0=ata66 gets me this (never mind the geometry):
ide_setup: ide0=ata66 -- OBSOLETE OPTION, WILL BE REMOVED SOON!
hda: 78140160 sectors (40007 MB) w/1768KiB Cache, CHS=4864/255/63, UDMA(100)
What's not to like?
# uname -r
2.6.11.2
# lspci
:00:00.0 Host bridge: ALi Corporation M1671 Super P4 Northbridge 
[AGP4X,PCI and SDR/DDR] (rev 02)
:00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller
:00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge 
[Aladdin IV]
:00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
:00:11.0 Bridge: ALi Corporation M7101 PMU

Cheers,
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: script to send changesets per mail

2005-03-13 Thread Sam Ravnborg
On Thu, Mar 03, 2005 at 11:59:50AM +0100, Martin Waitz wrote:
 hoi :)
 
 I just tested my little script that can send changesets per mail.
 okok, it still had a bug when I first tested it but that should be
 fixed now.

Greg has a similar script - could you take a look and tell
which is the better (and why). We only want one in the kernel.

It is attached.

Sam

send_lots_of_emails.pl:

#!/usr/bin/perl -w

# horrible hack of a script to send off a large number of email messages, one 
after
# each other, all chained together.  This is useful for large numbers of 
patches.
#
# Use at your own risk
#
# greg kroah-hartman Jan 8, 2002
# [EMAIL PROTECTED]a
# 
# updated to give a valid subject and CC the owner of the patch - Jan 2005
# 

# change this to your email address.
$from = SOMEONE [EMAIL PROTECTED];

# modify these options each time you run the script
$to = 'linux-kernel@vger.kernel.org';
$initial_reply_to = '[EMAIL PROTECTED]';
$initial_subject = [PATCH] XXX fixes for 2.6.11-rc3;
@files = (
rev-1.2041.patch,
rev-1.2042.patch,
rev-1.2043.patch,
rev-1.2044.patch,
rev-1.2045.patch,
rev-1.2046.patch,
);

use Mail::Sendmail;


# we make a fake message id by taking the current number
# of seconds since the beginning of Unix time and tacking on
# a random number to the end, in case we are called quicker than
# 1 second since the last time we were called.
sub make_message_id
{
my $date = `date +\%s`;
chomp($date);
my $pseudo_rand = int (rand(4200));
$message_id = [EMAIL PROTECTED];
print new message id = $message_id\n;
}



$cc = ;

sub send_message
{
%mail = (   To  =  $to,
From=  $from,
CC  =  $cc,
Subject =  $subject,
Message =  $message,
'Reply-to'  =  Greg K-H [EMAIL PROTECTED],
'In-Reply-To'   =  $reply_to,
'Message-ID'=  $message_id,
'X-Mailer'  =  gregkh_patchbomb,
);

$mail{smtp} = 'localhost';

sendmail(%mail) or die $Mail::Sendmail::error;

print OK. Log says:\n, $Mail::Sendmail::log;
print \n\n
}


$reply_to = $initial_reply_to;
make_message_id();
$subject = $initial_subject;

foreach $t (@files) {
$F = $t;
open F or die can't open file $t;

# first line is the CC: list
$cc = F;
print cc: $cc;

# second line is the Subject:
$subject = F;
print subject: $subject;

undef $/;
$message = F; # slurp the whole file in
close F;
$/ = \n;
send_message();

# set up for the next message
$reply_to = $message_id;
make_message_id();
#   $subject = Re: .$initial_subject;
}

-
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: [CHECKER] crash + fsck cause file systems to contain loops (msdos and vfat, 2.6.11)

2005-03-13 Thread OGAWA Hirofumi
Junfeng Yang [EMAIL PROTECTED] writes:

 I'm using dosfsck 2.10, 22 Sep 2003, FAT32, LFN, and yes,
 I do see root directory after I run dosfsck on the crashed disk
 image.

You can download fixed version of dosfsck at

  http://user.parknet.co.jp/hirofumi/tmp/fatfsprogs.tar.bz2

(vanilla dosfsck-2.10 doesn't fix this corruption.)

 I'm checking 2.6.11.  By your testing tree didn't have my
 patches yet, you mean you have the patch but haven't made it
 public?

No. My patches was merged to linus tree at 2 or 3 days ago (merged
after 2.6.11 release).  So, I guessed your tree didn't have my patches
yet.

 This testing tree is the Linux source tree? 

Yes.

Thanks.
-- 
OGAWA Hirofumi [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][2.6.11-mm3] perfctr ia32 syscalls on x86-64 fix

2005-03-13 Thread Mikael Pettersson
On Sat, 12 Mar 2005 21:55:49 -0800, Andrew Morton wrote:
It would be nice to start folding these patches together a bit to reduce
such problems, but that's rather non-trivial because there is no way to
simply join these patches together which maintains a sensible sequencing.

If we're going to do anything then it's either a major refactoring, or
simply wham the entire feature into a single diff.  That diff could then be
split into four patches: core, ppc, x86 and x86_64.  We would lose the
layering between ye olde perfctr, the inheritance implementation, the syfs
API, etc.  I could live with that.

What do you think?

At my end there is already just the current version
(with history in cvs) so merging is fine with me.

/Mikael
-
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: indirect lcall without `*'

2005-03-13 Thread Mikael Pettersson
On Sun, 13 Mar 2005 00:46:24 -0500, Hacksaw [EMAIL PROTECTED] wrote:
In compiling 2.4.29 I get this during the compilation of pci-pc.c:

Warning: indirect lcall without `*'

I note from looking around the net that this is an old problem, dating back 
at least to 2.4.18, if not earlier.

What does it mean? Should I care? If I shouldn't, shouldn't there be a message 
somewhere in the build process that says This isn't a problem so people 
don't write to lkml and ask about it?

It's a binutils version issue. Older binutils didn't
require the '*', while newer ones print a warning when
it's missing. Adding the missing '*'s breaks old binutils,
which isn't considered acceptable in the stable 2.4 series.

So just live with the warnings, or apply personal patches
to silence them (like I've been doing for ages).

/Mikael
-
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: machine check on sleep, PowerBook5.4

2005-03-13 Thread Sean Neakums
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: machine check, sig: 7 [#1]
TASK = etc. 'pmud' etc.
(for registers and such, see:
 http://flynn.zork.net/~sneakums/pmac-machine-check-on-sleep-2611mm3.jpeg )
Call trace:
 pmac_ide_pci_suspend
 pci_device_suspend
 suspend_device
 device_suspend
 0xc03dd894
 0xc03dddb8
 0xc03de7cc
 do_ioctl
 vfs_ioctl
 sys_ioctl
 ret_from_syscall


-- 
Dag vijandelijk luchtschip de huismeester is dood
-
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-13 Thread Oleg Nesterov
I suspect that del_timer_sync() in its current form is racy.

CPU 0   CPU 1

__run_timers() sets timer-base = NULL

del_timer_sync() starts, calls 
del_timer(), it returns
because timer-base == NULL.

waits until the run is complete:
while 
(base-running_timer == timer)

preempt_check_resched();

calls schedule(), or long 
interrupt happens.

timer reschedules itself, __run_timers()
exits.

base-running_timer == NULL, 
end of loop.

next timer interrupt, __run_timers() picks
this timer again, sets timer-base = NULL

if (timer_pending(timer))   
// no, timer-base == NULL
goto del_again; 
// not taken

del_timer_sync() returns

timer runs.

No?

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: [CHECKER] sync doesn't flush everything out (msdos and vfat, 2.6.11)

2005-03-13 Thread OGAWA Hirofumi
Junfeng Yang [EMAIL PROTECTED] writes:

 /å004  and
 /0005
   share clusters.
   Truncating second to 0 bytes.
 /0005
   File size is 4 bytes, cluster chain length is 0 bytes.
   Truncating file to 0 bytes.
 Performing changes.
 /dev/sbd0: 5 files, 4/8167 clusters

 This causes file /0005 to be truncated to 0.

The 0004 seems to be already deleted directory actually, because first
char is 0xE5 (0xE5 is deleted mark).

Please download fixed dosfsck
   http://user.parknet.co.jp/hirofumi/tmp/fatfsprogs.tar.bz2
-- 
OGAWA Hirofumi [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: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 12:01 +, Sean Neakums wrote:
 Machine check in kernel mode.
 Caused by (from SRR1=149030): Transfer error ack signal
 Oops: machine check, sig: 7 [#1]
 TASK = etc. 'pmud' etc.
 (for registers and such, see:
  http://flynn.zork.net/~sneakums/pmac-machine-check-on-sleep-2611mm3.jpeg )
 Call trace:
  pmac_ide_pci_suspend
  pci_device_suspend
  suspend_device
  device_suspend
  0xc03dd894
  0xc03dddb8
  0xc03de7cc
  do_ioctl
  vfs_ioctl
  sys_ioctl
  ret_from_syscall

Thanks, I'll investigate.

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: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 12:01 +, Sean Neakums wrote:
 Machine check in kernel mode.
 Caused by (from SRR1=149030): Transfer error ack signal
 Oops: machine check, sig: 7 [#1]
 TASK = etc. 'pmud' etc.
 (for registers and such, see:
  http://flynn.zork.net/~sneakums/pmac-machine-check-on-sleep-2611mm3.jpeg )
 Call trace:
  pmac_ide_pci_suspend
  pci_device_suspend
  suspend_device
  device_suspend
  0xc03dd894
  0xc03dddb8
  0xc03de7cc
  do_ioctl
  vfs_ioctl
  sys_ioctl
  ret_from_syscall

Does that fix it ?

Index: linux-work/drivers/ide/ppc/pmac.c
===
--- linux-work.orig/drivers/ide/ppc/pmac.c  2005-03-13 10:10:58.0 
+1100
+++ linux-work/drivers/ide/ppc/pmac.c   2005-03-13 23:29:40.0 +1100
@@ -1208,16 +1208,17 @@
if (pmif-mediabay)
return 0;

-   /* Disable the bus */
-   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id, 
0);
-
-   /* Kauai has it different */
+   /* Kauai has bus control FCRs directly here */
if (pmif-kauai_fcr) {
u32 fcr = readl(pmif-kauai_fcr);
fcr = ~(KAUAI_FCR_UATA_RESET_N | KAUAI_FCR_UATA_ENABLE);
writel(fcr, pmif-kauai_fcr);
}
 
+   /* Disable the bus on older machines and the cell on kauai */
+   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id,
+   0);
+
return 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: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 23:30 +1100, Benjamin Herrenschmidt wrote:
 On Sun, 2005-03-13 at 12:01 +, Sean Neakums wrote:
  Machine check in kernel mode.
  Caused by (from SRR1=149030): Transfer error ack signal
  Oops: machine check, sig: 7 [#1]
  TASK = etc. 'pmud' etc.
  (for registers and such, see:
   http://flynn.zork.net/~sneakums/pmac-machine-check-on-sleep-2611mm3.jpeg )
  Call trace:
   pmac_ide_pci_suspend
   pci_device_suspend
   suspend_device
   device_suspend
   0xc03dd894
   0xc03dddb8
   0xc03de7cc
   do_ioctl
   vfs_ioctl
   sys_ioctl
   ret_from_syscall
 
 Does that fix it ?

Oh, and eventually this one too. Closer to what darwin does: doesn't
disable the ATA/100 cell during sleep. Let me know with both of the
patches. Best would even be if you could figure out which one gives the
best power consumption during sleep in fact (if it makes any noticeable
difference).

Index: linux-work/drivers/ide/ppc/pmac.c
===
--- linux-work.orig/drivers/ide/ppc/pmac.c  2005-03-13 10:10:58.0 
+1100
+++ linux-work/drivers/ide/ppc/pmac.c   2005-03-13 23:29:40.0 +1100
@@ -1208,16 +1208,17 @@
if (pmif-mediabay)
return 0;

-   /* Disable the bus */
-   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id, 
0);
-
-   /* Kauai has it different */
+   /* Kauai has bus control FCRs directly here */
if (pmif-kauai_fcr) {
u32 fcr = readl(pmif-kauai_fcr);
fcr = ~(KAUAI_FCR_UATA_RESET_N | KAUAI_FCR_UATA_ENABLE);
writel(fcr, pmif-kauai_fcr);
}
 
+   /* Disable the bus on older machines and the cell on kauai */
+   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id,
+   0);
+
return 0;
 }
 
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c   2005-03-13 
18:23:11.0 +1100
+++ linux-work/arch/ppc/platforms/pmac_feature.c2005-03-13 
23:34:18.0 +1100
@@ -830,6 +830,7 @@
return 0;
 }
 
+#if 0
 static long __pmac
 core99_ata100_enable(struct device_node* node, long value)
 {
@@ -859,6 +860,7 @@
}
return 0;
 }
+#endif
 
 static long __pmac
 core99_ide_enable(struct device_node* node, long param, long value)
@@ -876,8 +878,10 @@
case 2:
return simple_feature_tweak(node, macio_unknown,
KEYLARGO_FCR1, KL1_UIDE_ENABLE, value);
+#if 0
case 3:
return core99_ata100_enable(node, value);
+#endif
default:
return -ENODEV;
}


-
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: IA32 (2.6.11 - 2005-03-12.16.00) - 56 New warnings

2005-03-13 Thread Johannes Stezenbach
On Sat, Mar 12, 2005 at 09:08:45PM -0800, John Cherry wrote:
 drivers/media/dvb/frontends/dvb-pll.c:104: warning: (near initialization for 
 `dvb_pll_unknown_1.entries')
 drivers/media/dvb/frontends/dvb-pll.c:104: warning: excess elements in array 
 initializer
 drivers/media/dvb/frontends/dvb-pll.c:105: warning: (near initialization for 
 `dvb_pll_unknown_1.entries')
 drivers/media/dvb/frontends/dvb-pll.c:105: warning: excess elements in array 
 initializer
[snip]

Gerd's original patch had

struct dvb_pll_desc {
char *name;
u32  min;
u32  max;
void (*setbw)(u8 *buf, int bandwidth);
int  count;
struct {
u32 limit;
u32 offset;
u32 stepsize;
u8  cb1;
u8  cb2;
} entries[];
};

while 2.6.11-mm3 changed it into entries[0]. I assume this was made
for gcc-4.0 compatibility? But the element type for entries is
fully defined, so it should not be a problem (as long as no one tries to
created arrays of struct dvb_pll_desc)?

Johannes
-
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: DRI breakage, 2.6.11-mm[123]

2005-03-13 Thread Sean Neakums
Dave Jones [EMAIL PROTECTED] writes:

 On Sun, Mar 13, 2005 at 10:13:49AM +1100, Dave Airlie wrote:
   On Sat, 12 Mar 2005 19:29:20 +, Sean Neakums [EMAIL PROTECTED] wrote:
Sean Neakums [EMAIL PROTECTED] writes:

 The following happens with 2.6.11-mm[123].  (I didn't have time to
 investigate earlier; sorry.)  It does not happen with 2.6.11-rc3-mm2
 and 2.6.11.  I have tested 2.6.11-mm3 with dri disabled (by not
 loading X's dri module) and it also does not happen then.

Also happens on 2.6.11-mm3 with bk-drm.patch reverted.

To expand on my crappy report, the graphics card is a Radeon 9200:
   
   Wierd the -mm tree has currently very few drm changes over the non-mm
   tree and if reverting bk-drm doesn't help it sounds like something in
   the generic ioctl code may be gone wrong...
   
   Can you try a 2.6.12-bk snapshot.. it may be the multi-head patches
   are buggy

 Could be. Given the other agp problems didn't get spotted in -mm
 my confidence in those patches has dropped off somewhat in the
 last few days.

 Hopefully it's something simple.

Same symptoms with 2.6.11-bk8.

-- 
Dag vijandelijk luchtschip de huismeester is dood
-
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.3] gcc4 / psmouse.h - compilation fix.

2005-03-13 Thread Pawe Sikora
Hi,

Attched patch fixes gcc error:
`drivers/input/mouse/psmouse.h:40: error: field `ps2dev' has incomplete type`

Please apply.

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

   #define say(x) lie(x)
drivers/input/mouse/psmouse.h:40: error: field `ps2dev' has incomplete type

--- linux-2.6.11.3/drivers/input/mouse/psmouse.h.orig	2005-03-13 07:44:40.0 +0100
+++ linux-2.6.11.3/drivers/input/mouse/psmouse.h	2005-03-13 14:08:06.0 +0100
@@ -1,6 +1,8 @@
 #ifndef _PSMOUSE_H
 #define _PSMOUSE_H
 
+#include linux/libps2.h
+
 #define PSMOUSE_CMD_SETSCALE11	0x00e6
 #define PSMOUSE_CMD_SETSCALE21	0x00e7
 #define PSMOUSE_CMD_SETRES	0x10e8


Re: Fw: 2.6.11-rc5-mm1: reiser4 eating cpu time

2005-03-13 Thread Alexander Gran
Hi, 

Well, of course it cannot handle that large files (I wouldn't expect that, 
either). My Problem is that when I open the file, it's not just kwrite but 
other processes that need so much cpu time. That kwrite is eating cpu is ok. 
I cannot reproduce the behaviour for some reason however. 
So for short what's now (2.6.11-mm3) hapening:
I open a file of 150MB with kwrite. Kwrite start using all cpu it can get
After some seconds pdflush kicks in. Kwrite seems to wait, and pdflush is 
eating cpu cyles. These 2 alternate for some time, until file is loaded. 
Please note that this happens when the file is in cache too. No Idea what 
kwrite is doing here, though.
In the case described earlier ent:hda6. was eating my cpu cyles, even after 
kwrite was killed!

regards
Alex

Am Donnerstag, 10. März 2005 15:22 schrieb E.Gryaznova:
 I opened  190Mb textfile with kwrite and tried  to  do  goto line
 number 1 800 000 (file has about 6 000 000 lines). File is placed not
 on reiser4 but on ext2 partition. And I see that  kwrite eats about
 90-100% CPU.
 Does kwrite work fine for you on so big files on ext2 filesystem?

 I have the following kde version:
 [EMAIL PROTECTED]:~ kwrite --version
 Qt: 3.2.1
 KDE: 3.1.4
 KWrite: 4.1

 Thanks,
 Lena.

 Begin forwarded message:
 
 Date: Fri, 4 Mar 2005 02:24:36 +0100
 From: Alexander Gran [EMAIL PROTECTED]
 To: linux-kernel@vger.kernel.org
 Subject: 2.6.11-rc5-mm1: reiser4 eating cpu time
 
 
 Hi,
 
 I have a reiser4 partition on a local IDE disk. I opened a 130MB textfile
  with kwrite, and killed it while ot opened the file (took to long...)
  diskio was finished at this point.
 a [ent:hda6.] Process was eating 100% CPU time for several (54) seconds.
 Is this a normal, expected behaviour?
 After trying again, pdflush was eating much cpu time, about the same (50+
 secs) Note that this happend after reiser4 panic (on an external disk as
 reported several minutes ago).
 
 regards
 Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
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-mm3] Warning fix and be extra careful about array in kernel/module.c

2005-03-13 Thread Jesper Juhl

Fix warning in kernel/module.c::who_is_doing_it()
kernel/module.c:1405: warning: ignoring return value of `copy_from_user', 
declared with attribute warn_unused_result
by subtracting copy_from_user return value from 'len' - if we copy less 
data than we intend there's no point in looping over more than we actually 
copy.
I've also changed the type of 'len' and 'i' from unsigned int to 
unsigned long since that's the type of mm_struct.arg_start/arg_end and 
it's also the type of the last argument to copy_from_user. Sure, it'll be 
promoted and truncated between int/long just fine, but it seems cleaner to 
me that it's just the same type all the way.
I also added an explicit check of the value of 'len' after the calcolation 
of arg_start - arg_end since they are both long values subtracting one 
from the other could theoretically ield a value larger than 512 and such a 
value would cause us to overflow our statically allocated array. I don't 
know if that can actually ever occour, I don't know the code that well, 
but I thought it would be better to be safe than sorry.

The code compiles and I've been running the kernel with this change for a 
few hrs, but that's all the testing I've done.

If this seems OK to you, please consider merging it. If there's something 
wrong with it I'm always looking forward to being enlightened.


Signed-off-by: Jesper Juhl [EMAIL PROTECTED]

diff -up linux-2.6.11-mm3-orig/kernel/module.c linux-2.6.11-mm3/kernel/module.c
--- linux-2.6.11-mm3-orig/kernel/module.c   2005-03-13 00:52:51.0 
+0100
+++ linux-2.6.11-mm3/kernel/module.c2005-03-13 01:51:11.0 +0100
@@ -1400,9 +1400,12 @@ static void who_is_doing_it(void)
 {
/* Print out all the args. */
char args[512];
-   unsigned int i, len = current-mm-arg_end - current-mm-arg_start;
+   unsigned long i, len = current-mm-arg_end - current-mm-arg_start;
 
-   copy_from_user(args, (void *)current-mm-arg_start, len);
+   if (len  512)
+   len = 512;
+
+   len -= copy_from_user(args, (void *)current-mm-arg_start, len);
 
for (i = 0; i  len; i++) {
if (args[i] == '\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: DRI breakage, 2.6.11-mm[123]

2005-03-13 Thread Dave Airlie
 
 Same symptoms with 2.6.11-bk8.

damn.. am travelling at the moment, won't get a chance to take a
detailed look for a while.. I'll see can I figure it out just from
code inspection...

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: Fw: 2.6.11-rc5-mm1: reiser4 eating cpu time

2005-03-13 Thread Fredrik Tolf
On Sun, 2005-03-13 at 14:24 +0100, Alexander Gran wrote:
 Hi, 
 
 Well, of course it cannot handle that large files (I wouldn't expect that, 
 either). My Problem is that when I open the file, it's not just kwrite but 
 other processes that need so much cpu time. That kwrite is eating cpu is ok. 
 I cannot reproduce the behaviour for some reason however. 
 So for short what's now (2.6.11-mm3) hapening:
 I open a file of 150MB with kwrite. Kwrite start using all cpu it can get
 After some seconds pdflush kicks in. Kwrite seems to wait, and pdflush is 
 eating cpu cyles. These 2 alternate for some time, until file is loaded. 

That seems very much like expected behavior to me. I would expect kwrite
to start loading the file, and then having pdflush kick in to page out
parts of kwrite, so that it can allocate more memory. Then kwrite will
continue to load until more of it needs to be paged out, at which point
pdflush will engage again, and so on, until the file is loaded.

 Please note that this happens when the file is in cache too. No Idea what 
 kwrite is doing here, though.

Of course, I don't know if you may have a gig or so of RAM, but I'm
having trouble believing that a 150 MB file could be kept in cache,
especially given that kwrite allocates at least as much anonymous memory
to hold it internally.

 In the case described earlier ent:hda6. was eating my cpu cyles, even after 
 kwrite was killed!

Now, I can't really speak for reiser4, but it doesn't seem too
incredible that it would be flushing page usage or rebalancing some tree
or something like that. As long as it is niced down (I dunno if it
actually is, though...), that shouldn't be a problem.

HTH
Fredrik Tolf

 regards
 Alex
 
 Am Donnerstag, 10. Mrz 2005 15:22 schrieb E.Gryaznova:
  I opened  190Mb textfile with kwrite and tried  to  do  goto line
  number 1 800 000 (file has about 6 000 000 lines). File is placed not
  on reiser4 but on ext2 partition. And I see that  kwrite eats about
  90-100% CPU.
  Does kwrite work fine for you on so big files on ext2 filesystem?
 
  I have the following kde version:
  [EMAIL PROTECTED]:~ kwrite --version
  Qt: 3.2.1
  KDE: 3.1.4
  KWrite: 4.1
 
  Thanks,
  Lena.
 
  Begin forwarded message:
  
  Date: Fri, 4 Mar 2005 02:24:36 +0100
  From: Alexander Gran [EMAIL PROTECTED]
  To: linux-kernel@vger.kernel.org
  Subject: 2.6.11-rc5-mm1: reiser4 eating cpu time
  
  
  Hi,
  
  I have a reiser4 partition on a local IDE disk. I opened a 130MB textfile
   with kwrite, and killed it while ot opened the file (took to long...)
   diskio was finished at this point.
  a [ent:hda6.] Process was eating 100% CPU time for several (54) seconds.
  Is this a normal, expected behaviour?
  After trying again, pdflush was eating much cpu time, about the same (50+
  secs) Note that this happend after reiser4 panic (on an external disk as
  reported several minutes ago).
  
  regards
  Alex
 

-
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: [CHECKER] crash + fsck cause file systems to contain loops (msdos and vfat, 2.6.11)

2005-03-13 Thread OGAWA Hirofumi
Junfeng Yang [EMAIL PROTECTED] writes:

 Can you be a little bit more specific?

Please try

kernel:
  http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.gz
   +
  http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.11-bk7.bz2
  or later

dosfstools:
  http://user.parknet.co.jp/hirofumi/tmp/fatfsprogs.tar.bz2

Thanks.
-- 
OGAWA Hirofumi [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: [MC] [CHECKER] Need help on mmap on FUSE (linux user-land file system)

2005-03-13 Thread Kyle Moffett
On Mar 13, 2005, at 02:28, Junfeng Yang wrote:
Forget to mention, we are checking linux 2.6.  It appears to us that 
mmap
doesnt' work for FUSE in linux 2.6.
IIRC, the reason mmap doesn't work on FUSE is because when it dirties 
pages they
cannot be flushed reliably, because writing them out involves calling a 
userspace
process which may allocate RAM, etc.

Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
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] break_lock forever broken

2005-03-13 Thread Arjan van de Ven
On Sun, 2005-03-13 at 09:35 +, Hugh Dickins wrote:
 On Sun, 13 Mar 2005, Arjan van de Ven wrote:
 \
   + if ((lock)-break_lock) \
   + (lock)-break_lock = 0; \
}
   \
  if it really worth an conditional there? the cacheline of the lock is
  made dirty anyway on unlock, so writing an extra 0 is like almost free
  (maybe half a cycle) while a conditional jump can be 100+
 
 I wondered the same, I don't know and would defer to those who do:
 really I was just following the style of where break_lock is set above,
 which follows soon (unless preempted) after a _raw_whatever_trylock.

if the cacheline is dirtied previously it's just free to do the write so
I suggest to remove the conditional...


-
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: Fw: 2.6.11-rc5-mm1: reiser4 eating cpu time

2005-03-13 Thread Alexander Gran
Am Sonntag, 13. Mrz 2005 14:44 schrieben Sie:
 That seems very much like expected behavior to me. I would expect kwrite
 to start loading the file, and then having pdflush kick in to page out
 parts of kwrite, so that it can allocate more memory. Then kwrite will
 continue to load until more of it needs to be paged out, at which point
 pdflush will engage again, and so on, until the file is loaded.

Well not quite. kwrite uses not so much ram. And I have 1Gig:
[EMAIL PROTECTED]:/files/ipt$ cat gross  /dev/null
[EMAIL PROTECTED]:/files/ipt$ free
 total   used   free sharedbuffers cached
Mem:   1032592 507564 525028  0868 336072
-/+ buffers/cache: 170624 861968
Swap:   498920  0 498920
[EMAIL PROTECTED]:/files/ipt$ kwrite gross

[1]+  Stopped kwrite gross
# kwrite loaded completely
[EMAIL PROTECTED]:/files/ipt$ free
 total   used   free sharedbuffers cached
Mem:   1032592 848900 183692  0876 651632
-/+ buffers/cache: 196392 836200
Swap:   498920  0 498920

Acording to top:
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  CODE DATA COMMAND
18436 alex  16   0 44476  29m  14m S  0.0  2.9   0:11.044  13m kwrite

 Of course, I don't know if you may have a gig or so of RAM, but I'm
 having trouble believing that a 150 MB file could be kept in cache,
 especially given that kwrite allocates at least as much anonymous memory
 to hold it internally.

Is there any whay I can be sure a file is cached? cat file  /dev/null takes 
130ms, that should be ok?

 Now, I can't really speak for reiser4, but it doesn't seem too
 incredible that it would be flushing page usage or rebalancing some tree
 or something like that. As long as it is niced down (I dunno if it
 actually is, though...), that shouldn't be a problem.

Well, It's not niced down, and it was doing what so ever while reading, not 
while writing?

regards
Alex

  regards
  Alex
 
  Am Donnerstag, 10. Mrz 2005 15:22 schrieb E.Gryaznova:
   I opened  190Mb textfile with kwrite and tried  to  do  goto line
   number 1 800 000 (file has about 6 000 000 lines). File is placed not
   on reiser4 but on ext2 partition. And I see that  kwrite eats about
   90-100% CPU.
   Does kwrite work fine for you on so big files on ext2 filesystem?
  
   I have the following kde version:
   [EMAIL PROTECTED]:~ kwrite --version
   Qt: 3.2.1
   KDE: 3.1.4
   KWrite: 4.1
  
   Thanks,
   Lena.
  
   Begin forwarded message:
   
   Date: Fri, 4 Mar 2005 02:24:36 +0100
   From: Alexander Gran [EMAIL PROTECTED]
   To: linux-kernel@vger.kernel.org
   Subject: 2.6.11-rc5-mm1: reiser4 eating cpu time
   
   
   Hi,
   
   I have a reiser4 partition on a local IDE disk. I opened a 130MB
textfile with kwrite, and killed it while ot opened the file (took to
long...) diskio was finished at this point.
   a [ent:hda6.] Process was eating 100% CPU time for several (54)
seconds. Is this a normal, expected behaviour?
   After trying again, pdflush was eating much cpu time, about the same
(50+ secs) Note that this happend after reiser4 panic (on an external
disk as reported several minutes ago).
   
   regards
   Alex

-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
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: XFS dm_crypt BUG?

2005-03-13 Thread Torben Viets
Hello,
it works with Kernel 2.6.11, probably the problem was that I had used 4 
kb stacks and now I use the 8kb, but I'm not sure whether this was the 
problem.

greetings
Torben Viets
Nathan Scott schrieb:
On Sun, Mar 06, 2005 at 09:31:01PM +0100, Torben Viets wrote:
 

hello,
I tried to reproduced the bug with the newest kernel and but it works 
perfectly :D

thnk you for fixing it.
   

No problem, thanks for checking - could you send a note to the
list(s) saying its resolved for you with that kernel version, in
case others have also been seeing the problem.
cheers.
 

-
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: indirect lcall without `*'

2005-03-13 Thread Hacksaw
Ahh, okay. I'm just jumpy because this is a production server.

Thanks for the answer. :-)
-- 
Nothing can plugh you now
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD


-
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: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB

2005-03-13 Thread Grzegorz Kulewski
On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
Can you do an lspci -vvn?  I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
   PCI: Via IRQ fixup for :00:07.2, from 9 to 10
   PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.
You have:
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] 
(rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])
:00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) (prog-if 00 
[UHCI])
and we apparently ran the quirk for 07.2 and 07.3.  I wouldn't
have thought those would have one of the above device IDs.  The
lspci -vvn should tell us for sure.
2.6.11 removed that quirk and runs quirk_via_bridge() for
all VIA devices, but only sets via_interrupt_line_quirk if
(pdev-devfn == 0), which you don't have.  So that's why
my patch didn't do anything.
Also two more questions:
1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why is it
needed? On what hardware / software it is needed?
I really don't know much about the VIA fixup.  I just noticed
that we seem to be doing it slightly differently in 2.6.11 than
we did in 2.6.9, and thought maybe it was related to your problem.
Here's a changeset that has a couple pointers:
   http://linux.bkbits.net:8080/linux-2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ
2. Why this patch shrinked bzImage that much:
-rw-r--r--  1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
-rw-r--r--  1 root root 1828355 mar  2 20:48 vmlinuz-2.6.11-cko1.old
I have no idea about this.  But it's only a couple hundred bytes.
So here's another patch to try (revert the first one, then apply this).
= drivers/acpi/pci_irq.c 1.37 vs edited =
--- 1.37/drivers/acpi/pci_irq.c 2005-03-01 09:57:29 -07:00
+++ edited/drivers/acpi/pci_irq.c   2005-03-11 15:13:49 -07:00
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/init.h
#include linux/types.h
+#include linux/delay.h
#include linux/proc_fs.h
#include linux/spinlock.h
#include linux/pm.h
@@ -438,10 +439,17 @@
}
}
-   if (via_interrupt_line_quirk)
-   pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq  15);
-
dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
+
+   if (dev-vendor == PCI_VENDOR_ID_VIA) {
+   u8 old_irq, new_irq = dev-irq  0xf;
+
+   pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
+   printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d 
+   to %d\n, pci_name(dev), old_irq, new_irq);
+   udelay(15);
+   pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+   }
printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u 
(%s, %s) - IRQ %d\n,
Ok, this patch works. Here is the log:
Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc 
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)) #3 
Sun Mar 13 17:10:10 CET 2005
Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
Mar 13 17:16:17 kangur BIOS-e820:  - 0009fc00 
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a 
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010 
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff 
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000 
(ACPI NVS)
Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000 
(ACPI data)
Mar 13 17:16:17 kangur BIOS-e820:  - 0001 
(reserved)
Mar 13 17:16:17 kangur 511MB LOWMEM available.
Mar 13 17:16:17 kangur On node 0 totalpages: 131056
Mar 13 17:16:17 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 13 17:16:17 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 13 17:16:17 kangur HighMem zone: 0 pages, LIFO batch:1
Mar 13 17:16:17 kangur DMI 2.2 present.
Mar 13 17:16:17 kangur ACPI: RSDP (v000 761686 
) @ 0x000f6a70
Mar 13 17:16:17 kangur ACPI: RSDT (v001 761686 AWRDACPI 0x42302e31 AWRD 
0x) @ 0x1fff3000
Mar 13 17:16:17 kangur ACPI: FADT (v001 761686 AWRDACPI 0x42302e31 AWRD 
0x) @ 0x1fff3040
Mar 13 17:16:17 kangur ACPI: DSDT (v001 761686 AWRDACPI 0x1000 MSFT 
0x010c) @ 0x
Mar 13 17:16:17 kangur ACPI: PM-Timer IO Port: 0x4008
Mar 13 17:16:17 kangur Allocating PCI resources starting at 2000 (gap: 
2000:dfff)
Mar 13 17:16:17 kangur Built 1 zonelists
Mar 13 17:16:17 kangur Kernel command line: ro root=/dev/hdb4
Mar 13 17:16:17 kangur Local APIC disabled by BIOS -- you can enable it 
with lapic
Mar 13 17:16:17 kangur mapped APIC to d000 (01402000)
Mar 13 17:16:17 kangur Initializing CPU#0

Re: Linux 2.6.11.3

2005-03-13 Thread Matthias Andree
On Sat, 12 Mar 2005, Greg KH wrote:

 A bitkeeper tree for the 2.6.11.y releases can be found at:
   bk://linux-release.bkbits.net/linux-2.6.11

Do we then start switching trees with every new minor release?

-- 
Matthias Andree
-
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: machine check on sleep, PowerBook5.4

2005-03-13 Thread Sean Neakums
Both patches give me a successful sleep, although I had to alter the
second to not #if 0 core99_ata100_enable -- there's another call to
that function in pmac_feature.c's set_initial_features().

I will try to gather some power numbers.

-- 
Dag vijandelijk luchtschip de huismeester is dood
-
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: linux dvb alps_tdlb7 removed

2005-03-13 Thread Peter Waechtler
Am 11.03.2005 um 21:10 schrieb Kenneth Aafløy:
On Friday 11 March 2005 13:58, Juri Haberland wrote:
In article [EMAIL PROTECTED] you wrote:
With version 2.6.10 the driver for the tuner frontend from ALPS TDLB7
was removed.
Why do you think that this is a dead file?
While I'm happy with the work you do for dvb on Linux, and I want to
thank you for this anyway, my TV does not work anymore! :(
I use a TechoTrend Premium card with that frontend on it. It worked
fine until 2.6.10.
Can you put it back into mainline? Is there some work to do for
reinsertion?
I think the driver you now need is sp8870. It's just another name for
Yup you are right. If someone has a card that is no longer working,
please have a look at these pages and contact the linuxtv-dvb 
mailing-list:

http://www.linuxtv.org/wiki/index.php/Supported_DVB_cards
http://www.linuxtv.org/wiki/index.php/DVB_cards_requiring_definition
http://www.linuxtv.org/lists.php
Thanx, now it works again under 2.6.11
I had to create a link in /usr/lib/hotplug/firmware with the new name 
also.

Peter
-
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

2005-03-13 Thread Barry K. Nathan
On Sat, Mar 12, 2005 at 03:42:22AM -0800, Andrew Morton wrote:
 - A new version of the acpi poweroff fix.  People who were having trouble
   with ACPI poweroff, please test and report.

I've tested this set of ACPI poweroff patches with both clean, proper
shutdowns and Alt-SysRq-O, on hardware that previously didn't work. Now it
works.

-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: Linux 2.6.11.3

2005-03-13 Thread Greg KH
On Sun, Mar 13, 2005 at 04:38:24PM +0100, Matthias Andree wrote:
 On Sat, 12 Mar 2005, Greg KH wrote:
 
  A bitkeeper tree for the 2.6.11.y releases can be found at:
  bk://linux-release.bkbits.net/linux-2.6.11
 
 Do we then start switching trees with every new minor release?

Yes.

thanks,

greg k-h
-
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 0/3] cdrom/cdu31a update

2005-03-13 Thread Domen Puncer
Hi.

These cdu31a patches are based on http://lkml.org/lkml/2004/12/18/107
from Ondrej Zary [EMAIL PROTECTED]

Split into three files (see replies):
1 - printk and other trivial cleanups
2 - semaphorifization (hey, i invented a new word)
3 - use wait_event instead of sleep_on in irq handling

Patches have been tested by Ondrej, thanks!


Domen
-
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 3/3] cdrom/cdu31a update

2005-03-13 Thread Domen Puncer
Use wait_event instead of sleep_on.
Also, remove two unused variables.


Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Ondrej Zary [EMAIL PROTECTED]

--- ./drivers/cdrom/cdu31a.c.orig3  2005-03-06 22:04:42.0 +0100
+++ ./drivers/cdrom/cdu31a.c2005-03-12 14:40:14.0 +0100
@@ -264,15 +264,8 @@ static int sony_toc_read = 0;  /* Has the
 static struct s_sony_subcode last_sony_subcode;/* Points to the last
   subcode address read */
 
-static volatile int sony_inuse = 0;/* Is the drive in use?  Only one 
operation
-  at a time allowed */
-
 static DECLARE_MUTEX(sony_sem);/* Semaphore for drive hardware 
access */
 
-static struct task_struct *has_cd_task = NULL; /* The task that is currently
-  using the CDROM drive, or
-  NULL if none. */
-
 static int is_double_speed = 0;/* does the drive support double speed 
? */
 
 static int is_auto_eject = 1;  /* Door has been locked? 1=No/0=Yes */
@@ -300,6 +293,7 @@ module_param(cdu31a_irq, int, 0);
 /* The interrupt handler will wake this queue up when it gets an
interrupts. */
 DECLARE_WAIT_QUEUE_HEAD(cdu31a_irq_wait);
+static int irq_flag = 0;
 
 static int curr_control_reg = 0;   /* Current value of the control 
register */
 
@@ -376,17 +370,31 @@ static inline void disable_interrupts(vo
  */
 static inline void sony_sleep(void)
 {
-   unsigned long flags;
-
if (cdu31a_irq = 0) {
yield();
} else {/* Interrupt driven */
+   DEFINE_WAIT(w);
+   int first = 1;
+
+   while (1) {
+   prepare_to_wait(cdu31a_irq_wait, w,
+   TASK_INTERRUPTIBLE);
+   if (first) {
+   enable_interrupts();
+   first = 0;
+   }
 
-   save_flags(flags);
-   cli();
-   enable_interrupts();
-   interruptible_sleep_on(cdu31a_irq_wait);
-   restore_flags(flags);
+   if (irq_flag != 0)
+   break;
+   if (!signal_pending(current)) {
+   schedule();
+   continue;
+   } else
+   disable_interrupts();
+   break;
+   }
+   finish_wait(cdu31a_irq_wait, w);
+   irq_flag = 0;
}
 }
 
@@ -530,11 +538,13 @@ static irqreturn_t cdu31a_interrupt(int 
/* If something was waiting, wake it up now. */
if (waitqueue_active(cdu31a_irq_wait)) {
disable_interrupts();
-   wake_up(cdu31a_irq_wait);
+   irq_flag = 1;
+   wake_up_interruptible(cdu31a_irq_wait);
}
} else if (waitqueue_active(cdu31a_irq_wait)) {
disable_interrupts();
-   wake_up(cdu31a_irq_wait);
+   irq_flag = 1;
+   wake_up_interruptible(cdu31a_irq_wait);
} else {
disable_interrupts();
printk(KERN_NOTICE PFX
-
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/3] cdrom/cdu31a update

2005-03-13 Thread Domen Puncer
Pretty trivial cleanups:
- reordered #includes
- improved some printk's (note: this actually enabled some debug printk's)
- removed ()'s from returns
- removed SONY_POLL_EACH_BYTE, as grep doesn't find it anywhere else
- removed panic() as it can't happen.


Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Ondrej Zary [EMAIL PROTECTED]

--- ./drivers/cdrom/cdu31a.c.orig   2005-03-06 15:55:44.0 +0100
+++ ./drivers/cdrom/cdu31a.c2005-03-13 14:10:32.0 +0100
@@ -148,10 +148,10 @@
  * Ondrej Zary [EMAIL PROTECTED]
 */
 
-#include linux/major.h
+#define DEBUG 1
 
+#include linux/major.h
 #include linux/module.h
-
 #include linux/errno.h
 #include linux/signal.h
 #include linux/sched.h
@@ -166,13 +166,13 @@
 #include linux/slab.h
 #include linux/init.h
 #include linux/interrupt.h
+#include linux/cdrom.h
 
 #include asm/system.h
 #include asm/io.h
 #include asm/uaccess.h
 #include asm/dma.h
 
-#include linux/cdrom.h
 #include cdu31a.h
 
 #define MAJOR_NR CDU31A_CDROM_MAJOR
@@ -180,10 +180,7 @@
 
 #define CDU31A_MAX_CONSECUTIVE_ATTENTIONS 10
 
-#define DEBUG 1
-
-/* Define the following if you have data corruption problems. */
-#undef SONY_POLL_EACH_BYTE
+#define PFX CDU31A: 
 
 /*
 ** Edit the following data to change interrupts, DMA channels, etc.
@@ -397,37 +394,37 @@ static inline void sony_sleep(void)
  */
 static inline int is_attention(void)
 {
-   return ((inb(sony_cd_status_reg)  SONY_ATTN_BIT) != 0);
+   return (inb(sony_cd_status_reg)  SONY_ATTN_BIT) != 0;
 }
 
 static inline int is_busy(void)
 {
-   return ((inb(sony_cd_status_reg)  SONY_BUSY_BIT) != 0);
+   return (inb(sony_cd_status_reg)  SONY_BUSY_BIT) != 0;
 }
 
 static inline int is_data_ready(void)
 {
-   return ((inb(sony_cd_status_reg)  SONY_DATA_RDY_BIT) != 0);
+   return (inb(sony_cd_status_reg)  SONY_DATA_RDY_BIT) != 0;
 }
 
 static inline int is_data_requested(void)
 {
-   return ((inb(sony_cd_status_reg)  SONY_DATA_REQUEST_BIT) != 0);
+   return (inb(sony_cd_status_reg)  SONY_DATA_REQUEST_BIT) != 0;
 }
 
 static inline int is_result_ready(void)
 {
-   return ((inb(sony_cd_status_reg)  SONY_RES_RDY_BIT) != 0);
+   return (inb(sony_cd_status_reg)  SONY_RES_RDY_BIT) != 0;
 }
 
 static inline int is_param_write_rdy(void)
 {
-   return ((inb(sony_cd_fifost_reg)  SONY_PARAM_WRITE_RDY_BIT) != 0);
+   return (inb(sony_cd_fifost_reg)  SONY_PARAM_WRITE_RDY_BIT) != 0;
 }
 
 static inline int is_result_reg_not_empty(void)
 {
-   return ((inb(sony_cd_fifost_reg)  SONY_RES_REG_NOT_EMP_BIT) != 0);
+   return (inb(sony_cd_fifost_reg)  SONY_RES_REG_NOT_EMP_BIT) != 0;
 }
 
 static inline void reset_drive(void)
@@ -478,17 +475,17 @@ static inline void clear_param_reg(void)
 
 static inline unsigned char read_status_register(void)
 {
-   return (inb(sony_cd_status_reg));
+   return inb(sony_cd_status_reg);
 }
 
 static inline unsigned char read_result_register(void)
 {
-   return (inb(sony_cd_result_reg));
+   return inb(sony_cd_result_reg);
 }
 
 static inline unsigned char read_data_register(void)
 {
-   return (inb(sony_cd_read_reg));
+   return inb(sony_cd_read_reg);
 }
 
 static inline void write_param(unsigned char param)
@@ -534,8 +531,8 @@ static irqreturn_t cdu31a_interrupt(int 
wake_up(cdu31a_irq_wait);
} else {
disable_interrupts();
-   printk
-   (CDU31A: Got an interrupt but nothing was waiting\n);
+   printk(KERN_NOTICE PFX
+   Got an interrupt but nothing was waiting\n);
}
return IRQ_HANDLED;
 }
@@ -610,8 +607,8 @@ static void set_drive_params(int want_do
do_sony_cd_cmd(SONY_SET_DRIVE_PARAM_CMD,
   params, 2, res_reg, res_size);
if ((res_size  2) || ((res_reg[0]  0xf0) == 0x20)) {
-   printk(  Unable to set spin-down time: 0x%2.2x\n,
-  res_reg[1]);
+   printk(KERN_NOTICE PFX
+   Unable to set spin-down time: 0x%2.2x\n, res_reg[1]);
}
 
params[0] = SONY_SD_MECH_CONTROL;
@@ -627,8 +624,8 @@ static void set_drive_params(int want_do
do_sony_cd_cmd(SONY_SET_DRIVE_PARAM_CMD,
   params, 2, res_reg, res_size);
if ((res_size  2) || ((res_reg[0]  0xf0) == 0x20)) {
-   printk(  Unable to set mechanical parameters: 0x%2.2x\n,
-  res_reg[1]);
+   printk(KERN_NOTICE PFX Unable to set mechanical 
+   parameters: 0x%2.2x\n, res_reg[1]);
}
 }
 
@@ -672,7 +669,7 @@ static void restart_on_error(void)
unsigned long retry_count;
 
 
-   printk(cdu31a: Resetting drive on error\n);
+   printk(KERN_NOTICE PFX Resetting drive on error\n);
reset_drive();
retry_count = jiffies + SONY_RESET_TIMEOUT;
while (time_before(jiffies, retry_count)  

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

2005-03-13 Thread Andi Kleen
Roland McGrath [EMAIL PROTECTED] writes:

 The existing x86-64 kprobes implementation doesn't cope with the
 %RIP-relative addressing mode.  Kprobes work by single-stepping a copy of

Thanks for fixing that long standing bug. 

 + static const unsigned char onebyte_has_modrm[256] = {

Can you turn these two arrays into a bitmap please? 

 +  * This basically replicates __vmalloc, except that it uses a

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.

 +  * range of addresses starting a MODULE_END.  This also
 +  * allocates a single page of address space with no following
 +  * guard page (__get_vm_area always adds PAGE_SIZE to the size,
 +  * so by passing zero we get the one page).  We set up all the

I think Andrea has just changed that and the patch went into
mainline. Be careful with merging.

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


Re: [patch 2/3] cdrom/cdu31a update

2005-03-13 Thread Domen Puncer
Use semaphores instead of sleep_on*.
Stolen from patch: http://lkml.org/lkml/2004/12/18/107 from
Ondrej Zary [EMAIL PROTECTED]


Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Ondrej Zary [EMAIL PROTECTED]

--- ./drivers/cdrom/cdu31a.c.orig2  2005-03-13 14:12:23.0 +0100
+++ ./drivers/cdrom/cdu31a.c2005-03-13 14:13:44.0 +0100
@@ -267,7 +267,7 @@ static struct s_sony_subcode last_sony_s
 static volatile int sony_inuse = 0;/* Is the drive in use?  Only one 
operation
   at a time allowed */
 
-static DECLARE_WAIT_QUEUE_HEAD(sony_wait); /* Things waiting for the drive 
*/
+static DECLARE_MUTEX(sony_sem);/* Semaphore for drive hardware 
access */
 
 static struct task_struct *has_cd_task = NULL; /* The task that is currently
   using the CDROM drive, or
@@ -341,13 +341,16 @@ static int scd_media_changed(struct cdro
  */
 static int scd_drive_status(struct cdrom_device_info *cdi, int slot_nr)
 {
-   if (CDSL_CURRENT != slot_nr) {
+   if (CDSL_CURRENT != slot_nr)
/* we have no changer support */
return -EINVAL;
-   }
-   if (scd_spinup() == 0) {
+   if (sony_spun_up)
+   return CDS_DISC_OK;
+   if (down_interruptible(sony_sem))
+   return -ERESTARTSYS;
+   if (scd_spinup() == 0)
sony_spun_up = 1;
-   }
+   up(sony_sem);
return sony_spun_up ? CDS_DISC_OK : CDS_DRIVE_NOT_READY;
 }
 
@@ -442,6 +445,8 @@ static int scd_reset(struct cdrom_device
 {
unsigned long retry_count;
 
+   if (down_interruptible(sony_sem))
+   return -ERESTARTSYS;
reset_drive();
 
retry_count = jiffies + SONY_RESET_TIMEOUT;
@@ -449,6 +454,7 @@ static int scd_reset(struct cdrom_device
sony_sleep();
}
 
+   up(sony_sem);
return 0;
 }
 
@@ -640,7 +646,10 @@ static int scd_select_speed(struct cdrom
else
sony_speed = speed - 1;
 
+   if (down_interruptible(sony_sem))
+   return -ERESTARTSYS;
set_drive_params(sony_speed);
+   up(sony_sem);
return 0;
 }
 
@@ -655,7 +664,10 @@ static int scd_lock_door(struct cdrom_de
} else {
is_auto_eject = 0;
}
+   if (down_interruptible(sony_sem))
+   return -ERESTARTSYS;
set_drive_params(sony_speed);
+   up(sony_sem);
return 0;
 }
 
@@ -848,38 +860,12 @@ do_sony_cd_cmd(unsigned char cmd,
   unsigned char *result_buffer, unsigned int *result_size)
 {
unsigned long retry_count;
-   int num_retries;
-   int recursive_call;
-   unsigned long flags;
-
-
-   save_flags(flags);
-   cli();
-   if (current != has_cd_task) {   /* Allow recursive calls to this 
routine */
-   while (sony_inuse) {
-   interruptible_sleep_on(sony_wait);
-   if (signal_pending(current)) {
-   result_buffer[0] = 0x20;
-   result_buffer[1] = SONY_SIGNAL_OP_ERR;
-   *result_size = 2;
-   restore_flags(flags);
-   return;
-   }
-   }
-   sony_inuse = 1;
-   has_cd_task = current;
-   recursive_call = 0;
-   } else {
-   recursive_call = 1;
-   }
+   int num_retries = 0;
 
-   num_retries = 0;
 retry_cd_operation:
 
while (handle_sony_cd_attention());
 
-   sti();
-
retry_count = jiffies + SONY_JIFFIES_TIMEOUT;
while (time_before(jiffies, retry_count)  (is_busy())) {
sony_sleep();
@@ -907,14 +893,6 @@ retry_cd_operation:
msleep(100);
goto retry_cd_operation;
}
-
-   if (!recursive_call) {
-   has_cd_task = NULL;
-   sony_inuse = 0;
-   wake_up_interruptible(sony_wait);
-   }
-
-   restore_flags(flags);
 }
 
 
@@ -1154,13 +1132,9 @@ static void abort_read(void)
pending read operation. */
 static void handle_abort_timeout(unsigned long data)
 {
-   unsigned long flags;
-
pr_debug(PFX Entering %s\n, __FUNCTION__);
-   save_flags(flags);
-   cli();
/* If it is in use, ignore it. */
-   if (!sony_inuse) {
+   if (down_trylock(sony_sem) == 0) {
/* We can't use abort_read(), because it will sleep
   or schedule in the timer interrupt.  Just start
   the operation, finish it on the next access to
@@ -1171,8 +1145,8 @@ static void handle_abort_timeout(unsigne
 
sony_blocks_left = 0;
abort_read_started = 1;
+   up(sony_sem);
}
-   restore_flags(flags);
pr_debug(PFX Leaving %s\n, __FUNCTION__);
 }
 

Re: [2.6.11.3] gcc4 / psmouse.h - compilation fix.

2005-03-13 Thread Dmitry Torokhov
On Sunday 13 March 2005 08:20, Pawe Sikora wrote:
 Hi,
 
 Attched patch fixes gcc error:
 `drivers/input/mouse/psmouse.h:40: error: field `ps2dev' has incomplete type`
 

What file fails compilation? As far as I can see all users of psmouse.h do
#include linux/libps2.h first.

-- 
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: [2.6.11.3] gcc4 / psmouse.h - compilation fix.

2005-03-13 Thread Pawe Sikora
On Sunday 13 of March 2005 17:48, Dmitry Torokhov wrote:
 On Sunday 13 March 2005 08:20, Pawe Sikora wrote:
  Hi,
 
  Attched patch fixes gcc error:
  `drivers/input/mouse/psmouse.h:40: error: field `ps2dev' has incomplete
  type`

 What file fails compilation?

custom patch for trackpoint device.

 As far as I can see all users of psmouse.h do 
 #include linux/libps2.h first.

IMHO each header (e.g. psmouse.h) should include headers for types it uses.

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

   #define say(x) lie(x)
-
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.3] gcc4 / psmouse.h - compilation fix.

2005-03-13 Thread Dmitry Torokhov
On Sunday 13 March 2005 11:54, Pawe Sikora wrote:
 On Sunday 13 of March 2005 17:48, Dmitry Torokhov wrote:
  On Sunday 13 March 2005 08:20, Pawe Sikora wrote:
   Hi,
  
   Attched patch fixes gcc error:
   `drivers/input/mouse/psmouse.h:40: error: field `ps2dev' has incomplete
   type`
 
  What file fails compilation?
 
 custom patch for trackpoint device.
 
  As far as I can see all users of psmouse.h do 
  #include linux/libps2.h first.
 
 IMHO each header (e.g. psmouse.h) should include headers for types it uses.
 

Hmm, I thought it was other way around to make it easier to track all users
of a particular header file.

-- 
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/


Petition against software patents in Europe

2005-03-13 Thread Mikael Voss
http://petition.eurolinux.org/

Is there anyone who has not signed this petition 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] x86-64 kprobes: handle %RIP-relative addressing mode

2005-03-13 Thread Oleg Nesterov
Roland McGrath wrote:

 + * This basically replicates __vmalloc, except that it uses a
 + * range of addresses starting at MODULE_END.  This also

Could you look at these patches:

[PATCH 1/5] vmalloc: introduce __vmalloc_area() function
http://marc.theaimsgroup.com/?l=linux-kernelm=111013183331326

[PATCH 5/5] vmalloc: use list of pages instead of array in vm_struct
http://marc.theaimsgroup.com/?l=linux-kernelm=111013224029332

There are in mm3 now. Note that the second one will conflict with
your patch.

Is it possible to use __vmalloc_area()?

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: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash

2005-03-13 Thread Pavel Machek
Hi!

Thats why moving the eye candy console into user space is such a good
idea. You don't have to run it 8) It also means that the console
development is accessible to all the crazy rasterman types.
   
   Yep. The basic console we already have. Everyone who wants eye candy can 
   switch
   from basic console to user space console in early userspace.
   
  
  Heh, I'm afraid it does not work like that. Anyone who wants eye-candy
  simply applies broken patch to their kernel... unless their distribution 
  applied one
  already.
  
  Situation where we have one working eye-candy patch would certainly
  be an improvement.
 
 Why do we need patches in the kernel. Just set you config to 
 CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or 
 vgacon. Then have a userspace app using /dev/fb and /dev/input create a 
 userland console. There is no need to do special hacks in the kernel.

Except that I'll not get usefull reports from Oopsen and panic's,
right? Ideally I'd also like high-priority kernel messages to be
displayed during boot.
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/


[patch] x86: fix ESP corruption CPU bug

2005-03-13 Thread Stas Sergeev
Hi Alan.
Attached patch works around the corruption
of the high word of the ESP register, which
is the official bug of x86 CPUs. The bug
triggers only when the one is using the
16bit stack segment, and is described here:
http://www.intel.com/design/intarch/specupdt/27287402.PDF
Patch helps running many apps under dosemu,
and, according to the comments found in
Wine sources, also helps Wine.
Also the patch closes the information leak,
which is that the half of the kernel's %esp
value gets leaked to user-space.
The initial discussion about the problem
can be found here:
http://lkml.org/lkml/2004/9/16/254
On a later stages the development of that
patch was driven mainly by Linus, but it
was in private.
This patch adds only 6 instructions for
the fast kernel--user return path, 6
instructions on an exception path and
5 instructions on an NMI path. All the
rest of the patch gets executed only
for the two apps in that world, namely,
dosemu and wine (and VMWare?).
That's why it should be relatevely easy
to make sure the patch doesn't do any
harm for the normal apps, and so it is
safe, and probably fits into an -ac tree.
How it works:
- Allocates the per-cpu data for 16bit
stacks and sets the per-cpu GDT entries
for them.
- On a return to userspace, checks whether
the SS is from LDT and is 16 bit.
- If it is, the iret frame gets copied
to the 16bit per-cpu stack and stack gets
switched to the 16bit one, while the
higher word of %esp gets preloaded with
the proper value.
- On an exceptions the check is performed
to see if we are on a 16bit stack, and
if we are - switch to the 32bit one.
Alan, would it be possible to apply that
patch to an -ac tree?
Acked-by: Linus Torvalds [EMAIL PROTECTED]
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
Signed-off-by: Stas Sergeev [EMAIL PROTECTED]
diff -ur linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c linux-2.6.11-ac2-stk/arch/i386/kernel/cpu/common.c
--- linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c	2005-03-13 17:59:45.0 +0300
+++ linux-2.6.11-ac2-stk/arch/i386/kernel/cpu/common.c	2005-03-13 18:17:47.0 +0300
@@ -21,6 +21,10 @@
 DEFINE_PER_CPU(struct desc_struct, cpu_gdt_table[GDT_ENTRIES]);
 EXPORT_PER_CPU_SYMBOL(cpu_gdt_table);
 
+unsigned char cpu_16bit_stack[CPU_16BIT_STACK_SIZE];
+DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
+EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
+
 static int cachesize_override __initdata = -1;
 static int disable_x86_fxsr __initdata = 0;
 static int disable_x86_serial_nr __initdata = 1;
@@ -557,6 +561,7 @@
 	int cpu = smp_processor_id();
 	struct tss_struct * t = per_cpu(init_tss, cpu);
 	struct thread_struct *thread = current-thread;
+	__u32 stk16_off = (__u32)per_cpu(cpu_16bit_stack, cpu);
 
 	if (cpu_test_and_set(cpu, cpu_initialized)) {
 		printk(KERN_WARNING CPU#%d already initialized!\n, cpu);
@@ -579,6 +584,13 @@
 	 */
 	memcpy(per_cpu(cpu_gdt_table, cpu), cpu_gdt_table,
 	   GDT_SIZE);
+
+	/* Set up GDT entry for 16bit stack */
+	*(__u64 *)(per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_ESPFIX_SS]) |=
+		__u64)stk16_off)  16)  0x00ffULL) |
+		__u64)stk16_off)  32)  0xff00ULL) |
+		(CPU_16BIT_STACK_SIZE - 1);
+
 	cpu_gdt_descr[cpu].size = GDT_SIZE - 1;
 	cpu_gdt_descr[cpu].address =
 	(unsigned long)per_cpu(cpu_gdt_table, cpu);
diff -ur linux-2.6.11-ac2/arch/i386/kernel/entry.S linux-2.6.11-ac2-stk/arch/i386/kernel/entry.S
--- linux-2.6.11-ac2/arch/i386/kernel/entry.S	2005-03-13 17:59:45.0 +0300
+++ linux-2.6.11-ac2-stk/arch/i386/kernel/entry.S	2005-03-13 18:17:47.0 +0300
@@ -47,6 +47,7 @@
 #include asm/segment.h
 #include asm/smp.h
 #include asm/page.h
+#include asm/desc.h
 #include irq_vectors.h
 
 #define nr_syscalls ((syscall_table_size)/4)
@@ -78,7 +79,7 @@
 #define preempt_stop		cli
 #else
 #define preempt_stop
-#define resume_kernel		restore_all
+#define resume_kernel		restore_nocheck
 #endif
 
 #define SAVE_ALL \
@@ -122,24 +123,6 @@
 .previous
 
 
-#define RESTORE_ALL	\
-	RESTORE_REGS	\
-	addl $4, %esp;	\
-1:	iret;		\
-.section .fixup,ax;   \
-2:	sti;		\
-	movl $(__USER_DS), %edx; \
-	movl %edx, %ds; \
-	movl %edx, %es; \
-	movl $11,%eax;	\
-	call do_exit;	\
-.previous;		\
-.section __ex_table,a;\
-	.align 4;	\
-	.long 1b,2b;	\
-.previous
-
-
 ENTRY(ret_from_fork)
 	pushl %eax
 	call schedule_tail
@@ -163,7 +146,7 @@
 	movl EFLAGS(%esp), %eax		# mix EFLAGS and CS
 	movb CS(%esp), %al
 	testl $(VM_MASK | 3), %eax
-	jz resume_kernel		# returning to kernel or vm86-space
+	jz resume_kernel
 ENTRY(resume_userspace)
  	cli# make sure we don't miss an interrupt
 	# setting need_resched or sigpending
@@ -178,7 +161,7 @@
 ENTRY(resume_kernel)
 	cli
 	cmpl $0,TI_preempt_count(%ebp)	# non-zero preempt_count ?
-	jnz restore_all
+	jnz restore_nocheck
 need_resched:
 	movl TI_flags(%ebp), %ecx	# need_resched set ?
 	testb $_TIF_NEED_RESCHED, %cl
@@ -189,6 +172,31 @@
 	jmp need_resched
 #endif
 
+ldt_ss:
+	larl OLDSS(%esp), %eax
+	jnz restore_nocheck
+	testl 

Re: Capabilities across execve

2005-03-13 Thread Pavel Machek
Hi!

 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. 
 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.
 
 From here on the inheritable mask will be passed on unchanged to the new
 tasks children unless told otherwise (effectively the complete
 capability state is passed on).
 
 With a small insert of prctl(PR_SET_KEEPCAPS, 1) into pam_cap.c at the
 correct place this makes pam_cap work as expected. I'm also attaching a
 test-case that tests capabilities across setuid = execve (makes the new
 task inherit CAP_CHOWN).

FWIV, I think this is good idea; this way capabilities will not only
be castle in the sky, but also will be actually usable.
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: spin_lock error in arch/i386/kernel/time.c on APM resume

2005-03-13 Thread Pavel Machek
Hi!

 And more... That this occures implies we are attempting to update the cmos
 clock on resume seems wrong.  One would presume that the time is wrong at 
 this
 time and we are about to save that wrong time.  Possibly the APM code 
 should
 change time_status to STA_UNSYNC on the way into the sleep (or what ever 
 it is
 called).  Who should we ping with this?
 
 
 timer_resume, which appears to be the problem, wants to calculate amount 
 of time was spent suspended, also your unconditional irq enable in 
 get_cmos_time breaks the atomicity of device_power_up and would deadlock 
 in sections of code which call get_time_diff() with xtime_lock held. I 
 sent a patch subject APM: fix interrupts enabled in device_power_up 
 which should address this.
 
 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..
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: 2.6.11: keyboard stopped working after memory upgrade

2005-03-13 Thread Pavel Machek
Hi!

 I'm just having a weird problem with 2.6.11.  Namely, the keyboard stopped
 working after I'd added more RAM to the box (Asus L5D notebok, x86-64
 kernel).  It works on 2.6.11-mm1.

Custom DSDT? DSDTs are known to depend on ammount of memory...
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: [patch] x86: fix ESP corruption CPU bug

2005-03-13 Thread Grzegorz Kulewski
On Sun, 13 Mar 2005, Stas Sergeev wrote:
Hi Alan.
Attached patch works around the corruption
of the high word of the ESP register, which
is the official bug of x86 CPUs. The bug
triggers only when the one is using the
16bit stack segment, and is described here:
http://www.intel.com/design/intarch/specupdt/27287402.PDF
Does the bug also egsist on AMD CPU's? Does the patch add anything to 
kernels compiled for AMD CPU's?

Thanks,
Grzegorz Kulewski
-
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: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash

2005-03-13 Thread Geert Uytterhoeven
On Sun, 13 Mar 2005, Pavel Machek wrote:
 Thats why moving the eye candy console into user space is such a good
 idea. You don't have to run it 8) It also means that the console
 development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy 
can switch
from basic console to user space console in early userspace.

   
   Heh, I'm afraid it does not work like that. Anyone who wants eye-candy
   simply applies broken patch to their kernel... unless their distribution 
   applied one
   already.
   
   Situation where we have one working eye-candy patch would certainly
   be an improvement.
  
  Why do we need patches in the kernel. Just set you config to 
  CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or 
  vgacon. Then have a userspace app using /dev/fb and /dev/input create a 
  userland console. There is no need to do special hacks in the kernel.
 
 Except that I'll not get usefull reports from Oopsen and panic's,
 right? Ideally I'd also like high-priority kernel messages to be
 displayed during boot.

Indeed. I thought the idea was to use the existing fbcon support to draw
emergency messages to the screen.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: machine check on sleep, PowerBook5.4

2005-03-13 Thread Sean Neakums
Sean Neakums [EMAIL PROTECTED] writes:

 Both patches give me a successful sleep, although I had to alter the
 second to not #if 0 core99_ata100_enable -- there's another call to
 that function in pmac_feature.c's set_initial_features().

 I will try to gather some power numbers.

With the first patch, charge dropped by 33 over 52 minutes, 0.64/min.
With the second patch, charge dropped by 65 over 80 minutes, 0.81/min.

-- 
Dag vijandelijk luchtschip de huismeester is dood
-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Stas Sergeev
Hello.
Grzegorz Kulewski wrote:
Does the bug also egsist on AMD CPU's?
Yes. As well as the ones of a Transmeta etc.
I just haven't tested the old Cyrixes, that
AFAIK were trying to ignore some Intel bugs.
The test-case for the bug is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0690.html
Does the patch add anything to 
kernels compiled for AMD CPU's?
Same as for the Intel ones - unless you are
a dosemu or, in a lesser extent, Wine user -
nothing except for fixing the small information
leak.
If you are the dosemu user however, then this
patch adds a lot. Whether or not it adds
something for the VMWare users I can't say, since
I am not the one of them, but my guess is that
it can help with the DOS programs under 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/


IDE failure on ACPI resume

2005-03-13 Thread Matthew Garrett
On resume, an HP nc6220 fails during resuming of the IDE devices. In
this section of code from ide-iops.c:

stat = hwif-INB(hwif-io_ports[IDE_STATUS_OFFSET]);
if ((stat  BUSY_STAT) == 0)
return 0;
/*
 * Assume a value of 0xff means nothing is connected to
 * the interface and it doesn't implement the pull-down
 * resistor on D7.
 */
if (stat == 0xff)
return -ENODEV;

0xff is read and ENODEV returned. This results in

hda: bus not ready on wakeup
hda: drive not ready on wakeup

and then the machine sits there until some later command times out. It
seems that reading anything off the IDE bus just results in 0xff being
read.

The IDE controller is an Intel ICH6. Another HP laptop with an identical
chipset works fine, which makes me suspicious of the BIOS. Is the fact
that Linux doesn't seem to run the GTF, STM or GTM methods likely to be
relevant here?

-- 
Matthew Garrett | [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: 2.6.11: keyboard stopped working after memory upgrade

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

On Sunday, 13 of March 2005 19:36, Pavel Machek wrote:
 Hi!
 
  I'm just having a weird problem with 2.6.11.  Namely, the keyboard stopped
  working after I'd added more RAM to the box (Asus L5D notebok, x86-64
  kernel).  It works on 2.6.11-mm1.
 
 Custom DSDT? DSDTs are known to depend on ammount of memory...

Yes, but the very same DSDT works fine on 2.6.11-mm[13].  Just for the record. 
:-)

Rafael


-- 
- 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: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash

2005-03-13 Thread Elladan
On Fri, Mar 11, 2005 at 06:03:20PM +, James Simmons wrote:
 
Thats why moving the eye candy console into user space is such a good
idea. You don't have to run it 8) It also means that the console
development is accessible to all the crazy rasterman types.
   
   Yep. The basic console we already have. Everyone who wants eye candy can 
   switch
   from basic console to user space console in early userspace.
   
  
  Heh, I'm afraid it does not work like that. Anyone who wants eye-candy
  simply applies broken patch to their kernel... unless their distribution 
  applied one
  already.
  
  Situation where we have one working eye-candy patch would certainly
  be an improvement.
 
 Why do we need patches in the kernel. Just set you config to 
 CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or 
 vgacon. Then have a userspace app using /dev/fb and /dev/input create a 
 userland console. There is no need to do special hacks in the kernel.

Putting it in userland would make it impossible to debug what's wrong
with the system if there's a kernel error, since userland will die long
before it can spit out anything useful.


The primary purpose of these things is to make a distribution look
pretty while booting.  Lots of people complain that Linux distros look
old fashioned or something because they don't show little dancing
girls during early boot.

I should think the primary features you need here are:

* Can display some pretty looking thing with a logo
* If there's a problem during boot (userspace error, oops, panic, etc.)
  then it should become a regular console able to scroll back over the
  boot-time spew.

I don't think a user-space version can do that for anything except
userspace errors, so a kernel console is better.

-J
-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Ondrej Zary
Stas Sergeev wrote:
Hello.
Grzegorz Kulewski wrote:
Does the bug also egsist on AMD CPU's?
Yes. As well as the ones of a Transmeta etc.
I just haven't tested the old Cyrixes, that
AFAIK were trying to ignore some Intel bugs.
The test-case for the bug is here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0690.html
I've just ran that on my Cyrix MII PR300 and the bug is present:
old_ss=0x7b new_ss=0x7f
In sighandler: esp=b780
old_esp=0xb780 new_esp=0xc1a6f780
BUG!
I have also an older Cyrix CPU - 6x86 PR166 - but can't test it now as 
it's sitting in a plastic box on the shelf :-)

UMC U5SX/33 in my router - also present:
old_ss=0x7b new_ss=0x7f
In sighandler: esp=b820
old_esp=0xb820 new_esp=0xc003f820
BUG!
--
Ondrej Zary
-
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: IA32 (2.6.11 - 2005-03-12.16.00) - 56 New warnings

2005-03-13 Thread Andrew Morton
Johannes Stezenbach [EMAIL PROTECTED] wrote:

  On Sat, Mar 12, 2005 at 09:08:45PM -0800, John Cherry wrote:
   drivers/media/dvb/frontends/dvb-pll.c:104: warning: (near initialization 
 for `dvb_pll_unknown_1.entries')
   drivers/media/dvb/frontends/dvb-pll.c:104: warning: excess elements in 
 array initializer
   drivers/media/dvb/frontends/dvb-pll.c:105: warning: (near initialization 
 for `dvb_pll_unknown_1.entries')
   drivers/media/dvb/frontends/dvb-pll.c:105: warning: excess elements in 
 array initializer
  [snip]
 
  Gerd's original patch had
 
   struct dvb_pll_desc {
   char *name;
   u32  min;
   u32  max;
   void (*setbw)(u8 *buf, int bandwidth);
   int  count;
   struct {
   u32 limit;
   u32 offset;
   u32 stepsize;
   u8  cb1;
   u8  cb2;
   } entries[];
   };
 
  while 2.6.11-mm3 changed it into entries[0].

The original code failed to compile with gcc-2.95.4, so I stuck the [0] in
there, then was vaguely surprised when no warnings came out.  Seems that
later compilers _do_ warn.

I guess we could put a 9 in there.
-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Stas Sergeev
Hello.
Ondrej Zary wrote:
I've just ran that on my Cyrix MII PR300 and the bug is present:
UMC U5SX/33 in my router - also present:
Thanks, now I know for sure that it exist
everywhere.
Now you can apply the patch and make sure
the bug goes away:)
-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Pavel Machek
Hi!

 Attached patch works around the corruption
 of the high word of the ESP register, which
 is the official bug of x86 CPUs. The bug
 triggers only when the one is using the
 16bit stack segment, and is described here:
 http://www.intel.com/design/intarch/specupdt/27287402.PDF
 
 Does the bug also egsist on AMD CPU's? Does the patch add anything to 
 kernels compiled for AMD CPU's?

Yes, same workaround is needed on AMDs, Cyrixes, ...

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: [CHECKER] inconsistent NFS stat cache (NFS on ext3, 2.6.11)

2005-03-13 Thread Daniel Jacobowitz
On Sun, Mar 13, 2005 at 12:04:27AM -0500, Trond Myklebust wrote:
 lau den 12.03.2005 Klokka 03:56 (-0800) skreiv Junfeng Yang:
  Hi,
  
  We checked NFS on top of ext3 using FiSC (our file system model checker)
  and found a case where NFS stat cache can contain inconsistent entries.
  
  Basically, to trigger this inconsistency, just do the following steps:
  1. create a file A1, write a few bytes to it, so A1 is 4 words
  2. create a hard link A2, pointing to A1
  3. stat on A2. A2's size is 4 words
  4. truncate A1 to a larger size, write a few bytes at the end. now it's
  1031 words.
  5. stat on A2. it's size is still 4 words, which should be 1031 words
  
  We have a test case to re-create this warning.  You can download it at
  http://fisc.stanford.edu/bug16/crash.c.  It includes some sudo commands
  to mount nfs partitions, which you might want to change according to your
  local settings.
  
  cat /etc/exports shows:
  /mnt/sbd0-export  localhost(rw,sync)
  /mnt/sbd1-export  localhost(rw,sync)
  
  Let me know if you have any problems reproducing the warning. We'd
  appreciate any confirmations/clarifications.
  
 
 This is a known problem. Turn off the (default - grrr) subtree checking
 export option on the server, and it will all work properly. The subtree
 checking option violates the NFS standards for filehandle generation in
 so many ways, that it isn't even funny.

I can't find any documentation about this, but it seems like the same
problem that has been causing me headaches lately; when I replace glibc
from the server side of an nfsroot, the client has a couple of
variously wrong reads before it sees the new files.  If it breaks NFS
so badly, why is it the default for the Linux NFS server?

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
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: More trouble with i386 EFLAGS and ptrace

2005-03-13 Thread Daniel Jacobowitz
On Sun, Mar 13, 2005 at 12:27:58AM -0800, Roland McGrath wrote:
 This patch further cleans up the appearance of TF in eflags when ptrace is
 involved.  With this, PTRACE_SINGLESTEP will not cause TF to appear in
 eflags as seen by PTRACE_GETREGS and the like, when the instruction faulted
 for some reason other than the single-step trap.
 
 This moves the check added by Dan's patch from setup_sigcontext to
 handle_signal.  This is a cosmetic difference, but I think it makes more
 sense to consolidate all the reset registers to canonical state work in
 the same place (i.e. put it with the syscall rollback code), separate from
 the signal handler setup.  The change that matters is moving the similar
 check out of do_debug, where it only covers the case of a single-step trap.
 Instead, it goes into the ptrace_signal_deliver macro, which is called
 before the ptrace stop for whatever signal results from whatever kind of
 fault in that instruction (or asynchronous signal).  With that, the
 handle_signal check is still needed only for the case of PTRACE_SINGLESTEP
 with a handled signal.
 
 
 Thanks,
 Roland

Thanks, looks right to me!


-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Pavel Machek
Hi!

 @@ -257,8 +265,31 @@
   movl TI_flags(%ebp), %ecx
   testw $_TIF_ALLWORK_MASK, %cx   # current-work
   jne syscall_exit_work
 +
  restore_all:
 - RESTORE_ALL
 + movl EFLAGS(%esp), %eax # mix EFLAGS, SS and CS
 + movb OLDSS(%esp), %ah
 + movb CS(%esp), %al
 + andl $(VM_MASK | (4  8) | 3), %eax
 + cmpl $((4  8) | 3), %eax
 + je ldt_ss   # returning to user-space with LDT SS

All common linux apps use same %ss, no? Perhaps it would be more
efficient to just check if %ss == 0x7b, and proceed directly to
restore_nocheck if not?

Or perhaps we could only enable this code after application loads
custom ldt?

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: [2.6 patch] unexport hugetlb_total_pages

2005-03-13 Thread William Lee Irwin III
On Sun, Mar 06, 2005 at 03:39:08PM +0100, Adrian Bunk wrote:
 I didn't find any possible modular usage in the kernel.
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Acked-by: William Irwin [EMAIL PROTECTED]


-- wli
-
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: [BUG] 2.6.11- sym53c8xx Broken on pp64

2005-03-13 Thread Omkhar Arasaratnam
Benjamin Herrenschmidt wrote:
On Thu, 2005-03-10 at 11:05 -0600, Omkhar Arasaratnam wrote:
 

2.6.10 seems to have a different kernel panic which I'm investigating 
(could be a problem with my ramdisk as it happens in my linuxrc). So 
long story short the 2.6.10 sym driver looks ok.
   

Can you try 2.6.11 with the 2.6.10 sym driver ?
Ben.

 

I copied over the code from drivers/scsi/sym53c8xx_2/ on 2.6.10 to the 
2.6.11 dir. The machine didn't come back up after the reboot - I will 
have to wait till Monday to see the error as I do not have remote 
console access to the machine - I will report my findings then.

Omkhar
-
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/


Serious problems with HFS+

2005-03-13 Thread Matt Mackall
I've noticed a few problems with HFS+ support in recent kernels on
another user's machine running Ubuntu (Warty) running
2.6.8.1-3-powerpc. I'm not in a position to extensively test or fix
either of these problem because of the fs tools situation so I'm just
passing this on.

First, it reports inappropriate blocks to stat(2). It uses 4096 byte
blocks rather than 512 byte blocks which stat callers are expecting.
This seriously confuses du(1) (and me, for a bit). Looks like it may
be forgetting to set s_blocksize_bits.

Second, if an HFS+ filesystem mounted via Firewire or USB becomes
detached, the filesystem appears to continue working just fine. I can
find on the entire tree, despite memory pressure. I can even create
new files that continue to appear in directory listings! Writes to
such files succeed (they're async, of course) and the typical app is
none the wiser. It's only when apps attempt to read later that they
encounter problems. It turns out that various apps including scp
ignore IO errors on read and silently copy zero-filled files to the
destination. So I got this report as why aren't the pictures I took
off my camera visible on my website?

This is obviously a really nasty failure mode. At the very least, open
of new files should fail with -EIO. Preferably the fs should force a
read-only remount on IO errors. Given that the vast majority of HFS+
filesystems Linux is likely to be used with are on hotpluggable media,
I think this FS should be marked EXPERIMENTAL until such integrity
problems are addressed.

Having the whole directory tree seemingly pinned in memory is probably
something that wants addressing as well.

-- 
Mathematics is the supreme nostalgia of our time.
-
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: [CHECKER] inconsistent NFS stat cache (NFS on ext3, 2.6.11)

2005-03-13 Thread Trond Myklebust
su den 13.03.2005 Klokka 15:04 (-0500) skreiv Daniel Jacobowitz:

 I can't find any documentation about this, but it seems like the same
 problem that has been causing me headaches lately; when I replace glibc
 from the server side of an nfsroot, the client has a couple of
 variously wrong reads before it sees the new files.  If it breaks NFS
 so badly, why is it the default for the Linux NFS server?

No, that's a very different issue: you are violating the NFS cache
consistency rules if you are changing a file that is being held open by
other machines.
The correct way to do the above is to use GNU install with the '-b'
option: that will rename the version of glibc that is in use, and then
install the new glibc in a different inode.

Cheers,
  Trond
-- 
Trond Myklebust [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: [CHECKER] inconsistent NFS stat cache (NFS on ext3, 2.6.11)

2005-03-13 Thread Trond Myklebust
su den 13.03.2005 Klokka 15:42 (-0500) skreiv Trond Myklebust:

 No, that's a very different issue: you are violating the NFS cache
 consistency rules if you are changing a file that is being held open by
 other machines.
 The correct way to do the above is to use GNU install with the '-b'
 option: that will rename the version of glibc that is in use, and then
 install the new glibc in a different inode.

BTW: there is a more complete description of the NFS cache consistency
model in the NFS FAQ:

  http://nfs.sourceforge.net/index.cel.php#faq_a8

Cheers,
  Trond

-- 
Trond Myklebust [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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Stas Sergeev
Hi.
Pavel Machek wrote:
+   andl $(VM_MASK | (4  8) | 3), %eax
+   cmpl $((4  8) | 3), %eax
+   je ldt_ss   # returning to user-space with LDT SS
All common linux apps use same %ss, no? Perhaps it would be more
efficient to just check if %ss == 0x7b, and proceed directly to
restore_nocheck if not?
Such an optimization will cost three more
instructions, one of which is a taken
jump. It seems like the taken jump on
a fast path is not good, while now it is
only 5 instructions with a not-taken jump.
I am not sure here, but I think the current
solution is better (depends on how bad the
taken jump is, and how bad it is to have
the three extra insns for that optimization
purpose).
Or perhaps we could only enable this code
after application loads custom ldt?
The good thing here is that the code
actually does what you say, i.e. it jumps
to ldt_ss only when the app has loaded
the custom ldt and loaded that selector
to %ss. The way it is implemented, is
probably different from what you mean,
I assume you mean the new per-thread flag?
But I don't see how it can be more optimal,
i.e. you propose to check whether or not
the app altered the ldt (which can just be
the old glibc I think), while the current
solution is to also check whether it was
loaded to %ss (so the glibc case is avoided,
IIRC glibc used to load %gs with LDT selector).
I.e. since right now we jump to ldt_ss only
when the %ss is loaded with an LDT selector,
I think the extra checks are not 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: [PATCH][0/10] verify_area cleanup

2005-03-13 Thread William Lee Irwin III
On Fri, Mar 04, 2005 at 03:47:07AM +0100, Jesper Juhl wrote:
 Now that 2.6.11 is out the door it's time to try and submit this again.
 The following patches convert all users of verify_area to access_ok and 
 the final patch then deprecates verify_area acros all archs with the 
 intention of removing it completely later. These patches get rid of 99+% 
 of all users, there's still one or two macros left using it and there are 
 still a few comments left refering to it that could be cleaned up - I'll 
 get to those, but what remains after these patches is extremely little.
 The reason for doing this is that verify_area is just a wrapper for 
 access_ok anyway, so there's no good reason to keep it around - access_ok 
 also seems more readable anyway with saner return values.
 Since these patches touch things all over the tree the CC list would be 
 enormous if I CC'd everyone involved on all patches, so I'll just CC this 
 initial mail to a few key people I think are relevant (I hope I got that 
 list right), and the actual patches I'll just send to linux-kernel and 
 Andrew (or directly to people who ask for that).

The execution at first glance appears good. Out of curiosity, does this
serve a larger purpose than eliminating a redundant API?


-- wli
-
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/


[OOPS] kHTTPd oops + patch

2005-03-13 Thread Hmamouche, Youssef
hi,
khttpd oopses after a browser request is sent to the admin port on 8080. The
decoded oops follows with a patch that fixes it:
ksymoops 2.4.9 on i686 2.4.28.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.28/ (default)
 -m /boot/linux-2.4.28-dec/System.map (specified)
Unable to handle kernel NULL pointer dereference at virtual address 
0004
c0116a36
*pde = 
Oops: 0002
CPU:0
EIP:0010:[c0116a36]Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax:    ebx: d097a424   ecx:    edx: d097a41c
esi: 0286   edi: c03b8dec   ebp: d01e2000   esp: d01e3f84
ds: 0018   es: 0018   ss: 0018
Process khttpd - 0 (pid: 1119, stackpage=d01e3000)
Stack: d097a400  c029dcbd d03b533c  c029f088 d097a400 
0050
   0002   c029cfac  d02ded54  

   d01e2000   0001 d01e2000 d01e1fd8 d02ded70 
0f00
Call Trace:[c029dcbd] [c029f088] [c029cfac] [c010565e] 
[c029cdb0]
Code: 89 48 04 89 01 c7 43 04 00 00 00 00 c7 42 08 00 00 00 00 56


 EIP; c0116a36 remove_wait_queue+16/40   =

 ebx; d097a424 _end+105bf278/18b86eb4
 edx; d097a41c _end+105bf270/18b86eb4
 edi; c03b8dec threadinfo+c/200
 ebp; d01e2000 _end+fe26e54/18b86eb4
 esp; d01e3f84 _end+fe28dd8/18b86eb4
Trace; c029dcbd CleanUpRequest+5d/70
Trace; c029f088 Userspace+68/a0
Trace; c029cfac MainDaemon+1fc/220
Trace; c010565e arch_kernel_thread+2e/40
Trace; c029cdb0 MainDaemon+0/220
Code;  c0116a36 remove_wait_queue+16/40
 _EIP:
Code;  c0116a36 remove_wait_queue+16/40   =
   0:   89 48 04  mov%ecx,0x4(%eax)   =
Code;  c0116a39 remove_wait_queue+19/40
   3:   89 01 mov%eax,(%ecx)
Code;  c0116a3b remove_wait_queue+1b/40
   5:   c7 43 04 00 00 00 00  movl   $0x0,0x4(%ebx)
Code;  c0116a42 remove_wait_queue+22/40
   c:   c7 42 08 00 00 00 00  movl   $0x0,0x8(%edx)
Code;  c0116a49 remove_wait_queue+29/40
  13:   56push   %esi
return value from sock_recvmsg in ReadRest() is unchecked. also the check 
for sock-sk==NULL is redundant and is done earlier anyway.

Thanks,
Youssef

Signed-off-by: Youssef Hmamouche [EMAIL PROTECTED]
--- /usr/src/linux-2.4.28-old/net/khttpd/misc.c 2001-02-09 11:29:44.0 
-0800
+++ /usr/src/linux-2.4.28/net/khttpd/misc.c 2005-03-13 14:32:39.0 
-0800
@@ -57,7 +57,7 @@
 before closing the socket.
 */
-static void ReadRest(struct socket *sock)
+static int ReadRest(struct socket *sock)
 {
struct msghdr   msg;
struct ioveciov;
@@ -69,9 +69,6 @@
EnterFunction(ReadRest);
-   if (sock-sk==NULL)
-   return;
-
len = 1;
while (len0)
@@ -94,8 +91,12 @@
oldfs = get_fs(); set_fs(KERNEL_DS);
len = sock_recvmsg(sock,msg,1024,MSG_DONTWAIT);
set_fs(oldfs);
+
+   if(len  0)
+   break;
}
LeaveFunction(ReadRest);
+   return len;
 }
@@ -107,12 +108,17 @@
 */
 void CleanUpRequest(struct http_request *Req)
 {
+   int len;
+
EnterFunction(CleanUpRequest);
-
+
/* Close the socket */
if ((Req-sock!=NULL)(Req-sock-sk!=NULL))
{
-   ReadRest(Req-sock);
+   if((len=ReadRest(Req-sock))0){
+   printk(KERN_ERR kHTTPd: error reading from socket\n);
+   goto out;
+   }
remove_wait_queue(Req-sock-sk-sleep,(Req-sleep));
sock_release(Req-sock);
}
@@ -124,7 +130,7 @@
Req-filp = NULL;
}
-
+  out:
/* ... and release the memory for the structure. */
kfree(Req);
-
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: [Linux-fbdev-devel] [announce 0/7] fbsplash - The Framebuffer Splash

2005-03-13 Thread Jon Smirl
On Sun, 13 Mar 2005 19:53:55 +0100 (CET), Geert Uytterhoeven
[EMAIL PROTECTED] wrote:
 On Sun, 13 Mar 2005, Pavel Machek wrote:
  Thats why moving the eye candy console into user space is such a 
  good
  idea. You don't have to run it 8) It also means that the console
  development is accessible to all the crazy rasterman types.

 Yep. The basic console we already have. Everyone who wants eye candy 
 can switch
 from basic console to user space console in early userspace.

   
Heh, I'm afraid it does not work like that. Anyone who wants eye-candy
simply applies broken patch to their kernel... unless their 
distribution applied one
already.
   
Situation where we have one working eye-candy patch would certainly
be an improvement.
  
   Why do we need patches in the kernel. Just set you config to
   CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or
   vgacon. Then have a userspace app using /dev/fb and /dev/input create a
   userland console. There is no need to do special hacks in the kernel.
 
  Except that I'll not get usefull reports from Oopsen and panic's,
  right? Ideally I'd also like high-priority kernel messages to be
  displayed during boot.
 
 Indeed. I thought the idea was to use the existing fbcon support to draw
 emergency messages to the screen.

That is the idea. I would like to even simplify the fbcon/dev even
more in this model and remove all in-kernel acceleration in fbdev. 
The user space console would be fully accelerated using DRM. If we
aren't using fbcon for normal console then it doesn't need to be
accelerated and that source of conflicts can be removed. fbcon would
be used for system recovery, OOPs, boot, kdbg, etc only kernel use, no
normal logins.


 
 Gr{oetje,eeting}s,
 
 Geert
 
 --
 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
 
 In personal conversations with technical people, I call myself a hacker. But
 when I'm talking to journalists I just say programmer or something like 
 that.
 -- Linus Torvalds
 
 ---
 SF email is sponsored by - The IT Product Guide
 Read honest  candid reviews on hundreds of IT Products from real users.
 Discover which products truly live up to the hype. Start reading now.
 http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
 ___
 Linux-fbdev-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
 


-- 
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Linus Torvalds


On Sun, 13 Mar 2005, Stas Sergeev wrote:

 Such an optimization will cost three more
 instructions, one of which is a taken
 jump.

I think Pavel missed the fact that you have to check the VM86 bit in
eflags before you check SS, since otherwise SS doesn't mean anything
special at all (ie checking for just the normal SS isn't correct: you
could have a 16-bit SS that looks normal, but is actually a vm86 segment).

Pavel: for the same reason you have to check the low two bits of CS too, 
since if they are zero, then SS hasn't been saved on the stack at all, so 
comparing it against some normal value is meaningless.

That said, the ldt_ss case should be moved _after_ the conditional
tests, since most CPU's out there will do static prediction based on
forward/backwards direction if the branch predictor isn't primed. And so
since it's an unusual case, the branch should be a forward branch, which
is usually the not-taken one (this depends on the core, of course, and you
could also add the prefix byte to mark it explicitly predict-not-taken for 
the newer cores that support it).

Linus
-
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 patch] unexport hugetlb_total_pages

2005-03-13 Thread William Lee Irwin III
On Sun, Mar 06, 2005 at 03:39:08PM +0100, Adrian Bunk wrote:
 I didn't find any possible modular usage in the kernel.
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Acked-by: William Irwin [EMAIL PROTECTED]


-- wli
-
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: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

2005-03-13 Thread Felix von Leitner
Thus spake Andrew Morton ([EMAIL PROTECTED]):
  My new nForce 4 mainboard has 10 or so USB 2.0 outlets.  In Windows,
  they all work.  In Linux, two of them work.  Putting my USB stick or
  anything else in one of the others produces nothing in Linux.
  Apparently no IRQ getting through or something?

 Did it work correctly on any earlier kernel?  If so, which one(s)?

It turns out the ports do work with 2.6.11; I was running rc4 when I
last observed it break.

Sorry for the bad bug report.

Felix
-
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: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

2005-03-13 Thread Felix von Leitner
Thus spake Andrew Morton ([EMAIL PROTECTED]):
  Finally Centrino SpeedStep.
  I have a Intel(R) Pentium(R) M processor 1.80GHz in my notebook.
  Linux does not support it.  This architecture has been out there for
  months now, and there even was a patch to support it posted here a in
  October last year or so.  Linux still does not include it.  Until
  2.6.11-rc4-bk8 or so, the old patched file from back then still worked.
  Now it doesn't.  Because some interface changed.  Now what?  Using a
  Centrino notebook without CPU throttling is completely out of the
  question.  Linux might as well not boot on it at all.
 Could you please dig out the old patch, send it?

I didn't keep the patch, but I kept the patched C file.
I'll attach it.

Felix


centrino-speedstep.tar.gz
Description: Binary data


Re: [2.6.11.3] gcc4 / psmouse.h - compilation fix.

2005-03-13 Thread Paul Jackson
Dmitry, responding to Pawe__:
  IMHO each header (e.g. psmouse.h) should include headers for types it uses.
  
 
 Hmm, I thought it was other way around 

I tend to agree with Pawe__ here.

There are two extremes here that I would avoid.  Do not try to include
in source files every header that is directly or indirectly needed, nor
try to minimize inclusions in header files by relying on every possible
prerequisite inclusion by the includers of that header.

Rather - think about the interface presented and used.

A source file should include headers for everything that it manifestly
makes use of (even if that means it happened to include something that
was also indirectly included elsewhere).  And no more.

A header file should provide all the inclusions that its users
(includers) will need to make use of what is in that header file,
without presuming that any user will already have included something
else.  And no less.

In this case, it seems that the header drivers/input/mouse/psmouse.h
requires the size of a struct ps2dev.  So I would think that psmouse.h
should include linux/libps2.h, as this patch provides for.  The users
of psmouse.h should not have to know of this dependency.

Respect the interfaces.  They are one of the means whereby we partial
out responsibility for keeping code sane, in the face of rapid,
conflicting changes from many developers across many architectures and
drivers, where no one individual can test all possible configurations.

A user of psmouse.h should not be required to include the libps2.h
header, because someday a user of psmouse.h that didn't do this, but was
working anyway because it happened to get libps2.h from some other
indirect inclusion, will get broken when someone working in a quite
different area happens to deprive our hapless psmouse.h user of its
libps2.h.

-- 
  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: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 16:19 +, Sean Neakums wrote:
 Both patches give me a successful sleep, although I had to alter the
 second to not #if 0 core99_ata100_enable -- there's another call to
 that function in pmac_feature.c's set_initial_features().
 
 I will try to gather some power numbers.

Thanks.

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: [PATCH] x86-64 kprobes: handle %RIP-relative addressing mode

2005-03-13 Thread Andrew Morton
Roland McGrath [EMAIL PROTECTED] wrote:

 + area = __get_vm_area(0, VM_ALLOC, MODULES_END, 0ULL - PAGE_SIZE);

The longlong here seems wrong?  If this is to mean the top of the address
space minus a page then unsigned long is the appropriate type.

-
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: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 19:07 +, Sean Neakums wrote:
 Sean Neakums [EMAIL PROTECTED] writes:
 
  Both patches give me a successful sleep, although I had to alter the
  second to not #if 0 core99_ata100_enable -- there's another call to
  that function in pmac_feature.c's set_initial_features().
 
  I will try to gather some power numbers.
 
 With the first patch, charge dropped by 33 over 52 minutes, 0.64/min.
 With the second patch, charge dropped by 65 over 80 minutes, 0.81/min.

Hi ! With the same initial charge ? The problem is that the drop isn't
really linear... Anyway, thanks for testing, so it would _seem_ that the
Darwin way isn't as efficient as what I did ;)

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: [PATCH][0/10] verify_area cleanup

2005-03-13 Thread Jesper Juhl
On Sun, 13 Mar 2005, William Lee Irwin III wrote:

 On Fri, Mar 04, 2005 at 03:47:07AM +0100, Jesper Juhl wrote:
  Now that 2.6.11 is out the door it's time to try and submit this again.
  The following patches convert all users of verify_area to access_ok and 
  the final patch then deprecates verify_area acros all archs with the 
  intention of removing it completely later. These patches get rid of 99+% 
  of all users, there's still one or two macros left using it and there are 
  still a few comments left refering to it that could be cleaned up - I'll 
  get to those, but what remains after these patches is extremely little.
  The reason for doing this is that verify_area is just a wrapper for 
  access_ok anyway, so there's no good reason to keep it around - access_ok 
  also seems more readable anyway with saner return values.
  Since these patches touch things all over the tree the CC list would be 
  enormous if I CC'd everyone involved on all patches, so I'll just CC this 
  initial mail to a few key people I think are relevant (I hope I got that 
  list right), and the actual patches I'll just send to linux-kernel and 
  Andrew (or directly to people who ask for that).
 
 The execution at first glance appears good. 

Thank you - Andrew found a few places where I'd messed up, but corrected 
those silently and merged the patches into -mm, so hopefully they can now 
get some proper testing.


Out of curiosity, does this
 serve a larger purpose than eliminating a redundant API?

No, it's a redundant API and one that seems harder to get right (judging 
from all the comments about fixing up incorrect verify_area use all over 
the place) than acces_ok. That's the only reason for getting rid of it.


-- 
Jesper

-
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] x86: fix ESP corruption CPU bug (take 2)

2005-03-13 Thread Stas Sergeev
Hello.
Linus Torvalds wrote:
I think Pavel missed the fact that you have to check the VM86 bit in
Ah, thanks, I must have forgotten the
essentials of the own patch :(
That said, the ldt_ss case should be moved _after_ the conditional
tests, since most CPU's out there will do static prediction based on
forward/backwards direction if the branch predictor isn't primed.
OK, I moved the ldt_ss below the check.
The new patch is attached.
Alan, can you please apply that to an -ac
tree?

Summary:
Attached patch works around the corruption
of the high word of the ESP register, which
is the official bug of x86 CPUs. The bug
triggers only when the one is using the
16bit stack segment, and is described here:
http://www.intel.com/design/intarch/specupdt/27287402.PDF
Acked-by: Linus Torvalds [EMAIL PROTECTED]
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Stas Sergeev [EMAIL PROTECTED]
diff -ur linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c linux-2.6.11-ac2-stk/arch/i386/kernel/cpu/common.c
--- linux-2.6.11-ac2/arch/i386/kernel/cpu/common.c	2005-03-13 17:59:45.0 +0300
+++ linux-2.6.11-ac2-stk/arch/i386/kernel/cpu/common.c	2005-03-13 20:36:12.0 +0300
@@ -21,6 +21,10 @@
 DEFINE_PER_CPU(struct desc_struct, cpu_gdt_table[GDT_ENTRIES]);
 EXPORT_PER_CPU_SYMBOL(cpu_gdt_table);
 
+unsigned char cpu_16bit_stack[CPU_16BIT_STACK_SIZE];
+DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
+EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
+
 static int cachesize_override __initdata = -1;
 static int disable_x86_fxsr __initdata = 0;
 static int disable_x86_serial_nr __initdata = 1;
@@ -557,6 +561,7 @@
 	int cpu = smp_processor_id();
 	struct tss_struct * t = per_cpu(init_tss, cpu);
 	struct thread_struct *thread = current-thread;
+	__u32 stk16_off = (__u32)per_cpu(cpu_16bit_stack, cpu);
 
 	if (cpu_test_and_set(cpu, cpu_initialized)) {
 		printk(KERN_WARNING CPU#%d already initialized!\n, cpu);
@@ -579,6 +584,13 @@
 	 */
 	memcpy(per_cpu(cpu_gdt_table, cpu), cpu_gdt_table,
 	   GDT_SIZE);
+
+	/* Set up GDT entry for 16bit stack */
+	*(__u64 *)(per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_ESPFIX_SS]) |=
+		__u64)stk16_off)  16)  0x00ffULL) |
+		__u64)stk16_off)  32)  0xff00ULL) |
+		(CPU_16BIT_STACK_SIZE - 1);
+
 	cpu_gdt_descr[cpu].size = GDT_SIZE - 1;
 	cpu_gdt_descr[cpu].address =
 	(unsigned long)per_cpu(cpu_gdt_table, cpu);
diff -ur linux-2.6.11-ac2/arch/i386/kernel/entry.S linux-2.6.11-ac2-stk/arch/i386/kernel/entry.S
--- linux-2.6.11-ac2/arch/i386/kernel/entry.S	2005-03-13 17:59:45.0 +0300
+++ linux-2.6.11-ac2-stk/arch/i386/kernel/entry.S	2005-03-14 00:45:16.0 +0300
@@ -47,6 +47,7 @@
 #include asm/segment.h
 #include asm/smp.h
 #include asm/page.h
+#include asm/desc.h
 #include irq_vectors.h
 
 #define nr_syscalls ((syscall_table_size)/4)
@@ -78,7 +79,7 @@
 #define preempt_stop		cli
 #else
 #define preempt_stop
-#define resume_kernel		restore_all
+#define resume_kernel		restore_nocheck
 #endif
 
 #define SAVE_ALL \
@@ -122,24 +123,6 @@
 .previous
 
 
-#define RESTORE_ALL	\
-	RESTORE_REGS	\
-	addl $4, %esp;	\
-1:	iret;		\
-.section .fixup,ax;   \
-2:	sti;		\
-	movl $(__USER_DS), %edx; \
-	movl %edx, %ds; \
-	movl %edx, %es; \
-	movl $11,%eax;	\
-	call do_exit;	\
-.previous;		\
-.section __ex_table,a;\
-	.align 4;	\
-	.long 1b,2b;	\
-.previous
-
-
 ENTRY(ret_from_fork)
 	pushl %eax
 	call schedule_tail
@@ -163,7 +146,7 @@
 	movl EFLAGS(%esp), %eax		# mix EFLAGS and CS
 	movb CS(%esp), %al
 	testl $(VM_MASK | 3), %eax
-	jz resume_kernel		# returning to kernel or vm86-space
+	jz resume_kernel
 ENTRY(resume_userspace)
  	cli# make sure we don't miss an interrupt
 	# setting need_resched or sigpending
@@ -178,7 +161,7 @@
 ENTRY(resume_kernel)
 	cli
 	cmpl $0,TI_preempt_count(%ebp)	# non-zero preempt_count ?
-	jnz restore_all
+	jnz restore_nocheck
 need_resched:
 	movl TI_flags(%ebp), %ecx	# need_resched set ?
 	testb $_TIF_NEED_RESCHED, %cl
@@ -257,8 +240,56 @@
 	movl TI_flags(%ebp), %ecx
 	testw $_TIF_ALLWORK_MASK, %cx	# current-work
 	jne syscall_exit_work
+
 restore_all:
-	RESTORE_ALL
+	movl EFLAGS(%esp), %eax		# mix EFLAGS, SS and CS
+	movb OLDSS(%esp), %ah
+	movb CS(%esp), %al
+	andl $(VM_MASK | (4  8) | 3), %eax
+	cmpl $((4  8) | 3), %eax
+	je ldt_ss			# returning to user-space with LDT SS
+restore_nocheck:
+	RESTORE_REGS
+	addl $4, %esp
+1:	iret
+.section .fixup,ax
+iret_exc:
+	sti
+	movl $__USER_DS, %edx
+	movl %edx, %ds
+	movl %edx, %es
+	movl $11,%eax
+	call do_exit
+.previous
+.section __ex_table,a
+	.align 4
+	.long 1b,iret_exc
+.previous
+
+ldt_ss:
+	larl OLDSS(%esp), %eax
+	jnz restore_nocheck
+	testl $0x0040, %eax		# returning to 32bit stack?
+	jnz restore_nocheck		# allright, normal return
+	/* If returning to userspace with 16bit stack,
+	 * try to fix the higher word of ESP, as the CPU
+	 * won't restore it.
+	 * This is an official bug of all the x86-compatible
+	 * CPUs, 

Re: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Sean Neakums
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:

 On Sun, 2005-03-13 at 19:07 +, Sean Neakums wrote:
 Sean Neakums [EMAIL PROTECTED] writes:
 
  Both patches give me a successful sleep, although I had to alter the
  second to not #if 0 core99_ata100_enable -- there's another call to
  that function in pmac_feature.c's set_initial_features().
 
  I will try to gather some power numbers.
 
 With the first patch, charge dropped by 33 over 52 minutes, 0.64/min.
 With the second patch, charge dropped by 65 over 80 minutes, 0.81/min.

 Hi ! With the same initial charge ? The problem is that the drop isn't
 really linear...

Oh, fiddlesticks, that didn't occur to me.  I can redo with overnight
sleeps on a full charge, if you like.

-- 
Dag vijandelijk luchtschip de huismeester is dood
-
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: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 22:08 +, Sean Neakums wrote:
 Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
 
  On Sun, 2005-03-13 at 19:07 +, Sean Neakums wrote:
  Sean Neakums [EMAIL PROTECTED] writes:
  
   Both patches give me a successful sleep, although I had to alter the
   second to not #if 0 core99_ata100_enable -- there's another call to
   that function in pmac_feature.c's set_initial_features().
  
   I will try to gather some power numbers.
  
  With the first patch, charge dropped by 33 over 52 minutes, 0.64/min.
  With the second patch, charge dropped by 65 over 80 minutes, 0.81/min.
 
  Hi ! With the same initial charge ? The problem is that the drop isn't
  really linear...
 
 Oh, fiddlesticks, that didn't occur to me.  I can redo with overnight
 sleeps on a full charge, if you like.

Yes, I would appreciate, thanks.

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: 2.6.11-mm3: machine check on sleep, PowerBook5.4

2005-03-13 Thread Benjamin Herrenschmidt

 Oh, fiddlesticks, that didn't occur to me.  I can redo with overnight
 sleeps on a full charge, if you like.

In the meantime, Andrew, please submit this one to Linus, I'll update
the stuff if it happens the other one gives better power consumptions:

--

This patch fixes a logic error in the ide-pmac driver which could try to
access the chip's fcr register after the cell clock has been shut down,
thus causing a machine check on machines with the Intrepid chipset.

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

Index: linux-work/drivers/ide/ppc/pmac.c
===
--- linux-work.orig/drivers/ide/ppc/pmac.c  2005-03-13 10:10:58.0 
+1100
+++ linux-work/drivers/ide/ppc/pmac.c   2005-03-13 23:29:40.0 +1100
@@ -1208,16 +1208,17 @@
if (pmif-mediabay)
return 0;

-   /* Disable the bus */
-   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id, 
0);
-
-   /* Kauai has it different */
+   /* Kauai has bus control FCRs directly here */
if (pmif-kauai_fcr) {
u32 fcr = readl(pmif-kauai_fcr);
fcr = ~(KAUAI_FCR_UATA_RESET_N | KAUAI_FCR_UATA_ENABLE);
writel(fcr, pmif-kauai_fcr);
}
 
+   /* Disable the bus on older machines and the cell on kauai */
+   ppc_md.feature_call(PMAC_FTR_IDE_ENABLE, pmif-node, pmif-aapl_bus_id,
+   0);
+
return 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: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-13 Thread Greg Stark
Patrick McFarland [EMAIL PROTECTED] writes:

 On Saturday 12 March 2005 01:31 pm, Greg Stark wrote:
  OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in
  2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is
  affected as well. This is with the Intel i810 drivers.
 
 Why are you not using ALSA?

Well frankly because whenever I tried it it didn't work. The i810 drivers were
*completely* broken in the 2.6 kernel I original installed, 2.6.5 I think.

In any case I understood that Quake doesn't work with alsa drivers because it
depends on mmapped output which they don't support at all. Or something like
that. I gave up on them when I found OSS worked reliably.

Until someone broke it between 2.6.6 and 2.6.9. How likely are the 2.6.6
drivers to compile with 2.6.10? Is it worth trying?

-- 
greg

-
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/


[ANNOUNCE] linux-libc-headers 2.6.11.0

2005-03-13 Thread Mariusz Mazur
Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- updated to 2.6.11 (added asm-frv)
- some minor fixes

The server hosting my page was down for a week or so. I don't provide any 
official mirrors, but you can get llh from anywhere (gazillions of 
LinuxFromScrach mirrors for example). I believe that should be enough 
(right?).

I bet somebody will ask what's with llh's vs. kernel's 2.6.x.y versioning, but 
let's just assume people can figure it out for themselves (iow -- I'll wait 
for the first actual question before I update llh's FAQ).


Happy hacking.

-- 
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
I'm pleased where man has been
Or tear it down, and start again
-
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]: Fix compiler warning in drivers/scsi/dpt_i2o.c

2005-03-13 Thread Stefan Roas
Hi there!

The attachted patch fixes a compiler warning in drivers/scsi/dpt_i2o.c.

If you reply to this post, please CC me as I'm not suscribed to the
list.

Best Regards

-- 
Stefan Roas
[EMAIL PROTECTED]
diff -rNu a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
--- a/drivers/scsi/dpt_i2o.c2005-03-02 14:01:26.910737000 +0100
+++ b/drivers/scsi/dpt_i2o.c2005-03-04 11:28:57.339003000 +0100
@@ -2027,8 +2027,8 @@
}
reply = (ulong)bus_to_virt(m);
 
-   if (readl(reply)  MSG_FAIL) {
-   u32 old_m = readl(reply+28); 
+   if (readl((void *)reply)  MSG_FAIL) {
+   u32 old_m = readl((void *)reply+28); 
ulong msg;
u32 old_context;
PDEBUG(%s: Failed message\n,pHba-name);
@@ -2039,34 +2039,34 @@
}
// Transaction context is 0 in failed reply frame
msg = (ulong)(pHba-msg_addr_virt + old_m);
-   old_context = readl(msg+12);
+   old_context = readl((void *)msg+12);
writel(old_context, reply+12);
adpt_send_nop(pHba, old_m);
} 
-   context = readl(reply+8);
+   context = readl((void *)reply+8);
if(context  0x4000){ // IOCTL
-   ulong p = (ulong)(readl(reply+12));
+   ulong p = (ulong)(readl((void *)reply+12));
if( p != 0) {
memcpy((void*)p, (void*)reply, REPLY_FRAME_SIZE 
* 4);
}
// All IOCTLs will also be post wait
}
if(context  0x8000){ // Post wait message
-   status = readl(reply+16);
+   status = readl((void *)reply+16);
if(status   24){
status =  0x; /* Get detail status */
} else {
status = I2O_POST_WAIT_OK;
}
if(!(context  0x4000)) {
-   cmd = (struct scsi_cmnd*) readl(reply+12); 
+   cmd = (struct scsi_cmnd*) readl((void 
*)reply+12); 
if(cmd != NULL) {
printk(KERN_WARNING%s: Apparent SCSI 
cmd in Post Wait Context - cmd=%p context=%x\n, pHba-name, cmd, context);
}
}
adpt_i2o_post_wait_complete(context, status);
} else { // SCSI message
-   cmd = (struct scsi_cmnd*) readl(reply+12); 
+   cmd = (struct scsi_cmnd*) readl((void *)reply+12); 
if(cmd != NULL){
if(cmd-serial_number != 0) { // If not timedout
adpt_i2o_to_scsi(reply, cmd);
@@ -2236,16 +2236,16 @@
adpt_hba* pHba;
u32 hba_status;
u32 dev_status;
-   u32 reply_flags = readl(reply)  0xff00; // Leave it shifted up 8 bits 
+   u32 reply_flags = readl((void *)reply)  0xff00; // Leave it shifted up 
8 bits 
// I know this would look cleaner if I just read bytes
// but the model I have been using for all the rest of the
// io is in 4 byte words - so I keep that model
-   u16 detailed_status = readl(reply+16) 0x;
+   u16 detailed_status = readl((void *)reply+16) 0x;
dev_status = (detailed_status  0xff);
hba_status = detailed_status  8;
 
// calculate resid for sg 
-   cmd-resid = cmd-request_bufflen - readl(reply+5);
+   cmd-resid = cmd-request_bufflen - readl((void *)reply+5);
 
pHba = (adpt_hba*) cmd-device-host-hostdata[0];
 
@@ -2256,7 +2256,7 @@
case I2O_SCSI_DSC_SUCCESS:
cmd-result = (DID_OK  16);
// handle underflow
-   if(readl(reply+5)  cmd-underflow ) {
+   if(readl((void *)reply+5)  cmd-underflow ) {
cmd-result = (DID_ERROR 16);
printk(KERN_WARNING%s: SCSI CMD 
underflow\n,pHba-name);
}


signature.asc
Description: Digital signature


Re: [PATCH] Add sysfs support to the IPMI driver

2005-03-13 Thread Corey Minyard
Greg KH wrote:
On Sat, Mar 12, 2005 at 10:57:24PM -0600, Corey Minyard wrote:
 

The IPMI driver has long needed to tie into the device model (and I've 
long been hoping someone else would do it).  I finally gave up and spent 
the time to learn how to do it.  I think this is right, it seems to work 
on on my system.
   

Looks good.  One minor question:
 

+
+	snprintf(name, sizeof(name), ipmi%d, if_num);
+	class_simple_device_add(ipmi_class, dev, NULL, name);
   

What do ipmi class devices live on?  pci devices?  i2c devices?
platform devices?  Or are they purely virtual things?
 

Good question.  I struggled with this for a little while and decided the 
class interface was important to have in first and I'd figure out the 
rest later.  They live in different places depending on the particular 
low-level interface.  Some live on the I2C bus (and will show up there 
in sysfs with the I2C driver).  Some live on the ISA bus, some are 
memory-mapped, some are on the PCI bus (though there is not a driver for 
PCI support yet), and some sit on the end of a serial port (driver is in 
the works).  I know, it's a mess, but there's not much I can do about 
these crazy hardware manufacturers.

I wasn't sure where to handle all this.  The I2C and PCI bus side of 
things should be handled.  However, the others probably need to sit 
someplace on a bus, right?  That should probably be handled in the 
low-level code that actually knows where the hardware sits.

Thanks,
-Corey
-
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] w6692 eliminate bad section references

2005-03-13 Thread maximilian attems
Fix w6692 section references:
  convert __initdata to __devinitdata.

Error: ./drivers/isdn/hisax/w6692.o .text refers to 002f R_386_32
.init.data

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-13 
23:36:34.0 +0100
@@ -45,7 +45,7 @@ const char *w6692_revision = $Revision:
 
 #define DBUSY_TIMER_VALUE 80
 
-static char *W6692Ver[] __initdata =
+static char *W6692Ver[] __devinitdata =
 {W6692 V00, W6692 V01, W6692 V10,
  W6692 V11};
 

-
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] x86: fix ESP corruption CPU bug

2005-03-13 Thread Pavel Machek
On Ne 13-03-05 13:13:16, Linus Torvalds wrote:
 
 
 On Sun, 13 Mar 2005, Stas Sergeev wrote:
 
  Such an optimization will cost three more
  instructions, one of which is a taken
  jump.
 
 I think Pavel missed the fact that you have to check the VM86 bit in
 eflags before you check SS, since otherwise SS doesn't mean anything
 special at all (ie checking for just the normal SS isn't correct: you
 could have a 16-bit SS that looks normal, but is actually a vm86 segment).
 
 Pavel: for the same reason you have to check the low two bits of CS too, 
 since if they are zero, then SS hasn't been saved on the stack at all, so 
 comparing it against some normal value is meaningless.

Yes, I missed that one, thanks.

What about flag similar to _TIF_SYSCALL_TRACE (call it
_TIF_THIS_BEAST_USES_V86 or something), and only do the tests in the
slowpath if it is set? As normal applications do not use v86, we could
make this 0 instructions in syscall fast path...
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/


  1   2   >