From anemo@mba.ocn.ne.jp Mon Jan 2 12:58:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Jan 2006 12:58:30 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:51429 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133394AbWABM6K (ORCPT ); Mon, 2 Jan 2006 12:58:10 +0000 Received: from localhost (p6207-ipad27funabasi.chiba.ocn.ne.jp [220.107.197.207]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id AD3303953; Mon, 2 Jan 2006 22:00:23 +0900 (JST) Date: Mon, 02 Jan 2006 21:59:49 +0900 (JST) Message-Id: <20060102.215949.41198615.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: dom@mips.com, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: ieee754[sd]p_neg workaround From: Atsushi Nemoto In-Reply-To: <20050421.161945.79301612.nemoto@toshiba-tops.co.jp> References: <16998.20933.14301.397793@arsenal.mips.com> <20050420131304.GF5212@linux-mips.org> <20050421.161945.79301612.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Thu, 21 Apr 2005 16:19:45 +0900 (JST), Atsushi Nemoto said: >>> So file a bug against glibc, but we should fix the emulator so it >>> correctly imitates the MIPS instruction set... ralf> As a matter of defensive design I think we should try to follow ralf> the establish behaviour if nothing more specific is defined ralf> anywhere. anemo> OK, I sent a bug reoport to glibc bugzilla. (Bug# 864) The bug was resolved ... marked as WONTFIX. glibc developers said math-emu should be fixed. Please look at: http://sourceware.org/bugzilla/show_bug.cgi?id=864 for their comments. So I send a patch for math-emu again. Description: It looks glibc's pow() assume an unary '-' operation for any number (including NaNs) always invert its sign bit (though IEEE754 does not specify the sign bit for NaNs). This patch make the kernel math-emu emulates real MIPS neg.[ds] instruction. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/math-emu/dp_simple.c b/arch/mips/math-emu/dp_simple.c index 495c1ac..1c555e6 100644 --- a/arch/mips/math-emu/dp_simple.c +++ b/arch/mips/math-emu/dp_simple.c @@ -48,16 +48,22 @@ ieee754dp ieee754dp_neg(ieee754dp x) CLEARCX; FLUSHXDP; + /* + * Invert the sign ALWAYS to prevent an endless recursion on + * pow() in libc. + */ + /* quick fix up */ + DPSIGN(x) ^= 1; + if (xc == IEEE754_CLASS_SNAN) { + ieee754dp y = ieee754dp_indef(); SETCX(IEEE754_INVALID_OPERATION); - return ieee754dp_nanxcpt(ieee754dp_indef(), "neg"); + DPSIGN(y) = DPSIGN(x); + return ieee754dp_nanxcpt(y, "neg"); } if (ieee754dp_isnan(x)) /* but not infinity */ return ieee754dp_nanxcpt(x, "neg", x); - - /* quick fix up */ - DPSIGN(x) ^= 1; return x; } diff --git a/arch/mips/math-emu/sp_simple.c b/arch/mips/math-emu/sp_simple.c index c809830..770f0f4 100644 --- a/arch/mips/math-emu/sp_simple.c +++ b/arch/mips/math-emu/sp_simple.c @@ -48,16 +48,22 @@ ieee754sp ieee754sp_neg(ieee754sp x) CLEARCX; FLUSHXSP; + /* + * Invert the sign ALWAYS to prevent an endless recursion on + * pow() in libc. + */ + /* quick fix up */ + SPSIGN(x) ^= 1; + if (xc == IEEE754_CLASS_SNAN) { + ieee754sp y = ieee754sp_indef(); SETCX(IEEE754_INVALID_OPERATION); - return ieee754sp_nanxcpt(ieee754sp_indef(), "neg"); + SPSIGN(y) = SPSIGN(x); + return ieee754sp_nanxcpt(y, "neg"); } if (ieee754sp_isnan(x)) /* but not infinity */ return ieee754sp_nanxcpt(x, "neg", x); - - /* quick fix up */ - SPSIGN(x) ^= 1; return x; } From matej.kupljen@ultra.si Tue Jan 3 14:23:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jan 2006 14:23:30 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:37331 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133761AbWACOXI (ORCPT ); Tue, 3 Jan 2006 14:23:08 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 7A7EAC008; Tue, 3 Jan 2006 15:25:25 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 309651BC084; Tue, 3 Jan 2006 15:25:28 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 9BFBD1A18B6; Tue, 3 Jan 2006 15:25:27 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: Jordan Crouse Cc: linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com In-Reply-To: <20051208210042.GB17458@cosmic.amd.com> References: <20051208210042.GB17458@cosmic.amd.com> Content-Type: text/plain Date: Tue, 03 Jan 2006 15:25:29 +0100 Message-Id: <1136298329.6765.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi > Ok, here we go. I give you the OHCI/EHCI host controller support for > the Alchemy AU1200 processor. I'm sending this up, partly because I have > it ready to go, but also because it seems that enough folks are getting their > hands on AU1200 parts to make this a hot topic. I tried you patch, and this is what I get on 2.6.16-rc5: [4294668.576000] Creating 3 MTD partitions on "Db1200 Flash": [4294668.581000] 0x00000000-0x03c00000 : "User FS" [4294668.587000] 0x03c00000-0x03d00000 : "YAMON" [4294668.593000] 0x03d00000-0x03fc0000 : "raw kernel" [4294668.602000] CPU 0 Unable to handle kernel paging request at virtual address 00000008, epc == 80350764, ra == 80350760 [4294668.613000] Oops[#1]: [4294668.613000] Cpu 0 [4294668.613000] $ 0 : 00000000 1000fc00 8054a000 00000000 [4294668.613000] $ 4 : 8054b000 00000000 00000000 8107d530 [4294668.613000] $ 8 : 00000000 802a4030 8107d520 8053d57c [4294668.613000] $12 : ffffffff ffffffff 00100100 00200200 [4294668.613000] $16 : 8053c0d0 8053c000 00001000 80460000 [4294668.613000] $20 : 8041dcb0 00000000 00000000 00000000 [4294668.613000] $24 : 00000008 00000000 [4294668.613000] $28 : 804f2000 804f3e58 00000000 80350760 [4294668.613000] Hi : 00000000 [4294668.613000] Lo : 00000000 [4294668.613000] epc : 80350764 ehci_init+0x190/0x2c0 Not tainted [4294668.613000] ra : 80350760 ehci_init+0x18c/0x2c0 [4294668.613000] Status: 1000fc03 KERNEL EXL IE [4294668.613000] Cause : 00800008 [4294668.613000] BadVA : 00000008 [4294668.613000] PrId : 04030201 [4294668.613000] Modules linked in: [4294668.613000] Process swapper (pid: 1, threadinfo=804f2000, task=804eec00) [4294668.613000] Stack : 8013044c 8033e100 804f2000 804f3e88 00001000 80352018 1000fc03 000301ff [4294668.613000] 8053c000 fffffff4 8045e138 803520bc 804f3e78 804689e0 804f3ef8 811bb5c0 [4294668.613000] 00000010 00000000 8045e138 8045e140 80471cfc 8045e204 00000000 803521e0 [4294668.613000] 804f3e88 810756a0 00000000 00000000 00000000 00000000 00000000 802e3cd0 [4294668.613000] 8045e18c 804f3f30 8045e18c 8040d780 8045e140 804c0000 80471cfc 802e40a0 [4294668.613000] ... [4294668.613000] Call Trace: [4294668.613000] [<8013044c>] __request_region+0x38/0xb4 [4294668.613000] [<8033e100>] usb_create_hcd+0x4c/0xc8 [4294668.613000] [<80352018>] usb_ehci_au1xxx_probe+0xc0/0x1f8 [4294668.613000] [<803520bc>] usb_ehci_au1xxx_probe+0x164/0x1f8 [4294668.613000] [<803521e0>] ehci_hcd_au1xxx_drv_probe+0x38/0x50 [4294668.613000] [<802e3cd0>] driver_probe_device+0x4c/0xe8 [4294668.613000] [<8040d780>] klist_next+0x40/0x70 [4294668.613000] [<802e40a0>] __driver_attach+0x178/0x1a0 [4294668.613000] [<802e3f28>] __driver_attach+0x0/0x1a0 [4294668.613000] [<802e3024>] next_device+0x10/0x28 [4294668.613000] [<802e3f28>] __driver_attach+0x0/0x1a0 [4294668.613000] [<802e3090>] bus_for_each_dev+0x54/0x90 [4294668.613000] [<8029e468>] kobject_register+0x4c/0x8c [4294668.613000] [<802e374c>] bus_add_driver+0xa8/0x18c [4294668.613000] [<8027bb80>] debugfs_create_dir+0x1c/0x28 [4294668.613000] [<802e47a4>] driver_register+0x40/0x50 [4294668.613000] [<80100510>] init+0xac/0x2dc [4294668.613000] [<80105ee0>] kernel_thread_helper+0x10/0x18 [4294668.613000] [<80105ed0>] kernel_thread_helper+0x0/0x18 [4294668.613000] [4294668.613000] [4294668.613000] Code: 0c0a8fd0 00063080 8e030000 <8c660008> 7000003f 10400046 00061102 24020008 ae020028 [4294668.866000] Kernel panic - not syncing: Attempted to kill init! Any ideas? BR, Matej From jcrouse@cosmic.amd.com Tue Jan 3 15:47:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jan 2006 15:48:14 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:24726 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133767AbWACPrx (ORCPT ); Tue, 3 Jan 2006 15:47:53 +0000 Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k03FoAiA015439; Tue, 3 Jan 2006 07:50:13 -0800 Received: from 139.95.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Tue, 03 Jan 2006 07:47:47 -0800 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id k03FlkVP007317; Tue, 3 Jan 2006 07:47:46 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id 7C9192028; Tue, 3 Jan 2006 08:47:46 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k03FslWV031984; Tue, 3 Jan 2006 08:54:47 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k03FslCm031983; Tue, 3 Jan 2006 08:54:47 -0700 Date: Tue, 3 Jan 2006 08:54:47 -0700 From: "Jordan Crouse" To: "Matej Kupljen" cc: linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Message-ID: <20060103155447.GI15770@cosmic.amd.com> References: <20051208210042.GB17458@cosmic.amd.com> <1136298329.6765.22.camel@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <1136298329.6765.22.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FA443292BK1531058-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips > I tried you patch, and this is what I get on 2.6.16-rc5: Well, thats a fun one. I'm assuming you tried to boot with a device plugged in. I'm a bit confused by the __reqest_region coming from usb_create_hcd - I quickly glanced at the function, and I don't see anything that would have called request_region / request_mem_region. However, there *is* a request_mem_region call immediately after the usb_create_hcd call in usb_ehci_au1xxx_probe, and I wonder that might be the guilty party. Matthias, any thoughts? Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From matej.kupljen@ultra.si Tue Jan 3 20:39:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Jan 2006 20:39:38 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:39556 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133788AbWACUjU (ORCPT ); Tue, 3 Jan 2006 20:39:20 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 4C95FC002; Tue, 3 Jan 2006 21:41:35 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id BC9C71BC08C; Tue, 3 Jan 2006 21:41:37 +0100 (CET) Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52]) by smtp.triera.net (Postfix) with ESMTP id 2EA541A18B9; Tue, 3 Jan 2006 21:41:36 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: Jordan Crouse Cc: linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com In-Reply-To: <20060103155447.GI15770@cosmic.amd.com> References: <20051208210042.GB17458@cosmic.amd.com> <1136298329.6765.22.camel@localhost.localdomain> <20060103155447.GI15770@cosmic.amd.com> Content-Type: text/plain Organization: Ultra d.o.o. Date: Tue, 03 Jan 2006 22:45:22 +0100 Message-Id: <1136324722.12175.20.camel@orionlinux.starfleet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi > > I tried you patch, and this is what I get on 2.6.16-rc5: I meant, 2.5.15-rc5 of course, and NOT 2.6.15-rc5. Sorry. > Well, thats a fun one. I'm assuming you tried to boot with a device > plugged in. I'm a bit confused by the __reqest_region coming from > usb_create_hcd - I quickly glanced at the function, and I don't see anything > that would have called request_region / request_mem_region. However, > there *is* a request_mem_region call immediately after the usb_create_hcd > call in usb_ehci_au1xxx_probe, and I wonder that might be the guilty party. I set up my BDI and tried to debug this. This is what I can tell you, and maybe you can then be able to help me: I get past the request_mem_region and ioremap in ehci-au1xxx.c. I get to line 144: if ((retval = driver->reset (hcd)) < 0) { now, driver->reset points to the (gdb) p driver->reset $6 = (int (*)(struct usb_hcd *)) 0x803505d4 I step into the call and I get to ehci_init in drivers/usb/host/ehci-hcd.c. If I continue, i get to the ehci_mem_init in the drivers/usb/host/ehci-mem.c On line: 228 memset (ehci->pshadow, 0, ehci->periodic_size * sizeof (void *)); If I do next in gdb, I end up in include/asm-mips/io.h, line 425 BUILDIO_MEM(l, u32) (Well, I am lost here now) Now if I disassemble at $pc: (gdb) x/20i $pc 0x80350760 : lw v1,0(s0) 0x80350764 : lw a2,8(v1) 0x80350768 : andi v0,a2,0x80 0x8035076c : beqz v0,0x80350888 0x80350770 : srl v0,a2,0x4 0x80350774 : li v0,8 0x80350778 : sw v0,40(s0) 0x8035077c : lw v0,24(s0) 0x80350780 : lw a1,16(s0) 0x80350784 : li v1,-2 0x80350788 : and v0,v0,v1 0x8035078c : li v1,-1 0x80350790 : sw v1,48(s0) 0x80350794 : sw v0,24(s0) 0x80350798 : sw zero,20(s0) 0x8035079c : sw zero,72(a1) 0x803507a0 : lw a0,16(s0) 0x803507a4 : li v1,-32 0x803507a8 : li a1,1 0x803507ac : lw v0,68(a0) (gdb) p $s0 $9 = 0x8053c0d0 (gdb) x/x $s0 0x8053c0d0: 0x00000000 So I guess, that the instruction at 0x80350764 is loading from location 0 and offset 8, which can be seen also in the original post: [4294668.602000] CPU 0 Unable to handle kernel paging request at virtual address 00000008, epc == 80350764, ra == 80350760 What is going on here? Is this some stack corruption, because of all this strange jumps over the source code (I know optimisation is turned on, but still). I hope this can help someone, I still have a lot of learning to do to figure this out. BR, Matej -- Matej Kupljen Ultra d.o.o. From matej.kupljen@ultra.si Wed Jan 4 07:16:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 07:16:21 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:6557 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133443AbWADHQE (ORCPT ); Wed, 4 Jan 2006 07:16:04 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 43256C074; Wed, 4 Jan 2006 08:18:28 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id A26C71BC084; Wed, 4 Jan 2006 08:18:29 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 28FF11A18AD; Wed, 4 Jan 2006 08:18:28 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: Jordan Crouse Cc: linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com In-Reply-To: <1136324722.12175.20.camel@orionlinux.starfleet.com> References: <20051208210042.GB17458@cosmic.amd.com> <1136298329.6765.22.camel@localhost.localdomain> <20060103155447.GI15770@cosmic.amd.com> <1136324722.12175.20.camel@orionlinux.starfleet.com> Content-Type: text/plain Date: Wed, 04 Jan 2006 08:18:25 +0100 Message-Id: <1136359105.27748.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi > > > I tried you patch, and this is what I get on 2.6.16-rc5: > > I meant, 2.5.15-rc5 of course, and NOT 2.6.15-rc5. Sorry. Wov, I did it again :( Now I said 2.5.15-rc5 :( :( The version I am testing this on is: 2.6.15-rc5. Sorry for all this. BR, Matej From matej.kupljen@ultra.si Wed Jan 4 12:09:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 12:10:02 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:19656 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133488AbWADMJo (ORCPT ); Wed, 4 Jan 2006 12:09:44 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 6E894C091; Wed, 4 Jan 2006 13:12:07 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 14E0E1BC085; Wed, 4 Jan 2006 13:12:10 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 743181A18B0; Wed, 4 Jan 2006 13:12:09 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: Jordan Crouse Cc: linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com In-Reply-To: <20060103155447.GI15770@cosmic.amd.com> References: <20051208210042.GB17458@cosmic.amd.com> <1136298329.6765.22.camel@localhost.localdomain> <20060103155447.GI15770@cosmic.amd.com> Content-Type: text/plain Date: Wed, 04 Jan 2006 13:12:06 +0100 Message-Id: <1136376726.27748.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi (After some confusion about kernel version, I think I found the problem, sorry about that). I used binutils 2.15 and 2.16.1, but did not work. The code in the ehci-hcd.c looks like this: ---------------------------------------------------------------------------- ehci->periodic_size = DEFAULT_I_TDPS; if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0) return retval; /* controllers may cache some of the periodic schedule ... */ hcc_params = readl(&ehci->caps->hcc_params); if (HCC_ISOC_CACHE(hcc_params)) // full frame cache ehci->i_thresh = 8; else // N microframes cached ehci->i_thresh = 2 + HCC_ISOC_THRES(hcc_params); ---------------------------------------------------------------------------- The problem is *AFTER* the call to ehci_mem_init, where a read from ehci->caps->hcc_params is attempted, but caps is NULL. This can be seen by this assembly code form Insight: ---------------------------------------------------------------------------- 0x80350758 jal 0x802a3f40 0x8035075c sll a2,a2,0x2 0x80350760 lw v1,0(s0) 0x80350764 lw a2,8(v1) s0 points to ehci at offset 0 from ehci is caps and at offset 8 from caps is hcc_params ---------------------------------------------------------------------------- Where should the caps be initialized? The only place, where it is set in drivers/usb/ is in drivers/usb/host/ehci-pci.c: ---------------------------------------------------------------------------- /* called during probe() after chip reset completes */ static int ehci_pci_setup(struct usb_hcd *hcd) { struct ehci_hcd *ehci = hcd_to_ehci(hcd); struct pci_dev *pdev = to_pci_dev(hcd->self.controller); u32 temp; int retval; ehci->caps = hcd->regs; ---------------------------------------------------------------------------- But the ehci-pci.c is not included in the compilation, because at the end of ehci-hcd.c we find: ---------------------------------------------------------------------------- #if defined(CONFIG_SOC_AU1X00) #include "ehci-au1xxx.c" #elif defined(CONFIG_PCI) #include "ehci-pci.c" #else #error "missing bus glue for ehci-hcd" #endif ---------------------------------------------------------------------------- What should be done? I hope this helps. BR, Matej From matthias.lenk@amd.com Wed Jan 4 12:32:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 12:32:24 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:11444 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133488AbWADMcG (ORCPT ); Wed, 4 Jan 2006 12:32:06 +0000 Received: from SSVLGW01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k04CYVc7017371; Wed, 4 Jan 2006 04:34:31 -0800 Received: from 163.181.250.1 by SSVLGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Wed, 04 Jan 2006 04:32:21 -0800 X-Server-Uuid: 89466532-923C-4A88-82C1-66ACAA0041DF Received: from elbe.amd.com (elbe.amd.com [172.20.31.2]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id k04CWHh5023833; Wed, 4 Jan 2006 06:32:18 -0600 (CST) Received: from bobritzsch.amd.com by elbe.amd.com (8.8.8+Sun/AMD-S-2.0) id NAA29633; Wed, 4 Jan 2006 13:32:17 +0100 (MET) From: "Matthias Lenk" Reply-to: matthias.lenk@amd.com Organization: AMD To: "Matej Kupljen" Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Date: Wed, 4 Jan 2006 13:32:15 +0100 User-Agent: KMail/1.8.2 cc: "Jordan Crouse" , linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net References: <20051208210042.GB17458@cosmic.amd.com> <20060103155447.GI15770@cosmic.amd.com> <1136376726.27748.32.camel@localhost.localdomain> In-Reply-To: <1136376726.27748.32.camel@localhost.localdomain> MIME-Version: 1.0 Message-ID: <200601041332.16043.matthias.lenk@amd.com> X-WSS-ID: 6FA51FDE2BK1886933-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matthias.lenk@amd.com Precedence: bulk X-list: linux-mips Hi Matej , I looked into the issue and came to the same conclusions as you. Something significant has changed from 2.6.15rc2 (what the patch was made for) to 2.6.15rc5. I added the initialization of the caps and regs fields of the ehci structure to the probe function in ehci-au1xxx.c. The driver doesn't crash anymore but does not work either. I also tried the Au1xxx OHCI and it hangs while loading the module with rc7. So it'll probably take some time to port the Au1200 EHCI and OHCI drivers to 2.6.15rc7 (again!). Any hints on what has changed are appreciated. Thanks, Matthias On Wednesday 04 January 2006 13:12, Matej Kupljen wrote: > Hi > > (After some confusion about kernel version, I think I found the > problem, sorry about that). > > I used binutils 2.15 and 2.16.1, but did not work. > > The code in the ehci-hcd.c looks like this: > --------------------------------------------------------------------------- >- ehci->periodic_size = DEFAULT_I_TDPS; > if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0) > return retval; > > /* controllers may cache some of the periodic schedule ... */ > hcc_params = readl(&ehci->caps->hcc_params); > if (HCC_ISOC_CACHE(hcc_params)) // full frame cache > ehci->i_thresh = 8; > else // N microframes cached > ehci->i_thresh = 2 + HCC_ISOC_THRES(hcc_params); > --------------------------------------------------------------------------- >- > > The problem is *AFTER* the call to ehci_mem_init, where a read from > ehci->caps->hcc_params is attempted, but caps is NULL. > > This can be seen by this assembly code form Insight: > --------------------------------------------------------------------------- >- 0x80350758 jal 0x802a3f40 > 0x8035075c sll a2,a2,0x2 > 0x80350760 lw v1,0(s0) > 0x80350764 lw a2,8(v1) > > s0 points to ehci > at offset 0 from ehci is caps > and at offset 8 from caps is hcc_params > --------------------------------------------------------------------------- >- > > Where should the caps be initialized? > The only place, where it is set in drivers/usb/ is in > drivers/usb/host/ehci-pci.c: > --------------------------------------------------------------------------- >- /* called during probe() after chip reset completes */ > static int ehci_pci_setup(struct usb_hcd *hcd) > { > struct ehci_hcd *ehci = hcd_to_ehci(hcd); > struct pci_dev *pdev = > to_pci_dev(hcd->self.controller); > u32 temp; > int retval; > > ehci->caps = hcd->regs; > --------------------------------------------------------------------------- >- But the ehci-pci.c is not included in the compilation, because at the end > of ehci-hcd.c we find: > --------------------------------------------------------------------------- >- #if defined(CONFIG_SOC_AU1X00) > #include "ehci-au1xxx.c" > #elif defined(CONFIG_PCI) > #include "ehci-pci.c" > #else > #error "missing bus glue for ehci-hcd" > #endif > --------------------------------------------------------------------------- >- > > What should be done? > I hope this helps. > > BR, > Matej From satheshbabu.edara@analog.com Wed Jan 4 12:48:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 12:48:41 +0000 (GMT) Received: from nwd2mail3.analog.com ([137.71.25.52]:39598 "EHLO nwd2mail3.analog.com") by ftp.linux-mips.org with ESMTP id S8133488AbWADMsX (ORCPT ); Wed, 4 Jan 2006 12:48:23 +0000 Received: from nwd2mhb2.analog.com (nwd2mhb2.analog.com [137.71.6.12]) by nwd2mail3.analog.com (8.12.10/8.12.10) with ESMTP id k04CoxHU017592; Wed, 4 Jan 2006 07:50:59 -0500 Received: from lilac.hdcindia.analog.com ([10.121.13.31]) by nwd2mhb2.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id HAA15593; Wed, 4 Jan 2006 07:50:51 -0500 (EST) Received: from SEdaraL01 ([10.121.13.96]) by lilac.hdcindia.analog.com (8.12.10+Sun/8.12.10) with ESMTP id k04CoGaZ025481; Wed, 4 Jan 2006 18:20:17 +0530 (IST) Message-Id: <200601041250.k04CoGaZ025481@lilac.hdcindia.analog.com> From: "Sathesh Babu Edara" To: , Subject: Date: Wed, 4 Jan 2006 18:20:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1136324722.12175.20.camel@orionlinux.starfleet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYQpiusjPo1a8yfR1inJpoGQLVGMgAgcRZA X-Scanned-By: MIMEDefang 2.49 on 137.71.25.52 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: satheshbabu.edara@analog.com Precedence: bulk X-list: linux-mips Hi, We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and the processor speed is 200Mhz. By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ value cause an overhead on the 200MHZ CPU.Can someone advise me on whether going back to HZ vaule of 100 like Linux-2.4 will reduce the overhead on this CPU.What are the side effects this change can cause?. Regards, Sathesh From kevink@mips.com Wed Jan 4 13:02:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 13:02:55 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:3292 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133500AbWADNCi (ORCPT ); Wed, 4 Jan 2006 13:02:38 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k04D4kml013356; Wed, 4 Jan 2006 05:04:47 -0800 (PST) Received: from [192.168.236.16] (grendel [192.168.236.16]) by mercury.mips.com (8.12.9/8.12.11) with ESMTP id k04D4iJq010899; Wed, 4 Jan 2006 05:04:45 -0800 (PST) Message-ID: <43BBC85C.4040405@mips.com> Date: Wed, 04 Jan 2006 14:06:36 +0100 From: "Kevin D. Kissell" User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Sathesh Babu Edara CC: linux-mips-bounce@linux-mips.org, linux-mips@linux-mips.org Subject: Re: References: <200601041250.k04CoGaZ025481@lilac.hdcindia.analog.com> In-Reply-To: <200601041250.k04CoGaZ025481@lilac.hdcindia.analog.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Sathesh Babu Edara wrote: > > > Hi, > We have ported linux-2.6.12 kernel onto MIPS processor (LX4189) and the > processor speed is 200Mhz. > By default Linux-2.6.12 kernel comes with HZ value 1000.Will this HZ value > cause an overhead on the 200MHZ CPU.Can someone advise me on whether going > back to HZ vaule of 100 like Linux-2.4 will reduce the overhead on this > CPU.What are the side effects this change can cause?. The 1000Hz clock should not actually cause any problems with a 200MHz CPU, but it will suck up an annoyingly high percentage of available cycles. Backing off to 100Hz may cause some degradation of some real-time/interactive response times, but the improved overall performance will probably more than make up for it. I never build with a HZ value greater than 100 these days, but then again, I'm mostly running on FPGAs and other hardware emulators where the CPU clock frequencies may be less than 1MHz, and are never more than 33MHz. Note that a HZ value of less than 100 may cause some kernel macros to generate divide-by-zero operations/exceptions. Regards, Kevin K. From matej.kupljen@ultra.si Wed Jan 4 13:05:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 13:05:46 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:36817 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133500AbWADNF2 (ORCPT ); Wed, 4 Jan 2006 13:05:28 +0000 Received: from localhost (in-3.mx.triera.net [213.161.0.27]) by deliver-1.mx.triera.net (Postfix) with ESMTP id E3C8EC089; Wed, 4 Jan 2006 14:07:51 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-3.mx.triera.net (Postfix) with SMTP id 739561BC08D; Wed, 4 Jan 2006 14:07:54 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 10C351A18B3; Wed, 4 Jan 2006 14:07:55 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: matthias.lenk@amd.com Cc: Jordan Crouse , linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net In-Reply-To: <200601041332.16043.matthias.lenk@amd.com> References: <20051208210042.GB17458@cosmic.amd.com> <20060103155447.GI15770@cosmic.amd.com> <1136376726.27748.32.camel@localhost.localdomain> <200601041332.16043.matthias.lenk@amd.com> Content-Type: text/plain Date: Wed, 04 Jan 2006 14:07:51 +0100 Message-Id: <1136380071.27748.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi > I looked into the issue and came to the same conclusions as you. Something > significant has changed from 2.6.15rc2 (what the patch was made for) to > 2.6.15rc5. I added the initialization of the caps and regs fields of the ehci > structure to the probe function in ehci-au1xxx.c. The driver doesn't crash > anymore but does not work either. Where did you put it? I don't know much about USB, but by looking into the ehci-pci.c I added this to the ehci-au1xxx.c, after ioremap of hcd->regs: ehci = hcd_to_ehci(hcd); ehci->caps = hcd->regs; ehci->regs = hcd->regs + HC_LENGTH(readl(&ehci->caps->hc_capbase)); Is this O.K.? Now, with this I get: [4294668.620000] au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI [4294668.626000] au1xxx-ehci au1xxx-ehci.0: new USB bus registered, assigned bus number 1 [4294668.634000] au1xxx-ehci au1xxx-ehci.0: irq 29, io mem 0x14020200 [4294668.640000] au1xxx-ehci au1xxx-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 [4294668.649000] hub 1-0:1.0: USB hub found [4294668.653000] hub 1-0:1.0: 0 ports detected [4294668.762000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI [4294668.767000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 2 [4294668.775000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100 [4294678.361000] BUG: soft lockup detected on CPU#0! [4294678.361000] Cpu 0 [4294678.361000] $ 0 : 00000000 1000fc01 807c856c 807c856c [4294678.361000] $ 4 : 807c8570 80721710 00000000 b4020100 [4294678.361000] $ 8 : 80000000 802a4030 00000000 8045a000 [4294678.361000] $12 : 80721108 fffffffb ffffffff 0000000a [4294678.361000] $16 : 807214d0 80721400 80721400 80470000 [4294678.361000] $20 : 00000002 804c0000 24000000 0000001d [4294678.361000] $24 : 00000018 81281d51 [4294678.361000] $28 : 81280000 81281e28 00000000 80355484 [4294678.361000] Hi : 000301ff [4294678.361000] Lo : fc85b000 [4294678.361000] epc : 80139c78 notifier_chain_register+0x18/0x54 Not tainted [4294678.361000] ra : 80355484 ohci_au1xxx_start+0x644/0x678 [4294678.361000] Status: 1000fc03 KERNEL EXL IE [4294678.361000] Cause : 00808000 [4294678.361000] PrId : 04030201 Well, a little further :( > I also tried the Au1xxx OHCI and it hangs while loading the module with rc7. > So it'll probably take some time to port the Au1200 EHCI and OHCI drivers to > 2.6.15rc7 (again!). I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4. Bora, can you confirm this? > Any hints on what has changed are appreciated. I disabled EHCI in .config and tried again. This is what I got: [4294668.621000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI [4294668.626000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 1 [4294668.635000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100 [4294668.725000] hub 1-0:1.0: USB hub found [4294668.729000] hub 1-0:1.0: 2 ports detected When I plug in USB 2.0 Flash key (with the vfat module lodaed): /root # [4294868.810000] usb 1-1: new full speed USB device using au1xxx-ohci and address 2 [4294877.045000] kobject_register failed for usbcore (-17) [4294877.050000] Call Trace: [4294877.053000] [<8029e490>] kobject_register+0x74/0x8c [4294877.058000] [<8029e440>] kobject_register+0x24/0x8c [4294877.063000] [<8014c070>] load_module+0xec4/0x1810 [4294877.068000] [<8014c04c>] load_module+0xea0/0x1810 [4294877.073000] [<80206ed4>] do_setlk+0x1cc/0x40c [4294877.078000] [<801640f8>] vma_prio_tree_insert+0x28/0x5c [4294877.084000] [<8016ae64>] __vma_link+0x34/0x80 [4294877.089000] [<801533d8>] generic_file_mmap+0x68/0x70 [4294877.094000] [<8016af40>] vma_link+0x90/0x160 [4294877.099000] [<8016aef0>] vma_link+0x40/0x160 [4294877.103000] [<8014cab4>] sys_init_module+0xd0/0x890 [4294877.108000] [<8010daac>] stack_done+0x20/0x40 [4294877.113000] [4294878.449000] Initializing USB Mass Storage driver... [4294878.508000] scsi0 : SCSI emulation for USB Mass Storage devices [4294878.606000] usbcore: registered new driver usb-storage [4294878.612000] USB Mass Storage support registered. [4294883.623000] Vendor: Generic Model: STORAGE DEVICE Rev: 1.04 [4294883.630000] Type: Direct-Access ANSI SCSI revision: 00 [4294883.913000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB) [4294883.928000] sda: Write Protect is on [4294883.932000] sda: assuming drive cache: write through [4294883.965000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB) [4294883.980000] sda: Write Protect is on [4294883.984000] sda: assuming drive cache: write through [4294883.989000] sda: sda1 [4294884.005000] sd 0:0:0:0: Attached scsi removable disk sda [4294884.028000] sd 0:0:0:0: Attached scsi generic sg0 type 0 And I can mount /dev/sda1. I'll try with only EHCI now, then I'll look into this kobject_register. BR, Matej From bora.sahin@ttnet.net.tr Wed Jan 4 13:51:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 13:52:16 +0000 (GMT) Received: from neptune.nocserver.net ([209.59.140.34]:43173 "EHLO neptune.nocserver.net") by ftp.linux-mips.org with ESMTP id S8133503AbWADNv5 (ORCPT ); Wed, 4 Jan 2006 13:51:57 +0000 Received: from [81.214.210.213] (port=32805 helo=boras) by neptune.nocserver.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.52) id 1Eu95V-0002jU-M9; Wed, 04 Jan 2006 08:54:02 -0500 From: bora.sahin@ttnet.net.tr To: Matej Kupljen Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) Date: Wed, 4 Jan 2006 15:54:29 +0200 User-Agent: KMail/1.7.2 Cc: matthias.lenk@amd.com, Jordan Crouse , linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net References: <20051208210042.GB17458@cosmic.amd.com> <200601041332.16043.matthias.lenk@amd.com> <1136380071.27748.49.camel@localhost.localdomain> In-Reply-To: <1136380071.27748.49.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="Iso-8859-9" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601041554.29497.bora.sahin@ttnet.net.tr> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - neptune.nocserver.net X-AntiAbuse: Original Domain - linux-mips.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ttnet.net.tr X-Source: X-Source-Args: X-Source-Dir: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bora.sahin@ttnet.net.tr Precedence: bulk X-list: linux-mips Hi, > I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4. > Bora, can you confirm this? Yes, it works both in my version of patch and Jordan's... But my kernel version is #define UTS_RELEASE "2.6.15-rc4-g2b269cc6" not 2.5.15-rc4 -- Bora SAHIN From matej.kupljen@ultra.si Wed Jan 4 14:15:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 14:15:36 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:52954 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133500AbWADOPS (ORCPT ); Wed, 4 Jan 2006 14:15:18 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id E0F3BC090; Wed, 4 Jan 2006 15:17:41 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 82BC51BC07F; Wed, 4 Jan 2006 15:17:45 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id 366331A18B1; Wed, 4 Jan 2006 15:17:45 +0100 (CET) Subject: Re: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) From: Matej Kupljen To: bora.sahin@ttnet.net.tr Cc: matthias.lenk@amd.com, Jordan Crouse , linux-mips@linux-mips.org, linux-usb-devel@lists.sourceforge.net In-Reply-To: <200601041554.29497.bora.sahin@ttnet.net.tr> References: <20051208210042.GB17458@cosmic.amd.com> <200601041332.16043.matthias.lenk@amd.com> <1136380071.27748.49.camel@localhost.localdomain> <200601041554.29497.bora.sahin@ttnet.net.tr> Content-Type: text/plain Date: Wed, 04 Jan 2006 15:17:42 +0100 Message-Id: <1136384262.27748.52.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Hi > > I think Bora Sahin said he used OHCI successfully on 2.5.15-rc4. > > Bora, can you confirm this? > > Yes, it works both in my version of patch and Jordan's... > > But my kernel version is > #define UTS_RELEASE "2.6.15-rc4-g2b269cc6" > not 2.5.15-rc4 Yes, I meant the right one: 2.6.15-rc4 (I don't know what is wrong with me and those kernel versions). So, there was some change between rc4 and rc5, that broke USB on Alchemey? BR, Matej From matej.kupljen@ultra.si Wed Jan 4 21:21:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Jan 2006 21:21:47 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:31900 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133540AbWADVV1 (ORCPT ); Wed, 4 Jan 2006 21:21:27 +0000 Received: from localhost (in-1.mx.triera.net [213.161.0.25]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 6D740C0B5; Wed, 4 Jan 2006 22:23:44 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-1.mx.triera.net (Postfix) with SMTP id 09C1C1BC07F; Wed, 4 Jan 2006 22:23:50 +0100 (CET) Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52]) by smtp.triera.net (Postfix) with ESMTP id 9E92E1A18B6; Wed, 4 Jan 2006 22:23:49 +0100 (CET) Subject: Re: smc91x support From: Matej Kupljen To: ppopov@embeddedalley.com Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <1131636585.4890.14.camel@localhost.localdomain> References: <1131634331.18165.30.camel@localhost.localdomain> <1131636585.4890.14.camel@localhost.localdomain> Content-Type: text/plain Organization: Ultra d.o.o. Date: Wed, 04 Jan 2006 22:23:52 +0100 Message-Id: <1136409832.11317.54.camel@orionlinux.starfleet.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Content-Length: 386 Lines: 18 Hi > > smc91x platform support; requires patch to smc91x.h which was sent > > upstream. > > > > Any news about this? > > What is the patch required for smc91x.h? > > I have to check with Nicolas Pitre. Pete, did you see this: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2006-January/033064.html Will it work for MIPS and especially for DBAU12100? BR, Matej From ppopov@embeddedalley.com Thu Jan 5 02:40:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 02:40:26 +0000 (GMT) Received: from smtp101.biz.mail.mud.yahoo.com ([68.142.200.236]:35205 "HELO smtp101.biz.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S3465743AbWAECkF (ORCPT ); Thu, 5 Jan 2006 02:40:05 +0000 Received: (qmail 61472 invoked from network); 5 Jan 2006 02:42:29 -0000 Received: from unknown (HELO ?192.168.1.102?) (ppopov@embeddedalley.com@63.194.214.47 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 5 Jan 2006 02:42:29 -0000 Subject: Re: smc91x support From: Pete Popov Reply-To: ppopov@embeddedalley.com To: Matej Kupljen Cc: "'linux-mips@linux-mips.org'" In-Reply-To: <1136409832.11317.54.camel@orionlinux.starfleet.com> References: <1131634331.18165.30.camel@localhost.localdomain> <1131636585.4890.14.camel@localhost.localdomain> <1136409832.11317.54.camel@orionlinux.starfleet.com> Content-Type: text/plain Organization: Embedded Alley Solutions, Inc Date: Wed, 04 Jan 2006 18:42:28 -0800 Message-Id: <1136428948.8379.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@embeddedalley.com Precedence: bulk X-list: linux-mips Content-Length: 643 Lines: 22 On Wed, 2006-01-04 at 22:23 +0100, Matej Kupljen wrote: > Hi > > > > smc91x platform support; requires patch to smc91x.h which was sent > > > upstream. > > > > > > Any news about this? > > > What is the patch required for smc91x.h? > > > > I have to check with Nicolas Pitre. > > Pete, did you see this: > http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2006-January/033064.html > > Will it work for MIPS and especially for DBAU12100? Someone has to try it and send Nicolas an incremental patch if it doesn't work for the dbau1200. I have a dbau1200 so I'll try it at some point but Jordan might beat me to it. Pete From matej.kupljen@ultra.si Thu Jan 5 13:24:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 13:24:46 +0000 (GMT) Received: from deliver-1.mx.triera.net ([213.161.0.31]:52106 "HELO deliver-1.mx.triera.net") by ftp.linux-mips.org with SMTP id S8133529AbWAENY2 (ORCPT ); Thu, 5 Jan 2006 13:24:28 +0000 Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 5D37FC0EF; Thu, 5 Jan 2006 14:26:58 +0100 (CET) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id D8C301BC08E; Thu, 5 Jan 2006 14:26:59 +0100 (CET) Received: from [172.18.1.53] (unknown [213.161.20.162]) by smtp.triera.net (Postfix) with ESMTP id C7F191A18B4; Thu, 5 Jan 2006 14:26:59 +0100 (CET) Subject: ALCHEMY: AU1200 USB Host Controller (OHCI/EHCI) PROGRESS From: Matej Kupljen To: Jordan Crouse Cc: linux-usb-devel@lists.sourceforge.net, matthias.lenk@amd.com, linux-mips@linux-mips.org Content-Type: text/plain Date: Thu, 05 Jan 2006 14:26:52 +0100 Message-Id: <1136467612.6378.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Triera AV Service Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: matej.kupljen@ultra.si Precedence: bulk X-list: linux-mips Content-Length: 4655 Lines: 98 Hi Made some progress in the AU1200 USB OHCI/EHCI. Previously, if both were selected we got: ------------------------------------------------------------------------ [4294669.339000] au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI [4294669.347000] au1xxx-ehci au1xxx-ehci.0: new USB bus registered, assigned bus number 1 [4294669.355000] au1xxx-ehci au1xxx-ehci.0: irq 29, io mem 0x14020200 [4294669.361000] au1xxx-ehci au1xxx-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 [4294669.374000] hub 1-0:1.0: USB hub found [4294669.378000] hub 1-0:1.0: 0 ports detected [4294669.488000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI [4294669.495000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 2 [4294669.504000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100 [4294679.372000] BUG: soft lockup detected on CPU#0! [4294679.372000] Cpu 0 [4294679.372000] $ 0 : 00000000 1000fc01 8f6278bc 8f6278bc [4294679.372000] $ 4 : 00000000 804471d0 00030200 80000000 [4294679.372000] $ 8 : 00000000 802b1df0 00000000 8046e000 [4294679.372000] $12 : 8f63b610 fffffffb ffffffff 0000000a [4294679.372000] $16 : 8f6278c0 8f63bbe4 80470000 8f63b8c4 [4294679.372000] $20 : 00000002 804e0000 0000001d 24000000 [4294679.372000] $24 : 00000018 00000000 [4294679.372000] $28 : 80524000 80525df0 00000000 8013aa48 [4294679.372000] Hi : 000301ff [4294679.372000] Lo : fc85b000 [4294679.372000] epc : 8013aa68 notifier_chain_register+0x48/0xb8 Not tainted [4294679.372000] ra : 8013aa48 notifier_chain_register+0x28/0xb8 [4294679.372000] Status: 1000fc03 KERNEL EXL IE [4294679.372000] Cause : 00808000 [4294679.372000] PrId : 04030201 ------------------------------------------------------------------------ The problem was in the ehci-au1xxx.c in usb_ehci_au1xxx_probe before the call to usb_add_hcd the driver called driver->reset (hcd). Reset points to ehci_init which at the end of function calls: register_reboot_notifier(&ehci->reboot_notifier); After that the usb_ehci_au1xxx_probe calls usb_add_hcd which *AGAIN* calls ehci_init *AND* register_reboot_notifer and thus creating reboot_notifier_list->next pointing to reboot_notifier_list! ------------------------------------------------------------------------ If I remove a call to reset, I get: [4294669.337000] au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI [4294669.344000] au1xxx-ehci au1xxx-ehci.0: new USB bus registered, assigned bus number 1 [4294669.352000] au1xxx-ehci au1xxx-ehci.0: irq 29, io mem 0x14020200 [4294669.359000] au1xxx-ehci au1xxx-ehci.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004 [4294669.371000] hub 1-0:1.0: USB hub found [4294669.375000] hub 1-0:1.0: 0 ports detected [4294669.486000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI [4294669.493000] au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 2 [4294669.502000] au1xxx-ohci au1xxx-ohci.0: irq 29, io mem 0x14020100 [4294669.595000] hub 2-0:1.0: USB hub found [4294669.599000] hub 2-0:1.0: 2 ports detected ------------------------------------------------------------------------ But it still does not work right. If I plug in USB 2.0 memory stick, I get: ------------------------------------------------------------------------ /root # [4294699.429000] usb 2-1: new full speed USB device using au1xxx-ohci and address 2 [4294699.438000] au1xxx-ehci au1xxx-ehci.0: fatal error [4294699.438000] au1xxx-ehci au1xxx-ehci.0: HC died; cleaning up [4294699.579000] usb 2-1: not running at top speed; connect to a high speed hub [4294709.001000] Initializing USB Mass Storage driver... [4294709.077000] scsi0 : SCSI emulation for USB Mass Storage devices [4294709.251000] usbcore: registered new driver usb-storage [4294709.257000] USB Mass Storage support registered. [4294714.269000] Vendor: Generic Model: STORAGE DEVICE Rev: 1.04 [4294714.276000] Type: Direct-Access ANSI SCSI revision: 00 [4294714.562000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB) [4294714.577000] sda: Write Protect is on [4294714.581000] sda: assuming drive cache: write through [4294714.619000] SCSI device sda: 256000 512-byte hdwr sectors (131 MB) [4294714.635000] sda: Write Protect is on [4294714.639000] sda: assuming drive cache: write through [4294714.644000] sda: sda1 [4294714.663000] sd 0:0:0:0: Attached scsi removable disk sda [4294714.708000] sd 0:0:0:0: Attached scsi generic sg0 type 0 ------------------------------------------------------------------------ Well, back to work. I just wanted to keep you posted, because I know somebody else is also working on it and I wouldn't like to duplicate the effort. BR, Matej From anemo@mba.ocn.ne.jp Thu Jan 5 15:12:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 15:12:31 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:35271 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S8133546AbWAEPMN (ORCPT ); Thu, 5 Jan 2006 15:12:13 +0000 Received: from localhost (p4083-ipad30funabasi.chiba.ocn.ne.jp [221.184.79.83]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 70B0AA538; Fri, 6 Jan 2006 00:14:45 +0900 (JST) Date: Fri, 06 Jan 2006 00:14:12 +0900 (JST) Message-Id: <20060106.001412.93019293.anemo@mba.ocn.ne.jp> To: rmk@arm.linux.org.uk Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console From: Atsushi Nemoto In-Reply-To: <20051227184152.GA4474@flint.arm.linux.org.uk> References: <43B143EE.6070700@ru.mvista.com> <20051228.003457.74752441.anemo@mba.ocn.ne.jp> <20051227184152.GA4474@flint.arm.linux.org.uk> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1183 Lines: 32 >>>>> On Tue, 27 Dec 2005 18:41:52 +0000, Russell King said: >> Yes, you are right. I missed the register_console call in >> uart_add_one_port(). So your patch will fix the problem. But I >> suppose the spinlock should be initialized in serial_core. How >> about this? rmk> I think you're layering work-around on top of work-around on top rmk> of work-around here. Russell, could you tell me where is the right place to initialize port's spinlock ? Currently, serial_core do initialize the spinlock in uart_set_options (for console) and uart_add_one_port (for other ports). And some low level drivers also initialize it in some place. (serial8250_isa_init_ports, etc.) A. The initialization in serial_core is just for failsafe and low level drivers should initialize the spinlock. B. Those initializations in low level drivers are there just by historical (or any other) reason and now redundant. They can be omitted because serial_core is responsible to initialize the spinlock. Which is right ? (if both are wrong, could you correct me ?) I will update and send patch(es) based on your answer. Thank you. --- Atsushi Nemoto From christi.garvin@lantronix.com Thu Jan 5 16:12:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 16:13:02 +0000 (GMT) Received: from ltrxmail.lantronix.com ([67.134.254.86]:10821 "EHLO double-bogey.int.lantronix.com") by ftp.linux-mips.org with ESMTP id S8133546AbWAEQMo convert rfc822-to-8bit (ORCPT ); Thu, 5 Jan 2006 16:12:44 +0000 X-MessageTextProcessor: DisclaimIt (2.00.201) on double-bogey.int.lantronix.com Received: from 3putt.int.lantronix.com ([172.16.1.16]) by double-bogey.int.lantronix.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 08:15:15 -0800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: iptables/vmalloc issues on alchemy (revisited) Date: Thu, 5 Jan 2006 08:15:13 -0800 Message-ID: <2F0FC2A92C0B154BB406D5E74CB3E693010849F5@3putt.int.lantronix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iptables/vmalloc issues on alchemy (revisited) thread-index: AcYSEzU4znvuLfZaQv6+6AVntEqEWg== Importance: normal From: "Christi Garvin" Priority: normal To: Cc: X-OriginalArrivalTime: 05 Jan 2006 16:15:15.0408 (UTC) FILETIME=[3676ED00:01C61213] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: christi.garvin@lantronix.com Precedence: bulk X-list: linux-mips Content-Length: 2320 Lines: 43 This issue was reported on this mailing list back in April '05.... On Tue, 2005-04-26 at 10:43 +0200, Herbert Valerio Riedel wrote: > ... > The problem seems to be so far, that when modifying the iptables > structures by adding/flushing the rules, a state can be reached sooner > or later (indeterministic! smells like race) where the data structure > becomes invalid (although there are checks in the kernel which would > prevent that); the result is either ip_tables.c:ipt_do_tables() causing > an oops due to bad pointer dereferencing (or the kernel freezing w/o > further notice at all), or the iptables tool being unable to > retrieve/modify the rules from the kernel (and getting ENOMEM/EINVAL) or > simply segfaulting due to other inconsistencies with the data... it appears the problem was found... On Wed, 2005-04-27 at 15:06 -0400, Dan Malek wrote: > Oh wait .... I found a bug a while ago from someone trying to load > large modules. There is a problem if the kernel grows to need > additional PTE tables, the top level pointers don't get propagated > correctly and subsequent access by a thread that didn't actually > do the allocation would fail. I'm looking into this, including your > past message about 64-bit PTEs. and possibly fixed: > From: Dan Malek [mailto:dan@embeddededge.com] > Sent: Thursday, April 28, 2005 3:57 PM > Subject: Re: iptables/vmalloc issues on alchemy > > I've just been talking about 2.6, so "long time ago" can't be > that long :-) I have the updates to the exception handler so > the PTEs get loaded correctly, that's on the way. I think 2.4 > should be OK if anyone is using that. I am encountering this same problem with 2.6.11 and iptables 1.2.11, and I've searched for an appropriate patch/fix, and cannot find one.... Can you tell me if this has been fixed, and if so, point me in the direction of the patch? regards, christi garvin ********************************************************************** This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. From bunk@stusta.de Thu Jan 5 17:34:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 17:34:47 +0000 (GMT) Received: from mailout.stusta.mhn.de ([141.84.69.5]:27410 "HELO mailout.stusta.mhn.de") by ftp.linux-mips.org with SMTP id S8133560AbWAERe0 (ORCPT ); Thu, 5 Jan 2006 17:34:26 +0000 Received: (qmail 10042 invoked from network); 5 Jan 2006 17:36:57 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 5 Jan 2006 17:36:57 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 315FE197670; Thu, 5 Jan 2006 18:36:58 +0100 (CET) Date: Thu, 5 Jan 2006 18:36:57 +0100 From: Adrian Bunk To: Andrew Morton Cc: Ralf Baechle , Domen Puncer , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, davem@davemloft.net Subject: [2.6 patch] Remove arch/mips/arc/salone.c Message-ID: <20060105173657.GA12313@stusta.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bunk@stusta.de Precedence: bulk X-list: linux-mips Content-Length: 1746 Lines: 58 From: Domen Puncer ArcLoad(), ArcInvoke(), ArcExecute() aren't used. Signed-off-by: Domen Puncer Signed-off-by: Alexey Dobriyan Signed-off-by: Adrian Bunk --- This patch was sent by Alexey Dobriyan on: - 8 Nov 2005 arch/mips/arc/Makefile | 2 +- arch/mips/arc/salone.c | 25 ------------------------- 2 files changed, 1 insertion(+), 26 deletions(-) --- linux-kj.orig/arch/mips/arc/Makefile 2005-11-08 20:46:24.000000000 +0300 +++ linux-kj/arch/mips/arc/Makefile 2005-11-08 20:47:36.000000000 +0300 @@ -3,7 +3,7 @@ # lib-y += cmdline.o env.o file.o identify.o init.o \ - misc.o salone.o time.o tree.o + misc.o time.o tree.o lib-$(CONFIG_ARC_MEMORY) += memory.o lib-$(CONFIG_ARC_CONSOLE) += arc_con.o Index: linux-kj/arch/mips/arc/salone.c =================================================================== --- linux-kj.orig/arch/mips/arc/salone.c 2005-11-08 20:46:24.000000000 +0300 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,24 +0,0 @@ -/* - * Routines to load into memory and execute stand-along program images using - * ARCS PROM firmware. - * - * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) - */ -#include -#include - -LONG __init ArcLoad(CHAR *Path, ULONG TopAddr, ULONG *ExecAddr, ULONG *LowAddr) -{ - return ARC_CALL4(load, Path, TopAddr, ExecAddr, LowAddr); -} - -LONG __init ArcInvoke(ULONG ExecAddr, ULONG StackAddr, ULONG Argc, CHAR *Argv[], - CHAR *Envp[]) -{ - return ARC_CALL5(invoke, ExecAddr, StackAddr, Argc, Argv, Envp); -} - -LONG __init ArcExecute(CHAR *Path, LONG Argc, CHAR *Argv[], CHAR *Envp[]) -{ - return ARC_CALL4(exec, Path, Argc, Argv, Envp); -} From robert@linuxdevelopment.de Thu Jan 5 22:22:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Jan 2006 22:22:58 +0000 (GMT) Received: from moutng.kundenserver.de ([212.227.126.171]:9414 "EHLO moutng.kundenserver.de") by ftp.linux-mips.org with ESMTP id S8133495AbWAEWWj (ORCPT ); Thu, 5 Jan 2006 22:22:39 +0000 Received: from [85.212.191.62] (helo=[10.0.0.4]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1EudXp2Loy-0001QF; Thu, 05 Jan 2006 23:25:18 +0100 Message-ID: <43BD9D93.40005@linuxdevelopment.de> Date: Thu, 05 Jan 2006 23:28:35 +0100 From: Robert Woerle User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.12) Gecko/20050921 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: diet-X11 fails /include/bits/types.h X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3a738c603c23670681f156cc7e748d26 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robert@linuxdevelopment.de Precedence: bulk X-list: linux-mips Content-Length: 2868 Lines: 65 Hi i am new to mips and i am compiling a familiar gpe image for mips based systems . Now diet-X11 and X11 are breaking to compile on the below error. I googled and found various occasions of this /include/bits/types.h causing problems i guess that has something todo with combination on compiler and glibc seems also glibc-2.3.5 fails on that i am using for that build glibc-2.3.3 gcc-cross-3.3.4 make[2]: Entering directory `/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util' | if gcc -DHAVE_CONFIG_H -I. -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util -I../../src -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xtrans -D_XOPEN_SOURCE=500 -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include -I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -MT makekeys-makekeys.o -MD -MP -MF ".deps/makekeys-makekeys.Tpo" -c -o makekeys-makekeys.o `test -f 'makekeys.c' || echo '/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util/'`makekeys.c; \ | then mv -f ".deps/makekeys-makekeys.Tpo" ".deps/makekeys-makekeys.Po"; else rm -f ".deps/makekeys-makekeys.Tpo"; exit 1; fi | In file included from /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/sys/types.h:31, | from /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xos.h:59, | from makekeys.c:34: | /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:127:3: #error | In file included from /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/sys/types.h:31, | from /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xos.h:59, | from makekeys.c:34: | /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: error: syntax error before "__dev_t" | /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: warning: type defaults to `int' in declaration of `__dev_t' | /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: warning: data definition has no type or storage class | /home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:140: error: syntax error before "__ino64_t" any hint is greatly appriciated regards rob_w From zzh.hust@gmail.com Fri Jan 6 06:38:19 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 06:38:39 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.202]:1116 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133383AbWAFGiT convert rfc822-to-8bit (ORCPT ); Fri, 6 Jan 2006 06:38:19 +0000 Received: by wproxy.gmail.com with SMTP id 36so2791421wra for ; Thu, 05 Jan 2006 22:40:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VSeGgt4S2M4PxIGqPsI+fIZSkBdqnlmfNAmpCFTItSHin11lDhZVDw2hqyTPIw1Z1mbnlq1cvYzqCAn9cLVRZkVPMANFUovk7rnnNdfQ3ltwfAHOqxljD5GXAw9Qd6LSwbsn4Cs1VR4GUJEWxILtLOsnEwV90NJkuwQ0L9gS3ZY= Received: by 10.54.149.8 with SMTP id w8mr4557050wrd; Thu, 05 Jan 2006 22:40:58 -0800 (PST) Received: by 10.54.156.1 with HTTP; Thu, 5 Jan 2006 22:40:58 -0800 (PST) Message-ID: <50c9a2250601052240n5696e353teb2b798ecbf802f0@mail.gmail.com> Date: Fri, 6 Jan 2006 14:40:58 +0800 From: zhuzhenhua To: "linux-mips@linux-mips.org" Subject: sometimes get "crc error" while uncompressed ramdisk MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 225 Lines: 9 i make a ramdisk by myself, and sometimes the kernel boot the ramdisk correctly but sometimes it printk "crc error" while uncompressed ramdisk, did someone meet this situation? thanks for any hints Best regards zhuzhenhua From jaypee@hotpop.com Fri Jan 6 08:53:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 08:54:03 +0000 (GMT) Received: from smtp-out.hotpop.com ([38.113.3.61]:61839 "EHLO smtp-out.hotpop.com") by ftp.linux-mips.org with ESMTP id S8133528AbWAFIxe (ORCPT ); Fri, 6 Jan 2006 08:53:34 +0000 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.105]) by smtp-out.hotpop.com (Postfix) with SMTP id 91A062222269 for ; Fri, 6 Jan 2006 08:56:02 +0000 (UTC) Received: from [10.8.64.42] (unknown [62.253.252.7]) by smtp-2.hotpop.com (Postfix) with ESMTP id 48AF622221A0; Fri, 6 Jan 2006 08:56:00 +0000 (UTC) Subject: Re: sometimes get "crc error" while uncompressed ramdisk From: jp To: zhuzhenhua , linux-mips In-Reply-To: <50c9a2250601052240n5696e353teb2b798ecbf802f0@mail.gmail.com> References: <50c9a2250601052240n5696e353teb2b798ecbf802f0@mail.gmail.com> Content-Type: text/plain Date: Fri, 06 Jan 2006 08:56:53 +0000 Message-Id: <1136537813.5239.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.3 Content-Transfer-Encoding: 7bit X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jaypee@hotpop.com Precedence: bulk X-list: linux-mips Content-Length: 825 Lines: 25 On Fri, 2006-01-06 at 14:40 +0800, zhuzhenhua wrote: > i make a ramdisk by myself, and sometimes the kernel boot the ramdisk > correctly but sometimes it printk "crc error" while uncompressed > ramdisk, did someone meet this situation? > thanks for any hints > Assuming your build and everything else is as it should be it may be a RAM fault. Are you using a custom board? I had some prototype boards here with some really long tracks to RAM. (and some really short ones too!) Memory tests such walking ones worked fine but the decompress of the ramdisk works RAM pretty hard and it showed up intermittent faults like you describe. Tended to be worse when the board was warm. I'd spray some Freezit on and it would go back to working OK. You could also try running the RAM slower and see if the fault disappears. JP From langabe@gmail.com Fri Jan 6 10:38:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 10:39:07 +0000 (GMT) Received: from nproxy.gmail.com ([64.233.182.194]:5982 "EHLO nproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133370AbWAFKit convert rfc822-to-8bit (ORCPT ); Fri, 6 Jan 2006 10:38:49 +0000 Received: by nproxy.gmail.com with SMTP id k27so7427nfc for ; Fri, 06 Jan 2006 02:41:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=H+zeV1IM68ru1z0EnFJ1P574MPc/WNHRLz+aqvXZHWat1Hi7BaoRTFtRUQE6XMPgLRS60eb89FTbBU/8Wh41mAZee83c2PVcrouBjpERjvfdpGAULdpAZTUDSv5dfTWaLJQS59qUc6E2XfvTxX970j9ogVfTgC1/gvTBuDpznbw= Received: by 10.48.249.2 with SMTP id w2mr651197nfh; Fri, 06 Jan 2006 02:41:30 -0800 (PST) Received: by 10.48.225.20 with HTTP; Fri, 6 Jan 2006 02:41:30 -0800 (PST) Message-ID: Date: Fri, 6 Jan 2006 10:41:30 +0000 From: Alex Gonzalez To: linux-mips@linux-mips.org Subject: Jump/branch to external symbol MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: langabe@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1377 Lines: 36 Hi, I am having GNU gas related problems when compiling assembler files which contain jumps to external symbols, for example when jumping from an assembler to a C function. Using binutils-2.15 GAS will produce a "Cannot branch to undefined symbol" error. Applying the patch at http://sources.redhat.com/ml/binutils/2004-04/msg00476.html, which creates an "allow_branch_to_undefined" option I am able to succesfully compile an executable. I am happy with this as I only need to apply the option to the problematic files and it does not change the behaviour of gas in general. Now, my crosscompiler toolchain is based on binutils-2.13. When I try to apply the same patch to it, I get a different error, "Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file format". There are various posts around referring to this problems. As a consequence I have read different opinions, solutions that apply to specific version or binutils, solutions more or less accepted by everyone, and as usual I am very confused. If I compile with "-mno-abicalls -fno-pic" gas reports no errors (which I believe is what the Linux kernel does), but I need to link with some pic libraries which use glibc, so this is not a valid solution for me. I am happy with the patch for binutils-2.15, and I would need a solution for binutils-2.13. Can anybody offer any help? Thanks, Alex From macro@linux-mips.org Fri Jan 6 11:49:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 11:49:32 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:30995 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S8133571AbWAFLtP (ORCPT ); Fri, 6 Jan 2006 11:49:15 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 6A3B0E1C9B; Fri, 6 Jan 2006 12:51:54 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04961-05; Fri, 6 Jan 2006 12:51:54 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 27997E1C81; Fri, 6 Jan 2006 12:51:54 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.3/8.13.1) with ESMTP id k06Bplme002297; Fri, 6 Jan 2006 12:51:47 +0100 Date: Fri, 6 Jan 2006 11:51:56 +0000 (GMT) From: "Maciej W. Rozycki" To: Alex Gonzalez Cc: linux-mips@linux-mips.org Subject: Re: Jump/branch to external symbol In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.87.1/1231/Thu Jan 5 23:51:25 2006 on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 368 Lines: 12 On Fri, 6 Jan 2006, Alex Gonzalez wrote: > I am happy with the patch for binutils-2.15, and I would need a > solution for binutils-2.13. > > Can anybody offer any help? Well, the most obvious solution is upgrading to the current release, which is 2.16.1 now. Otherwise you are probably on your own -- 2.15 is already somewhat old and 2.13 is ancient. Maciej From drow@nevyn.them.org Fri Jan 6 14:49:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 14:49:53 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:16515 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S8133576AbWAFOtg (ORCPT ); Fri, 6 Jan 2006 14:49:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Euswy-0001mv-K9; Fri, 06 Jan 2006 09:52:16 -0500 Date: Fri, 6 Jan 2006 09:52:16 -0500 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Alex Gonzalez , linux-mips@linux-mips.org Subject: Re: Jump/branch to external symbol Message-ID: <20060106145216.GA6849@nevyn.them.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 546 Lines: 17 On Fri, Jan 06, 2006 at 11:51:56AM +0000, Maciej W. Rozycki wrote: > On Fri, 6 Jan 2006, Alex Gonzalez wrote: > > > I am happy with the patch for binutils-2.15, and I would need a > > solution for binutils-2.13. > > > > Can anybody offer any help? > > Well, the most obvious solution is upgrading to the current release, > which is 2.16.1 now. Otherwise you are probably on your own -- 2.15 is > already somewhat old and 2.13 is ancient. Or better yet to trunk and you won't need any patches for this. -- Daniel Jacobowitz CodeSourcery From robert@linuxdevelopment.de Fri Jan 6 15:00:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 15:01:12 +0000 (GMT) Received: from moutng.kundenserver.de ([212.227.126.187]:26075 "EHLO moutng.kundenserver.de") by ftp.linux-mips.org with ESMTP id S8133576AbWAFPAy (ORCPT ); Fri, 6 Jan 2006 15:00:54 +0000 Received: from [85.212.192.127] (helo=[10.0.0.4]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Eut7t1QiI-0008Br; Fri, 06 Jan 2006 16:03:33 +0100 Message-ID: <43BE878D.6080105@linuxdevelopment.de> Date: Fri, 06 Jan 2006 16:06:53 +0100 From: Robert Woerle User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.12) Gecko/20050921 X-Accept-Language: de, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: diet-X11 fails /include/bits/types.h References: <43BD9D93.40005@linuxdevelopment.de> In-Reply-To: <43BD9D93.40005@linuxdevelopment.de> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:3a738c603c23670681f156cc7e748d26 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robert@linuxdevelopment.de Precedence: bulk X-list: linux-mips Content-Length: 3153 Lines: 75 Ok check that types.h and to me it looks that nothing in my toolchain provides WORDSIZE so i used the WORDSIZE=32 values and filled them in the 3rd else statement . now all compiles fine Robert Woerle schrieb: >Hi > >i am new to mips and i am compiling a familiar gpe image for mips based >systems . >Now diet-X11 and X11 are breaking to compile on the below error. >I googled and found various occasions of this /include/bits/types.h >causing problems > >i guess that has something todo with combination on compiler and glibc >seems also glibc-2.3.5 fails on that > >i am using for that build >glibc-2.3.3 >gcc-cross-3.3.4 > >make[2]: Entering directory >`/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util' >| if gcc -DHAVE_CONFIG_H -I. >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util >-I../../src >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include >-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes >-Wmissing-declarations -Wnested-externs -fno-strict-aliasing >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xtrans >-D_XOPEN_SOURCE=500 >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include >-I/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include >-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 >-MT makekeys-makekeys.o -MD -MP -MF ".deps/makekeys-makekeys.Tpo" -c -o >makekeys-makekeys.o `test -f 'makekeys.c' || echo >'/home/bob/Handhelds/oe/stuff/mips-build/tmp/work/diet-x11-6.2.1cvs20050226-r5/X11/src/util/'`makekeys.c; >\ >| then mv -f ".deps/makekeys-makekeys.Tpo" ".deps/makekeys-makekeys.Po"; >else rm -f ".deps/makekeys-makekeys.Tpo"; exit 1; fi >| In file included from >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/sys/types.h:31, >| from >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xos.h:59, >| from makekeys.c:34: >| >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:127:3: >#error >| In file included from >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/sys/types.h:31, >| from >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/X11/Xos.h:59, >| from makekeys.c:34: >| >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: >error: syntax error before "__dev_t" >| >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: >warning: type defaults to `int' in declaration of `__dev_t' >| >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:136: >warning: data definition has no type or storage class >| >/home/bob/Handhelds/oe/stuff/mips-build/tmp/staging/mipsel-linux/include/bits/types.h:140: >error: syntax error before "__ino64_t" > >any hint is greatly appriciated >regards > >rob_w > > > From sshtylyov@ru.mvista.com Fri Jan 6 16:29:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 16:30:00 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:25520 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133585AbWAFQ3m (ORCPT ); Fri, 6 Jan 2006 16:29:42 +0000 Received: (qmail 5312 invoked from network); 6 Jan 2006 16:32:17 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 6 Jan 2006 16:32:17 -0000 Message-ID: <43BE9C20.2040805@ru.mvista.com> Date: Fri, 06 Jan 2006 19:34:40 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Manish Lachwani , Jordan Crouse , ralf@linux-mips.org Subject: [PATCH] Make KGDB compile for AMD Au1200 Content-Type: multipart/mixed; boundary="------------040105000905030801070202" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1179 Lines: 41 This is a multi-part message in MIME format. --------------040105000905030801070202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. AMD Au1200 SOC just doesn't have UART3, so KGDB won't even compile for it as is, here's the fix to make KGDB use UART1. Note that I haven't really tested KGDB itself... WBR, Sergei --------------040105000905030801070202 Content-Type: text/plain; name="DBAu1200-fix-KGDB-UART.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DBAu1200-fix-KGDB-UART.patch" diff --git a/include/asm-mips/mach-au1x00/au1000.h b/include/asm-mips/mach-au1x00/au1000.h index 8e1d7ed..4686e17 100644 --- a/include/asm-mips/mach-au1x00/au1000.h +++ b/include/asm-mips/mach-au1x00/au1000.h @@ -1198,7 +1198,11 @@ extern au1xxx_irq_map_t au1xxx_irq_map[] /* UARTS 0-3 */ #define UART_BASE UART0_ADDR +#ifdef CONFIG_SOC_AU1200 +#define UART_DEBUG_BASE UART1_ADDR +#else #define UART_DEBUG_BASE UART3_ADDR +#endif #define UART_RX 0 /* Receive buffer */ #define UART_TX 4 /* Transmit buffer */ --------------040105000905030801070202-- From sshtylyov@ru.mvista.com Fri Jan 6 16:33:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 16:33:23 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:46768 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S8133585AbWAFQdF (ORCPT ); Fri, 6 Jan 2006 16:33:05 +0000 Received: (qmail 5346 invoked from network); 6 Jan 2006 16:35:42 -0000 Received: from wasted.dev.rtsoft.ru (HELO ?192.168.1.248?) (192.168.1.248) by mail.dev.rtsoft.ru with SMTP; 6 Jan 2006 16:35:42 -0000 Message-ID: <43BE9CED.3080207@ru.mvista.com> Date: Fri, 06 Jan 2006 19:38:05 +0300 From: Sergei Shtylylov Organization: MostaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Linux MIPS CC: Manish Lachwani , ralf@linux-mips.org Subject: [PATCH] Make KGDB compile again Content-Type: multipart/mixed; boundary="------------030207070504090609040403" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Content-Length: 976 Lines: 38 This is a multi-part message in MIME format. --------------030207070504090609040403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. The last commit to arch/mips/kernel/gdb-stub.c introduced a stupid typo into the spinlock initializer, here's the fix... WBR, Sergei --------------030207070504090609040403 Content-Type: text/plain; name="KGDB-fix-spinlock-init.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="KGDB-fix-spinlock-init.patch" diff --git a/arch/mips/kernel/gdb-stub.c b/arch/mips/kernel/gdb-stub.c index 96d18c4..0b2c44f 100644 --- a/arch/mips/kernel/gdb-stub.c +++ b/arch/mips/kernel/gdb-stub.c @@ -178,7 +178,7 @@ int kgdb_enabled; */ static DEFINE_SPINLOCK(kgdb_lock); static raw_spinlock_t kgdb_cpulock[NR_CPUS] = { - [0 ... NR_CPUS-1] = __RAW_SPIN_LOCK_UNLOCKED; + [0 ... NR_CPUS-1] = __RAW_SPIN_LOCK_UNLOCKED }; /* --------------030207070504090609040403-- From jcrouse@cosmic.amd.com Fri Jan 6 16:34:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 16:35:09 +0000 (GMT) Received: from amdext3.amd.com ([139.95.251.6]:9654 "EHLO amdext3.amd.com") by ftp.linux-mips.org with ESMTP id S8133585AbWAFQer (ORCPT ); Fri, 6 Jan 2006 16:34:47 +0000 Received: from SSVLGW02.amd.com (ssvlgw02.amd.com [139.95.250.170]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k06GY0Ar000480; Fri, 6 Jan 2006 08:36:31 -0800 Received: from 139.95.250.1 by SSVLGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 06 Jan 2006 08:36:21 -0800 X-Server-Uuid: 519AC16A-9632-469E-B354-112C592D09E8 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id k06GaLVP007358; Fri, 6 Jan 2006 08:36:21 -0800 (PST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id C5CD9202D; Fri, 6 Jan 2006 09:36:20 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k06Gi9Yc016061; Fri, 6 Jan 2006 09:44:09 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k06Gi6Wn016060; Fri, 6 Jan 2006 09:44:06 -0700 Date: Fri, 6 Jan 2006 09:44:06 -0700 From: "Jordan Crouse" To: linux-mips@linux-mips.org, rmk+lkml@arm.linux.org.uk, drzeus@drzeus.cx Subject: [PATCH] Force MMC/SD to 512 byte block sizes Message-ID: <20060106164406.GA15617@cosmic.amd.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.11 X-WSS-ID: 6FA0430F2C42669973-01-01 Content-Type: multipart/mixed; boundary=45Z9DzgjV8m4Oswq Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 3279 Lines: 103 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit This patch is not specific to the AU1200 SD driver, but thats what we used to debug and verify this, so thats why it is applied against the linux-mips tree. Pierre, I'm sending this to you too, because I thought you may be interested. Large SD cards (>=2GB) report a physical block size greater then 512 bytes (2GB reports 1024, and 4GB reports 2048). However, a sample of different brands of USB attached SD readers have shown that the logical block size is still forced to 512 bytes. The original mmc_block code was setting the block size to whatever the card was reporting, thereby causing much pain and suffering when using a card initialized elsewhere (bad partition tables, invalid FAT tables, etc). This patch forces the block size to be 512 bytes, and adjusts the capacity accordingly. With this you should be able to happily use very large cards interchangeably between platforms. At least, it has worked for us. Comments welcome, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mmc_fix.patch Content-Transfer-Encoding: 7bit PATCH: Force MMC/SD to 512 byte block sizes. Angry customers and investigation into USB attached MMC/SD readers have lead us to believe that the SD device block size should be fixed at 512 bytes regardless of the block size reported by the card. This comes into play with >2G cards. After applying this fix, filesystems written with a USB card reader can be read by the MMC subsystem and vice-versa. Signed-off-by: Jordan Crouse --- drivers/mmc/mmc_block.c | 16 +++++++++++++--- 1 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/mmc_block.c b/drivers/mmc/mmc_block.c index d91fcf7..96fa121 100644 --- a/drivers/mmc/mmc_block.c +++ b/drivers/mmc/mmc_block.c @@ -303,6 +303,7 @@ static struct mmc_blk_data *mmc_blk_allo { struct mmc_blk_data *md; int devidx, ret; + unsigned long cap; devidx = find_first_zero_bit(dev_use, MMC_NUM_MINORS); if (devidx >= MMC_NUM_MINORS) @@ -356,10 +357,19 @@ static struct mmc_blk_data *mmc_blk_allo sprintf(md->disk->disk_name, "mmcblk%d", devidx); sprintf(md->disk->devfs_name, "mmc/blk%d", devidx); - md->block_bits = card->csd.read_blkbits; + if (card->csd.read_blkbits > 9) { + md->block_bits = 9; + + cap = card->csd.capacity << + (card->csd.read_blkbits - 9); + } + else { + md->block_bits = card->csd.read_blkbits; + cap = card->csd.capacity; + } blk_queue_hardsect_size(md->queue.queue, 1 << md->block_bits); - set_capacity(md->disk, card->csd.capacity); + set_capacity(md->disk, cap); } out: return md; @@ -373,7 +383,7 @@ mmc_blk_set_blksize(struct mmc_blk_data mmc_card_claim_host(card); cmd.opcode = MMC_SET_BLOCKLEN; - cmd.arg = 1 << card->csd.read_blkbits; + cmd.arg = 1 << ((card->csd.read_blkbits > 9) ? 9 : card->csd.read_blkbits); cmd.flags = MMC_RSP_R1; err = mmc_wait_for_cmd(card->host, &cmd, 5); mmc_card_release_host(card); --45Z9DzgjV8m4Oswq-- From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Fri Jan 6 16:56:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 16:57:11 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([212.18.232.186]:22285 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S8133583AbWAFQ4x (ORCPT ); Fri, 6 Jan 2006 16:56:53 +0000 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.52) id 1Euuw8-0001Qt-UD; Fri, 06 Jan 2006 16:59:33 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.52) id 1Euuw6-0007xQ-Me; Fri, 06 Jan 2006 16:59:31 +0000 Date: Fri, 6 Jan 2006 16:59:30 +0000 From: Russell King To: Jordan Crouse Cc: linux-mips@linux-mips.org, drzeus@drzeus.cx Subject: Re: [PATCH] Force MMC/SD to 512 byte block sizes Message-ID: <20060106165930.GC16093@flint.arm.linux.org.uk> References: <20060106164406.GA15617@cosmic.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060106164406.GA15617@cosmic.amd.com> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-mips Content-Length: 687 Lines: 17 On Fri, Jan 06, 2006 at 09:44:06AM -0700, Jordan Crouse wrote: > This patch is not specific to the AU1200 SD driver, but thats what > we used to debug and verify this, so thats why it is applied against > the linux-mips tree. Pierre, I'm sending this to you too, because I thought > you may be interested. NACK. Please wait until the next round of patches get merged and then revalidate this. It's obviously wrong in the case of cards which do not support partial block writes, and it does nothing to detect this (apart from violating their advertised capabilities.) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core From drzeus@drzeus.cx Fri Jan 6 17:01:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 17:02:01 +0000 (GMT) Received: from [85.8.13.51] ([85.8.13.51]:31681 "EHLO smtp.drzeus.cx") by ftp.linux-mips.org with ESMTP id S8133583AbWAFRBo (ORCPT ); Fri, 6 Jan 2006 17:01:44 +0000 Received: from [10.8.0.5] (apollo.drzeus.cx [::ffff:10.8.0.5]) (AUTH: PLAIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by smtp.drzeus.cx with esmtp; Fri, 06 Jan 2006 18:04:24 +0100 id 00062716.43BEA318.00007826 Message-ID: <43BEA317.8010203@drzeus.cx> Date: Fri, 06 Jan 2006 18:04:23 +0100 From: Pierre Ossman User-Agent: Mozilla Thunderbird 1.0.7-2.1.fc4.nr (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jordan Crouse CC: linux-mips@linux-mips.org, rmk+lkml@arm.linux.org.uk Subject: Re: [PATCH] Force MMC/SD to 512 byte block sizes References: <20060106164406.GA15617@cosmic.amd.com> In-Reply-To: <20060106164406.GA15617@cosmic.amd.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: drzeus@drzeus.cx Precedence: bulk X-list: linux-mips Content-Length: 1933 Lines: 49 Jordan Crouse wrote: > This patch is not specific to the AU1200 SD driver, but thats what > we used to debug and verify this, so thats why it is applied against > the linux-mips tree. Pierre, I'm sending this to you too, because I thought > you may be interested. Much appreciated. :) > > Large SD cards (>=2GB) report a physical block size greater then 512 bytes > (2GB reports 1024, and 4GB reports 2048). However, a sample of different > brands of USB attached SD readers have shown that the logical block size > is still forced to 512 bytes. > > The original mmc_block code was setting the block size to whatever the > card was reporting, thereby causing much pain and suffering when using > a card initialized elsewhere (bad partition tables, invalid FAT tables, etc). > > This patch forces the block size to be 512 bytes, and adjusts the > capacity accordingly. With this you should be able to happily use very > large cards interchangeably between platforms. At least, it has worked for > us. > > > @@ -373,7 +383,7 @@ mmc_blk_set_blksize(struct mmc_blk_data > > mmc_card_claim_host(card); > cmd.opcode = MMC_SET_BLOCKLEN; > - cmd.arg = 1 << card->csd.read_blkbits; > + cmd.arg = 1 << ((card->csd.read_blkbits > 9) ? 9 : card->csd.read_blkbits); > cmd.flags = MMC_RSP_R1; > err = mmc_wait_for_cmd(card->host, &cmd, 5); > mmc_card_release_host(card); This will not work. Some cards do not accept block sizes larger than the one they've specified. This issue has been discussed on the arm kernel ml and Russell has begun producing patches to resolve the issue. To solve the issue you're seeing we should lie to the block layer, not the card. Which will cause problems when the block layer issues request that cannot be mapped to a integer number of card blocks. The issue is more complex than your patch suggests and I do not know enough about the block layer to propose a way out. Rgds Pierre From jcrouse@cosmic.amd.com Fri Jan 6 17:32:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 17:32:46 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:21978 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133821AbWAFRcX (ORCPT ); Fri, 6 Jan 2006 17:32:23 +0000 Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k06HYWIK013993; Fri, 6 Jan 2006 11:34:42 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 06 Jan 2006 11:34:35 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id k06HYZh5002156; Fri, 6 Jan 2006 11:34:35 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id EBF1B2028; Fri, 6 Jan 2006 10:34:34 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k06HgO0T016686; Fri, 6 Jan 2006 10:42:24 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k06HgNS2016685; Fri, 6 Jan 2006 10:42:23 -0700 Date: Fri, 6 Jan 2006 10:42:23 -0700 From: "Jordan Crouse" To: "Russell King" cc: linux-mips@linux-mips.org, drzeus@drzeus.cx Subject: Re: Force MMC/SD to 512 byte block sizes Message-ID: <20060106174223.GB15617@cosmic.amd.com> References: <20060106164406.GA15617@cosmic.amd.com> <20060106165930.GC16093@flint.arm.linux.org.uk> MIME-Version: 1.0 In-Reply-To: <20060106165930.GC16093@flint.arm.linux.org.uk> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FA075A10T02055239-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 1181 Lines: 32 On 06/01/06 16:59 +0000, Russell King wrote: > On Fri, Jan 06, 2006 at 09:44:06AM -0700, Jordan Crouse wrote: > > This patch is not specific to the AU1200 SD driver, but thats what > > we used to debug and verify this, so thats why it is applied against > > the linux-mips tree. Pierre, I'm sending this to you too, because I thought > > you may be interested. > > NACK. Please wait until the next round of patches get merged and then > revalidate this. Fair enough - I am only getting what Ralf and Linus put in their git tree - I probably should have checked your tree before assuming the code was current. > It's obviously wrong in the case of cards which do not support partial > block writes, and it does nothing to detect this (apart from violating > their advertised capabilities.) Ok - I can understand that - its unlikely that such cards would have a physical block size > 512 bytes, but its always better to be safe then sorry. Thats a fairly straight forward fix, and I'll do it while waiting for your code to bubble through. Regards, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From jcrouse@cosmic.amd.com Fri Jan 6 17:40:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 17:40:29 +0000 (GMT) Received: from amdext4.amd.com ([163.181.251.6]:7387 "EHLO amdext4.amd.com") by ftp.linux-mips.org with ESMTP id S8133835AbWAFRkH (ORCPT ); Fri, 6 Jan 2006 17:40:07 +0000 Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id k06HgGth015227; Fri, 6 Jan 2006 11:42:31 -0600 Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.1.0)); Fri, 06 Jan 2006 11:42:20 -0600 X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id k06HgKh5002423; Fri, 6 Jan 2006 11:42:20 -0600 (CST) Received: from cosmic.amd.com (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with ESMTP id D70262028; Fri, 6 Jan 2006 10:42:19 -0700 (MST) Received: from cosmic.amd.com (localhost [127.0.0.1]) by cosmic.amd.com (8.13.4/8.13.4) with ESMTP id k06Ho9cp016715; Fri, 6 Jan 2006 10:50:09 -0700 Received: (from jcrouse@localhost) by cosmic.amd.com ( 8.13.4/8.13.4/Submit) id k06Ho8Zs016714; Fri, 6 Jan 2006 10:50:08 -0700 Date: Fri, 6 Jan 2006 10:50:08 -0700 From: "Jordan Crouse" To: "Pierre Ossman" cc: linux-mips@linux-mips.org, rmk+lkml@arm.linux.org.uk Subject: Re: Force MMC/SD to 512 byte block sizes Message-ID: <20060106175008.GC15617@cosmic.amd.com> References: <20060106164406.GA15617@cosmic.amd.com> <43BEA317.8010203@drzeus.cx> MIME-Version: 1.0 In-Reply-To: <43BEA317.8010203@drzeus.cx> User-Agent: Mutt/1.5.11 X-WSS-ID: 6FA074760T02056895-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jordan.crouse@amd.com Precedence: bulk X-list: linux-mips Content-Length: 717 Lines: 22 On 06/01/06 18:04 +0100, Pierre Ossman wrote: > This will not work. Some cards do not accept block sizes larger than the > one they've specified. > > This issue has been discussed on the arm kernel ml and Russell has begun > producing patches to resolve the issue. Which just goes to prove that if I'm going to do SD development, I need to start watching the right mailing lists. I'll defer to the previous work on this - I do know that this has worked for pretty much every 2G and 4G card we could get our hands on, so that was enough for me to throw it at you guys and see what sticks. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group From linux-mips@packetvision.com Fri Jan 6 17:48:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Jan 2006 17:48:51 +0000 (GMT) Received: from mra02.ch.as12513.net ([82.153.252.24]:13224 "EHLO mra02.ch.as12513.net") by ftp.linux-mips.org with ESMTP id S8133842AbWAFRse (ORCPT ); Fri, 6 Jan 2006 17:48:34 +0000 Received: from localhost (localhost [127.0.0.1]) by mra02.ch.as12513.net (Postfix) with ESMTP id 936F8D4504; Fri, 6 Jan 2006 17:51:10 +0000 (GMT) Received: from mra02.ch.as12513.net ([127.0.0.1]) by localhost (mra02.ch.as12513.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29495-01-21; Fri, 6 Jan 2006 17:51:10 +0000 (GMT) Received: from [192.168.1.212] (unknown [82.152.104.245]) by mra02.ch.as12513.net (Postfix) with ESMTP id 8F099D45B3; Fri, 6 Jan 2006 17:51:09 +0000 (GMT) Subject: Re: Jump/branch to external symbol From: Alex Gonzalez Reply-To: linux-mips@alexgg.plus.com To: Daniel Jacobowitz Cc: "Maciej W. Rozycki" , Alex Gonzalez , linux-mips@linux-mips.org In-Reply-To: <20060106145216.GA6849@nevyn.them.org> References: <20060106145216.GA6849@nevyn.them.org> Content-Type: text/plain Date: Fri, 06 Jan 2006 17:50:20 +0000 Message-Id: <1136569820.9887.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux-mips@packetvision.com Precedence: bulk X-list: linux-mips Content-Length: 671 Lines: 19 Thanks, that works. Somehow it didn't occurred to me to try it. Alex On Fri, 2006-01-06 at 09:52 -0500, Daniel Jacobowitz wrote: > On Fri, Jan 06, 2006 at 11:51:56AM +0000, Maciej W. Rozycki wrote: > > On Fri, 6 Jan 2006, Alex Gonzalez wrote: > > > > > I am happy with the patch for binutils-2.15, and I would need a > > > solution for binutils-2.13. > > > > > > Can anybody offer any help? > > > > Well, the most obvious solution is upgrading to the current release, > > which is 2.16.1 now. Otherwise you are probably on your own -- 2.15 is > > already somewhat old and 2.13 is ancient. > > Or better yet to trunk and you won't need any patches for this. > From zzh.hust@gmail.com Sat Jan 7 03:36:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jan 2006 03:37:05 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.206]:19296 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8133835AbWAGDgs convert rfc822-to-8bit (ORCPT ); Sat, 7 Jan 2006 03:36:48 +0000 Received: by wproxy.gmail.com with SMTP id 36so2988747wra for ; Fri, 06 Jan 2006 19:39:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I1kW2CCPDtkoxj+NvQlmBT8FTYN8gBBu+hcqO4jrpkgO6DlfvRGnnrvBSPx0OUt4yj+o2CiSXcHHf/YqfFTmm6so8e34lzzCU/4OryKPJZbdEBHU5SFhM5B3qWDncIHXXqq6wt6qKJSSXD5fHLpDXT2Wo6lsooeOtkKttmZz8e0= Received: by 10.54.158.2 with SMTP id g2mr1596625wre; Fri, 06 Jan 2006 19:38:46 -0800 (PST) Received: by 10.54.156.1 with HTTP; Fri, 6 Jan 2006 19:39:32 -0800 (PST) Message-ID: <50c9a2250601061939j42c4cc85n1c0246d9f8068938@mail.gmail.com> Date: Sat, 7 Jan 2006 11:39:32 +0800 From: zhuzhenhua To: jp Subject: Re: sometimes get "crc error" while uncompressed ramdisk Cc: linux-mips In-Reply-To: <1136537813.5239.23.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <50c9a2250601052240n5696e353teb2b798ecbf802f0@mail.gmail.com> <1136537813.5239.23.camel@localhost.localdomain> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1112 Lines: 36 On 1/6/06, jp wrote: > On Fri, 2006-01-06 at 14:40 +0800, zhuzhenhua wrote: > > i make a ramdisk by myself, and sometimes the kernel boot the ramdisk > > correctly but sometimes it printk "crc error" while uncompressed > > ramdisk, did someone meet this situation? > > thanks for any hints > > > > Assuming your build and everything else is as it should be it may be a > RAM fault. Are you using a custom board? > > I had some prototype boards here with some really long tracks to RAM. > (and some really short ones too!) > > Memory tests such walking ones worked fine but the decompress of the > ramdisk works RAM pretty hard and it showed up intermittent faults like > you describe. Tended to be worse when the board was warm. I'd spray some > Freezit on and it would go back to working OK. > > You could also try running the RAM slower and see if the fault > disappears. > > > JP > > > maybe you are right, because i work on our FPGA board, and the situation is similiar as your description. i will try to slow down the sdram and to see what will happen thanks! Best regards zhuzhenhua From lhrkernelcoder@gmail.com Sat Jan 7 06:59:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jan 2006 07:00:09 +0000 (GMT) Received: from wproxy.gmail.com ([64.233.184.207]:42318 "EHLO wproxy.gmail.com") by ftp.linux-mips.org with ESMTP id S8126484AbWAGG7v convert rfc822-to-8bit (ORCPT ); Sat, 7 Jan 2006 06:59:51 +0000 Received: by wproxy.gmail.com with SMTP id 36so3005044wra for ; Fri, 06 Jan 2006 23:02:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YxkG56eHgDUukODYCBCprgk+yrQAsIJBInd2m0rabMIsK0c/+vqNtizBmfDzRLcK3tYbdJ0p/Yt9vJen9H/ujuWADjjFIXGvnTg8Arf+FVJ32qqtbuZMs2+g3Ccmv13YWIZZEWQ8Bsr9mykYJOmb9xp8fSFFVZ37CTiOOUfqXwE= Received: by 10.54.139.2 with SMTP id m2mr5774314wrd; Fri, 06 Jan 2006 23:02:37 -0800 (PST) Received: by 10.54.147.20 with HTTP; Fri, 6 Jan 2006 23:02:37 -0800 (PST) Message-ID: Date: Fri, 6 Jan 2006 23:02:37 -0800 From: kernel coder To: linux-mips@linux-mips.org Subject: Almost 80% of UDP packets dropped MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lhrkernelcoder@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1314 Lines: 30 hi, I was trying to measure the UDP reception speed on my borad which has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file from intel pentium 4 machine to MIPS board,but the recieved file was only 900kB. When i further investigated the problem ,i came to know that the user application was not getting enough opportunities to get data from socket queue which caused almost 80% of packets to be dropped as socket queue had no free space. When i increased the socket recieve buffer size,it resulted in increase in no. of packets recieved .When i slow slowed down the transmitter , it also caused more packets to be recieved. But the above mentioned mechanism only decreased no. of lost packets.But there was no way that i could increase UDP reception speed because the user application was not getting enough opportunities to read packets in burst of UDP packets. I noticed that user application started recieveing packets after Kernel had recieved all the UDP packets. Please tell me how can i make sure that user application or udp client running MIPS 4kc processor gets enough opportunities to dequeue packets from socket buffer so that lost of packets could be reduced to minimal and also the size of UDP recieved file in a specific interval of time could be increased. lhrkernelcoder From fosterb@uoguelph.ca Sat Jan 7 07:35:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jan 2006 07:35:49 +0000 (GMT) Received: from dragonboat.cs.uoguelph.ca ([131.104.96.108]:39624 "EHLO dragonboat.cs.uoguelph.ca") by ftp.linux-mips.org with ESMTP id S8126484AbWAGHf2 (ORCPT ); Sat, 7 Jan 2006 07:35:28 +0000 Received: from beddie.cis.uoguelph.ca (marvin.cis.uoguelph.ca [131.104.48.131]) by dragonboat.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id k077cDWd021183; Sat, 7 Jan 2006 02:38:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by beddie.cis.uoguelph.ca (Postfix) with ESMTP id 53BA17E8F; Sat, 7 Jan 2006 02:36:17 -0500 (EST) Received: from beddie.cis.uoguelph.ca ([127.0.0.1]) by localhost (beddie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21768-06; Sat, 7 Jan 2006 02:36:16 -0500 (EST) Received: from [192.168.0.104] (CPE001217cc2ab6-CM001371143eca.cpe.net.cable.rogers.com [70.30.137.118]) by beddie.cis.uoguelph.ca (Postfix) with ESMTP id 685557D0D; Sat, 7 Jan 2006 02:36:16 -0500 (EST) Message-ID: <43BF6FE3.7030600@uoguelph.ca> Date: Sat, 07 Jan 2006 02:38:11 -0500 From: Brett Foster User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kernel coder CC: linux-mips@linux-mips.org Subject: Re: Almost 80% of UDP packets dropped References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cs-club.org X-Scanned-By: MIMEDefang 2.52 on 131.104.96.108 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fosterb@uoguelph.ca Precedence: bulk X-list: linux-mips Content-Length: 875 Lines: 25 kernel coder wrote: >hi, > I was trying to measure the UDP reception speed on my borad which >has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file >from intel pentium 4 machine to MIPS board,but the recieved file was >only 900kB. > > UDP was not designed with reliability in mind -- it really isn't meant for sending a 10 meg file without a packet loss. >When i further investigated the problem ,i came to know that the user >application was not getting enough opportunities to get data from >socket queue which caused almost 80% of packets to be dropped as >socket queue had no free space. > > (Among other sources) I'm pretty sure this behaviour was discussed in: Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition (Something like page 257.) I don't know if there is anything else going on with the kernel but... Brett From KevinK@mips.com Sat Jan 7 09:22:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jan 2006 09:22:25 +0000 (GMT) Received: from 209-232-97-206.ded.pacbell.net ([209.232.97.206]:37098 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S8133363AbWAGJWI (ORCPT ); Sat, 7 Jan 2006 09:22:08 +0000 Received: from mercury.mips.com (sbcns-dmz [209.232.97.193]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id k079Oipt001546; Sat, 7 Jan 2006 01:24:44 -0800 (PST) Received: from Ulysses (laptop-ying-ho.mips.com [192.168.2.2] (may be forged)) by mercury.mips.com (8.12.9/8.12.11) with SMTP id k079OdYr004772; Sat, 7 Jan 2006 01:24:40 -0800 (PST) Message-ID: <001d01c6136c$2a77ae40$0202a8c0@Ulysses> From: "Kevin D. Kissell" To: "kernel coder" , References: Subject: Re: Almost 80% of UDP packets dropped Date: Sat, 7 Jan 2006 10:24:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: KevinK@mips.com Precedence: bulk X-list: linux-mips Content-Length: 1706 Lines: 42 What value of HZ are you using? If you're still at the 2.6 default of 1000, try reducing it to 100 and see if things improve... ----- Original Message ----- From: "kernel coder" To: Sent: Saturday, January 07, 2006 8:02 AM Subject: Almost 80% of UDP packets dropped > hi, > I was trying to measure the UDP reception speed on my borad which > has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file > from intel pentium 4 machine to MIPS board,but the recieved file was > only 900kB. > > When i further investigated the problem ,i came to know that the user > application was not getting enough opportunities to get data from > socket queue which caused almost 80% of packets to be dropped as > socket queue had no free space. > > When i increased the socket recieve buffer size,it resulted in > increase in no. of packets recieved .When i slow slowed down the > transmitter , it also caused more packets to be recieved. > > But the above mentioned mechanism only decreased no. of lost > packets.But there was no way that i could increase UDP reception speed > because the user application was not getting enough opportunities to > read packets in burst of UDP packets. > > I noticed that user application started recieveing packets after > Kernel had recieved all the UDP packets. > > Please tell me how can i make sure that user application or udp client > running MIPS 4kc processor gets enough opportunities to dequeue > packets from socket buffer so that lost of packets could be reduced to > minimal and also the size of UDP recieved file in a specific interval > of time could be increased. > > lhrkernelcoder > > From alan@lxorguk.ukuu.org.uk Sat Jan 7 09:42:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Jan 2006 09:43:14 +0000 (GMT) Received: from [81.2.110.250] ([81.2.110.250]:22931 "EHLO lxorguk.ukuu.org.uk") by ftp.linux-mips.org with ESMTP id S8133363AbWAGJm5 (ORCPT ); Sat, 7 Jan 2006 09:42:57 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.13.4/8.13.4) with ESMTP id k079meLo010775; Sat, 7 Jan 2006 09:48:41 GMT Received: (from alan@localhost) by localhost.localdomain (8.13.4/8.13.4/Submit) id k079md6L010774; Sat, 7 Jan 2006 09:48:39 GMT X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Almost 80% of UDP packets dropped From: Alan Cox To: kernel coder Cc: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 07 Jan 2006 09:48:35 +0000 Message-Id: <1136627315.3748.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 9801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 613 Lines: 14 On Gwe, 2006-01-06 at 23:02 -0800, kernel coder wrote: > I noticed that user application started recieveing packets after > Kernel had recieved all the UDP packets. If your network chip/ram/processor c