From owner-linux-arm-kernel@lists.arm.linux.org.uk Fri Sep 01 19:23:35 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13UvSH-000375-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Fri, 01 Sep 2000 19:22:21 +0100 Received: from [12.38.17.9] (helo=mail.aeptec.com) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13UvSG-00036y-00 for linux-arm-kernel@lists.arm.linux.org.uk; Fri, 01 Sep 2000 19:22:20 +0100 Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 14:11:50 -0400 Message-ID: <32CC5B62AF0BD2119E4C00A0C9663E221F3C21@MAIL> From: "Sun, Lei" To: "'linux-arm-kernel@lists.arm.linux.org.uk'" Subject: kernel oops.. error Date: Fri, 1 Sep 2000 14:11:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk Hi all: I have SA1110 Assabet and Neponset with linux 2.4.0-test4 running on it. In order to do data aquisition and control via the strong Arm board, I wrote a simple driver for DAQ1200 card(PCMCIA based). In testing my program, I can read the the data, it works just fine, however, if I let my program keep running for a hour or longer, the data read getting incorrect and finally, kernel oops error occured, system crashed. It seems like the driver has bug, but what confuse me is that why it work just fine initially and as the time flies by, it goes wrong? what can cause this problem? My application is just a loop to constantly read the data from file descriptor obtained by openning my device ( I implement it as a char device!). Can anybody give me a hint! regards Lei Sun unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Fri Sep 01 20:07:05 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13Uw9D-0004ga-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Fri, 01 Sep 2000 20:06:43 +0100 Received: from [12.38.17.9] (helo=mail.aeptec.com) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13Uw9C-0004gQ-00 for linux-arm-kernel@lists.arm.linux.org.uk; Fri, 01 Sep 2000 20:06:42 +0100 Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 14:56:13 -0400 Message-ID: <32CC5B62AF0BD2119E4C00A0C9663E221F3C22@MAIL> From: "Sun, Lei" To: "Sun, Lei" , "'linux-arm-kernel@lists.arm.linux.org.uk'" Subject: RE: kernel oops.. error Date: Fri, 1 Sep 2000 14:56:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk Hi: Forget the question I posted a while ago,I figured it out! Sorry for the trouble! THank you! lei -----Original Message----- From: Sun, Lei [mailto:Sun@AEPTEC.COM] Sent: Friday, September 01, 2000 2:12 PM To: 'linux-arm-kernel@lists.arm.linux.org.uk' Subject: kernel oops.. error Hi all: I have SA1110 Assabet and Neponset with linux 2.4.0-test4 running on it. In order to do data aquisition and control via the strong Arm board, I wrote a simple driver for DAQ1200 card(PCMCIA based). In testing my program, I can read the the data, it works just fine, however, if I let my program keep running for a hour or longer, the data read getting incorrect and finally, kernel oops error occured, system crashed. It seems like the driver has bug, but what confuse me is that why it work just fine initially and as the time flies by, it goes wrong? what can cause this problem? My application is just a loop to constantly read the data from file descriptor obtained by openning my device ( I implement it as a char device!). Can anybody give me a hint! regards Lei Sun unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Fri Sep 01 21:26:15 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13UxNz-0007nd-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Fri, 01 Sep 2000 21:26:03 +0100 Received: from [195.70.48.76] (helo=sun1.dps.hu) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13UxNy-0007nS-00 for linux-arm-kernel@lists.arm.linux.org.uk; Fri, 01 Sep 2000 21:26:02 +0100 Received: from guardwaresystems.com ([172.16.3.22]) by sun1.dps.hu (8.9.3+Sun/8.9.1) with ESMTP id WAA04669 for ; Fri, 1 Sep 2000 22:20:45 +0200 (MET DST) Message-ID: <39B0116B.8644A94D@guardwaresystems.com> Date: Fri, 01 Sep 2000 22:28:27 +0200 From: Andras Toth Reply-To: toth@sun1.dps.hu Organization: Guardware Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 CC: linux-arm-kernel@lists.arm.linux.org.uk Subject: ARM Linux and network layer References: <200008291425.QAA20110@duteinh.et.tudelft.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk Dear all, My name is Andras Toth, I am responsible for Linux development at my company. Please help me to find any solution to my problem below: I 've just managed to install )(and fix some bugs ) in Cirrus Logic ARM-Linux into EPD7212 Evaluation Board. This board also has an ethernet chip , so I tried to install an IP-capable Linux for it. BUT: We cannot use IP ( nor ICMP ) I do understand there is no official support for this port, but our project seems to be really important for us (we have to produce a demo board 2 weeks later) , so please help us or forward this request to whom it may concern: There are the protocols configured in the kernel , because during the boot process kernel says Protocols: ICMP,. UDP, TCP installed. Also says RT netlink socket OK. !!!!!!!!!!! The IP address is successfully obtained by RARP from the host PC, so there is no problem about this protocol ! !!!!!!!! According to the driver logs (and ifconfig packet counter results) the packets are transmitted and received but none of the underlying layers ( IP, ICMP ) can access them. For example, the host PC sends a ping ( echo request) to client (ARM) , the packet counter increases successfully but there is no answer sent. On trying the reverse direction ( from PC to ARM ) , ARM receives the packet and seems to send back something to the PC but there are no messages on the screen about it neither the PC nor the ARM side. If I install a socket server in the ARM, PC cannot access it. It is also impossible to 'log in' to a PC side server socket. Wolud ypou give me some tips to find the error in the kernel code ? How the net layer works exactly ? Is it possible to 'debug' some protocols ? Is it possible, that ethernet driver code 'traps' some protocols ? If not, where is the protocol 'dispathcer' in the kernel ? Thank you in advance, Andras Toth Software Engineer Guardware Systems Hungary unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 01:08:41 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13V0r2-0005tl-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 01:08:16 +0100 Received: from [158.152.145.93] (helo=willow.armlinux.org) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13V0qr-0005tG-00 for linux-arm-kernel@lists.arm.linux.org.uk; Sat, 02 Sep 2000 01:08:06 +0100 Received: by willow.armlinux.org (Postfix, from userid 1000) id 305C8FCAB5; Sat, 2 Sep 2000 01:08:05 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by willow.armlinux.org (Postfix) with ESMTP id 9C00D148DD9 for ; Sat, 2 Sep 2000 01:08:05 +0100 (BST) Date: Sat, 2 Sep 2000 01:08:04 +0100 (BST) From: Chris Rutter Reply-To: chris@fluff.org To: linux-arm-kernel@lists.arm.linux.org.uk Subject: VIDC video driver in 2.2.16-rmk2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk I've noticed something of an oddity; an fbset-set mode of 1024x768-70 in 16-bit depth (which, under RISC OS, comes out under the safe limit of 160Mb/s) seems to throw the video display into spasm, suggesting the VIDC's being strained past its limits. Anyone know the reason for this disparity? Also, with 3.3.5 of the fbdev X server and the said kernel, the problem where the virtual height is huge still persists. Is there a fix for this yet? c. unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 02:28:29 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13V25t-000799-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 02:27:41 +0100 Received: from [203.34.97.3] (helo=mail.ocs.com.au) by www.linux.org.uk with smtp (Exim 3.13 #1) id 13V25e-00078x-00 for linux-arm-kernel@lists.arm.linux.org.uk; Sat, 02 Sep 2000 02:27:27 +0100 Received: (qmail 6603 invoked from network); 2 Sep 2000 01:27:23 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Sep 2000 01:27:23 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-arm-kernel@lists.arm.linux.org.uk, linux-m68k@lists.linux-m68k.org, linux-mac68k@mac.linux-m68k.org, linuxppc-dev@lists.linuxppc.org, linux-mips@fnet.fr, sparclinux@vger.kernel.org, ultralinux@vger.kernel.org, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org, linux-vm@vm.marist.edu, gniibe@chroot.org, kkojima@rr.iij4u.or.jp Subject: 2.4.0 do_fork() change, all architectures Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Sep 2000 12:27:23 +1100 Message-ID: <8124.967858043@ocs3.ocs-net> Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk This patch hits every arch so it is being cross mailed to every arch mailing list, apologies for duplicates. Please trim replies to the relevant mailing list. Also please cc: kaos@ocs.com.au on replies, I am not on every list. IA64 needs an extra parameter on do_fork() and copy_thread(), those functions are globally defined but arch local so there are changes to every architecture. For everything except IA64, the extra parameter is unused and is specified as 0. Sparc assembler changes by DaveM, blame me for everything else. If nobody complains, this patch against 2.4.0-test8-pre1 will go to Linus on Monday evening GMT. Index: 0-test8-pre1.1/kernel/fork.c --- 0-test8-pre1.1/kernel/fork.c Tue, 29 Aug 2000 15:22:12 +1100 kaos (linux-2.4/j/35_fork.c 1.1.1.9.1.6 644) +++ 0-test8-pre1.1(w)/kernel/fork.c Sat, 02 Sep 2000 11:34:02 +1100 kaos (linux-2.4/j/35_fork.c 1.1.1.9.1.6 644) @@ -528,10 +528,15 @@ /* * Ok, this is the main fork-routine. It copies the system process - * information (task[nr]) and sets up the necessary registers. It - * also copies the data segment in its entirety. + * information (task[nr]) and sets up the necessary registers. It also + * copies the data segment in its entirety. The "stack_start" and + * "stack_top" arguments are simply passed along to the platform + * specific copy_thread() routine. Most platforms ignore stack_top. + * For an example that's using stack_top, see + * arch/ia64/kernel/process.c. */ -int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs) +int do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long stack_top, + struct pt_regs *regs) { int retval = -ENOMEM; struct task_struct *p; @@ -628,7 +633,7 @@ goto bad_fork_cleanup_fs; if (copy_mm(clone_flags, p)) goto bad_fork_cleanup_sighand; - retval = copy_thread(0, clone_flags, usp, p, regs); + retval = copy_thread(0, clone_flags, stack_start, stack_top, p, regs); if (retval) goto bad_fork_cleanup_sighand; p->semundo = NULL; Index: 0-test8-pre1.1/include/linux/sched.h --- 0-test8-pre1.1/include/linux/sched.h Tue, 29 Aug 2000 15:22:12 +1100 kaos (linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644) +++ 0-test8-pre1.1(w)/include/linux/sched.h Sat, 02 Sep 2000 11:45:41 +1100 kaos (linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644) @@ -708,7 +708,7 @@ extern int expand_fdset(struct files_struct *, int nr); extern void free_fdset(fd_set *, int); -extern int copy_thread(int, unsigned long, unsigned long, struct task_struct *, struct pt_regs *); +extern int copy_thread(int, unsigned long, unsigned long, unsigned long, struct task_struct *, struct pt_regs *); extern void flush_thread(void); extern void exit_thread(void); @@ -719,7 +719,7 @@ extern void daemonize(void); extern int do_execve(char *, char **, char **, struct pt_regs *); -extern int do_fork(unsigned long, unsigned long, struct pt_regs *); +extern int do_fork(unsigned long, unsigned long, unsigned long, struct pt_regs *); extern void FASTCALL(add_wait_queue(wait_queue_head_t *q, wait_queue_t * wait)); extern void FASTCALL(add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t * wait)); Index: 0-test8-pre1.1/arch/s390/kernel/smp.c --- 0-test8-pre1.1/arch/s390/kernel/smp.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/Y/b/24_smp.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/s390/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/Y/b/24_smp.c 1.2 644) @@ -528,7 +528,7 @@ /* don't care about the psw and regs settings since we'll never reschedule the forked task. */ memset(®s,sizeof(pt_regs),0); - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } static void __init do_boot_cpu(int cpu) Index: 0-test8-pre1.1/arch/s390/kernel/process.c --- 0-test8-pre1.1/arch/s390/kernel/process.c Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/Y/b/35_process.c 1.2.1.1 644) +++ 0-test8-pre1.1(w)/arch/s390/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/Y/b/35_process.c 1.2.1.1 644) @@ -264,6 +264,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long new_stackp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct stack_frame @@ -313,7 +314,7 @@ int ret; lock_kernel(); - ret = do_fork(SIGCHLD, regs.gprs[15], ®s); + ret = do_fork(SIGCHLD, regs.gprs[15], 0, ®s); unlock_kernel(); return ret; } @@ -329,7 +330,7 @@ newsp = regs.gprs[2]; if (!newsp) newsp = regs.gprs[15]; - ret = do_fork(clone_flags, newsp, ®s); + ret = do_fork(clone_flags, newsp, 0, ®s); unlock_kernel(); return ret; } @@ -347,7 +348,7 @@ asmlinkage int sys_vfork(struct pt_regs regs) { return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, - regs.gprs[15], ®s); + regs.gprs[15], 0, ®s); } /* Index: 0-test8-pre1.1/arch/mips64/kernel/syscall.c --- 0-test8-pre1.1/arch/mips64/kernel/syscall.c Tue, 01 Aug 2000 16:55:46 +1000 kaos (linux-2.4/a/c/16_syscall.c 1.1.1.4 644) +++ 0-test8-pre1.1(w)/arch/mips64/kernel/syscall.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/a/c/16_syscall.c 1.1.1.4 644) @@ -77,7 +77,7 @@ int res; save_static(®s); - res = do_fork(SIGCHLD, regs.regs[29], ®s); + res = do_fork(SIGCHLD, regs.regs[29], 0, ®s); return res; } @@ -92,7 +92,7 @@ newsp = regs.regs[5]; if (!newsp) newsp = regs.regs[29]; - res = do_fork(clone_flags, newsp, ®s); + res = do_fork(clone_flags, newsp, 0, ®s); return res; } Index: 0-test8-pre1.1/arch/mips64/kernel/process.c --- 0-test8-pre1.1/arch/mips64/kernel/process.c Thu, 13 Jul 2000 18:35:31 +1000 kaos (linux-2.4/a/c/31_process.c 1.5 644) +++ 0-test8-pre1.1(w)/arch/mips64/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/a/c/31_process.c 1.5 644) @@ -69,6 +69,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/sh/kernel/process.c --- 0-test8-pre1.1/arch/sh/kernel/process.c Sat, 22 Jul 2000 18:25:55 +1000 kaos (linux-2.4/d/c/21_process.c 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/sh/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/d/c/21_process.c 1.1.1.3 644) @@ -211,6 +211,7 @@ asmlinkage void ret_from_fork(void); int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct pt_regs *childregs; @@ -292,7 +293,7 @@ unsigned long r6, unsigned long r7, struct pt_regs regs) { - return do_fork(SIGCHLD, regs.regs[15], ®s); + return do_fork(SIGCHLD, regs.regs[15], 0, ®s); } asmlinkage int sys_clone(unsigned long clone_flags, unsigned long newsp, @@ -301,7 +302,7 @@ { if (!newsp) newsp = regs.regs[15]; - return do_fork(clone_flags, newsp, ®s); + return do_fork(clone_flags, newsp, 0, ®s); } /* @@ -318,7 +319,7 @@ unsigned long r6, unsigned long r7, struct pt_regs regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.regs[15], ®s); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.regs[15], 0, ®s); } /* Index: 0-test8-pre1.1/arch/arm/kernel/process.c --- 0-test8-pre1.1/arch/arm/kernel/process.c Tue, 15 Aug 2000 17:59:12 +1000 kaos (linux-2.4/f/c/43_process.c 1.1.1.5 644) +++ 0-test8-pre1.1(w)/arch/arm/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/f/c/43_process.c 1.1.1.5 644) @@ -291,6 +291,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long esp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/arm/kernel/sys_arm.c --- 0-test8-pre1.1/arch/arm/kernel/sys_arm.c Wed, 19 Jul 2000 17:53:13 +1000 kaos (linux-2.4/f/c/50_sys_arm.c 1.4 644) +++ 0-test8-pre1.1(w)/arch/arm/kernel/sys_arm.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/f/c/50_sys_arm.c 1.4 644) @@ -203,7 +203,7 @@ */ asmlinkage int sys_fork(struct pt_regs *regs) { - return do_fork(SIGCHLD, regs->ARM_sp, regs); + return do_fork(SIGCHLD, regs->ARM_sp, 0, regs); } /* Clone a task - this clones the calling program thread. @@ -213,12 +213,12 @@ { if (!newsp) newsp = regs->ARM_sp; - return do_fork(clone_flags, newsp, regs); + return do_fork(clone_flags, newsp, 0, regs); } asmlinkage int sys_vfork(struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->ARM_sp, regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->ARM_sp, 0, regs); } /* sys_execve() executes a new program. Index: 0-test8-pre1.1/arch/sparc64/kernel/entry.S --- 0-test8-pre1.1/arch/sparc64/kernel/entry.S Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/i/c/20_entry.S 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/sparc64/kernel/entry.S Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/i/c/20_entry.S 1.1.1.3 644) @@ -911,7 +911,7 @@ mov SIGCHLD, %o0 sys_clone: flushw movrz %o1, %fp, %o1 - nop + mov 0, %o3 ba,pt %xcc, do_fork add %sp, STACK_BIAS + REGWIN_SZ, %o2 ret_from_syscall: Index: 0-test8-pre1.1/arch/sparc64/kernel/process.c --- 0-test8-pre1.1/arch/sparc64/kernel/process.c Thu, 24 Aug 2000 03:13:10 +1000 kaos (linux-2.4/i/c/25_process.c 1.6 644) +++ 0-test8-pre1.1(w)/arch/sparc64/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/i/c/25_process.c 1.6 644) @@ -573,6 +573,7 @@ * do_fork(). */ int copy_thread(int nr, unsigned long clone_flags, unsigned long sp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct thread_struct *t = &p->thread; Index: 0-test8-pre1.1/arch/m68k/kernel/process.c --- 0-test8-pre1.1/arch/m68k/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/l/c/42_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/m68k/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/l/c/42_process.c 1.2 644) @@ -181,12 +181,12 @@ asmlinkage int m68k_fork(struct pt_regs *regs) { - return do_fork(SIGCHLD, rdusp(), regs); + return do_fork(SIGCHLD, rdusp(), 0, regs); } asmlinkage int m68k_vfork(struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), 0, regs); } asmlinkage int m68k_clone(struct pt_regs *regs) @@ -199,10 +199,11 @@ newsp = regs->d2; if (!newsp) newsp = rdusp(); - return do_fork(clone_flags, newsp, regs); + return do_fork(clone_flags, newsp, 0, regs); } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/ppc/kernel/smp.c --- 0-test8-pre1.1/arch/ppc/kernel/smp.c Fri, 14 Jul 2000 19:35:46 +1000 kaos (linux-2.4/q/c/36_smp.c 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/ppc/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/q/c/36_smp.c 1.1.1.3 644) @@ -347,7 +347,7 @@ /* create a process for the processor */ /* we don't care about the values in regs since we'll never reschedule the forked task. */ - if (do_fork(CLONE_VM|CLONE_PID, 0, ®s) < 0) + if (do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s) < 0) panic("failed fork for CPU %d", i); p = init_task.prev_task; if (!p) Index: 0-test8-pre1.1/arch/ppc/kernel/process.c --- 0-test8-pre1.1/arch/ppc/kernel/process.c Wed, 21 Jun 2000 12:24:29 +1000 kaos (linux-2.4/r/c/11_process.c 1.1.1.1 644) +++ 0-test8-pre1.1(w)/arch/ppc/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/r/c/11_process.c 1.1.1.1 644) @@ -315,6 +315,7 @@ */ int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { unsigned long msr; @@ -446,7 +447,7 @@ unsigned long clone_flags = p1; int res; lock_kernel(); - res = do_fork(clone_flags, regs->gpr[1], regs); + res = do_fork(clone_flags, regs->gpr[1], 0, regs); #ifdef CONFIG_SMP /* When we clone the idle task we keep the same pid but * the return value of 0 for both causes problems. @@ -465,7 +466,7 @@ int res; - res = do_fork(SIGCHLD, regs->gpr[1], regs); + res = do_fork(SIGCHLD, regs->gpr[1], 0, regs); #ifdef CONFIG_SMP /* When we clone the idle task we keep the same pid but * the return value of 0 for both causes problems. @@ -480,7 +481,7 @@ asmlinkage int sys_vfork(int p1, int p2, int p3, int p4, int p5, int p6, struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->gpr[1], regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->gpr[1], 0, regs); } asmlinkage int sys_execve(unsigned long a0, unsigned long a1, unsigned long a2, Index: 0-test8-pre1.1/arch/mips/kernel/syscall.c --- 0-test8-pre1.1/arch/mips/kernel/syscall.c Tue, 11 Jul 2000 00:21:05 +1000 kaos (linux-2.4/u/c/17_syscall.c 1.3 644) +++ 0-test8-pre1.1(w)/arch/mips/kernel/syscall.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/u/c/17_syscall.c 1.3 644) @@ -97,7 +97,7 @@ int res; save_static(®s); - res = do_fork(SIGCHLD, regs.regs[29], ®s); + res = do_fork(SIGCHLD, regs.regs[29], 0, ®s); return res; } @@ -112,7 +112,7 @@ newsp = regs.regs[5]; if (!newsp) newsp = regs.regs[29]; - res = do_fork(clone_flags, newsp, ®s); + res = do_fork(clone_flags, newsp, 0, ®s); return res; } Index: 0-test8-pre1.1/arch/mips/kernel/process.c --- 0-test8-pre1.1/arch/mips/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/u/c/26_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/mips/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/u/c/26_process.c 1.2 644) @@ -72,6 +72,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/sparc/kernel/process.c --- 0-test8-pre1.1/arch/sparc/kernel/process.c Wed, 12 Jul 2000 11:58:08 +1000 kaos (linux-2.4/w/c/50_process.c 1.4 644) +++ 0-test8-pre1.1(w)/arch/sparc/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/w/c/50_process.c 1.4 644) @@ -462,6 +462,7 @@ #endif int copy_thread(int nr, unsigned long clone_flags, unsigned long sp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct pt_regs *childregs; Index: 0-test8-pre1.1/arch/sparc/kernel/entry.S --- 0-test8-pre1.1/arch/sparc/kernel/entry.S Wed, 21 Jun 2000 12:24:29 +1000 kaos (linux-2.4/x/c/6_entry.S 1.1.1.1 644) +++ 0-test8-pre1.1(w)/arch/sparc/kernel/entry.S Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/x/c/6_entry.S 1.1.1.1 644) @@ -1391,6 +1391,7 @@ mov %fp, %o1 ! arg1: usp std %g4, [%curptr + AOFF_task_thread + AOFF_thread_fork_kpsr] add %sp, REGWIN_SZ, %o2 ! arg2: pt_regs ptr + mov 0, %o3 call C_LABEL(do_fork) mov %l5, %o7 @@ -1413,6 +1414,7 @@ 1: std %g4, [%curptr + AOFF_task_thread + AOFF_thread_fork_kpsr] add %sp, REGWIN_SZ, %o2 ! arg2: pt_regs ptr + mov 0, %o3 call C_LABEL(do_fork) mov %l5, %o7 @@ -1430,6 +1432,7 @@ mov %fp, %o1 or %o0, %lo(0x4000 | 0x0100 | SIGCHLD), %o0 sethi %hi(C_LABEL(do_fork)), %l1 + mov 0, %o3 jmpl %l1 + %lo(C_LABEL(do_fork)), %g0 add %sp, REGWIN_SZ, %o2 Index: 0-test8-pre1.1/arch/alpha/kernel/smp.c --- 0-test8-pre1.1/arch/alpha/kernel/smp.c Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/y/c/9_smp.c 1.1.1.2.1.2 644) +++ 0-test8-pre1.1(w)/arch/alpha/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/y/c/9_smp.c 1.1.1.2.1.2 644) @@ -420,7 +420,7 @@ * don't care about the regs settings since * we'll never reschedule the forked task. */ - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } /* Index: 0-test8-pre1.1/arch/alpha/kernel/process.c --- 0-test8-pre1.1/arch/alpha/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/y/c/13_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/alpha/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/y/c/13_process.c 1.2 644) @@ -276,14 +276,14 @@ { if (!usp) usp = rdusp(); - return do_fork(clone_flags, usp, (struct pt_regs *) (swstack+1)); + return do_fork(clone_flags, usp, 0, (struct pt_regs *) (swstack+1)); } int alpha_vfork(struct switch_stack * swstack) { return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), - (struct pt_regs *) (swstack+1)); + 0, (struct pt_regs *) (swstack+1)); } /* @@ -299,6 +299,7 @@ int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { extern void ret_from_sys_call(void); Index: 0-test8-pre1.1/arch/i386/kernel/smpboot.c --- 0-test8-pre1.1/arch/i386/kernel/smpboot.c Thu, 24 Aug 2000 03:13:10 +1000 kaos (linux-2.4/z/c/29_smpboot.c 1.1.1.2 644) +++ 0-test8-pre1.1(w)/arch/i386/kernel/smpboot.c Sat, 02 Sep 2000 11:30:30 +1100 kaos (linux-2.4/z/c/29_smpboot.c 1.1.1.2 644) @@ -497,7 +497,7 @@ * don't care about the eip and regs settings since * we'll never reschedule the forked task. */ - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } #if APIC_DEBUG Index: 0-test8-pre1.1/arch/i386/kernel/process.c --- 0-test8-pre1.1/arch/i386/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/z/c/47_process.c 1.1.2.3.1.1.1.2 644) +++ 0-test8-pre1.1(w)/arch/i386/kernel/process.c Sat, 02 Sep 2000 11:31:25 +1100 kaos (linux-2.4/z/c/47_process.c 1.1.2.3.1.1.1.2 644) @@ -525,6 +525,7 @@ asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value))) int copy_thread(int nr, unsigned long clone_flags, unsigned long esp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; @@ -686,7 +687,7 @@ asmlinkage int sys_fork(struct pt_regs regs) { - return do_fork(SIGCHLD, regs.esp, ®s); + return do_fork(SIGCHLD, regs.esp, 0, ®s); } asmlinkage int sys_clone(struct pt_regs regs) @@ -698,7 +699,7 @@ newsp = regs.ecx; if (!newsp) newsp = regs.esp; - return do_fork(clone_flags, newsp, ®s); + return do_fork(clone_flags, newsp, 0, ®s); } /* @@ -713,7 +714,7 @@ */ asmlinkage int sys_vfork(struct pt_regs regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.esp, ®s); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.esp, 0, ®s); } /* unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 03:19:21 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13V2tQ-0007je-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 03:18:52 +0100 Received: from [203.34.97.3] (helo=mail.ocs.com.au) by www.linux.org.uk with smtp (Exim 3.13 #1) id 13V2tN-0007jD-00 for linux-arm-kernel@lists.arm.linux.org.uk; Sat, 02 Sep 2000 03:18:50 +0100 Received: (qmail 7031 invoked from network); 2 Sep 2000 02:18:47 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Sep 2000 02:18:47 -0000 Date: Sat, 02 Sep 2000 13:18:46 +1100 Message-ID: <8893.967861126@ocs3.ocs-net> From: Keith Owens Subject: 2.4.0 do_fork() change, all architectures - take 2 BCC: Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk ------- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-kernel@vger.kernel.org Subject: 2.4.0 do_fork() change, all architectures - take 2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Sep 2000 13:18:46 +1100 Message-ID: <8893.967861126@ocs3.ocs-net> DaveM pointed out that my 2.4.0-test8-pre1 do_fork patch would generate better sparc assembler if the extra parameter to do_fork was added at the end instead of in the middle. So change all do_fork(flags,sp,0,®s) to do_fork(flags,sp,®s,0); I'm not going to mail the complete patch again, you can get it from ftp://ftp.ocs.com.au/pub/do_fork-2.4.0-test8-take2.gz. The only significant difference is this bit to IA64, untested. Index: 0-test8-pre1.1/arch/ia64/kernel/entry.S - --- 0-test8-pre1.1/arch/ia64/kernel/entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos (linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644) +++ 0-test8-pre1.2(w)/arch/ia64/kernel/entry.S Sat, 02 Sep 2000 12:49:16 +1100 kaos (linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644) @@ -68,8 +68,8 @@ mov loc1=r16 // save ar.pfs across do_fork UNW(.body) mov out1=in1 - - mov out2=in2 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp // out3 = ®s + mov out3=in2 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s mov out0=in0 // out0 = clone_flags br.call.sptk.few rp=do_fork .ret1: UNW(.restore sp) @@ -87,8 +87,8 @@ mov loc1=r16 // save ar.pfs across do_fork UNW(.body) mov out1=in1 - - mov out2=0 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp // out3 = ®s + mov out3=0 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s mov out0=in0 // out0 = clone_flags br.call.sptk.few rp=do_fork .ret2: UNW(.restore sp) Index: 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S - --- 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos (linux-2.4/c/c/25_ia32_entry 1.3.1.1 644) +++ 0-test8-pre1.2(w)/arch/ia64/ia32/ia32_entry.S Sat, 02 Sep 2000 12:49:58 +1100 kaos (linux-2.4/c/c/25_ia32_entry 1.3.1.1 644) @@ -91,8 +91,8 @@ UNW(.body) mov out1=0 - - mov out2=0 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp + mov out3=0 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s br.call.sptk.few rp=do_fork .ret3: mov ar.pfs=loc1 UNW(.restore sp) ------- End of Blind-Carbon-Copy unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 09:18:51 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13V8UR-0003yi-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 09:17:27 +0100 Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13V8UO-0003yZ-00; Sat, 02 Sep 2000 09:17:24 +0100 Received: from flint.arm.linux.org.uk (root@flint [192.168.0.4]) by caramon.arm.linux.org.uk (8.9.3/8.9.3) with ESMTP id JAA32168; Sat, 2 Sep 2000 09:06:15 +0100 Received: (from linux@localhost) by flint.arm.linux.org.uk (8.9.3/8.9.3) id JAA07105; Sat, 2 Sep 2000 09:04:54 +0100 From: Russell King - ARM Linux Admin Message-Id: <200009020804.JAA07105@flint.arm.linux.org.uk> Subject: Re: VIDC video driver in 2.2.16-rmk2 To: chris@fluff.org Date: Sat, 2 Sep 2000 09:04:54 +0100 (BST) Cc: linux-arm-kernel@lists.arm.linux.org.uk In-Reply-To: from "Chris Rutter" at Sep 02, 2000 01:08:04 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk Chris Rutter writes: > I've noticed something of an oddity; an fbset-set mode of 1024x768-70 > in 16-bit depth (which, under RISC OS, comes out under the safe limit > of 160Mb/s) seems to throw the video display into spasm, suggesting > the VIDC's being strained past its limits. Anyone know the reason for > this disparity? fbset uses a different database from RISC OS - you may want to look in your fb.modes file to see what the dotclock and other parameters are, and how they compare to the RISC OS setting. > Also, with 3.3.5 of the fbdev X server and the said kernel, the problem > where the virtual height is huge still persists. Is there a fix for > this yet? The kernel won't be fixed, because its not a kernel problem. Its a fbdev problem, trying to use text mode acceleration on what is obviously a graphics console. In other words, someone will have to fix the fbdev X server. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King linux@arm.linux.org.uk --- --- | | | | http://www.arm.linux.org.uk/ / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 12:57:59 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13VBvE-0006J7-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 12:57:20 +0100 Received: from [158.152.145.93] (helo=willow.armlinux.org) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13VBvC-0006J1-00 for linux-arm-kernel@lists.arm.linux.org.uk; Sat, 02 Sep 2000 12:57:18 +0100 Received: by willow.armlinux.org (Postfix, from userid 1000) id 7A96EFCAB5; Sat, 2 Sep 2000 12:57:17 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by willow.armlinux.org (Postfix) with ESMTP id 0AD60148C1D; Sat, 2 Sep 2000 12:57:16 +0100 (BST) Date: Sat, 2 Sep 2000 12:57:16 +0100 (BST) From: Chris Rutter Reply-To: chris@fluff.org To: Russell King - ARM Linux Admin Cc: linux-arm-kernel@lists.arm.linux.org.uk Subject: Re: VIDC video driver in 2.2.16-rmk2 In-Reply-To: <200009020804.JAA07105@flint.arm.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk On Sat, 2 Sep 2000, Russell King - ARM Linux Admin wrote: > fbset uses a different database from RISC OS - you may want to look in > your fb.modes file to see what the dotclock and other parameters are, and > how they compare to the RISC OS setting. Indeed. Well, what my fb.modes says (it's the standard `ATI' one) is: # 1024x768, 75Hz, Non-Interlaced (78.75 MHz dotclock) # # [...] mode "1024x768-75" # D: 78.75 MHz, H: 60.023 kHz, V: 75.03 Hz geometry 1024 768 1024 768 8 timings 12699 176 16 28 1 96 3 hsync high vsync high endmode The 1024x768 @ 75Hz mode I use in RISC OS apparently has a `pixel rate' of 80310, and a bandwidth of 160MB/sec in 16 bpp, which is stable on my VIDC. I'm afraid my knowledge is lacking about the meaning of the majority of these terms. :-/ > The kernel won't be fixed, because its not a kernel problem. Its a fbdev > problem, trying to use text mode acceleration on what is obviously a > graphics console. > > In other words, someone will have to fix the fbdev X server. Ah, right; I seem to recall a change in the ARM kernel posted a few months ago titled `virtual height problem fixed' or something: was that not the whole problem, or unrelated? I'll try the patch for the userland stuff recently posted to the list. c. unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sat Sep 02 13:09:53 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13VC7D-0006Xd-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sat, 02 Sep 2000 13:09:43 +0100 Received: from dyn-33.linux.theplanet.co.uk ([195.92.244.33] helo=caramon.arm.linux.org.uk) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13VC7A-0006XV-00; Sat, 02 Sep 2000 13:09:41 +0100 Received: from flint.arm.linux.org.uk (root@flint [192.168.0.4]) by caramon.arm.linux.org.uk (8.9.3/8.9.3) with ESMTP id NAA00918; Sat, 2 Sep 2000 13:09:42 +0100 Received: (from linux@localhost) by flint.arm.linux.org.uk (8.9.3/8.9.3) id NAA08547; Sat, 2 Sep 2000 13:08:20 +0100 From: Russell King - ARM Linux Admin Message-Id: <200009021208.NAA08547@flint.arm.linux.org.uk> Subject: Re: VIDC video driver in 2.2.16-rmk2 To: chris@fluff.org Date: Sat, 2 Sep 2000 13:08:20 +0100 (BST) Cc: linux-arm-kernel@lists.arm.linux.org.uk In-Reply-To: from "Chris Rutter" at Sep 02, 2000 12:57:16 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk Chris Rutter writes: > The 1024x768 @ 75Hz mode I use in RISC OS apparently has a `pixel rate' > of 80310, and a bandwidth of 160MB/sec in 16 bpp, which is stable on my > VIDC. I'm afraid my knowledge is lacking about the meaning of the > majority of these terms. :-/ Well, that mode is using a pixel rate of 78.746MHz, so it should be within the bandwidth. Hmm, I'll look more closely - which kernel version are you using, and has this been brought on by changing kernel versions? > Ah, right; I seem to recall a change in the ARM kernel posted a few > months ago titled `virtual height problem fixed' or something: was > that not the whole problem, or unrelated? It was related; that change was to stop the kernel setting the virtual height no matter what. It now only sets it if you want text-mode acceleration, which, when you're doing graphics should not be enabled. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King linux@arm.linux.org.uk --- --- | | | | http://www.arm.linux.org.uk/ / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk From owner-linux-arm-kernel@lists.arm.linux.org.uk Sun Sep 03 16:40:20 2000 Received: from majordomo by www.linux.org.uk with local (Exim 3.13 #1) id 13Vbpa-0002rL-00 for linux-arm-kernel-outgoingx@www.linux.org.uk; Sun, 03 Sep 2000 16:37:14 +0100 Received: from [158.152.145.93] (helo=willow.armlinux.org) by www.linux.org.uk with esmtp (Exim 3.13 #1) id 13VbpZ-0002rC-00 for linux-arm-kernel@lists.arm.linux.org.uk; Sun, 03 Sep 2000 16:37:13 +0100 Received: by willow.armlinux.org (Postfix, from userid 1000) id 524DBFCAB5; Sun, 3 Sep 2000 16:37:13 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by willow.armlinux.org (Postfix) with ESMTP id E27C5148C2A; Sun, 3 Sep 2000 16:37:13 +0100 (BST) Date: Sun, 3 Sep 2000 16:37:13 +0100 (BST) From: Chris Rutter Reply-To: chris@fluff.org To: Russell King - ARM Linux Admin Cc: linux-arm-kernel@lists.arm.linux.org.uk Subject: Re: VIDC video driver in 2.2.16-rmk2 In-Reply-To: <200009021208.NAA08547@flint.arm.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm-kernel@lists.arm.linux.org.uk Precedence: bulk On Sat, 2 Sep 2000, Russell King - ARM Linux Admin wrote: > Well, that mode is using a pixel rate of 78.746MHz, so it should be within > the bandwidth. Hmm, I'll look more closely - which kernel version are > you using, and has this been brought on by changing kernel versions? It's in 2.2.16-rmk2; as I /recall/, earlier 2.2 kernels from a few months ago did the same thing. > It was related; that change was to stop the kernel setting the virtual > height no matter what. It now only sets it if you want text-mode > acceleration, which, when you're doing graphics should not be enabled. Ah, righty, so the user-land patch is the currently-appropriate one. Great. c. unsubscribe: body of `unsubscribe linux-arm-kernel' to majordomo@lists.arm.linux.org.uk