From rolfliu@gmail.com Fri Jul  1 00:55:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 00:55:57 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.202]:42141 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226113AbVF3Xzi> convert rfc822-to-8bit;
	Fri, 1 Jul 2005 00:55:38 +0100
Received: by wproxy.gmail.com with SMTP id 70so234930wra
        for <linux-mips@linux-mips.org>; Thu, 30 Jun 2005 16:55:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=S+h2cSFVfMLfEVq8ziTAv7KV6T2imsySwIPKIxtyX5RfRD9+7S2yS7g+1zihSMojhUXyEi3eIe/2bsS1/zV4E7wVl1i4zgeQrG7pxPg+5JbCnFnuU4KZgHMYb6o3kuAjLbjfw5dgBnzzJu5xexTgMMBC+esqvJ89GpQgB58+Vfk=
Received: by 10.54.38.64 with SMTP id l64mr795705wrl;
        Thu, 30 Jun 2005 16:55:25 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 30 Jun 2005 16:55:25 -0700 (PDT)
Message-ID: <2db32b720506301655542c8c15@mail.gmail.com>
Date:	Thu, 30 Jun 2005 16:55:25 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: ide support on db1550 of linux 2.4.31
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8281
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips

I just made the multi-port work on db1550. The problem is due to the
misplacement of the UART register. So if anybody else want to run
other boards on db1550, make sure you use the UART register address of
your "own boards", not au1000.h. Thanks for the help.

Now I am trying to support a IDE/CompactFlash adapter. I patched the
kernel as other mentioned, forcing HPT371N to use the timing of
HPT372N. But got no luck to succeed.  The output is:

Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT371: IDE controller at PCI slot 00:0b.0
HPT371: chipset revision 2
HPT371: not 100% native mode: will probe irqs later
hpt: HPT372N detected, using 372N timing.
FREQ: 73 PLL: 35
hpt: no known IDE timings, disabling DMA.
hpt: no known IDE timings, disabling DMA.
probing for hda: present=0, media=32, probetype=ATA
probing for hda: present=0, media=32, probetype=ATAPI
probing for hdb: present=0, media=32, probetype=ATA
probing for hdb: present=0, media=32, probetype=ATAPI
probing for hdc: present=0, media=32, probetype=ATA
probing for hdc: present=0, media=32, probetype=ATAPI
probing for hdd: present=0, media=32, probetype=ATA
probing for hdd: present=0, media=32, probetype=ATAPI
probing for hde: present=0, media=32, probetype=ATA
probing for hde: present=0, media=32, probetype=ATAPI
probing for hdf: present=0, media=32, probetype=ATA
probing for hdf: present=0, media=32, probetype=ATAPI
probing for hdg: present=0, media=32, probetype=ATA
probing for hdg: present=0, media=32, probetype=ATAPI
probing for hdh: present=0, media=32, probetype=ATA
probing for hdh: present=0, media=32, probetype=ATAPI
probing for hdi: present=0, media=32, probetype=ATA
probing for hdi: present=0, media=32, probetype=ATAPI
probing for hdj: present=0, media=32, probetype=ATA
probing for hdj: present=0, media=32, probetype=ATAPI
probing for hdk: present=0, media=32, probetype=ATA
probing for hdk: present=0, media=32, probetype=ATAPI
probing for hdl: present=0, media=32, probetype=ATA
probing for hdl: present=0, media=32, probetype=ATAPI

Any idea what is happening here?

thanks

From anemo@mba.ocn.ne.jp Fri Jul  1 03:44:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 03:44:37 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:38918
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8226124AbVGACoP>; Fri, 1 Jul 2005 03:44:15 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 1 Jul 2005 02:44:03 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id A4A041F472;
	Fri,  1 Jul 2005 11:43:59 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 8EB6318E4E;
	Fri,  1 Jul 2005 11:43:59 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j612hwoj014952;
	Fri, 1 Jul 2005 11:43:59 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Fri, 01 Jul 2005 11:43:58 +0900 (JST)
Message-Id: <20050701.114358.21591461.nemoto@toshiba-tops.co.jp>
To:	djohnson+linuxmips@sw.starentnetworks.com
Cc:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <17092.5345.75666.403044@cortez.sw.starentnetworks.com>
References: <17092.5345.75666.403044@cortez.sw.starentnetworks.com>
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.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 8282
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, 30 Jun 2005 11:50:57 -0400, Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com> said:
dave> The PC it was trying to lookup is in preempt_schedule_irq().
dave> Without preempt_schedule_irq in mfinfo[] it ended up with the
dave> wrong function and then dereferenced a NULL FP.

dave> Should this be in mfinfo or am I on the wrong track here?
...
dave> Also, __preempt_spin_lock and __preempt_write_lock are nowhere
dave> to be found so I had to remove those from the table.

Well, The current get_wchan implementation is still problematic
because:

* Some functions in __sched (and __lock) section are static.
* Functions in __lock are not handled.
* Maintenance of the struct mips_frame_info mfinfo[] is a pain.
* sleep_on*() is deprecated.  kernel-janitors people want to remove
  references for them.

I suppose searching a caller of scheduling functions in get_wchan is
not necessary.  Calling thread_saved_pc() will be enough for most
usage.

So I posted a patch to simplify things a while ago.

http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20050126.120916.88699500.nemoto%40toshiba-tops.co.jp

And here is a revised patch.

diff -u linux-mips/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
--- linux-mips/arch/mips/kernel/process.c	2005-06-21 17:34:10.000000000 +0900
+++ linux/arch/mips/kernel/process.c	2005-07-01 11:15:26.000000000 +0900
@@ -270,47 +270,15 @@
 }
 
 static struct mips_frame_info {
-	void *func;
-	int omit_fp;	/* compiled without fno-omit-frame-pointer */
 	int frame_offset;
 	int pc_offset;
-} schedule_frame, mfinfo[] = {
-	{ schedule, 0 },	/* must be first */
-	/* arch/mips/kernel/semaphore.c */
-	{ __down, 1 },
-	{ __down_interruptible, 1 },
-	/* kernel/sched.c */
-#ifdef CONFIG_PREEMPT
-	{ preempt_schedule, 0 },
-#endif
-	{ wait_for_completion, 0 },
-	{ interruptible_sleep_on, 0 },
-	{ interruptible_sleep_on_timeout, 0 },
-	{ sleep_on, 0 },
-	{ sleep_on_timeout, 0 },
-	{ yield, 0 },
-	{ io_schedule, 0 },
-	{ io_schedule_timeout, 0 },
-#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT)
-	{ __preempt_spin_lock, 0 },
-	{ __preempt_write_lock, 0 },
-#endif
-	/* kernel/timer.c */
-	{ schedule_timeout, 1 },
-/*	{ nanosleep_restart, 1 }, */
-	/* lib/rwsem-spinlock.c */
-	{ __down_read, 1 },
-	{ __down_write, 1 },
-};
-
-static int mips_frame_info_initialized;
-static int __init get_frame_info(struct mips_frame_info *info)
+} schedule_frame;
+static int __init get_frame_info(struct mips_frame_info *info, void *func)
 {
 	int i;
-	void *func = info->func;
 	union mips_instruction *ip = (union mips_instruction *)func;
 	info->pc_offset = -1;
-	info->frame_offset = info->omit_fp ? 0 : -1;
+	info->frame_offset = -1;
 	for (i = 0; i < 128; i++, ip++) {
 		/* if jal, jalr, jr, stop. */
 		if (ip->j_format.opcode == jal_op ||
@@ -358,26 +326,7 @@
 
 static int __init frame_info_init(void)
 {
-	int i, found;
-	for (i = 0; i < ARRAY_SIZE(mfinfo); i++)
-		if (get_frame_info(&mfinfo[i]))
-			return -1;
-	schedule_frame = mfinfo[0];
-	/* bubble sort */
-	do {
-		struct mips_frame_info tmp;
-		found = 0;
-		for (i = 1; i < ARRAY_SIZE(mfinfo); i++) {
-			if (mfinfo[i-1].func > mfinfo[i].func) {
-				tmp = mfinfo[i];
-				mfinfo[i] = mfinfo[i-1];
-				mfinfo[i-1] = tmp;
-				found = 1;
-			}
-		}
-	} while (found);
-	mips_frame_info_initialized = 1;
-	return 0;
+	return get_frame_info(&schedule_frame, schedule);
 }
 
 arch_initcall(frame_info_init);
@@ -398,39 +347,12 @@
 	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
 }
 
-/* get_wchan - a maintenance nightmare^W^Wpain in the ass ...  */
 unsigned long get_wchan(struct task_struct *p)
 {
-	unsigned long frame, pc;
-
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
-	if (!mips_frame_info_initialized)
-		return 0;
-	pc = thread_saved_pc(p);
-
-	if (!in_sched_functions(pc))
-		goto out;
-
-	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
-	do {
-		int i;
-		for (i = ARRAY_SIZE(mfinfo) - 1; i >= 0; i--) {
-			if (pc >= (unsigned long) mfinfo[i].func)
-				break;
-		}
-		if (i < 0)
-			break;
-
-		if (mfinfo[i].omit_fp)
-			break;
-		pc = ((unsigned long *)frame)[mfinfo[i].pc_offset];
-		frame = ((unsigned long *)frame)[mfinfo[i].frame_offset];
-	} while (in_sched_functions(pc));
-
-out:
-	return pc;
+	return thread_saved_pc(p);
 }
 
 EXPORT_SYMBOL(get_wchan);


---
Atsushi Nemoto

From drow@nevyn.them.org Fri Jul  1 04:51:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 04:51:39 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:31150 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8226113AbVGADvV>;
	Fri, 1 Jul 2005 04:51:21 +0100
Received: from drow by nevyn.them.org with local (Exim 4.51)
	id 1DoCYT-0002VU-L9; Thu, 30 Jun 2005 23:51:05 -0400
Date:	Thu, 30 Jun 2005 23:51:05 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Stephen P. Becker" <geoman@gentoo.org>
Cc:	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
Message-ID: <20050701035105.GA9601@nevyn.them.org>
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42C46D85.9050104@gentoo.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
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: 8283
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

On Thu, Jun 30, 2005 at 06:09:09PM -0400, Stephen P. Becker wrote:
> 
> > Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> > I don't know how well that works nowadays; but current CVS versions do
> > work, or did when I last tested (a month or two ago).
> > 
> 
> Hmm, well with respect to my problem, I'm using a pretty recent
> toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> Bryan's segfault, but could not.  That code ran without error when I
> linked with libpthread.  Any thoughts?

I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
in a long time.  Try CVS HEAD of glibc instead.

Other than that, you're on your own - building glibc is extremely error
prone.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From kumba@gentoo.org Fri Jul  1 05:40:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 05:41:09 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:58575 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8226113AbVGAEks>; Fri, 1 Jul 2005 05:40:48 +0100
Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45])
          by comcast.net (sccrmhc11) with ESMTP
          id <2005070104403001100lsrpfe>; Fri, 1 Jul 2005 04:40:30 +0000
Message-ID: <42C4CA23.7080301@gentoo.org>
Date:	Fri, 01 Jul 2005 00:44:19 -0400
From:	Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
In-Reply-To: <20050701035105.GA9601@nevyn.them.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
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: 8284
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Daniel Jacobowitz wrote:
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.
> 
> Other than that, you're on your own - building glibc is extremely error
> prone.
> 

I'm thiking this is more a possible oddity/bug in the kernel.  It may be glibc 
related, but I'm no concrete interpreter of strace output.

That said, I tried geoman's conftest.c snippet in an o32/glibc userland, 
n32/glibc userland, and o32/uclibc userland just to see if there was any difference.

The commonalities between all three was something is happening with 
rt_siguspend/sys32_rt_siguspend.  In o32/glibc and o32/uclibc, calls to 
rt_sigsuspend returned EINTR (interrupted system call).  o32 itself generates a 
silent SIGBUS (only seen in strace output.  o32/uclibc seems to complete 
(reaches exit(0)), but its rt_sigsuspend calls were also returning EINTR. 
n32/glibc was the one that generates the Oops message (w/o locking the system up).

The only differences was that o32/glibc and n32/glibc both SIGBUS/SIGSEG, while 
o32/uclibc seems to complete.  This could point to a glibc problem.

Below is the snipped output from strace and ksymoops on n32 (cause strace 
doesn't seem to work in n32 yet):

o32/glibc:
clone(child_stack=0x10003010, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) 
= 9954
write(4, "*\260b \0\0\0\5\0\0\0\0*\257\352H*\253\3H*\253\200\0\4"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [32], 16) = 0
write(4, "*\265\20\200\0\0\0\0\0\0\0\0\0@\10\240\0\0\0\0\200\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [32], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now ~[HUP INT QUIT ILL IOT 
KILL BUS ALRM TERM USR1 CHLD PWR URG IO CONT TTOU PROF XFSZ 32 33 34 35 37 38 39 
40 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 74 77 78 79 80 81 83 84 85 86 87 88 89 90 91 92 94 95 96 99 100 101 105 108 
110 112 114 115 116 117 118 119 120 121 122 123 124 125 126])
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++


n32/glibc:
 >>$31; a80000002001abc4 <do_signal32+1f4/298>

 >>PC;  00000000 Before first symbol

Trace; a80000002001ade8 <_sys32_rt_sigsuspend+180/1a8>
Trace; a80000002001e7f4 <handle_sysn32+54/a0>
Trace; a80000002001e7f4 <handle_sysn32+54/a0>


o32/uclibc:
clone(child_stack=0x100030c0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) 
= 10004
write(4, "\0\0\0\0\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
write(4, "*\263\363\300\0\0\0\0\0\0\0\0\0@\0070\0\0\0\0\200\0\0\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
write(4, "*\263\363\300\0\0\0\1\0\0\4\2\0@\0070\0\0\0\0\200\0\0\0"..., 148) = 148
write(4, "*\263\363\300\0\0\0\2\0\0\0\0*\2571T*\257iT*\257i\10\0"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 16) = 0
rt_siguspend([] <unfinished ...>
--- SIGRT_0 (Unknown signal 32) @ 0 (0) ---
<... rt_siguspend resumed> )            = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [TRAP IOT FPE BUS PIPE 
CHLD PROF RT_1 RT_3 RT_4 RT_5 RT_6 RT_7 RT_9 RT_10 RT_68 RT_69 RT_71 RT_72 RT_73])
wait4(10004, NULL, __WCLONE, NULL)      = 10004
exit(0)                                 = ?


Thoughts?


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

From kumba@gentoo.org Fri Jul  1 05:48:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 05:48:28 +0100 (BST)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:12794 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8226113AbVGAEsL>; Fri, 1 Jul 2005 05:48:11 +0100
Received: from [192.168.1.4] (pcp0011842295pcs.waldrf01.md.comcast.net[69.251.97.45])
          by comcast.net (rwcrmhc11) with ESMTP
          id <2005070104475401300rngcie>; Fri, 1 Jul 2005 04:47:54 +0000
Message-ID: <42C4CBDF.1030609@gentoo.org>
Date:	Fri, 01 Jul 2005 00:51:43 -0400
From:	Kumba <kumba@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	gcc-patches@gcc.gnu.org
CC:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: -march=r10000 Support for MIPS Targets (Old 3.4.x Patch; requires
 porting, assistance requested)
References: <42C0D94F.3030809@gentoo.org> <200506281007.12754.stevenb@suse.de>
In-Reply-To: <200506281007.12754.stevenb@suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.org>
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: 8285
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Steven Bosscher wrote:
> Looks like all the arith->shift attribute changes from the patch you
> posted are already in mainline, so all you really need to add r10000
> support is a pipeline model.  All the MIPSen were converted from the
> old pipeline description (i.e. "define_function_unit") to the new one
> (i.e. "define_insn_reservation" and friends) in a big patch posted
> last year: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01065.html.
> Maybe you can find in the trhead surrounding that message some ideas
> on how to convert your r10000 pipeline model.
> 
> HTH,
> 
> Gr.
> Steven

Yeah, I've poked around at how the new pipeline descriptions work, but my 
relative lack of understanding in regards to compiler internals makes it 
difficult to understand some terms and especially what the numbers in portions 
of define_function_unit do, and as such, I have no idea where to place them in 
the newer define_insn_reservation.  Not really having the free time to 
constantly rebuild gcc to test to see if numbers were placed appropriately, I've 
looked for other means to get this patch converted.

I did find a script on the gcc-patches ML that was a very early auto-converter 
for old gcc-3.4.x define_function_unit to gcc-4 define_insn_reservation, but it 
was written in gawk, and for some reason, I couldn't coax my copy of gawk to 
execute it correctly.  If there's a straight-forward guide to converting, I'd be 
interested in reading it (assuming it doesn't have a pre-requisite of deep gcc 
internals knowledge).


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

From ddaney@avtrex.com Fri Jul  1 05:55:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 05:56:11 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:18438
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8226113AbVGAEzy>;
	Fri, 1 Jul 2005 05:55:54 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57DF9.55978810"
Subject: RE: Problems with Intel e100 driver on new MIPS port, was: Advice needed WRT very slow nfs in new port...
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date:	Thu, 30 Jun 2005 21:57:08 -0700
Message-ID: <01049E563C8ECC43AD6B53A5AF419B38098BD1@avtrex-server2.hq2.avtrex.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Problems with Intel e100 driver on new MIPS port, was: Advice needed WRT very slow nfs in new port...
thread-index: AcV9oSR1XQkpRJenRl6RKFHbK/oEhgAVveT6
From:	"David Daney" <ddaney@avtrex.com>
To:	"Michael Stickel" <michael@cubic.org>
Cc:	<linux-mips@linux-mips.org>
Return-Path: <ddaney@avtrex.com>
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: 8286
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57DF9.55978810
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David Daney wrote:
>Michael Stickel wrote:
>> M. Warner Losh wrote:
>>
>>> In message: <42C359F8.4060000@avtrex.com>
>>>            David Daney <ddaney@avtrex.com> writes:
>>> : M. Warner Losh wrote:
>>> : > In message: <42C34C4D.9020902@avtrex.com>
>>> : >             David Daney <ddaney@avtrex.com> writes:
>>> : > : Does anyone have any idea what would cause 1000mS delay?
>>> : > : > That's remarkably close to 1s.  This often indicates that =
the
>>> transmit
>>> : > of your next packet is causing the receive buffer to empty.  =
This is
>>> : > usually due to blocked interrupts, or a failure to enable =
interrupts.
>>> : > : : But I observe ever increasing counts for the device in
>>> /proc/interrupts. :   So the interrupts are working somewhat.
>>>
>>> Are you sure that you've routed the interrupts correctly?  Maybe =
those
>>> interrupts are 'really' for a different device....
>>>=20
>>>
>> Add some debugging to the interrupt routine of the e100 and see what
>> happens.
>
>The interrupt routine is getting called each time a packet is received.
>
>It looks like packets are not being transmitted until the interrupt for
>the the received packet is received.
>
>If I ping the board at different intervals the round trip time is =
always
>almost exactly equal to the ping interval.  So if I ping every 50mS the
>round trip time is 50mS, ping every 200mS gives a RTT of 200mS, etc.
>
>Any more ideas?
>
>I am thinking that perhaps the CPU write-back-queue is interfearing =
with
>writes to the NIC's registers.  Perhaps I will try to disable it.

I think I solved the problem.

It seems that it is a memory consistancy problem of some sort.  By =
placing wbflush() after all writes to NIC registers it works.  This =
leads me to think that either the driver is buggy WRT processors that =
have write-back queues or my implementation (the default implementation) =
of writeb() and friends is buggy on this processor.  Now it could be =
that all that is needed is wmb() before some of the register writes, but =
since on my processor they both do the same thing (sync) it is hard to =
tell.

That will be the subject of my next message.

David Daney



------_=_NextPart_001_01C57DF9.55978810
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">=0A=
<TITLE>Re: Problems with Intel e100 driver on new MIPS port, was: Advice =
needed WRT very slow nfs in new port...</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV dir=3Dltr><FONT size=3D2>David Daney wrote:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>&gt;Michael Stickel wrote:<BR>&gt;&gt; M. =
Warner Losh =0A=
wrote:<BR>&gt;&gt;<BR>&gt;&gt;&gt; In message: =0A=
&lt;42C359F8.4060000@avtrex.com&gt;<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =0A=
David Daney &lt;ddaney@avtrex.com&gt; writes:<BR>&gt;&gt;&gt; : M. =
Warner Losh =0A=
wrote:<BR>&gt;&gt;&gt; : &gt; In message: =0A=
&lt;42C34C4D.9020902@avtrex.com&gt;<BR>&gt;&gt;&gt; : =0A=
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =0A=
David Daney &lt;ddaney@avtrex.com&gt; writes:<BR>&gt;&gt;&gt; : &gt; : =
Does =0A=
anyone have any idea what would cause 1000mS delay?<BR>&gt;&gt;&gt; : =
&gt; : =0A=
&gt; That's remarkably close to 1s.&nbsp; This often indicates that =0A=
the<BR>&gt;&gt;&gt; transmit<BR>&gt;&gt;&gt; : &gt; of your next packet =
is =0A=
causing the receive buffer to empty.&nbsp; This is<BR>&gt;&gt;&gt; : =
&gt; =0A=
usually due to blocked interrupts, or a failure to enable =0A=
interrupts.<BR>&gt;&gt;&gt; : &gt; : : But I observe ever increasing =
counts for =0A=
the device in<BR>&gt;&gt;&gt; /proc/interrupts. :&nbsp;&nbsp; So the =
interrupts =0A=
are working somewhat.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Are you sure that =
you've =0A=
routed the interrupts correctly?&nbsp; Maybe those<BR>&gt;&gt;&gt; =
interrupts =0A=
are 'really' for a different =0A=
device....<BR>&gt;&gt;&gt;&nbsp;<BR>&gt;&gt;&gt;<BR>&gt;&gt; Add some =
debugging =0A=
to the interrupt routine of the e100 and see what<BR>&gt;&gt; =0A=
happens.<BR>&gt;<BR>&gt;The interrupt routine is getting called each =
time a =0A=
packet is received.<BR>&gt;<BR>&gt;It looks like packets are not being =0A=
transmitted until the interrupt for<BR>&gt;the the received packet is =0A=
received.<BR>&gt;<BR>&gt;If I ping the board at different intervals the =
round =0A=
trip time is always<BR>&gt;almost exactly equal to the ping =
interval.&nbsp; So =0A=
if I ping every 50mS the<BR>&gt;round trip time is 50mS, ping every =
200mS gives =0A=
a RTT of 200mS, etc.<BR>&gt;<BR>&gt;Any more ideas?<BR>&gt;<BR>&gt;I am =
thinking =0A=
that perhaps the CPU write-back-queue is interfearing with<BR>&gt;writes =
to the =0A=
NIC's registers.&nbsp; Perhaps I will try to disable it.<BR></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>I think I solved the problem.</FONT></DIV>=0A=
<P><FONT size=3D2>It seems that it is a memory consistancy problem of =
some =0A=
sort.&nbsp; By placing</FONT><FONT size=3D2>&nbsp;wbflush() after all =
writes to =0A=
NIC registers it works.&nbsp; This leads me to think that either the =
driver is =0A=
buggy WRT processors that have write-back queues or my implementation =
(the =0A=
default implementation) of writeb() and friends is buggy on this =0A=
processor.&nbsp; Now it could be that all that is needed is wmb() before =
some of =0A=
the register writes, but since on my processor they both do the same =
thing =0A=
(sync) it is hard to tell.</FONT></P>=0A=
<P><FONT size=3D2>That will be the subject of my next message.</FONT></P>=0A=
<P><FONT size=3D2>David Daney</P>=0A=
<DIV dir=3Dltr><BR></DIV></FONT>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C57DF9.55978810--

From ddaney@avtrex.com Fri Jul  1 06:21:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 06:21:19 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:52229
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8226122AbVGAFVC>;
	Fri, 1 Jul 2005 06:21:02 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57DFC.D8A9ACDA"
Subject: RFH:  What are the semantics of writeb() and friends?
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date:	Thu, 30 Jun 2005 22:22:17 -0700
Message-ID: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What are the semantics of writeb() and friends?
thread-index: AcV9/NiK6F9uD0lyR+2aPP/vqUOfgw==
From:	"David Daney" <ddaney@avtrex.com>
To:	<linux-mips@linux-mips.org>
Return-Path: <ddaney@avtrex.com>
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: 8287
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57DFC.D8A9ACDA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In this thread:
=20
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=3Dlinux-mips&i=3D42C1C6EA.50=
80709%40avtrex.com
=20
I relate the problems I was having with the Intel e100 driver on a new =
2.6.12 port to a 4ke based system.
=20
My new question is:  What are the semantics of writeb(), writel() et =
al.?  I would assume that the effects of these must be in the same order =
that they were issued, and that any hardware write back queue cannot =
combine or merge them in any way.  Is that correct?
=20
=20
A second question I have is:  What is the difference in the semantics of =
wbflush() and wmb()?  For my CPU they both evaluate to the same thing =
(the 'sync' instruction).  So for my own sake I could use either, but =
depending on the situation I assume that one would be used over the =
other.
=20
Thanks,
David Daney.

------_=_NextPart_001_01C57DFC.D8A9ACDA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML =
DIR=3Dltr><HEAD><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1"></HEAD><BODY><DIV><FONT face=3D'Arial' =
color=3D#000000 size=3D2>In this thread:</FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial color=3D#000000 size=3D2><A =0A=
href=3D"http://www.linux-mips.org/cgi-bin/mesg.cgi?a=3Dlinux-mips&amp;i=3D=
42C1C6EA.5080709%40avtrex.com">http://www.linux-mips.org/cgi-bin/mesg.cgi=
?a=3Dlinux-mips&amp;i=3D42C1C6EA.5080709%40avtrex.com</A></FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial size=3D2>I relate the problems I was having with =
the Intel =0A=
e100 driver on a new 2.6.12 port to a 4ke based system.</FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial size=3D2>My new question is:&nbsp; What are the =
semantics of =0A=
writeb(), writel() et al.?&nbsp; I would assume that the effects of =
these must =0A=
be in the same order that they were issued, and that any hardware write =
back =0A=
queue cannot combine or merge them in any way.&nbsp; Is that =0A=
correct?</FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial size=3D2>A second question I have is:&nbsp; What =
is the =0A=
difference in the semantics of wbflush() and wmb()?&nbsp; For my CPU =
they both =0A=
evaluate to the same thing (the 'sync' instruction).&nbsp; So for my own =
sake I =0A=
could use either, but depending on the situation I assume that one would =
be used =0A=
over the other.</FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>=0A=
<DIV><FONT face=3DArial size=3D2>David Daney.</FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C57DFC.D8A9ACDA--

From francis_moreau2000@yahoo.fr Fri Jul  1 09:00:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 09:00:41 +0100 (BST)
Received: from web25802.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.187]:24144
	"HELO web25802.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8226122AbVGAIAW>; Fri, 1 Jul 2005 09:00:22 +0100
Received: (qmail 54752 invoked by uid 60001); 1 Jul 2005 08:00:03 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.fr;
  h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=JC/Xwq1cJIQExT1x80z3wyl1kJYQSrmCJhr2/JvbHt3UDf5LvJL63ZK27PwCEWOcMuV8hxSzCmg/iMLMoKS3ldMZyVX0YA6o5sac1iWfQBck7cQXcrahD0Bf6GTwpkUXWOokjzSMTJ76yDUDYPgD58f4Y/t5B1evIODmuHH4jVw=  ;
Message-ID: <20050701080003.54738.qmail@web25802.mail.ukl.yahoo.com>
Received: from [217.167.142.149] by web25802.mail.ukl.yahoo.com via HTTP; Fri, 01 Jul 2005 10:00:02 CEST
Date:	Fri, 1 Jul 2005 10:00:02 +0200 (CEST)
From:	moreau francis <francis_moreau2000@yahoo.fr>
Subject: Re: I built a mipsel-linux toolchain, but it doesn't work
To:	David Daney <ddaney@avtrex.com>
Cc:	zhan rongkai <zhanrk@gmail.com>, linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
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: 8288
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: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips

David Daney wrote:

> zhan rongkai wrote:
>
>> Hi folks,
>>
>> At last night, I built a mipsel-linux cross-toolchain according to the
>> following steps:
>>
>> 1) The list of GNU Toolchain source packages
>> =======================================================
>>
>> * binutils: binutils-2.16.1.tar.gz
>> *      gcc: gcc-3.4.4.tar.gz
>> *    Linux: Linux-2.6.12.tar.bz2 (from www.kernel.org)
>> *   uClibc: uClibc-0.9.27.tar.gz
>> *      gdb: gdb-6.3.tar.gz
>>
>
> IIRC gcc does not currently work out-of-the-box with uClibc.  If you are
> using uClibc, your best bet is probably to use the Buildroot system that 
> can be found at the uClibc web site.
>

Could you develop please ? What kind of config/hack does Buildroot to be able
to use GCC with uClibc ?

thanks

              Francis


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

From macro@linux-mips.org Fri Jul  1 09:38:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 09:38:55 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:29453 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226127AbVGAIik>; Fri, 1 Jul 2005 09:38:40 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 41EDDE1C8A; Fri,  1 Jul 2005 10:38:27 +0200 (CEST)
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 07433-05; Fri,  1 Jul 2005 10:38:27 +0200 (CEST)
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 1A9C3E1C78; Fri,  1 Jul 2005 10:38:27 +0200 (CEST)
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 j618cS6l008448;
	Fri, 1 Jul 2005 10:38:29 +0200
Date:	Fri, 1 Jul 2005 09:38:31 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Fabrizio Fazzino <fabrizio@fazzino.it>
Cc:	linux-mips@linux-mips.org
Subject: Re: Assembly macro with parameters
In-Reply-To: <42C429C3.2090905@fazzino.it>
Message-ID: <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl>
References: <425573AD.9010702@fazzino.it> <20050407182549.GA24235@linux-mips.org>
 <4256B5BE.8070708@fazzino.it> <20050408165717.GA8157@nevyn.them.org>
 <42C429C3.2090905@fazzino.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8289
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

On Thu, 30 Jun 2005, Fabrizio Fazzino wrote:

> Daniel suggested using .word and writing the function by hand,
> but which is the syntax I have to use?
> 
> #define myopcode(rs,rt,rd) { \
> int opcode_number = 0xC4000000 | (rs<<21) | (rt<<16) | (rd<<11); \
> char opcode_string[20]; \
> sprintf(opcode_string, ".word 0x%X", opcode_number); \
> asm(opcode_string); \
> }

 This is untested, but it should be a reasonable starting point:

#define myopcode(rs,rt,rd) do { \
	int opcode_number = 0xC4000000 | (rs<<21) | (rt<<16) | (rd<<11); \
	asm(".word %0" : : "i" (opcode_number)); \
} while (0)

But you may want to add code to tell GCC that these registers are used and 
how, because otherwise you may have little use of your macro.  You'll 
probably have to investigate the explicit register variable GCC feature 
and cpp stringification.  It should be straightforward though rather 
boring, so I'm leaving it as an exercise.

  Maciej

From macro@linux-mips.org Fri Jul  1 09:49:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 09:50:02 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:40970 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226122AbVGAItr>; Fri, 1 Jul 2005 09:49:47 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1B36FE1C8A; Fri,  1 Jul 2005 10:49:35 +0200 (CEST)
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 26253-10; Fri,  1 Jul 2005 10:49:34 +0200 (CEST)
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 BABF4E1C78; Fri,  1 Jul 2005 10:49:34 +0200 (CEST)
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 j618nZdd008825;
	Fri, 1 Jul 2005 10:49:36 +0200
Date:	Fri, 1 Jul 2005 09:49:39 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	"Stephen P. Becker" <geoman@gentoo.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <20050701035105.GA9601@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl>
References: <20050630173409Z8226102-3678+735@linux-mips.org>
 <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org>
 <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8290
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

On Thu, 30 Jun 2005, Daniel Jacobowitz wrote:

> > Hmm, well with respect to my problem, I'm using a pretty recent
> > toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> > from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> > Bryan's segfault, but could not.  That code ran without error when I
> > linked with libpthread.  Any thoughts?
> 
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.

 Well, I tried a few trivial programs that use libpthread in my (n)64 
environment, which is based on 2.3.5, and they worked just fine.  They 
could have bin as simple as `ls', but as I have seen in the original 
report you do not have to make extensive use of the library to trigger 
problematic behaviour.

 Though it can be related to patches I have applied, me having built glibc 
with GCC 4.0.0 or perhaps it only happens for BE...

> Other than that, you're on your own - building glibc is extremely error
> prone.

 And you may need external patches as glibc is (effectively) not 
maintained.

  Maciej

From macro@linux-mips.org Fri Jul  1 09:52:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 09:53:00 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:43022 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226129AbVGAIwn>; Fri, 1 Jul 2005 09:52:43 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id EC3D1E1C8A; Fri,  1 Jul 2005 10:52:31 +0200 (CEST)
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 05937-07; Fri,  1 Jul 2005 10:52:31 +0200 (CEST)
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 BD33FE1C78; Fri,  1 Jul 2005 10:52:31 +0200 (CEST)
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 j618qXCg008950;
	Fri, 1 Jul 2005 10:52:33 +0200
Date:	Fri, 1 Jul 2005 09:52:37 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: top and SMP
In-Reply-To: <20050630174556Z8226101-3678+737@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507010950310.30138@blysk.ds.pg.gda.pl>
References: <20050630174556Z8226101-3678+737@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8291
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

On Thu, 30 Jun 2005, Bryan Althouse wrote:

> I have tried to get top to display processor utilization on a per CPU basis,
> but to no avail.  Does anyone know how to get top to properly display
> statistics for a SMP system?  Better yet, does anyone know of a better
> utility than top?  

 Do you have a recent version of procps?

  Maciej

From macro@linux-mips.org Fri Jul  1 09:57:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 09:58:02 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:19464 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226129AbVGAI5o>; Fri, 1 Jul 2005 09:57:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 4F636F5964; Fri,  1 Jul 2005 10:57:32 +0200 (CEST)
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 19277-03; Fri,  1 Jul 2005 10:57:32 +0200 (CEST)
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 1B29CE1C8A; Fri,  1 Jul 2005 10:57:32 +0200 (CEST)
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 j618vXlc009175;
	Fri, 1 Jul 2005 10:57:33 +0200
Date:	Fri, 1 Jul 2005 09:57:37 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	David Daney <ddaney@avtrex.com>
Cc:	Michael Stickel <michael@cubic.org>, linux-mips@linux-mips.org
Subject: RE: Problems with Intel e100 driver on new MIPS port, was: Advice
 needed WRT very slow nfs in new port...
In-Reply-To: <01049E563C8ECC43AD6B53A5AF419B38098BD1@avtrex-server2.hq2.avtrex.com>
Message-ID: <Pine.LNX.4.61L.0507010953420.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD1@avtrex-server2.hq2.avtrex.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8292
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

On Thu, 30 Jun 2005, David Daney wrote:

> It seems that it is a memory consistancy problem of some sort.  By 
> placing wbflush() after all writes to NIC registers it works.  This 
> leads me to think that either the driver is buggy WRT processors that 
> have write-back queues or my implementation (the default implementation) 
> of writeb() and friends is buggy on this processor.  Now it could be 
> that all that is needed is wmb() before some of the register writes, but 
> since on my processor they both do the same thing (sync) it is hard to 
> tell.

 Most likely that code has only been ever used on i386 systems (who'd want 
to use such a weird Ethernet chip elsewhere?), so don't expect it to be 
terribly sane.

  Maciej

From geert@linux-m68k.org Fri Jul  1 10:00:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 10:00:56 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:48002 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226129AbVGAJAj>;
	Fri, 1 Jul 2005 10:00:39 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j6190Qpr024687;
	Fri, 1 Jul 2005 11:00:26 +0200 (MEST)
Date:	Fri, 1 Jul 2005 11:00:20 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
cc:	David Daney <ddaney@avtrex.com>,
	Michael Stickel <michael@cubic.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: Problems with Intel e100 driver on new MIPS port, was: Advice
 needed WRT very slow nfs in new port...
In-Reply-To: <Pine.LNX.4.61L.0507010953420.30138@blysk.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.62.0507011059420.5245@numbat.sonytel.be>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD1@avtrex-server2.hq2.avtrex.com>
 <Pine.LNX.4.61L.0507010953420.30138@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8293
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Fri, 1 Jul 2005, Maciej W. Rozycki wrote:
> On Thu, 30 Jun 2005, David Daney wrote:
> > It seems that it is a memory consistancy problem of some sort.  By 
> > placing wbflush() after all writes to NIC registers it works.  This 
> > leads me to think that either the driver is buggy WRT processors that 
> > have write-back queues or my implementation (the default implementation) 
> > of writeb() and friends is buggy on this processor.  Now it could be 
> > that all that is needed is wmb() before some of the register writes, but 
> > since on my processor they both do the same thing (sync) it is hard to 
> > tell.
> 
>  Most likely that code has only been ever used on i386 systems (who'd want 
> to use such a weird Ethernet chip elsewhere?), so don't expect it to be 
> terribly sane.

The e100 is a quite popular card, so I'd expect it to be in use on many
platforms.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From macro@linux-mips.org Fri Jul  1 10:34:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 10:34:21 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:58891 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226135AbVGAJeE>; Fri, 1 Jul 2005 10:34:04 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 3B932E1C8A; Fri,  1 Jul 2005 11:33:52 +0200 (CEST)
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 07710-09; Fri,  1 Jul 2005 11:33:52 +0200 (CEST)
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 EAA6CE1C78; Fri,  1 Jul 2005 11:33:51 +0200 (CEST)
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 j619Xs2X011019;
	Fri, 1 Jul 2005 11:33:54 +0200
Date:	Fri, 1 Jul 2005 10:33:58 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	David Daney <ddaney@avtrex.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: RFH:  What are the semantics of writeb() and friends?
In-Reply-To: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
Message-ID: <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8294
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

On Thu, 30 Jun 2005, David Daney wrote:

> My new question is:  What are the semantics of writeb(), writel() et 
> al.?  I would assume that the effects of these must be in the same order 
> that they were issued, and that any hardware write back queue cannot 
> combine or merge them in any way.  Is that correct?

 No it's not.  You need to insert appropriate barriers, one of: wmb(), 
mb() or rmb().  In rare cases you may need to use iob(), which is 
currently non-portable (which reminds me I should really push it 
upstream).

 For historical reasons only outb(), inl(), outl(), inl(), etc. are meant 
to imply an mb() beforehand and afterwards (IOW, their resulting cycles 
always appear externally in the programmed order).  You may still need 
iob(), though.

> A second question I have is:  What is the difference in the semantics of 
> wbflush() and wmb()?  For my CPU they both evaluate to the same thing 
> (the 'sync' instruction).  So for my own sake I could use either, but 
> depending on the situation I assume that one would be used over the 
> other.

 wbflush() is an old name for iob() -- it will probably vanish one day as 
the name is somewhat inadequate for non-MIPS systems.  They are meant as a 
read/write barrier combined with write completion from the host's point of 
view (i.e. external writes cycles are actually issued by CPU and its 
system controller; they may still be posted e.g. in an I/O bus bridge and 
require another bridge-specific operation to proceed further).  wmb() is 
just a write barrier -- it assures later writes won't be combined with or 
reordered before earlier ones.

 Depending on your needs iob() may be too strong resulting in unnecessary 
performance penalty or wmb() may be to weak resulting in cycles appearing 
in the wrong order or being delayed for too long.  If your CPU happens to 
use "sync" for both, then it probably has an overkill implementation for 
this instruction resulting in performance loss in some places.

  Maciej

From macro@linux-mips.org Fri Jul  1 10:39:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 10:39:18 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:28690 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226135AbVGAJjB>; Fri, 1 Jul 2005 10:39:01 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 33A4EF5977; Fri,  1 Jul 2005 11:38:49 +0200 (CEST)
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 15473-09; Fri,  1 Jul 2005 11:38:49 +0200 (CEST)
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 E39DAE1C8A; Fri,  1 Jul 2005 11:38:48 +0200 (CEST)
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 j619cp2b011209;
	Fri, 1 Jul 2005 11:38:51 +0200
Date:	Fri, 1 Jul 2005 10:38:55 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Geert Uytterhoeven <geert@linux-m68k.org>
Cc:	David Daney <ddaney@avtrex.com>,
	Michael Stickel <michael@cubic.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: RE: Problems with Intel e100 driver on new MIPS port, was: Advice
 needed WRT very slow nfs in new port...
In-Reply-To: <Pine.LNX.4.62.0507011059420.5245@numbat.sonytel.be>
Message-ID: <Pine.LNX.4.61L.0507011036110.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD1@avtrex-server2.hq2.avtrex.com>
 <Pine.LNX.4.61L.0507010953420.30138@blysk.ds.pg.gda.pl>
 <Pine.LNX.4.62.0507011059420.5245@numbat.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8295
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

On Fri, 1 Jul 2005, Geert Uytterhoeven wrote:

> The e100 is a quite popular card, so I'd expect it to be in use on many
> platforms.

 Is it?  I've thought manufacturers only mount these chips on motherboards 
as otherwise nobody would buy them. ;-)  Oh well...

  Maciej

From matej.kupljen@ultra.si Fri Jul  1 12:45:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 12:46:14 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:49899 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8226142AbVGALp6>; Fri, 1 Jul 2005 12:45:58 +0100
Received: from localhost (in-3.mx.triera.net [213.161.0.27])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id 8B72DC050
	for <linux-mips@linux-mips.org>; Fri,  1 Jul 2005 13:45:42 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-3.mx.triera.net (Postfix) with SMTP id 6EA3F1BC079
	for <linux-mips@linux-mips.org>; Fri,  1 Jul 2005 13:45:44 +0200 (CEST)
Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52])
	by smtp.triera.net (Postfix) with ESMTP id 69AE31A18AE
	for <linux-mips@linux-mips.org>; Fri,  1 Jul 2005 13:45:45 +0200 (CEST)
Subject: DB1200
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	Linux/MIPS Development <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: Ultra d.o.o.
Date:	Fri, 01 Jul 2005 13:45:46 +0200
Message-Id: <1120218346.10628.18.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
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: 8296
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 all,

I am using DB1200 from AMD and have checked this mailing list
and "the rest of the Internet" for information about
Linux and MAE on this board.

It seems there are only few users of this board and there
is a lot of work to be done. I am willing to do it, but
would just like some directions, hints, ... of other
users.

I tried contacting AMD, but until now did not receive any
answer. I tested MAE with their binary images (thank to
Ruslan V.Pisarev) and it works. My main concern is MAE 
(probably this is the main concern for all users
using AU1200, otherwise they wouldn't use it).

What should be done?
Wait for AMD to release the source of the drivers and 
maiplayer, if ever? And probably for 2.4 kernel only :-(
Write new drivers? What would the design be?
I think the best way to use the MAE would be trough 
MPlayer (or xine, ...), like using Dxr3 card or H+, which
is MPEG2 acceleartion card.

Any suggestions?

Thanks and BR,
Matej


From alan@lxorguk.ukuu.org.uk Fri Jul  1 12:49:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 12:49:35 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:46982
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226142AbVGALtS>; Fri, 1 Jul 2005 12:49:18 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j61BkUju014755;
	Fri, 1 Jul 2005 12:46:30 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j61BkTeO014754;
	Fri, 1 Jul 2005 12:46:29 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: RFH:  What are the semantics of writeb() and friends?
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
In-Reply-To: <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
	 <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1120218385.12446.16.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Fri, 01 Jul 2005 12:46:28 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
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: 8297
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

On Gwe, 2005-07-01 at 10:33, Maciej W. Rozycki wrote:
> > al.?  I would assume that the effects of these must be in the same order 
> > that they were issued, and that any hardware write back queue cannot 
> > combine or merge them in any way.  Is that correct?
> 
>  No it's not.  You need to insert appropriate barriers, one of: wmb(), 
> mb() or rmb().  In rare cases you may need to use iob(), which is 
> currently non-portable (which reminds me I should really push it 
> upstream).

Its even more complicated than that 8)

writeb/writel may be merged in some cases (but not re-ordered) for I/O
devices but a simple mb() will only synchronize them as viewed from
cpu/memory interface. There are two other synchronization points. From
the bridge with the I/O device (typically the PCI root bridge) which is
not enforced automatically across processors on some large numa boxes
but is not usually a problem and on the PCI bus itself.

PCI permits posting (delaying writes) and some forms of merging (but not
re-ordering). Thus if you need an I/O to hit a device on the PCI bus and
know it arrived you must follow it by a read from the same device. So
for example if you want to shut down a DMA transfer and free the buffer
for a PCI device you
need to do

		writel(TURN_DMA_OFF, dev->control);
		readl(dev->something);
		/* Only now is the free safe */

Alan


From macro@linux-mips.org Fri Jul  1 13:54:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 13:55:03 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:28934 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226142AbVGAMyr>; Fri, 1 Jul 2005 13:54:47 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 7D4F3E1CA5; Fri,  1 Jul 2005 14:54:34 +0200 (CEST)
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 11271-05; Fri,  1 Jul 2005 14:54:34 +0200 (CEST)
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 517A0E1C8B; Fri,  1 Jul 2005 14:54:34 +0200 (CEST)
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 j61CsbrY019400;
	Fri, 1 Jul 2005 14:54:37 +0200
Date:	Fri, 1 Jul 2005 13:54:44 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: RFH:  What are the semantics of writeb() and friends?
In-Reply-To: <1120218385.12446.16.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
  <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
 <1120218385.12446.16.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/962/Fri Jul  1 07:19:05 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8298
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

On Fri, 1 Jul 2005, Alan Cox wrote:

> >  No it's not.  You need to insert appropriate barriers, one of: wmb(), 
> > mb() or rmb().  In rare cases you may need to use iob(), which is 
> > currently non-portable (which reminds me I should really push it 
> > upstream).
> 
> Its even more complicated than that 8)
> 
> writeb/writel may be merged in some cases (but not re-ordered) for I/O

 Is that non-reordering specified anywhere for the API or does it just 
happen to be satisfied by most implementations?  Ours (for MIPS, that is) 
for example does nothing to ensure that.

> devices but a simple mb() will only synchronize them as viewed from
> cpu/memory interface. There are two other synchronization points. From

 That's true -- which is why I mentioned bridge-specific operations may be 
required.

> the bridge with the I/O device (typically the PCI root bridge) which is
> not enforced automatically across processors on some large numa boxes
> but is not usually a problem and on the PCI bus itself.

 What if the host I/O bus is not PCI?  For this kind of stuff I tend to 
think in the terms of TURBOchannel systems, just to be sure not to get 
influenced by the most common hardware. ;-)

 E.g. I have this R4400-based TURBOchannel system with aggressive 
buffering in the CPU's MB (memory buffer) ASIC which requires a read-back 
(RAM is OK for that) after a write and a memory barrier only to make 
writes propagate to the I/O bridge.  It may be worse yet with TURBOchannel 
Alpha and VAX systems.  With the latters TURBOchannel is behind two 
bridges, with two intermediate buses on the way.

> PCI permits posting (delaying writes) and some forms of merging (but not
> re-ordering). Thus if you need an I/O to hit a device on the PCI bus and
> know it arrived you must follow it by a read from the same device. So
> for example if you want to shut down a DMA transfer and free the buffer
> for a PCI device you
> need to do
> 
> 		writel(TURN_DMA_OFF, dev->control);
> 		readl(dev->something);
> 		/* Only now is the free safe */

 Again, the I/O bus your host is attached to need not be PCI and you may 
need a bridge specific operation to make your write be completed, possibly 
combined with your quoted sequence (if there is actually PCI somewhere in 
the system; think AlphaServer 8400).

  Maciej

From alan@lxorguk.ukuu.org.uk Fri Jul  1 14:34:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 14:34:55 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:1415
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226142AbVGANei>; Fri, 1 Jul 2005 14:34:38 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j61DVpF2015066;
	Fri, 1 Jul 2005 14:31:51 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j61DVpf2015065;
	Fri, 1 Jul 2005 14:31:51 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: RFH:  What are the semantics of writeb() and friends?
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
In-Reply-To: <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
	 <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
	 <1120218385.12446.16.camel@localhost.localdomain>
	 <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1120224708.12446.26.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Fri, 01 Jul 2005 14:31:49 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
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: 8299
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

On Gwe, 2005-07-01 at 13:54, Maciej W. Rozycki wrote:
> > writeb/writel may be merged in some cases (but not re-ordered) for I/O
> 
>  Is that non-reordering specified anywhere for the API or does it just 
> happen to be satisfied by most implementations?  Ours (for MIPS, that is) 
> for example does nothing to ensure that.

It is defined by the device I/O document as follows:


        The read and write functions are defined to be ordered. That is
the
        compiler is not permitted to reorder the I/O sequence. When the
        ordering can be compiler optimised, you can use <function>
        __readb</function> and friends to indicate the relaxed ordering.
Use
        this with care.

Note order - not synchronicity. On that it says

       While the basic functions are defined to be synchronous with
respect
        to each other and ordered with respect to each other the busses
the
        devices sit on may themselves have asynchronicity. In particular
many
        authors are burned by the fact that PCI bus writes are posted
        asynchronously. A driver author must issue a read from the same
        device to ensure that writes have occurred in the specific cases
the
        author cares. This kind of property cannot be hidden from driver
        writers in the API.  In some cases, the read used to flush the
device
        may be expected to fail (if the card is resetting, for
example).  In
        that case, the read should be done from config space, which is
        guaranteed to soft-fail if the card doesn't respond.

>  What if the host I/O bus is not PCI?  For this kind of stuff I tend to 
> think in the terms of TURBOchannel systems, just to be sure not to get 
> influenced by the most common hardware. ;-)

The bus behaviour is bus defined.

>  Again, the I/O bus your host is attached to need not be PCI and you may 
> need a bridge specific operation to make your write be completed, possibly 
> combined with your quoted sequence (if there is actually PCI somewhere in 
> the system; think AlphaServer 8400).

We don't currently have cross bridge "io_write_and_be_synchronous()"
type functions. So far drivers have always known what to do. Your
example might break that of course.

Alan
--
        "In flight refueling scares me. It's like two elephants
                        mating at mach one"
                                -- Arjan van de Ven


From drow@nevyn.them.org Fri Jul  1 14:39:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 14:39:39 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:56800 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8226147AbVGANjY>;
	Fri, 1 Jul 2005 14:39:24 +0100
Received: from drow by nevyn.them.org with local (Exim 4.51)
	id 1DoLja-0006Rz-O8; Fri, 01 Jul 2005 09:39:10 -0400
Date:	Fri, 1 Jul 2005 09:39:10 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	"Stephen P. Becker" <geoman@gentoo.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
Message-ID: <20050701133910.GA24716@nevyn.them.org>
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
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: 8300
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

On Fri, Jul 01, 2005 at 09:49:39AM +0100, Maciej W. Rozycki wrote:
>  And you may need external patches as glibc is (effectively) not 
> maintained.

Shall I just stop trying, then?  I'm getting tired of arguing with you
about this.

For the twentieth time: I am doing everything I can to keep glibc HEAD
building for MIPS.  I do not have the time or energy to deal with
Roland's restrictive stable branch rules, so I can not help with 2.3.5.
But if you encounter a problem on HEAD, let me know, and I will either
fix it myself or (if you've got a patch) pester people relentlessly
until it is applied.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From djohnson@sw.starentnetworks.com Fri Jul  1 14:55:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 14:55:30 +0100 (BST)
Received: from pasta.sw.starentnetworks.com ([IPv6:::ffff:12.33.234.10]:17287
	"EHLO pasta.sw.starentnetworks.com") by linux-mips.org with ESMTP
	id <S8226146AbVGANzK>; Fri, 1 Jul 2005 14:55:10 +0100
Received: from cortez.sw.starentnetworks.com (cortez.sw.starentnetworks.com [12.33.233.12])
	by pasta.sw.starentnetworks.com (Postfix) with ESMTP
	id 8698D14B669; Fri,  1 Jul 2005 09:54:49 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17093.19241.353160.946039@cortez.sw.starentnetworks.com>
Date:	Fri, 1 Jul 2005 09:54:49 -0400
From:	Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
In-Reply-To: <20050701.114358.21591461.nemoto@toshiba-tops.co.jp>
References: <17092.5345.75666.403044@cortez.sw.starentnetworks.com>
	<20050701.114358.21591461.nemoto@toshiba-tops.co.jp>
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Return-Path: <djohnson@sw.starentnetworks.com>
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: 8301
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: djohnson+linuxmips@sw.starentnetworks.com
Precedence: bulk
X-list: linux-mips


That'll do it.  My patch wasn't enough.

I added some sanity checks to get_wchan and it hit one while running
overnight.

The task being examined transitioned from !TASK_RUNNING to
TASK_RUNNING while it was being examined. Doh!

Definately not SMP/preempt safe as written today.


-- 
Dave Johnson
Starent Networks


Atsushi Nemoto writes:
> >>>>> On Thu, 30 Jun 2005 11:50:57 -0400, Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com> said:
> dave> The PC it was trying to lookup is in preempt_schedule_irq().
> dave> Without preempt_schedule_irq in mfinfo[] it ended up with the
> dave> wrong function and then dereferenced a NULL FP.
> 
> dave> Should this be in mfinfo or am I on the wrong track here?
> ...
> dave> Also, __preempt_spin_lock and __preempt_write_lock are nowhere
> dave> to be found so I had to remove those from the table.
> 
> Well, The current get_wchan implementation is still problematic
> because:
> 
> * Some functions in __sched (and __lock) section are static.
> * Functions in __lock are not handled.
> * Maintenance of the struct mips_frame_info mfinfo[] is a pain.
> * sleep_on*() is deprecated.  kernel-janitors people want to remove
>   references for them.
> 
> I suppose searching a caller of scheduling functions in get_wchan is
> not necessary.  Calling thread_saved_pc() will be enough for most
> usage.
> 
> So I posted a patch to simplify things a while ago.
> 
> http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20050126.120916.88699500.nemoto%40toshiba-tops.co.jp
> 
> And here is a revised patch.
> 
> diff -u linux-mips/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c
> --- linux-mips/arch/mips/kernel/process.c	2005-06-21 17:34:10.000000000 +0900
> +++ linux/arch/mips/kernel/process.c	2005-07-01 11:15:26.000000000 +0900
> @@ -270,47 +270,15 @@
>  }
>  
>  static struct mips_frame_info {
> -	void *func;
> -	int omit_fp;	/* compiled without fno-omit-frame-pointer */
>  	int frame_offset;
>  	int pc_offset;
> -} schedule_frame, mfinfo[] = {
> -	{ schedule, 0 },	/* must be first */
> -	/* arch/mips/kernel/semaphore.c */
> -	{ __down, 1 },
> -	{ __down_interruptible, 1 },
> -	/* kernel/sched.c */
> -#ifdef CONFIG_PREEMPT
> -	{ preempt_schedule, 0 },
> -#endif
> -	{ wait_for_completion, 0 },
> -	{ interruptible_sleep_on, 0 },
> -	{ interruptible_sleep_on_timeout, 0 },
> -	{ sleep_on, 0 },
> -	{ sleep_on_timeout, 0 },
> -	{ yield, 0 },
> -	{ io_schedule, 0 },
> -	{ io_schedule_timeout, 0 },
> -#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT)
> -	{ __preempt_spin_lock, 0 },
> -	{ __preempt_write_lock, 0 },
> -#endif
> -	/* kernel/timer.c */
> -	{ schedule_timeout, 1 },
> -/*	{ nanosleep_restart, 1 }, */
> -	/* lib/rwsem-spinlock.c */
> -	{ __down_read, 1 },
> -	{ __down_write, 1 },
> -};
> -
> -static int mips_frame_info_initialized;
> -static int __init get_frame_info(struct mips_frame_info *info)
> +} schedule_frame;
> +static int __init get_frame_info(struct mips_frame_info *info, void *func)
>  {
>  	int i;
> -	void *func = info->func;
>  	union mips_instruction *ip = (union mips_instruction *)func;
>  	info->pc_offset = -1;
> -	info->frame_offset = info->omit_fp ? 0 : -1;
> +	info->frame_offset = -1;
>  	for (i = 0; i < 128; i++, ip++) {
>  		/* if jal, jalr, jr, stop. */
>  		if (ip->j_format.opcode == jal_op ||
> @@ -358,26 +326,7 @@
>  
>  static int __init frame_info_init(void)
>  {
> -	int i, found;
> -	for (i = 0; i < ARRAY_SIZE(mfinfo); i++)
> -		if (get_frame_info(&mfinfo[i]))
> -			return -1;
> -	schedule_frame = mfinfo[0];
> -	/* bubble sort */
> -	do {
> -		struct mips_frame_info tmp;
> -		found = 0;
> -		for (i = 1; i < ARRAY_SIZE(mfinfo); i++) {
> -			if (mfinfo[i-1].func > mfinfo[i].func) {
> -				tmp = mfinfo[i];
> -				mfinfo[i] = mfinfo[i-1];
> -				mfinfo[i-1] = tmp;
> -				found = 1;
> -			}
> -		}
> -	} while (found);
> -	mips_frame_info_initialized = 1;
> -	return 0;
> +	return get_frame_info(&schedule_frame, schedule);
>  }
>  
>  arch_initcall(frame_info_init);
> @@ -398,39 +347,12 @@
>  	return ((unsigned long *)t->reg29)[schedule_frame.pc_offset];
>  }
>  
> -/* get_wchan - a maintenance nightmare^W^Wpain in the ass ...  */
>  unsigned long get_wchan(struct task_struct *p)
>  {
> -	unsigned long frame, pc;
> -
>  	if (!p || p == current || p->state == TASK_RUNNING)
>  		return 0;
>  
> -	if (!mips_frame_info_initialized)
> -		return 0;
> -	pc = thread_saved_pc(p);
> -
> -	if (!in_sched_functions(pc))
> -		goto out;
> -
> -	frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset];
> -	do {
> -		int i;
> -		for (i = ARRAY_SIZE(mfinfo) - 1; i >= 0; i--) {
> -			if (pc >= (unsigned long) mfinfo[i].func)
> -				break;
> -		}
> -		if (i < 0)
> -			break;
> -
> -		if (mfinfo[i].omit_fp)
> -			break;
> -		pc = ((unsigned long *)frame)[mfinfo[i].pc_offset];
> -		frame = ((unsigned long *)frame)[mfinfo[i].frame_offset];
> -	} while (in_sched_functions(pc));
> -
> -out:
> -	return pc;
> +	return thread_saved_pc(p);
>  }
>  
>  EXPORT_SYMBOL(get_wchan);
> 
> 
> ---
> Atsushi Nemoto


From macro@linux-mips.org Fri Jul  1 15:10:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 15:11:09 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:26630 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226148AbVGAOKv>; Fri, 1 Jul 2005 15:10:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 7A8C0F5999; Fri,  1 Jul 2005 16:10:38 +0200 (CEST)
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 05091-10; Fri,  1 Jul 2005 16:10:38 +0200 (CEST)
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 29565F598E; Fri,  1 Jul 2005 16:10:38 +0200 (CEST)
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 j61EA0n6004138;
	Fri, 1 Jul 2005 16:10:00 +0200
Date:	Fri, 1 Jul 2005 15:10:08 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	"Stephen P. Becker" <geoman@gentoo.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <20050701133910.GA24716@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0507011450180.30138@blysk.ds.pg.gda.pl>
References: <20050630173409Z8226102-3678+735@linux-mips.org>
 <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org>
 <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
 <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl>
 <20050701133910.GA24716@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/963/Fri Jul  1 15:27:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8302
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

On Fri, 1 Jul 2005, Daniel Jacobowitz wrote:

> >  And you may need external patches as glibc is (effectively) not 
> > maintained.
> 
> Shall I just stop trying, then?  I'm getting tired of arguing with you
> about this.

 Certainly not! -- in this case I haven't meant the MIPS port, but glibc 
as a whole -- just have a look at the response to fixes for the Alpha or 
i386!

 And please forgive me for the feeling of me arguing with you -- it wasn't 
my intention.  Frankly I cannot even realize exactly when it happened.

> For the twentieth time: I am doing everything I can to keep glibc HEAD
> building for MIPS.  I do not have the time or energy to deal with
> Roland's restrictive stable branch rules, so I can not help with 2.3.5.

 Building is not everything. ;-)

> But if you encounter a problem on HEAD, let me know, and I will either
> fix it myself or (if you've got a patch) pester people relentlessly
> until it is applied.

 Certainly -- I'm assuming you are ready for a pile of patches then?  
Well, perhaps not that many, but I think I've got around four that should 
go upstream.  I'll have a look if they apply cleanly.  None of them 
addresses a problem with building though.

  Maciej

From macro@linux-mips.org Fri Jul  1 15:43:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 15:44:00 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:19724 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226150AbVGAOno>; Fri, 1 Jul 2005 15:43:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id B3230F5985; Fri,  1 Jul 2005 16:43:32 +0200 (CEST)
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 30374-01; Fri,  1 Jul 2005 16:43:32 +0200 (CEST)
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 739DFF5983; Fri,  1 Jul 2005 16:43:32 +0200 (CEST)
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 j61EhXIB006017;
	Fri, 1 Jul 2005 16:43:33 +0200
Date:	Fri, 1 Jul 2005 15:43:41 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: RFH:  What are the semantics of writeb() and friends?
In-Reply-To: <1120224708.12446.26.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61L.0507011513320.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
  <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl> 
 <1120218385.12446.16.camel@localhost.localdomain> 
 <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
 <1120224708.12446.26.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/963/Fri Jul  1 15:27:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8303
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

On Fri, 1 Jul 2005, Alan Cox wrote:

> >  Is that non-reordering specified anywhere for the API or does it just 
> > happen to be satisfied by most implementations?  Ours (for MIPS, that is) 
> > for example does nothing to ensure that.
> 
> It is defined by the device I/O document as follows:
> 
> 
>         The read and write functions are defined to be ordered. That is
> the
>         compiler is not permitted to reorder the I/O sequence. When the
>         ordering can be compiler optimised, you can use <function>
>         __readb</function> and friends to indicate the relaxed ordering.
> Use
>         this with care.

 Oh, wonderful! -- another set of three functions per each operation, for 
direct, CPU-endian and memory-endian accesses.  Sigh...

> Note order - not synchronicity. On that it says

 But that mentions compiler only, not CPU ordering!  I understand the BIU 
of the issuing CPU and any external hardware is still permitted to 
merge/reorder these accesses unless separated by wmb()/rmb()/mb() as 
appropriate.  Note that there are MIPS-based systems that e.g. retrieve 
data pending in the write-back buffer (which is logically external to the 
CPU; sometimes even physically) for reads, e.g. with:

	writel(COMMAND, dev->csr);
	status = readl(dev->csr);

you'll likely get COMMAND in status, rather than any actual value of 
dev->csr and no read cycle ever reaches that device at all!  You need an 
mb() in between so that COMMAND leaves the CPU domain before issuing a 
read for this code to work as expected.  And of course an arbitrary number 
of read cycles to dev->irq_status placed after readl() above may bypass 
the write as well.

 We have that iob() macro/call as well, so that you can push cycles out of 
the CPU domain immediately as well, which is equivalent to:

	mb(); 
	make_host_complete_writes();

>        While the basic functions are defined to be synchronous with
> respect
>         to each other and ordered with respect to each other the busses
> the
>         devices sit on may themselves have asynchronicity. In particular
> many
>         authors are burned by the fact that PCI bus writes are posted
>         asynchronously. A driver author must issue a read from the same
>         device to ensure that writes have occurred in the specific cases
> the
>         author cares. This kind of property cannot be hidden from driver
>         writers in the API.  In some cases, the read used to flush the
> device
>         may be expected to fail (if the card is resetting, for
> example).  In
>         that case, the read should be done from config space, which is
>         guaranteed to soft-fail if the card doesn't respond.

 True and obvious once cycles actually reach your I/O bus of choice -- 
rules for that bus apply from then on.

> >  What if the host I/O bus is not PCI?  For this kind of stuff I tend to 
> > think in the terms of TURBOchannel systems, just to be sure not to get 
> > influenced by the most common hardware. ;-)
> 
> The bus behaviour is bus defined.

 Certainly -- does it apply to host buses as well from the Linux point of 
view?  I don't think drivers should be made aware of them -- they should 
be abstracted by the means of these barriers.

> >  Again, the I/O bus your host is attached to need not be PCI and you may 
> > need a bridge specific operation to make your write be completed, possibly 
> > combined with your quoted sequence (if there is actually PCI somewhere in 
> > the system; think AlphaServer 8400).
> 
> We don't currently have cross bridge "io_write_and_be_synchronous()"
> type functions. So far drivers have always known what to do. Your
> example might break that of course.

 So far I've been able to get away with that iob() function, but if the 
bus and buffering hierarchy gets even more complicated, there may be more 
barriers like this needed.

  Maciej

From drow@nevyn.them.org Fri Jul  1 15:46:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 15:47:07 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:53191 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8226150AbVGAOqt>;
	Fri, 1 Jul 2005 15:46:49 +0100
Received: from drow by nevyn.them.org with local (Exim 4.51)
	id 1DoMmu-00080D-7B; Fri, 01 Jul 2005 10:46:40 -0400
Date:	Fri, 1 Jul 2005 10:46:40 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	"Stephen P. Becker" <geoman@gentoo.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
Message-ID: <20050701144640.GA30720@nevyn.them.org>
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl> <20050701133910.GA24716@nevyn.them.org> <Pine.LNX.4.61L.0507011450180.30138@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507011450180.30138@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
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: 8304
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

On Fri, Jul 01, 2005 at 03:10:08PM +0100, Maciej W. Rozycki wrote:
>  Certainly -- I'm assuming you are ready for a pile of patches then?  
> Well, perhaps not that many, but I think I've got around four that should 
> go upstream.  I'll have a look if they apply cleanly.  None of them 
> addresses a problem with building though.

Sure - send them to me, or better yet, put them in bugzilla and make
sure you copy me.  I can't promise you timely response just now because
I'm about twelve feet under on this current project at work, but I'll
do everything I can.

We're going to have automated MIPS regression testing sometime this
year, too.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From geoman@gentoo.org Fri Jul  1 15:57:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 15:58:16 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:11213 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8226150AbVGAO54>; Fri, 1 Jul 2005 15:57:56 +0100
Received: from dagger.cc.vt.edu (IDENT:mirapoint@[10.1.1.11])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j61EuVpO006465;
	Fri, 1 Jul 2005 10:56:41 -0400
Received: from [128.173.184.73] (gs4073.geos.vt.edu [128.173.184.73])
	by dagger.cc.vt.edu (MOS 3.6.4-CR)
	with ESMTP id DOU46020;
	Fri, 1 Jul 2005 10:56:24 -0400 (EDT)
Message-ID: <42C55991.70109@gentoo.org>
Date:	Fri, 01 Jul 2005 10:56:17 -0400
From:	"Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050624)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Daniel Jacobowitz <dan@debian.org>
CC:	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
In-Reply-To: <20050701035105.GA9601@nevyn.them.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.org>
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: 8305
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: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips

>>Hmm, well with respect to my problem, I'm using a pretty recent
>>toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
>>from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
>>Bryan's segfault, but could not.  That code ran without error when I
>>linked with libpthread.  Any thoughts?
> 
> 
> I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
> in a long time.  Try CVS HEAD of glibc instead.
> 
> Other than that, you're on your own - building glibc is extremely error
> prone.
> 

I'm sure it can be error prone, but that isn't the problem here at all.
  My n32 glibc 2.3.5 compiled and seems to work just fine, and I was
able to compile an entire userland around it that has no (other)
problems so far as I can tell.  By this, I mean "emerge system" in
Gentoo terms, which is a pretty good test of whether the toolchain works
or not.  Furthermore, other programs that are linked against libpthread
run without causing a segfault and oops.  I'm talking about glib, as in
the glib that used to be part of GTK+ before it was split out some time
ago.

The segfault with kernel oops that I can't get around occurs while
glib's configure script is checking for libpthread.  Specifically, it
links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
libpthread and then runs it.

I've somewhat convinced myself this is either a kernel and/or a header
problem.  It seems I'm only able to reproduce this problem when trying
to compile and run that code while running 2.6.12 from cvs.  As I
previously mentioned, I tested the offending code on a kernel I compiled
from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.

-Steve

From macro@linux-mips.org Fri Jul  1 16:07:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:07:45 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:61190 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226156AbVGAPHZ>; Fri, 1 Jul 2005 16:07:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id BE155F59AB; Fri,  1 Jul 2005 17:07:13 +0200 (CEST)
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 06978-06; Fri,  1 Jul 2005 17:07:13 +0200 (CEST)
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 8EB33F599C; Fri,  1 Jul 2005 17:07:13 +0200 (CEST)
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 j61F47tZ007207;
	Fri, 1 Jul 2005 17:07:10 +0200
Date:	Fri, 1 Jul 2005 16:04:15 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Daniel Jacobowitz <dan@debian.org>
Cc:	"Stephen P. Becker" <geoman@gentoo.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <20050701144640.GA30720@nevyn.them.org>
Message-ID: <Pine.LNX.4.61L.0507011602540.30138@blysk.ds.pg.gda.pl>
References: <20050630173409Z8226102-3678+735@linux-mips.org>
 <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org>
 <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
 <Pine.LNX.4.61L.0507010940280.30138@blysk.ds.pg.gda.pl>
 <20050701133910.GA24716@nevyn.them.org> <Pine.LNX.4.61L.0507011450180.30138@blysk.ds.pg.gda.pl>
 <20050701144640.GA30720@nevyn.them.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/963/Fri Jul  1 15:27:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8306
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

On Fri, 1 Jul 2005, Daniel Jacobowitz wrote:

> Sure - send them to me, or better yet, put them in bugzilla and make
> sure you copy me.  I can't promise you timely response just now because
> I'm about twelve feet under on this current project at work, but I'll
> do everything I can.

 OK, one is already there as bug #933 and I'll add the rest.

> We're going to have automated MIPS regression testing sometime this
> year, too.

 Oh, that would be most welcome.

  Maciej

From bryan.althouse@3phoenix.com Fri Jul  1 16:09:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:09:58 +0100 (BST)
Received: from sccrmhc14.comcast.net ([IPv6:::ffff:204.127.202.59]:39159 "EHLO
	sccrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8226157AbVGAPJi>; Fri, 1 Jul 2005 16:09:38 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (sccrmhc14) with SMTP
          id <20050701150924014004f2s2e>; Fri, 1 Jul 2005 15:09:25 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Daniel Jacobowitz'" <dan@debian.org>,
	"'Stephen P. Becker'" <geoman@gentoo.org>,
	<macro@blysk.ds.pg.gda.pl>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: Seg fault when compiled with -mabi=64 and -lpthread
Date:	Fri, 1 Jul 2005 11:09:22 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-index: AcV98BzgA6st/adyScio+YU2hd//HgAW8vUw
In-Reply-To: <20050701035105.GA9601@nevyn.them.org>
Message-Id: <20050701150938Z8226157-3678+821@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
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: 8307
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips

Thanks for everyone's input!

Looks like I should upgrade glibc, and possibly gcc.  When you say that I
should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
the linux-mips.org CVS and the closest thing I can find is libc, and it
looks really old.  I have also found a glibc CVS at
:pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
this the "CVS HEAD"?  

Should I get GCC from the generic GCC site, or should get it from the
linux-mips CVS?  

I apologize for the simple questions.  I have not built a tool chain before.
I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
these sources for MIPs?

Bryan  

-----Original Message-----
From: Daniel Jacobowitz [mailto:dan@debian.org] 
Sent: Thursday, June 30, 2005 11:51 PM
To: Stephen P. Becker
Cc: Ralf Baechle; Bryan Althouse; 'Linux/MIPS Development'
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread

On Thu, Jun 30, 2005 at 06:09:09PM -0400, Stephen P. Becker wrote:
> 
> > Bryan seems to be using the original Red Hat gnupro 64-bit toolchain. 
> > I don't know how well that works nowadays; but current CVS versions do
> > work, or did when I last tested (a month or two ago).
> > 
> 
> Hmm, well with respect to my problem, I'm using a pretty recent
> toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers
> from a linux-mips 2.6.11 snapshot.  Interestingly, I tried to reproduce
> Bryan's segfault, but could not.  That code ran without error when I
> linked with libpthread.  Any thoughts?

I don't think glibc 2.3.5 worked for mips64.  But I haven't checked it
in a long time.  Try CVS HEAD of glibc instead.

Other than that, you're on your own - building glibc is extremely error
prone.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


From macro@linux-mips.org Fri Jul  1 16:22:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:22:37 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:45577 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226157AbVGAPWU>; Fri, 1 Jul 2005 16:22:20 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 24E09F598F; Fri,  1 Jul 2005 17:22:08 +0200 (CEST)
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 02511-05; Fri,  1 Jul 2005 17:22:08 +0200 (CEST)
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 D8C1EF598D; Fri,  1 Jul 2005 17:22:07 +0200 (CEST)
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 j61FMAN2008141;
	Fri, 1 Jul 2005 17:22:11 +0200
Date:	Fri, 1 Jul 2005 16:22:19 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	"Stephen P. Becker" <geoman@gentoo.org>
Cc:	Daniel Jacobowitz <dan@debian.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <42C55991.70109@gentoo.org>
Message-ID: <Pine.LNX.4.61L.0507011613510.30138@blysk.ds.pg.gda.pl>
References: <20050630173409Z8226102-3678+735@linux-mips.org>
 <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org>
 <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org>
 <42C55991.70109@gentoo.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/963/Fri Jul  1 15:27:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8308
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

On Fri, 1 Jul 2005, Stephen P. Becker wrote:

> I'm sure it can be error prone, but that isn't the problem here at all.
>   My n32 glibc 2.3.5 compiled and seems to work just fine, and I was
> able to compile an entire userland around it that has no (other)
> problems so far as I can tell.  By this, I mean "emerge system" in
> Gentoo terms, which is a pretty good test of whether the toolchain works
> or not.  Furthermore, other programs that are linked against libpthread
> run without causing a segfault and oops.  I'm talking about glib, as in
> the glib that used to be part of GTK+ before it was split out some time
> ago.
> 
> The segfault with kernel oops that I can't get around occurs while
> glib's configure script is checking for libpthread.  Specifically, it
> links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
> libpthread and then runs it.

 And libpthread is part of glibc, not glib.  So if an autoconf test (which 
I'm assuming is AC_CHECK_LIB() rather than a hand-crafted hack) breaks on 
running a program linked against libpthread, then it's not a problem with 
glib, but probably with either glibc or the toolchain used.

> I've somewhat convinced myself this is either a kernel and/or a header
> problem.  It seems I'm only able to reproduce this problem when trying
> to compile and run that code while running 2.6.12 from cvs.  As I
> previously mentioned, I tested the offending code on a kernel I compiled
> from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.

 If you get an Oops when running software as non-root, then it's a kernel 
bug, no matter what.

  Maciej

From macro@linux-mips.org Fri Jul  1 16:29:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:29:48 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:62736 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226159AbVGAP3b>; Fri, 1 Jul 2005 16:29:31 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 07967F598F; Fri,  1 Jul 2005 17:29:19 +0200 (CEST)
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 14038-09; Fri,  1 Jul 2005 17:29:18 +0200 (CEST)
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 BE05CF598D; Fri,  1 Jul 2005 17:29:18 +0200 (CEST)
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 j61FTMYd008310;
	Fri, 1 Jul 2005 17:29:22 +0200
Date:	Fri, 1 Jul 2005 16:29:30 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	"'Daniel Jacobowitz'" <dan@debian.org>,
	"'Stephen P. Becker'" <geoman@gentoo.org>,
	macro@blysk.ds.pg.gda.pl,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <20050701150938Z8226157-3678+821@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507011622380.30138@blysk.ds.pg.gda.pl>
References: <20050701150938Z8226157-3678+821@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/963/Fri Jul  1 15:27:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8309
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

On Fri, 1 Jul 2005, Bryan Althouse wrote:

> Looks like I should upgrade glibc, and possibly gcc.  When you say that I
> should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
> the linux-mips.org CVS and the closest thing I can find is libc, and it
> looks really old.  I have also found a glibc CVS at
> :pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
> this the "CVS HEAD"?  

 Yes, just pull the tree without any tags.

> Should I get GCC from the generic GCC site, or should get it from the
> linux-mips CVS?  

 The latest GCC 3.4.x should probably be OK, but if you want 4.x, then 
just get the latest release from (your closest mirror of) ftp.gnu.org -- 
if you don't rush, that may be 4.0.1.

> I apologize for the simple questions.  I have not built a tool chain before.
> I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
> these sources for MIPs?

 It depends on whether you trigger any bugs.

  Maciej

From ddaney@avtrex.com Fri Jul  1 16:48:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:48:39 +0100 (BST)
Received: from adsl-67-116-42-147.dsl.sntc01.pacbell.net ([IPv6:::ffff:67.116.42.147]:19210
	"EHLO avtrex.com") by linux-mips.org with ESMTP id <S8226159AbVGAPsK>;
	Fri, 1 Jul 2005 16:48:10 +0100
Received: from [192.168.7.26] ([192.168.7.3]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 1 Jul 2005 08:49:24 -0700
Message-ID: <42C565AC.4060300@avtrex.com>
Date:	Fri, 01 Jul 2005 08:47:56 -0700
From:	David Daney <ddaney@avtrex.com>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	moreau francis <francis_moreau2000@yahoo.fr>
CC:	zhan rongkai <zhanrk@gmail.com>, linux-mips@linux-mips.org
Subject: Re: I built a mipsel-linux toolchain, but it doesn't work
References: <20050701080003.54738.qmail@web25802.mail.ukl.yahoo.com>
In-Reply-To: <20050701080003.54738.qmail@web25802.mail.ukl.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Jul 2005 15:49:24.0046 (UTC) FILETIME=[741EDEE0:01C57E54]
Return-Path: <ddaney@avtrex.com>
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: 8310
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips

moreau francis wrote:
> Could you develop please ? What kind of config/hack does Buildroot to be able
> to use GCC with uClibc ?
> 

It is quite complicated, but you can find a summary on this web page:

http://www.google.com/search?q=uclibc+buildroot

From sjhill@realitydiluted.com Fri Jul  1 16:54:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 16:54:37 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:34528 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8226162AbVGAPyQ>; Fri, 1 Jul 2005 16:54:16 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1DoMu9-0007J0-62; Fri, 01 Jul 2005 09:54:09 -0500
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
In-Reply-To: <20050701150938Z8226157-3678+821@linux-mips.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Date:	Fri, 1 Jul 2005 09:54:09 -0500 (CDT)
CC:	"'Daniel Jacobowitz'" <dan@debian.org>,
	"'Stephen P. Becker'" <geoman@gentoo.org>,
	macro@blysk.ds.pg.gda.pl,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1DoMu9-0007J0-62@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
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: 8311
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: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

> Looks like I should upgrade glibc, and possibly gcc.  When you say that I
> should try CVS HEAD of glibc, I'm not sure what you mean.  I have looked in
> the linux-mips.org CVS and the closest thing I can find is libc, and it
> looks really old.  I have also found a glibc CVS at
> :pserver:anoncvs@sources.redhat.com:/cvs/glibc.  If I get libc from here is
> this the "CVS HEAD"?  
> 
> Should I get GCC from the generic GCC site, or should get it from the
> linux-mips CVS?  
> 
> I apologize for the simple questions.  I have not built a tool chain before.
> I've been using the one supplied by PMC-Sierra.  Will I need to patch any of
> these sources for MIPs?
> 
Also, stay away from the HEAD of GCC CVS. GCC-4.1.0 compilers cannot
build Linux kernels.

-Steve

From sjhill@realitydiluted.com Fri Jul  1 17:00:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 17:00:36 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:37344 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8226159AbVGAQAM>; Fri, 1 Jul 2005 17:00:12 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 4.50 #1 (Debian))
	id 1DoN00-0007Jb-Gs; Fri, 01 Jul 2005 10:00:12 -0500
Subject: Re: I built a mipsel-linux toolchain, but it doesn't work
In-Reply-To: <42C565AC.4060300@avtrex.com>
To:	David Daney <ddaney@avtrex.com>
Date:	Fri, 1 Jul 2005 10:00:12 -0500 (CDT)
CC:	moreau francis <francis_moreau2000@yahoo.fr>,
	zhan rongkai <zhanrk@gmail.com>, linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1DoN00-0007Jb-Gs@real.realitydiluted.com>
From:	sjhill@realitydiluted.com
Return-Path: <sjhill@realitydiluted.com>
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: 8312
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: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

> moreau francis wrote:
> > Could you develop please ? What kind of config/hack does Buildroot to be able
> > to use GCC with uClibc ?
> > 
> 
> It is quite complicated, but you can find a summary on this web page:
> 
> http://www.google.com/search?q=uclibc+buildroot
> 
Here is the page for it:

   http://buildroot.uclibc.org/

The mipsel target is supported and will build for your needs. Do not
use uClibc-0.9.27 when you configure your buildroot system. Use the
latest uClibc snapshot. There are issues with uClibc-0.9.27 with MIPS
targets.

-Steve

From geoman@gentoo.org Fri Jul  1 17:41:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 17:41:40 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:42939 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8226159AbVGAQlU>; Fri, 1 Jul 2005 17:41:20 +0100
Received: from zidane.cc.vt.edu (IDENT:mirapoint@[10.1.1.13])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j61Gdqm7005445;
	Fri, 1 Jul 2005 12:40:02 -0400
Received: from [128.173.184.73] (gs4073.geos.vt.edu [128.173.184.73])
	by zidane.cc.vt.edu (MOS 3.6.4-CR)
	with ESMTP id DMZ68355;
	Fri, 1 Jul 2005 12:39:38 -0400 (EDT)
Message-ID: <42C571C3.1060703@gentoo.org>
Date:	Fri, 01 Jul 2005 12:39:31 -0400
From:	"Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050624)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
CC:	Daniel Jacobowitz <dan@debian.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <42C55991.70109@gentoo.org> <Pine.LNX.4.61L.0507011613510.30138@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.61L.0507011613510.30138@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.org>
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: 8313
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: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips

>>The segfault with kernel oops that I can't get around occurs while
>>glib's configure script is checking for libpthread.  Specifically, it
>>links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
>>libpthread and then runs it.
> 
> 
> And libpthread is part of glibc, not glib.  So if an autoconf test (which 
> I'm assuming is AC_CHECK_LIB() rather than a hand-crafted hack) breaks on 
> running a program linked against libpthread, then it's not a problem with 
> glib, but probably with either glibc or the toolchain used.

I'm aware of this. It just sounded like Daniel was questioning whether
or not my glibc was compiling/working in the first place.

>>I've somewhat convinced myself this is either a kernel and/or a header
>>problem.  It seems I'm only able to reproduce this problem when trying
>>to compile and run that code while running 2.6.12 from cvs.  As I
>>previously mentioned, I tested the offending code on a kernel I compiled
>>from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops.
> 
> 
>  If you get an Oops when running software as non-root, then it's a kernel 
> bug, no matter what.
> 

Yes, it certainly happens when running as a non-privileged user.  If I
get a bit of time later today, I was going to try and track down which
cvs commit and/or kernel version broke things.

-Steve

From drow@nevyn.them.org Fri Jul  1 18:03:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 18:03:28 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:24267 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8226168AbVGARDJ>;
	Fri, 1 Jul 2005 18:03:09 +0100
Received: from drow by nevyn.them.org with local (Exim 4.51)
	id 1DoOuo-0005r2-Kn; Fri, 01 Jul 2005 13:02:58 -0400
Date:	Fri, 1 Jul 2005 13:02:58 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	"Stephen P. Becker" <geoman@gentoo.org>
Cc:	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
Message-ID: <20050701170258.GA22405@nevyn.them.org>
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <42C55991.70109@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42C55991.70109@gentoo.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
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: 8315
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: 556
Lines: 15

On Fri, Jul 01, 2005 at 10:56:17AM -0400, Stephen P. Becker wrote:
> The segfault with kernel oops that I can't get around occurs while
> glib's configure script is checking for libpthread.  Specifically, it
> links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
> libpthread and then runs it.

If that oopses, your famed emerge testing hasn't run any threaded
programs, my friend :-)

Could be kernel, could be library, could be both.  Must be at least
kernel because the kernel should never oops.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From geoman@gentoo.org Fri Jul  1 18:17:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 18:17:36 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:8924 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8226168AbVGARRU>; Fri, 1 Jul 2005 18:17:20 +0100
Received: from vivi.cc.vt.edu (IDENT:mirapoint@[10.1.1.12])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j61HG0Qx017070;
	Fri, 1 Jul 2005 13:16:10 -0400
Received: from [128.173.184.73] (gs4073.geos.vt.edu [128.173.184.73])
	by vivi.cc.vt.edu (MOS 3.6.4-CR)
	with ESMTP id DNQ77670;
	Fri, 1 Jul 2005 13:15:45 -0400 (EDT)
Message-ID: <42C57A2E.4070702@gentoo.org>
Date:	Fri, 01 Jul 2005 13:15:26 -0400
From:	"Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050624)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Daniel Jacobowitz <dan@debian.org>
CC:	Ralf Baechle <ralf@linux-mips.org>,
	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread
References: <20050630173409Z8226102-3678+735@linux-mips.org> <20050630202111.GC3245@linux-mips.org> <20050630210357.GA23456@nevyn.them.org> <42C46D85.9050104@gentoo.org> <20050701035105.GA9601@nevyn.them.org> <42C55991.70109@gentoo.org> <20050701170258.GA22405@nevyn.them.org>
In-Reply-To: <20050701170258.GA22405@nevyn.them.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.org>
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: 8316
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: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1111
Lines: 30

Daniel Jacobowitz wrote:
> On Fri, Jul 01, 2005 at 10:56:17AM -0400, Stephen P. Becker wrote:
> 
>>The segfault with kernel oops that I can't get around occurs while
>>glib's configure script is checking for libpthread.  Specifically, it
>>links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against
>>libpthread and then runs it.
> 
> 
> If that oopses, your famed emerge testing hasn't run any threaded
> programs, my friend :-)

What do you mean by "famed" emerge testing?  In any case, that is what I
am in the process of doing (testing).  This userland I am working with
is in no way an official Gentoo install. :)  At some point in the
future, we will probably make official n32 install stages available to
the general users, after we work all the bugs out...this just happens to
be one of those bugs.

> Could be kernel, could be library, could be both.

Well, since you say that glibc 2.3.5 probably isn't up to par for
mips64, I'll see if I can get cvs HEAD going in a chroot and see if that
fixes the problem.

> Must be at least kernel because the kernel should never oops.

Agreed.

-Steve

From bryan.althouse@3phoenix.com Fri Jul  1 18:26:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 18:26:56 +0100 (BST)
Received: from sccrmhc14.comcast.net ([IPv6:::ffff:204.127.202.59]:28602 "EHLO
	sccrmhc14.comcast.net") by linux-mips.org with ESMTP
	id <S8226172AbVGAR0l>; Fri, 1 Jul 2005 18:26:41 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (sccrmhc14) with SMTP
          id <20050701172627014004e4jhe>; Fri, 1 Jul 2005 17:26:28 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Maciej W. Rozycki'" <macro@linux-mips.org>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: top and SMP
Date:	Fri, 1 Jul 2005 13:26:25 -0400
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: <Pine.LNX.4.61L.0507010950310.30138@blysk.ds.pg.gda.pl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcV+GjopURKKgsNTSVGITQNgbOGu6wARoEGw
Message-Id: <20050701172641Z8226172-3678+842@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
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: 8317
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 963
Lines: 31

Maciej,

Looks like I am running procps version 2.0.7.  The latest is 3.2.5, so I am
a bit out of date.  I would like to upgrade, but I am having trouble cross
compiling the latest.  I get this error:
	Proc/libproc-3.2.5.so: undefined reference to '__ctype_b'
For other reasons, I need to upgrade my toolchain.  Hopefully I'll have
better luck cross compiling procps afterwards.

Bryan

-----Original Message-----
From: macro@blysk.ds.pg.gda.pl [mailto:macro@blysk.ds.pg.gda.pl] On Behalf
Of Maciej W. Rozycki
Sent: Friday, July 01, 2005 4:53 AM
To: Bryan Althouse
Cc: 'Linux/MIPS Development'
Subject: Re: top and SMP

On Thu, 30 Jun 2005, Bryan Althouse wrote:

> I have tried to get top to display processor utilization on a per CPU
basis,
> but to no avail.  Does anyone know how to get top to properly display
> statistics for a SMP system?  Better yet, does anyone know of a better
> utility than top?  

 Do you have a recent version of procps?

  Maciej


From alan@lxorguk.ukuu.org.uk Fri Jul  1 20:55:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 20:56:16 +0100 (BST)
Received: from clock-tower.bc.nu ([IPv6:::ffff:81.2.110.250]:29577 "EHLO
	lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226173AbVGATz7>; Fri, 1 Jul 2005 20:55:59 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j61JrGjG016309;
	Fri, 1 Jul 2005 20:53:17 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j61JrGSg016308;
	Fri, 1 Jul 2005 20:53:16 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: RFH:  What are the semantics of writeb() and friends?
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
In-Reply-To: <Pine.LNX.4.61L.0507011513320.30138@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
	 <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>
	 <1120218385.12446.16.camel@localhost.localdomain>
	 <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
	 <1120224708.12446.26.camel@localhost.localdomain>
	 <Pine.LNX.4.61L.0507011513320.30138@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1120247593.12462.38.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Fri, 01 Jul 2005 20:53:15 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
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: 8318
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: 1054
Lines: 24

On Gwe, 2005-07-01 at 15:43, Maciej W. Rozycki wrote:
>  But that mentions compiler only, not CPU ordering!  I understand the BIU 
> of the issuing CPU and any external hardware is still permitted to 
> merge/reorder these accesses unless separated by wmb()/rmb()/mb() as 

I think the practical situation is that this implies ordering to the bus
interface. It might be interesting to ask the powerpc people their
experience but looking at most PCI drivers they assume this and it would
be expensive not to do so on x86.

>  We have that iob() macro/call as well, so that you can push cycles out of 
> the CPU domain immediately as well, which is equivalent to:

> 	mb(); 
> 	make_host_complete_writes();

My feeling is the default readb etc are __readb + mb + make_hos...
>  So far I've been able to get away with that iob() function, but if the 
> bus and buffering hierarchy gets even more complicated, there may be more 
> barriers like this needed.

Agreed - and we now have the device model so we can actually do that by
passing a device pointer.


From rolfliu@gmail.com Fri Jul  1 22:18:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 22:18:24 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.197]:16723 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226173AbVGAVSE> convert rfc822-to-8bit;
	Fri, 1 Jul 2005 22:18:04 +0100
Received: by wproxy.gmail.com with SMTP id 70so434355wra
        for <linux-mips@linux-mips.org>; Fri, 01 Jul 2005 14:17:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=RiYSaoYkdKN/5gqnNEw8iGZNXvKk3F0D44nqcmiXC4oU1ETiMCFU2Pw1BpkChfqGRkmzgzDRfciSXVpFzZE7uO4UfKYwb7v51jbHm2+Fx7rM5w0WyuXs6A/wRbVad38/0XMamSvrCdkueP/kPbqG1v6dw137qc/17MSpAKHvuCY=
Received: by 10.54.26.45 with SMTP id 45mr1937182wrz;
        Fri, 01 Jul 2005 14:17:46 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 1 Jul 2005 14:17:46 -0700 (PDT)
Message-ID: <2db32b7205070114172483d2dd@mail.gmail.com>
Date:	Fri, 1 Jul 2005 14:17:46 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	rolfliu@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8319
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 8797
Lines: 207

linux crashes during the booting process. it is right at mounting the
root file system through NFS server. the following is the trace. the
root file system is based on redhat 7.1, could be used to boot 2.4
kernel. Any suggestions?

Another problem is, if I want to compile in the hpt366.c, the kernel
will hang right after it found the disk drive:
(Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT371: IDE controller at PCI slot 0000:00:0b.0
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
HPT371: chipset revision 2
HPT37X: using 33MHz PCI clock
HPT371: 100% native mode on irq 5
    ide2: BM-DMA at 0x1000-0x1007, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0x1008-0x100f, BIOS settings: hdg:pio, hdh:pio
hdg: IBM-DTTA-350840, ATA DISK drive
)
It just freeze there for ever :(

a long email. I really appreciate the help and will give the feedback then.

thanks

OUTPUT:
Linux version 2.6.12-mipscvs-20050626 (rolf@DBServer) (gcc version
3.4.4) #3 Fri Jul 1 13:25:50 PDT 2005
CPU revision is: 03030200
AMD Alchemy Au1550/Db1550 Board
(PRId 03030200) @ 396MHZ
BCLK switching enabled!
Determined physical RAM map:
 memory: 0c000000 @ 00000000 (usable)
Built 1 zonelists
Kernel command line: ip=dhcp nfsroot=10.200.0.198:/db1550 console=ttyS0,115200
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes.
Primary data cache 16kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (17 instructions).
Synthesized TLB load handler fastpath (34 instructions).
Synthesized TLB store handler fastpath (34 instructions).
Synthesized TLB modify handler fastpath (33 instructions).
PID hash table entries: 1024 (order: 10, 16384 bytes)
calculating r4koff... 00060ae0(396000)
CPU frequency 396.00 MHz
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 190212k/196608k available (2486k kernel code, 6160k reserved,
617k data, 128k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  unavailable.
NET: Registered protocol family 16
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Serial: Au1x00 driver
ttyS0 at I/O 0xb1100000 (irq = 0) is a AU1X00_UART
ttyS1 at I/O 0xb1200000 (irq = 8) is a AU1X00_UART
ttyS2 at I/O 0xb1400000 (irq = 9) is a AU1X00_UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
au1000eth version 1.5 Pete Popov <ppopov@embeddedalley.com>
eth0: Au1x Ethernet found at 0xb0500000, irq 27
eth0: AMD 79C874 10/100 BaseT PHY at phy address 31
eth0: Using AMD 79C874 10/100 BaseT PHY as default
eth1: Au1x Ethernet found at 0xb0510000, irq 28
eth1: AMD 79C874 10/100 BaseT PHY at phy address 31
eth1: Using AMD 79C874 10/100 BaseT PHY as default
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Db1550 Flash: probing 32-bit flash bus
Db1550 Flash: Found 2 x16 devices at 0x0 in 32-bit bank
Db1550 Flash: Found 2 x16 devices at 0x4000000 in 32-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
Db1550 Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "Db1550 Flash":
0x00000000-0x07c00000 : "User FS"
0x07c00000-0x07d00000 : "YAMON"
0x07d00000-0x07fc0000 : "raw kernel"
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Sending DHCP requests .<6>eth0: link up
eth1: link up
., OK
IP-Config: Got DHCP answer from 255.255.255.255, my address is 10.200.1.54
IP-Config: Complete:
      device=eth0, addr=10.200.1.54, mask=255.255.0.0, gw=10.200.0.1,
     host=10.200.1.54, domain=sel, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=10.200.0.198, rootpath=
Looking up port of RPC 100003/2 on 10.200.0.198
Reserved instruction in kernel code in
arch/mips/kernel/traps.c::do_ri, line 706[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 00010000 00000000
$ 4   : 812b8e40 00000093 00000000 811df97c
$ 8   : 00000040 812b9e40 00000000 812a4e10
$12   : 0000ffff 00200200 00100100 812a3ef4
$16   : 812b8e40 00000000 812b8e40 00000060
$20   : 8042a6e0 00010000 811df90c 80144b20
$24   : 00000000 00000001                  
$28   : 811de000 811df8f0 8042a6e0 802facd0
Hi    : 00000000
Lo    : 00000780
epc   : 802ca258 sock_alloc_send_skb+0x74/0x5c8     Not tainted
ra    : 802facd0 ip_append_data+0x7c8/0xa34
Status: 1000fc03    KERNEL EXL IE 
Cause : 00800028
PrId  : 03030200
Modules linked in:
Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
Stack : c600c80a 3601c80a 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000074 00000000 812b8e40 00000060 812b8e40 812b9e40 00000060 00000008
        812b8e98 802facd0 00000000 00000093 00000000 811df97c 00000000 00000000
        00000000 00000000 812b9e40 00000000 00000010 00000000 000005dc 00000000
        ...
Call Trace:
 [<802facd0>] ip_append_data+0x7c8/0xa34
 [<8031e3c4>] udp_sendmsg+0x224/0xa08
 [<802fa44c>] ip_generic_getfrag+0x0/0xbc
 [<802c6558>] sock_sendmsg+0xac/0xf0
 [<80334890>] fn_hash_lookup+0x100/0x150
 [<80334890>] fn_hash_lookup+0x100/0x150
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<802c65c0>] kernel_sendmsg+0x24/0x38
 [<80362f48>] xdr_sendpages+0x1dc/0x29c
 [<80355284>] xprt_transmit+0xec/0x5f4
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<803529c4>] call_transmit+0x1f4/0x2d4
 [<80356674>] rpc_delete_timer+0xdc/0x108
 [<80357cb4>] __rpc_execute+0xa8/0x54c
 [<80420000>] init_mtdchar+0x20/0x60
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<8035976c>] rpcauth_bindcred+0xac/0x248
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<80420000>] init_mtdchar+0x20/0x60
 [<80420000>] init_mtdchar+0x20/0x60
 [<80420000>] init_mtdchar+0x20/0x60
 [<80351d28>] rpc_call_sync+0x8c/0xd8
 [<80351d14>] rpc_call_sync+0x78/0xd8
 [<80361fdc>] pmap_create+0x74/0xc0
 [<80420000>] init_mtdchar+0x20/0x60
 [<803622e8>] rpc_getport_external+0x11c/0x180
 [<80420000>] init_mtdchar+0x20/0x60
 [<8041b854>] root_nfs_getport+0x8c/0xa8
 [<80420000>] init_mtdchar+0x20/0x60
 [<80254000>] snprintf+0x14/0x20
 [<8041bb94>] nfs_root_data+0x324/0x3a8
 [<80420000>] init_mtdchar+0x20/0x60
 [<80128f24>] printk+0x1c/0x28
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<80420000>] init_mtdchar+0x20/0x60
 [<8013e444>] flush_workqueue+0x28/0x34
 [<80197f58>] path_lookup+0xe0/0x3d0
 [<80194c78>] getname+0x28/0xf8
 [<80198644>] __user_walk+0x78/0x94
 [<80420000>] init_mtdchar+0x20/0x60
 [<80409cb0>] mount_root+0xac/0x1c4
 [<80144b20>] autoremove_wake_function+0x0/0x44
 [<80420000>] init_mtdchar+0x20/0x60
 [<80420000>] init_mtdchar+0x20/0x60
 [<80409e10>] prepare_namespace+0x48/0x148
 [<8013e444>] flush_workqueue+0x28/0x34
 [<8010065c>] init+0x200/0x264
 [<80100574>] init+0x118/0x264
 [<80105e20>] kernel_thread_helper+0x10/0x18
 [<80105e10>] kernel_thread_helper+0x0/0x18


Code: 10400091  0280f021  c20300a0 <0000102d> e20200a0  1040fffc 
00000000  00032823  14a0009f
Kernel panic - not syncing: Attempted to kill init!




Also, I tried to run 2.4.31 on db1550, but got no luck to get the hard
drive working, which also crashes during the probing process:
probing for hda: present=0, media=32, probetype=ATA
probing for hda: present=0, media=32, probetype=ATAPI
probing for hdb: present=0, media=32, probetype=ATA
probing for hdb: present=0, media=32, probetype=ATAPI
probing for hdc: present=0, media=32, probetype=ATA
probing for hdc: present=0, media=32, probetype=ATAPI
probing for hdd: present=0, media=32, probetype=ATA
probing for hdd: present=0, media=32, probetype=ATAPI
probing for hde: present=0, media=32, probetype=ATA
probing for hde: present=0, media=32, probetype=ATAPI
probing for hdf: present=0, media=32, probetype=ATA
probing for hdf: present=0, media=32, probetype=ATAPI
probing for hdg: present=0, media=32, probetype=ATA
hdg: IBM-DTTA-350840, ATA DISK drive
probing for hdh: present=0, media=32, probetype=ATA
probing for hdh: present=0, media=32, probetype=ATAPI
Unable to handle kernel paging request at virtual address 00000000,
epc == 801e77f0, ra == 801e7b48
Oops in fault.c::do_page_fault, line 206:

From ppopov@embeddedalley.com Fri Jul  1 22:24:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 22:24:29 +0100 (BST)
Received: from smtp004.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.81]:26787
	"HELO smtp004.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226177AbVGAVYM>; Fri, 1 Jul 2005 22:24:12 +0100
Received: (qmail 77852 invoked from network); 1 Jul 2005 21:24:03 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp004.bizmail.sc5.yahoo.com with SMTP; 1 Jul 2005 21:24:03 -0000
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070114172483d2dd@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 01 Jul 2005 14:24:08 -0700
Message-Id: <1120253048.5987.16.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8320
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: 6747
Lines: 164


<snip>

The problem below is caused by a .mips3 directive in xchg_u32. I talked
to Ralf and Maciel about the problem; Ralf sent a patch but I don't see
it applied in the tree yet.  Try this:

Index: include/asm-mips/system.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/system.h,v
retrieving revision 1.85
diff -u -r1.85 system.h
--- include/asm-mips/system.h   23 Jun 2005 15:57:18 -0000      1.85
+++ include/asm-mips/system.h   29 Jun 2005 12:01:54 -0000
@@ -178,7 +178,9 @@
                __asm__ __volatile__(
                "       .set    mips3                                   \n"
                "1:     ll      %0, %3                  #
xchg_u32      \n"
+               "       .set    mips0                                   \n"
                "       move    %2, %
z4                                 \n"
+               "       .set    mips3                                   \n"
                "       sc      %2, %
1                                  \n"
                "       beqzl   %2,
1b                                  \n"
                ROT_IN_PIECES
@@ -195,7 +197,9 @@
                __asm__ __volatile__(
                "       .set    mips3                                   \n"
                "1:     ll      %0, %3                  #
xchg_u32      \n"
+               "       .set    mips0                                   \n"
                "       move    %2, %
z4                                 \n"
+               "       .set    mips3                                   \n"
                "       sc      %2, %
1                                  \n"
                "       beqz    %2,
1b                                  \n"
 #ifdef CONFIG_SMP



Pete

> eth1: link up
> ., OK
> IP-Config: Got DHCP answer from 255.255.255.255, my address is 10.200.1.54
> IP-Config: Complete:
>       device=eth0, addr=10.200.1.54, mask=255.255.0.0, gw=10.200.0.1,
>      host=10.200.1.54, domain=sel, nis-domain=(none),
>      bootserver=255.255.255.255, rootserver=10.200.0.198, rootpath=
> Looking up port of RPC 100003/2 on 10.200.0.198
> Reserved instruction in kernel code in
> arch/mips/kernel/traps.c::do_ri, line 706[#1]:
> Cpu 0
> $ 0   : 00000000 1000fc00 00010000 00000000
> $ 4   : 812b8e40 00000093 00000000 811df97c
> $ 8   : 00000040 812b9e40 00000000 812a4e10
> $12   : 0000ffff 00200200 00100100 812a3ef4
> $16   : 812b8e40 00000000 812b8e40 00000060
> $20   : 8042a6e0 00010000 811df90c 80144b20
> $24   : 00000000 00000001                  
> $28   : 811de000 811df8f0 8042a6e0 802facd0
> Hi    : 00000000
> Lo    : 00000780
> epc   : 802ca258 sock_alloc_send_skb+0x74/0x5c8     Not tainted
> ra    : 802facd0 ip_append_data+0x7c8/0xa34
> Status: 1000fc03    KERNEL EXL IE 
> Cause : 00800028
> PrId  : 03030200
> Modules linked in:
> Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> Stack : c600c80a 3601c80a 00000000 00000000 00000000 00000000 00000000 00000000
>         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>         00000074 00000000 812b8e40 00000060 812b8e40 812b9e40 00000060 00000008
>         812b8e98 802facd0 00000000 00000093 00000000 811df97c 00000000 00000000
>         00000000 00000000 812b9e40 00000000 00000010 00000000 000005dc 00000000
>         ...
> Call Trace:
>  [<802facd0>] ip_append_data+0x7c8/0xa34
>  [<8031e3c4>] udp_sendmsg+0x224/0xa08
>  [<802fa44c>] ip_generic_getfrag+0x0/0xbc
>  [<802c6558>] sock_sendmsg+0xac/0xf0
>  [<80334890>] fn_hash_lookup+0x100/0x150
>  [<80334890>] fn_hash_lookup+0x100/0x150
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<802c65c0>] kernel_sendmsg+0x24/0x38
>  [<80362f48>] xdr_sendpages+0x1dc/0x29c
>  [<80355284>] xprt_transmit+0xec/0x5f4
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<803529c4>] call_transmit+0x1f4/0x2d4
>  [<80356674>] rpc_delete_timer+0xdc/0x108
>  [<80357cb4>] __rpc_execute+0xa8/0x54c
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<8035976c>] rpcauth_bindcred+0xac/0x248
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80351d28>] rpc_call_sync+0x8c/0xd8
>  [<80351d14>] rpc_call_sync+0x78/0xd8
>  [<80361fdc>] pmap_create+0x74/0xc0
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<803622e8>] rpc_getport_external+0x11c/0x180
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<8041b854>] root_nfs_getport+0x8c/0xa8
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80254000>] snprintf+0x14/0x20
>  [<8041bb94>] nfs_root_data+0x324/0x3a8
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80128f24>] printk+0x1c/0x28
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<8013e444>] flush_workqueue+0x28/0x34
>  [<80197f58>] path_lookup+0xe0/0x3d0
>  [<80194c78>] getname+0x28/0xf8
>  [<80198644>] __user_walk+0x78/0x94
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80409cb0>] mount_root+0xac/0x1c4
>  [<80144b20>] autoremove_wake_function+0x0/0x44
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80420000>] init_mtdchar+0x20/0x60
>  [<80409e10>] prepare_namespace+0x48/0x148
>  [<8013e444>] flush_workqueue+0x28/0x34
>  [<8010065c>] init+0x200/0x264
>  [<80100574>] init+0x118/0x264
>  [<80105e20>] kernel_thread_helper+0x10/0x18
>  [<80105e10>] kernel_thread_helper+0x0/0x18
> 
> 
> Code: 10400091  0280f021  c20300a0 <0000102d> e20200a0  1040fffc 
> 00000000  00032823  14a0009f
> Kernel panic - not syncing: Attempted to kill init!
> 
> 
> 
> 
> Also, I tried to run 2.4.31 on db1550, but got no luck to get the hard
> drive working, which also crashes during the probing process:
> probing for hda: present=0, media=32, probetype=ATA
> probing for hda: present=0, media=32, probetype=ATAPI
> probing for hdb: present=0, media=32, probetype=ATA
> probing for hdb: present=0, media=32, probetype=ATAPI
> probing for hdc: present=0, media=32, probetype=ATA
> probing for hdc: present=0, media=32, probetype=ATAPI
> probing for hdd: present=0, media=32, probetype=ATA
> probing for hdd: present=0, media=32, probetype=ATAPI
> probing for hde: present=0, media=32, probetype=ATA
> probing for hde: present=0, media=32, probetype=ATAPI
> probing for hdf: present=0, media=32, probetype=ATA
> probing for hdf: present=0, media=32, probetype=ATAPI
> probing for hdg: present=0, media=32, probetype=ATA
> hdg: IBM-DTTA-350840, ATA DISK drive
> probing for hdh: present=0, media=32, probetype=ATA
> probing for hdh: present=0, media=32, probetype=ATAPI
> Unable to handle kernel paging request at virtual address 00000000,
> epc == 801e77f0, ra == 801e7b48
> Oops in fault.c::do_page_fault, line 206:
> 


From vprashant@echelon.com Fri Jul  1 22:48:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 22:48:42 +0100 (BST)
Received: from ntfw.echelon.com ([IPv6:::ffff:205.229.50.10]:23482 "EHLO
	[205.229.50.10]") by linux-mips.org with ESMTP id <S8226177AbVGAVsW>;
	Fri, 1 Jul 2005 22:48:22 +0100
Received: from miles.echelon.com by [205.229.50.10]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with ESMTP; Fri, 1 Jul 2005 14:48:16 -0700
Received: by miles.echelon.echcorp.com with Internet Mail Service (5.5.2653.19)
	id <NRBD31B0>; Fri, 1 Jul 2005 14:48:13 -0700
Message-ID: <5375D9FB1CC3994D9DCBC47C344EEB5905FA4379@miles.echelon.echcorp.com>
From:	Prashant Viswanathan <vprashant@echelon.com>
To:	linux-mips@linux-mips.org
Subject: help in choosing stable linux kernel version for db1550
Date:	Fri, 1 Jul 2005 14:48:11 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57E86.933559A6"
Return-Path: <vprashant@echelon.com>
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: 8321
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: vprashant@echelon.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6497
Lines: 241

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C57E86.933559A6
Content-Type: text/plain

Hi,
 
I would like to install a recent but stable kernel on my dbAu1550 board.
Kernel.org says 2.6.12.2 is the latest stable kernel. However, I would
appreciate any input on choosing a stable version for the dbAu1550.
 
Thanks
Prashant

------_=_NextPart_001_01C57E86.933559A6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C57E4C.5C7C9550">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Copperplate Gothic Bold";
	mso-font-alt:Arial;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:536902279 -2147483648 8 0 511 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.Appendix, li.Appendix, div.Appendix
	{mso-style-name:Appendix;
	margin-top:6.0pt;
	margin-right:0in;
	margin-bottom:30.0pt;
	margin-left:0in;
	text-align:center;
	text-indent:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	mso-list:l0 level1 lfo1;
	font-size:12.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Copperplate Gothic Bold";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	text-shadow:auto;}
span.EmailStyle18
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1436704306;
	mso-list-template-ids:1585727826;}
@list l0:level1
	{mso-level-number-format:alpha-upper;
	mso-level-style-link:Appendix;
	mso-level-suffix:none;
	mso-level-text:"Appendix %1";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:0in;
	text-indent:0in;}
@list l0:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.75in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.";
	mso-level-tab-stop:2.4in;
	mso-level-number-position:left;
	margin-left:2.4in;
	text-indent:-.65in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.";
	mso-level-tab-stop:2.75in;
	mso-level-number-position:left;
	margin-left:2.75in;
	text-indent:-.75in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.";
	mso-level-tab-stop:3.1in;
	mso-level-number-position:left;
	margin-left:3.1in;
	text-indent:-.85in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9\.";
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	margin-left:3.5in;
	text-indent:-1.0in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I would like to install a recent but stable kernel =
on my
dbAu1550 board. Kernel.org says 2.6.12.2 is the latest stable kernel. =
However,
I would appreciate any input on choosing a stable version for the =
dbAu1550.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Prashant<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C57E86.933559A6--

From ppopov@embeddedalley.com Fri Jul  1 23:07:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 23:07:46 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:36472
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226180AbVGAWH1>; Fri, 1 Jul 2005 23:07:27 +0100
Received: (qmail 65467 invoked from network); 1 Jul 2005 22:07:19 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 1 Jul 2005 22:07:18 -0000
Subject: Re: help in choosing stable linux kernel version for db1550
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Prashant Viswanathan <vprashant@echelon.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <5375D9FB1CC3994D9DCBC47C344EEB5905FA4379@miles.echelon.echcorp.com>
References: <5375D9FB1CC3994D9DCBC47C344EEB5905FA4379@miles.echelon.echcorp.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 01 Jul 2005 15:07:23 -0700
Message-Id: <1120255643.5987.21.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8322
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: 350
Lines: 14

On Fri, 2005-07-01 at 14:48 -0700, Prashant Viswanathan wrote:
> Hi,
> 
>  
> 
> I would like to install a recent but stable kernel on my dbAu1550
> board. Kernel.org says 2.6.12.2 is the latest stable kernel. However,
> I would appreciate any input on choosing a stable version for the
> dbAu1550.

DbAu1550 should be stable in the 2.6 tree.

Pete


From rolfliu@gmail.com Fri Jul  1 23:35:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 23:35:45 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.202]:6420 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226180AbVGAWf3> convert rfc822-to-8bit;
	Fri, 1 Jul 2005 23:35:29 +0100
Received: by wproxy.gmail.com with SMTP id i25so396228wra
        for <linux-mips@linux-mips.org>; Fri, 01 Jul 2005 15:35:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=VhAHFDTfkhYLrDjxqmepa6xaS95PuluBLBAJI5LZtByHE4SCB+ObwhQKYUopGUwA67AY19PVEM7xfKksFgjoQtW0HPBsHHoZGOhrpGaG0MjqTO1WK802rap5SnVjJQGro4k1WEpAK0KhXWrFR5rVa/RdkZOKGxPLEYHW/MG0aqg=
Received: by 10.54.117.16 with SMTP id p16mr2015753wrc;
        Fri, 01 Jul 2005 15:35:23 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 1 Jul 2005 15:35:22 -0700 (PDT)
Message-ID: <2db32b72050701153566c83bb6@mail.gmail.com>
Date:	Fri, 1 Jul 2005 15:35:22 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120253048.5987.16.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8323
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7851
Lines: 187

thanks, Pete.
I applied the patch, it can mount the root now. Such a delicate patch.

Have you made the HPT371N working for 2.6 tree?  When I want to
compile in the hpt366.c, the kernel will hang up right after it found
the disk drive:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT371: IDE controller at PCI slot 0000:00:0b.0
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
HPT371: chipset revision 2
HPT37X: using 33MHz PCI clock
HPT371: 100% native mode on irq 5
   ide2: BM-DMA at 0x1000-0x1007, BIOS settings: hde:pio, hdf:pio
   ide3: BM-DMA at 0x1008-0x100f, BIOS settings: hdg:pio, hdh:pio
hdg: IBM-DTTA-350840, ATA DISK drive

hang up ................ :(


On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> 
> <snip>
> 
> The problem below is caused by a .mips3 directive in xchg_u32. I talked
> to Ralf and Maciel about the problem; Ralf sent a patch but I don't see
> it applied in the tree yet.  Try this:
> 
> Index: include/asm-mips/system.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips/system.h,v
> retrieving revision 1.85
> diff -u -r1.85 system.h
> --- include/asm-mips/system.h   23 Jun 2005 15:57:18 -0000      1.85
> +++ include/asm-mips/system.h   29 Jun 2005 12:01:54 -0000
> @@ -178,7 +178,9 @@
>                __asm__ __volatile__(
>                "       .set    mips3                                   \n"
>                "1:     ll      %0, %3                  #
> xchg_u32      \n"
> +               "       .set    mips0                                   \n"
>                "       move    %2, %
> z4                                 \n"
> +               "       .set    mips3                                   \n"
>                "       sc      %2, %
> 1                                  \n"
>                "       beqzl   %2,
> 1b                                  \n"
>                ROT_IN_PIECES
> @@ -195,7 +197,9 @@
>                __asm__ __volatile__(
>                "       .set    mips3                                   \n"
>                "1:     ll      %0, %3                  #
> xchg_u32      \n"
> +               "       .set    mips0                                   \n"
>                "       move    %2, %
> z4                                 \n"
> +               "       .set    mips3                                   \n"
>                "       sc      %2, %
> 1                                  \n"
>                "       beqz    %2,
> 1b                                  \n"
>  #ifdef CONFIG_SMP
> 
> 
> 
> Pete
> 
> > eth1: link up
> > ., OK
> > IP-Config: Got DHCP answer from 255.255.255.255, my address is 10.200.1.54
> > IP-Config: Complete:
> >       device=eth0, addr=10.200.1.54, mask=255.255.0.0, gw=10.200.0.1,
> >      host=10.200.1.54, domain=sel, nis-domain=(none),
> >      bootserver=255.255.255.255, rootserver=10.200.0.198, rootpath=
> > Looking up port of RPC 100003/2 on 10.200.0.198
> > Reserved instruction in kernel code in
> > arch/mips/kernel/traps.c::do_ri, line 706[#1]:
> > Cpu 0
> > $ 0   : 00000000 1000fc00 00010000 00000000
> > $ 4   : 812b8e40 00000093 00000000 811df97c
> > $ 8   : 00000040 812b9e40 00000000 812a4e10
> > $12   : 0000ffff 00200200 00100100 812a3ef4
> > $16   : 812b8e40 00000000 812b8e40 00000060
> > $20   : 8042a6e0 00010000 811df90c 80144b20
> > $24   : 00000000 00000001
> > $28   : 811de000 811df8f0 8042a6e0 802facd0
> > Hi    : 00000000
> > Lo    : 00000780
> > epc   : 802ca258 sock_alloc_send_skb+0x74/0x5c8     Not tainted
> > ra    : 802facd0 ip_append_data+0x7c8/0xa34
> > Status: 1000fc03    KERNEL EXL IE
> > Cause : 00800028
> > PrId  : 03030200
> > Modules linked in:
> > Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> > Stack : c600c80a 3601c80a 00000000 00000000 00000000 00000000 00000000 00000000
> >         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> >         00000074 00000000 812b8e40 00000060 812b8e40 812b9e40 00000060 00000008
> >         812b8e98 802facd0 00000000 00000093 00000000 811df97c 00000000 00000000
> >         00000000 00000000 812b9e40 00000000 00000010 00000000 000005dc 00000000
> >         ...
> > Call Trace:
> >  [<802facd0>] ip_append_data+0x7c8/0xa34
> >  [<8031e3c4>] udp_sendmsg+0x224/0xa08
> >  [<802fa44c>] ip_generic_getfrag+0x0/0xbc
> >  [<802c6558>] sock_sendmsg+0xac/0xf0
> >  [<80334890>] fn_hash_lookup+0x100/0x150
> >  [<80334890>] fn_hash_lookup+0x100/0x150
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<802c65c0>] kernel_sendmsg+0x24/0x38
> >  [<80362f48>] xdr_sendpages+0x1dc/0x29c
> >  [<80355284>] xprt_transmit+0xec/0x5f4
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<803529c4>] call_transmit+0x1f4/0x2d4
> >  [<80356674>] rpc_delete_timer+0xdc/0x108
> >  [<80357cb4>] __rpc_execute+0xa8/0x54c
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<8035976c>] rpcauth_bindcred+0xac/0x248
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80351d28>] rpc_call_sync+0x8c/0xd8
> >  [<80351d14>] rpc_call_sync+0x78/0xd8
> >  [<80361fdc>] pmap_create+0x74/0xc0
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<803622e8>] rpc_getport_external+0x11c/0x180
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<8041b854>] root_nfs_getport+0x8c/0xa8
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80254000>] snprintf+0x14/0x20
> >  [<8041bb94>] nfs_root_data+0x324/0x3a8
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80128f24>] printk+0x1c/0x28
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<8013e444>] flush_workqueue+0x28/0x34
> >  [<80197f58>] path_lookup+0xe0/0x3d0
> >  [<80194c78>] getname+0x28/0xf8
> >  [<80198644>] __user_walk+0x78/0x94
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80409cb0>] mount_root+0xac/0x1c4
> >  [<80144b20>] autoremove_wake_function+0x0/0x44
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80420000>] init_mtdchar+0x20/0x60
> >  [<80409e10>] prepare_namespace+0x48/0x148
> >  [<8013e444>] flush_workqueue+0x28/0x34
> >  [<8010065c>] init+0x200/0x264
> >  [<80100574>] init+0x118/0x264
> >  [<80105e20>] kernel_thread_helper+0x10/0x18
> >  [<80105e10>] kernel_thread_helper+0x0/0x18
> >
> >
> > Code: 10400091  0280f021  c20300a0 <0000102d> e20200a0  1040fffc
> > 00000000  00032823  14a0009f
> > Kernel panic - not syncing: Attempted to kill init!
> >
> >
> >
> >
> > Also, I tried to run 2.4.31 on db1550, but got no luck to get the hard
> > drive working, which also crashes during the probing process:
> > probing for hda: present=0, media=32, probetype=ATA
> > probing for hda: present=0, media=32, probetype=ATAPI
> > probing for hdb: present=0, media=32, probetype=ATA
> > probing for hdb: present=0, media=32, probetype=ATAPI
> > probing for hdc: present=0, media=32, probetype=ATA
> > probing for hdc: present=0, media=32, probetype=ATAPI
> > probing for hdd: present=0, media=32, probetype=ATA
> > probing for hdd: present=0, media=32, probetype=ATAPI
> > probing for hde: present=0, media=32, probetype=ATA
> > probing for hde: present=0, media=32, probetype=ATAPI
> > probing for hdf: present=0, media=32, probetype=ATA
> > probing for hdf: present=0, media=32, probetype=ATAPI
> > probing for hdg: present=0, media=32, probetype=ATA
> > hdg: IBM-DTTA-350840, ATA DISK drive
> > probing for hdh: present=0, media=32, probetype=ATA
> > probing for hdh: present=0, media=32, probetype=ATAPI
> > Unable to handle kernel paging request at virtual address 00000000,
> > epc == 801e77f0, ra == 801e7b48
> > Oops in fault.c::do_page_fault, line 206:
> >
> 
>

From ppopov@embeddedalley.com Fri Jul  1 23:44:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 23:44:35 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:41869
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226180AbVGAWoP>; Fri, 1 Jul 2005 23:44:15 +0100
Received: (qmail 78788 invoked from network); 1 Jul 2005 22:44:07 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 1 Jul 2005 22:44:07 -0000
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b72050701153566c83bb6@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 01 Jul 2005 15:44:11 -0700
Message-Id: <1120257851.5987.37.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8324
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: 8639
Lines: 200

On Fri, 2005-07-01 at 15:35 -0700, rolf liu wrote:
> thanks, Pete.
> I applied the patch, it can mount the root now. Such a delicate patch.
> 
> Have you made the HPT371N working for 2.6 tree? 

One and off, yes. There was a timing issue I remember ... I had a 2.4
patch in my oss directory that worked fine for 2.4. I don't remember if
the same patch worked ok in 2.6. I didn't have much time to debug it,
but I remember when I put a few debug prints in the hpt init routine,
the problem went away, indicating an initialization timing issue.

Pete

>  When I want to
> compile in the hpt366.c, the kernel will hang up right after it found
> the disk drive:
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> HPT371: IDE controller at PCI slot 0000:00:0b.0
> PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> HPT371: chipset revision 2
> HPT37X: using 33MHz PCI clock
> HPT371: 100% native mode on irq 5
>    ide2: BM-DMA at 0x1000-0x1007, BIOS settings: hde:pio, hdf:pio
>    ide3: BM-DMA at 0x1008-0x100f, BIOS settings: hdg:pio, hdh:pio
> hdg: IBM-DTTA-350840, ATA DISK drive
> 
> hang up ................ :(
> 
> 
> On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > 
> > <snip>
> > 
> > The problem below is caused by a .mips3 directive in xchg_u32. I talked
> > to Ralf and Maciel about the problem; Ralf sent a patch but I don't see
> > it applied in the tree yet.  Try this:
> > 
> > Index: include/asm-mips/system.h
> > ===================================================================
> > RCS file: /home/cvs/linux/include/asm-mips/system.h,v
> > retrieving revision 1.85
> > diff -u -r1.85 system.h
> > --- include/asm-mips/system.h   23 Jun 2005 15:57:18 -0000      1.85
> > +++ include/asm-mips/system.h   29 Jun 2005 12:01:54 -0000
> > @@ -178,7 +178,9 @@
> >                __asm__ __volatile__(
> >                "       .set    mips3                                   \n"
> >                "1:     ll      %0, %3                  #
> > xchg_u32      \n"
> > +               "       .set    mips0                                   \n"
> >                "       move    %2, %
> > z4                                 \n"
> > +               "       .set    mips3                                   \n"
> >                "       sc      %2, %
> > 1                                  \n"
> >                "       beqzl   %2,
> > 1b                                  \n"
> >                ROT_IN_PIECES
> > @@ -195,7 +197,9 @@
> >                __asm__ __volatile__(
> >                "       .set    mips3                                   \n"
> >                "1:     ll      %0, %3                  #
> > xchg_u32      \n"
> > +               "       .set    mips0                                   \n"
> >                "       move    %2, %
> > z4                                 \n"
> > +               "       .set    mips3                                   \n"
> >                "       sc      %2, %
> > 1                                  \n"
> >                "       beqz    %2,
> > 1b                                  \n"
> >  #ifdef CONFIG_SMP
> > 
> > 
> > 
> > Pete
> > 
> > > eth1: link up
> > > ., OK
> > > IP-Config: Got DHCP answer from 255.255.255.255, my address is 10.200.1.54
> > > IP-Config: Complete:
> > >       device=eth0, addr=10.200.1.54, mask=255.255.0.0, gw=10.200.0.1,
> > >      host=10.200.1.54, domain=sel, nis-domain=(none),
> > >      bootserver=255.255.255.255, rootserver=10.200.0.198, rootpath=
> > > Looking up port of RPC 100003/2 on 10.200.0.198
> > > Reserved instruction in kernel code in
> > > arch/mips/kernel/traps.c::do_ri, line 706[#1]:
> > > Cpu 0
> > > $ 0   : 00000000 1000fc00 00010000 00000000
> > > $ 4   : 812b8e40 00000093 00000000 811df97c
> > > $ 8   : 00000040 812b9e40 00000000 812a4e10
> > > $12   : 0000ffff 00200200 00100100 812a3ef4
> > > $16   : 812b8e40 00000000 812b8e40 00000060
> > > $20   : 8042a6e0 00010000 811df90c 80144b20
> > > $24   : 00000000 00000001
> > > $28   : 811de000 811df8f0 8042a6e0 802facd0
> > > Hi    : 00000000
> > > Lo    : 00000780
> > > epc   : 802ca258 sock_alloc_send_skb+0x74/0x5c8     Not tainted
> > > ra    : 802facd0 ip_append_data+0x7c8/0xa34
> > > Status: 1000fc03    KERNEL EXL IE
> > > Cause : 00800028
> > > PrId  : 03030200
> > > Modules linked in:
> > > Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> > > Stack : c600c80a 3601c80a 00000000 00000000 00000000 00000000 00000000 00000000
> > >         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > >         00000074 00000000 812b8e40 00000060 812b8e40 812b9e40 00000060 00000008
> > >         812b8e98 802facd0 00000000 00000093 00000000 811df97c 00000000 00000000
> > >         00000000 00000000 812b9e40 00000000 00000010 00000000 000005dc 00000000
> > >         ...
> > > Call Trace:
> > >  [<802facd0>] ip_append_data+0x7c8/0xa34
> > >  [<8031e3c4>] udp_sendmsg+0x224/0xa08
> > >  [<802fa44c>] ip_generic_getfrag+0x0/0xbc
> > >  [<802c6558>] sock_sendmsg+0xac/0xf0
> > >  [<80334890>] fn_hash_lookup+0x100/0x150
> > >  [<80334890>] fn_hash_lookup+0x100/0x150
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<802c65c0>] kernel_sendmsg+0x24/0x38
> > >  [<80362f48>] xdr_sendpages+0x1dc/0x29c
> > >  [<80355284>] xprt_transmit+0xec/0x5f4
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<803529c4>] call_transmit+0x1f4/0x2d4
> > >  [<80356674>] rpc_delete_timer+0xdc/0x108
> > >  [<80357cb4>] __rpc_execute+0xa8/0x54c
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<8035976c>] rpcauth_bindcred+0xac/0x248
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80351d28>] rpc_call_sync+0x8c/0xd8
> > >  [<80351d14>] rpc_call_sync+0x78/0xd8
> > >  [<80361fdc>] pmap_create+0x74/0xc0
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<803622e8>] rpc_getport_external+0x11c/0x180
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<8041b854>] root_nfs_getport+0x8c/0xa8
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80254000>] snprintf+0x14/0x20
> > >  [<8041bb94>] nfs_root_data+0x324/0x3a8
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80128f24>] printk+0x1c/0x28
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<8013e444>] flush_workqueue+0x28/0x34
> > >  [<80197f58>] path_lookup+0xe0/0x3d0
> > >  [<80194c78>] getname+0x28/0xf8
> > >  [<80198644>] __user_walk+0x78/0x94
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80409cb0>] mount_root+0xac/0x1c4
> > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80420000>] init_mtdchar+0x20/0x60
> > >  [<80409e10>] prepare_namespace+0x48/0x148
> > >  [<8013e444>] flush_workqueue+0x28/0x34
> > >  [<8010065c>] init+0x200/0x264
> > >  [<80100574>] init+0x118/0x264
> > >  [<80105e20>] kernel_thread_helper+0x10/0x18
> > >  [<80105e10>] kernel_thread_helper+0x0/0x18
> > >
> > >
> > > Code: 10400091  0280f021  c20300a0 <0000102d> e20200a0  1040fffc
> > > 00000000  00032823  14a0009f
> > > Kernel panic - not syncing: Attempted to kill init!
> > >
> > >
> > >
> > >
> > > Also, I tried to run 2.4.31 on db1550, but got no luck to get the hard
> > > drive working, which also crashes during the probing process:
> > > probing for hda: present=0, media=32, probetype=ATA
> > > probing for hda: present=0, media=32, probetype=ATAPI
> > > probing for hdb: present=0, media=32, probetype=ATA
> > > probing for hdb: present=0, media=32, probetype=ATAPI
> > > probing for hdc: present=0, media=32, probetype=ATA
> > > probing for hdc: present=0, media=32, probetype=ATAPI
> > > probing for hdd: present=0, media=32, probetype=ATA
> > > probing for hdd: present=0, media=32, probetype=ATAPI
> > > probing for hde: present=0, media=32, probetype=ATA
> > > probing for hde: present=0, media=32, probetype=ATAPI
> > > probing for hdf: present=0, media=32, probetype=ATA
> > > probing for hdf: present=0, media=32, probetype=ATAPI
> > > probing for hdg: present=0, media=32, probetype=ATA
> > > hdg: IBM-DTTA-350840, ATA DISK drive
> > > probing for hdh: present=0, media=32, probetype=ATA
> > > probing for hdh: present=0, media=32, probetype=ATAPI
> > > Unable to handle kernel paging request at virtual address 00000000,
> > > epc == 801e77f0, ra == 801e7b48
> > > Oops in fault.c::do_page_fault, line 206:
> > >
> > 
> >
> 


From rolfliu@gmail.com Fri Jul  1 23:52:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Jul 2005 23:53:08 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.195]:28685 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226180AbVGAWws> convert rfc822-to-8bit;
	Fri, 1 Jul 2005 23:52:48 +0100
Received: by wproxy.gmail.com with SMTP id 70so445242wra
        for <linux-mips@linux-mips.org>; Fri, 01 Jul 2005 15:52:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hK2ZVLiUwJ+sJxGMd8GQgrwlnXuZFHoPdSu++A5Uw1zZ6mgobJ+iY3s0gH4AUF1ihytNj+nBQzKdv5co32MNm02+GoH30Nk22dWe6ruDt3FIZfTwgEE8wLpnd7sQVyhlINOGbswA445IqhRvN2SsrSZSWv3FkT6CMyWsvuGkT9w=
Received: by 10.54.101.2 with SMTP id y2mr2031027wrb;
        Fri, 01 Jul 2005 15:52:41 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 1 Jul 2005 15:52:41 -0700 (PDT)
Message-ID: <2db32b720507011552403f22c4@mail.gmail.com>
Date:	Fri, 1 Jul 2005 15:52:41 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120257851.5987.37.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8325
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 10601
Lines: 236

I used that patch to force 371 to use 372 timing to 2.4.31. but
unfortunately, the kernel crashed during the probing process. any
idea?
thanks

Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT371: IDE controller at PCI slot 00:0b.0
HPT371: chipset revision 2
HPT371: not 100% native mode: will probe irqs later
hpt: HPT372N detected, using 372N timing.
FREQ: 73 PLL: 35
hpt: no known IDE timings, disabling DMA.
hpt: no known IDE timings, disabling DMA.
probing for hda: present=0, media=32, probetype=ATA
probing for hda: present=0, media=32, probetype=ATAPI
probing for hdb: present=0, media=32, probetype=ATA
probing for hdb: present=0, media=32, probetype=ATAPI
probing for hdc: present=0, media=32, probetype=ATA
probing for hdc: present=0, media=32, probetype=ATAPI
probing for hdd: present=0, media=32, probetype=ATA
probing for hdd: present=0, media=32, probetype=ATAPI
probing for hde: present=0, media=32, probetype=ATA
probing for hde: present=0, media=32, probetype=ATAPI
probing for hdf: present=0, media=32, probetype=ATA
probing for hdf: present=0, media=32, probetype=ATAPI
probing for hdg: present=0, media=32, probetype=ATA
hdg: IBM-DTTA-350840, ATA DISK drive
probing for hdh: present=0, media=32, probetype=ATA
probing for hdh: present=0, media=32, probetype=ATAPI
Unable to handle kernel paging request at virtual address 00000000,
epc == 801e77f0, ra == 801e7b48
Oops in fault.c::do_page_fault, line 206:

On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Fri, 2005-07-01 at 15:35 -0700, rolf liu wrote:
> > thanks, Pete.
> > I applied the patch, it can mount the root now. Such a delicate patch.
> >
> > Have you made the HPT371N working for 2.6 tree?
> 
> One and off, yes. There was a timing issue I remember ... I had a 2.4
> patch in my oss directory that worked fine for 2.4. I don't remember if
> the same patch worked ok in 2.6. I didn't have much time to debug it,
> but I remember when I put a few debug prints in the hpt init routine,
> the problem went away, indicating an initialization timing issue.
> 
> Pete
> 
> >  When I want to
> > compile in the hpt366.c, the kernel will hang up right after it found
> > the disk drive:
> >
> > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > HPT371: IDE controller at PCI slot 0000:00:0b.0
> > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> > HPT371: chipset revision 2
> > HPT37X: using 33MHz PCI clock
> > HPT371: 100% native mode on irq 5
> >    ide2: BM-DMA at 0x1000-0x1007, BIOS settings: hde:pio, hdf:pio
> >    ide3: BM-DMA at 0x1008-0x100f, BIOS settings: hdg:pio, hdh:pio
> > hdg: IBM-DTTA-350840, ATA DISK drive
> >
> > hang up ................ :(
> >
> >
> > On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > >
> > > <snip>
> > >
> > > The problem below is caused by a .mips3 directive in xchg_u32. I talked
> > > to Ralf and Maciel about the problem; Ralf sent a patch but I don't see
> > > it applied in the tree yet.  Try this:
> > >
> > > Index: include/asm-mips/system.h
> > > ===================================================================
> > > RCS file: /home/cvs/linux/include/asm-mips/system.h,v
> > > retrieving revision 1.85
> > > diff -u -r1.85 system.h
> > > --- include/asm-mips/system.h   23 Jun 2005 15:57:18 -0000      1.85
> > > +++ include/asm-mips/system.h   29 Jun 2005 12:01:54 -0000
> > > @@ -178,7 +178,9 @@
> > >                __asm__ __volatile__(
> > >                "       .set    mips3                                   \n"
> > >                "1:     ll      %0, %3                  #
> > > xchg_u32      \n"
> > > +               "       .set    mips0                                   \n"
> > >                "       move    %2, %
> > > z4                                 \n"
> > > +               "       .set    mips3                                   \n"
> > >                "       sc      %2, %
> > > 1                                  \n"
> > >                "       beqzl   %2,
> > > 1b                                  \n"
> > >                ROT_IN_PIECES
> > > @@ -195,7 +197,9 @@
> > >                __asm__ __volatile__(
> > >                "       .set    mips3                                   \n"
> > >                "1:     ll      %0, %3                  #
> > > xchg_u32      \n"
> > > +               "       .set    mips0                                   \n"
> > >                "       move    %2, %
> > > z4                                 \n"
> > > +               "       .set    mips3                                   \n"
> > >                "       sc      %2, %
> > > 1                                  \n"
> > >                "       beqz    %2,
> > > 1b                                  \n"
> > >  #ifdef CONFIG_SMP
> > >
> > >
> > >
> > > Pete
> > >
> > > > eth1: link up
> > > > ., OK
> > > > IP-Config: Got DHCP answer from 255.255.255.255, my address is 10.200.1.54
> > > > IP-Config: Complete:
> > > >       device=eth0, addr=10.200.1.54, mask=255.255.0.0, gw=10.200.0.1,
> > > >      host=10.200.1.54, domain=sel, nis-domain=(none),
> > > >      bootserver=255.255.255.255, rootserver=10.200.0.198, rootpath=
> > > > Looking up port of RPC 100003/2 on 10.200.0.198
> > > > Reserved instruction in kernel code in
> > > > arch/mips/kernel/traps.c::do_ri, line 706[#1]:
> > > > Cpu 0
> > > > $ 0   : 00000000 1000fc00 00010000 00000000
> > > > $ 4   : 812b8e40 00000093 00000000 811df97c
> > > > $ 8   : 00000040 812b9e40 00000000 812a4e10
> > > > $12   : 0000ffff 00200200 00100100 812a3ef4
> > > > $16   : 812b8e40 00000000 812b8e40 00000060
> > > > $20   : 8042a6e0 00010000 811df90c 80144b20
> > > > $24   : 00000000 00000001
> > > > $28   : 811de000 811df8f0 8042a6e0 802facd0
> > > > Hi    : 00000000
> > > > Lo    : 00000780
> > > > epc   : 802ca258 sock_alloc_send_skb+0x74/0x5c8     Not tainted
> > > > ra    : 802facd0 ip_append_data+0x7c8/0xa34
> > > > Status: 1000fc03    KERNEL EXL IE
> > > > Cause : 00800028
> > > > PrId  : 03030200
> > > > Modules linked in:
> > > > Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> > > > Stack : c600c80a 3601c80a 00000000 00000000 00000000 00000000 00000000 00000000
> > > >         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > >         00000074 00000000 812b8e40 00000060 812b8e40 812b9e40 00000060 00000008
> > > >         812b8e98 802facd0 00000000 00000093 00000000 811df97c 00000000 00000000
> > > >         00000000 00000000 812b9e40 00000000 00000010 00000000 000005dc 00000000
> > > >         ...
> > > > Call Trace:
> > > >  [<802facd0>] ip_append_data+0x7c8/0xa34
> > > >  [<8031e3c4>] udp_sendmsg+0x224/0xa08
> > > >  [<802fa44c>] ip_generic_getfrag+0x0/0xbc
> > > >  [<802c6558>] sock_sendmsg+0xac/0xf0
> > > >  [<80334890>] fn_hash_lookup+0x100/0x150
> > > >  [<80334890>] fn_hash_lookup+0x100/0x150
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<802c65c0>] kernel_sendmsg+0x24/0x38
> > > >  [<80362f48>] xdr_sendpages+0x1dc/0x29c
> > > >  [<80355284>] xprt_transmit+0xec/0x5f4
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<803529c4>] call_transmit+0x1f4/0x2d4
> > > >  [<80356674>] rpc_delete_timer+0xdc/0x108
> > > >  [<80357cb4>] __rpc_execute+0xa8/0x54c
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<8035976c>] rpcauth_bindcred+0xac/0x248
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80351d28>] rpc_call_sync+0x8c/0xd8
> > > >  [<80351d14>] rpc_call_sync+0x78/0xd8
> > > >  [<80361fdc>] pmap_create+0x74/0xc0
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<803622e8>] rpc_getport_external+0x11c/0x180
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<8041b854>] root_nfs_getport+0x8c/0xa8
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80254000>] snprintf+0x14/0x20
> > > >  [<8041bb94>] nfs_root_data+0x324/0x3a8
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80128f24>] printk+0x1c/0x28
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<8013e444>] flush_workqueue+0x28/0x34
> > > >  [<80197f58>] path_lookup+0xe0/0x3d0
> > > >  [<80194c78>] getname+0x28/0xf8
> > > >  [<80198644>] __user_walk+0x78/0x94
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80409cb0>] mount_root+0xac/0x1c4
> > > >  [<80144b20>] autoremove_wake_function+0x0/0x44
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80420000>] init_mtdchar+0x20/0x60
> > > >  [<80409e10>] prepare_namespace+0x48/0x148
> > > >  [<8013e444>] flush_workqueue+0x28/0x34
> > > >  [<8010065c>] init+0x200/0x264
> > > >  [<80100574>] init+0x118/0x264
> > > >  [<80105e20>] kernel_thread_helper+0x10/0x18
> > > >  [<80105e10>] kernel_thread_helper+0x0/0x18
> > > >
> > > >
> > > > Code: 10400091  0280f021  c20300a0 <0000102d> e20200a0  1040fffc
> > > > 00000000  00032823  14a0009f
> > > > Kernel panic - not syncing: Attempted to kill init!
> > > >
> > > >
> > > >
> > > >
> > > > Also, I tried to run 2.4.31 on db1550, but got no luck to get the hard
> > > > drive working, which also crashes during the probing process:
> > > > probing for hda: present=0, media=32, probetype=ATA
> > > > probing for hda: present=0, media=32, probetype=ATAPI
> > > > probing for hdb: present=0, media=32, probetype=ATA
> > > > probing for hdb: present=0, media=32, probetype=ATAPI
> > > > probing for hdc: present=0, media=32, probetype=ATA
> > > > probing for hdc: present=0, media=32, probetype=ATAPI
> > > > probing for hdd: present=0, media=32, probetype=ATA
> > > > probing for hdd: present=0, media=32, probetype=ATAPI
> > > > probing for hde: present=0, media=32, probetype=ATA
> > > > probing for hde: present=0, media=32, probetype=ATAPI
> > > > probing for hdf: present=0, media=32, probetype=ATA
> > > > probing for hdf: present=0, media=32, probetype=ATAPI
> > > > probing for hdg: present=0, media=32, probetype=ATA
> > > > hdg: IBM-DTTA-350840, ATA DISK drive
> > > > probing for hdh: present=0, media=32, probetype=ATA
> > > > probing for hdh: present=0, media=32, probetype=ATAPI
> > > > Unable to handle kernel paging request at virtual address 00000000,
> > > > epc == 801e77f0, ra == 801e7b48
> > > > Oops in fault.c::do_page_fault, line 206:
> > > >
> > >
> > >
> >
> 
>

From wd@denx.de Sat Jul  2 00:02:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 00:02:29 +0100 (BST)
Received: from mailout06.sul.t-online.com ([IPv6:::ffff:194.25.134.19]:43958
	"EHLO mailout06.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8226180AbVGAXCN>; Sat, 2 Jul 2005 00:02:13 +0100
Received: from fwd35.aul.t-online.de 
	by mailout06.sul.t-online.com with smtp 
	id 1DoUWL-00009d-00; Sat, 02 Jul 2005 01:02:05 +0200
Received: from denx.de (VO5RE8ZSZezD9EyDSqFanWjsog4OOVsfaKX-aWLhfy+UrJcWjzP9Qw@[84.150.71.68]) by fwd35.sul.t-online.de
	with esmtp id 1DoUWA-22Pp0S0; Sat, 2 Jul 2005 01:01:54 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 454AC42D8D; Sat,  2 Jul 2005 01:01:52 +0200 (MEST)
Received: from atlas.denx.de (localhost.localdomain [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP id D09EC353A36;
	Sat,  2 Jul 2005 01:00:56 +0200 (MEST)
To:	rolf liu <rolfliu@gmail.com>
Cc:	linux-mips@linux-mips.org
From:	Wolfgang Denk <wd@denx.de>
Subject: Re: glibc based toolchain for mips 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Thu, 30 Jun 2005 15:58:46 PDT."
             <2db32b72050630155831582cd7@mail.gmail.com> 
Date:	Sat, 02 Jul 2005 01:00:56 +0200
Message-Id: <20050701230056.D09EC353A36@atlas.denx.de>
X-ID:	VO5RE8ZSZezD9EyDSqFanWjsog4OOVsfaKX-aWLhfy+UrJcWjzP9Qw@t-dialin.net
X-TOI-MSGID: d0c3744e-dc61-441e-9b9e-74a8ea5ec7ea
Return-Path: <wd@denx.de>
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: 8326
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: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1133
Lines: 29

In message <2db32b72050630155831582cd7@mail.gmail.com> you wrote:
> 
> I download the package. after installation,  the 4KCle is still
> linking to the mips-linux-, which is big-endian.

Please explain exactly what you did.

We have kernel, all libraries and apps running in  this  environment,
and if I check it looks very much like little endinan, for example:

$ file /opt/eldk/mips_4KCle/bin/bash
/opt/eldk/3.1.1/mips_4KCle/bin/bash: ELF 32-bit LSB executable, MIPS, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped

versus

$ file /opt/eldk/mips_4KC/bin/bash
 /opt/eldk/3.1.1/mips_4KC/bin/bash: ELF 32-bit MSB executable, MIPS, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
CONSUMER NOTICE:  Because  of  the  "Uncertainty  Principle,"  It  Is
Impossible  for  the  Consumer  to  Find  Out  at  the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.

From rolfliu@gmail.com Sat Jul  2 00:09:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 00:09:49 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.201]:65011 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226180AbVGAXJd> convert rfc822-to-8bit;
	Sat, 2 Jul 2005 00:09:33 +0100
Received: by wproxy.gmail.com with SMTP id 70so446920wra
        for <linux-mips@linux-mips.org>; Fri, 01 Jul 2005 16:09:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=F+opu++hZWxsj9cnBbBb+ZAVbAdDnyJhWoQUlVpgDnglp/HtGx6YUYqYl0vhv3Vq+zDB47u9R61Le5hu+jYVTlTWuCaeTBQhBhxB/3QzLMGiYjT4mJWvgNerb5/JOLXsNjHyutYFvLdciM2rjus2fDOasOWll2mIHBWVF5lbfrw=
Received: by 10.54.51.8 with SMTP id y8mr2035620wry;
        Fri, 01 Jul 2005 16:09:27 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 1 Jul 2005 16:09:26 -0700 (PDT)
Message-ID: <2db32b7205070116091240fcf4@mail.gmail.com>
Date:	Fri, 1 Jul 2005 16:09:26 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Wolfgang Denk <wd@denx.de>
Subject: Re: glibc based toolchain for mips
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050701230056.D09EC353A36@atlas.denx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b72050630155831582cd7@mail.gmail.com>
	 <20050701230056.D09EC353A36@atlas.denx.de>
Return-Path: <rolfliu@gmail.com>
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: 8327
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1492
Lines: 42

Sorry I didn't say it clearly.

The files in /opt/eldk/mips_4KCle are in little endian mips, for sure. 
What I want is a cross-development tools for i386-to-mipsel, including
the corss gcc, binutils, other libs. I couldn't find such tools :(

thanks



On 7/1/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <2db32b72050630155831582cd7@mail.gmail.com> you wrote:
> >
> > I download the package. after installation,  the 4KCle is still
> > linking to the mips-linux-, which is big-endian.
> 
> Please explain exactly what you did.
> 
> We have kernel, all libraries and apps running in  this  environment,
> and if I check it looks very much like little endinan, for example:
> 
> $ file /opt/eldk/mips_4KCle/bin/bash
> /opt/eldk/3.1.1/mips_4KCle/bin/bash: ELF 32-bit LSB executable, MIPS, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
> 
> versus
> 
> $ file /opt/eldk/mips_4KC/bin/bash
>  /opt/eldk/3.1.1/mips_4KC/bin/bash: ELF 32-bit MSB executable, MIPS, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> CONSUMER NOTICE:  Because  of  the  "Uncertainty  Principle,"  It  Is
> Impossible  for  the  Consumer  to  Find  Out  at  the Same Time Both
> Precisely Where This Product Is and How Fast It Is Moving.
> 
>

From rolfliu@gmail.com Sat Jul  2 01:56:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 01:56:59 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.207]:58358 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226180AbVGBA4k> convert rfc822-to-8bit;
	Sat, 2 Jul 2005 01:56:40 +0100
Received: by wproxy.gmail.com with SMTP id 70so455861wra
        for <linux-mips@linux-mips.org>; Fri, 01 Jul 2005 17:56:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=B0N2GBjnEg0XtYEP8PrBOk5VtMikHzBPnKw4HoQWc97h14O4gK6MRYQuGfGe+u+UxOjS84scOpyIQRWaSF2qMGH3Xp6vZFqcrmPNkzFOnFYJ06nwMuVJtX8UArk+e9bz4lucuKq6DVxQXWx4tia7o/lrZ6Yg5StLjgPWxEPQj3Y=
Received: by 10.54.101.2 with SMTP id y2mr2093100wrb;
        Fri, 01 Jul 2005 17:56:29 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 1 Jul 2005 17:56:29 -0700 (PDT)
Message-ID: <2db32b720507011756247735d6@mail.gmail.com>
Date:	Fri, 1 Jul 2005 17:56:29 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: possible serial driver fixup for au1x00 in 2.6?
Cc:	rolfliu@gmail.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8328
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 179
Lines: 5

Basically, au1x00_uart.c is doing the same thing as 8250.c. If I want
to add extra serial port support by 8250.c. There could be some
problem. Any idea?

Correct me if I am wrong

From ppopov@embeddedalley.com Sat Jul  2 02:06:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 02:06:41 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:14683
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226180AbVGBBGZ>; Sat, 2 Jul 2005 02:06:25 +0100
Received: (qmail 23007 invoked from network); 2 Jul 2005 01:06:19 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 2 Jul 2005 01:06:18 -0000
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b720507011756247735d6@mail.gmail.com>
References: <2db32b720507011756247735d6@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Fri, 01 Jul 2005 18:06:23 -0700
Message-Id: <1120266383.5987.46.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8329
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: 324
Lines: 14

On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> Basically, au1x00_uart.c is doing the same thing as 8250.c. 

Basically.

> If I want
> to add extra serial port support by 8250.c. There could be some
> problem. Any idea?

Don't know, haven't tried it. In general, the au1x00 serial driver needs
to be rewritten.

Pete


From ajaysingh@ti.com Sat Jul  2 09:41:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 09:41:26 +0100 (BST)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:6793 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8226202AbVGBIlB> convert rfc822-to-8bit;
	Sat, 2 Jul 2005 09:41:01 +0100
Received: from dlep31.itg.ti.com ([157.170.139.161])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j628eqYT017585;
	Sat, 2 Jul 2005 03:40:52 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep31.itg.ti.com (8.12.11/8.12.11) with ESMTP id j628ep54020885;
	Sat, 2 Jul 2005 03:40:51 -0500 (CDT)
Received: from dbde01.ent.ti.com (localhost [127.0.0.1])
	by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j628enhB006633;
	Sat, 2 Jul 2005 03:40:50 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: I built a mipsel-linux toolchain, but it doesn't work
Date:	Sat, 2 Jul 2005 14:10:48 +0530
Message-ID: <A8A67F242940E246A515077CF9ECACC157F3F6@dbde01.ent.ti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I built a mipsel-linux toolchain, but it doesn't work
Thread-Index: AcV+ViWjSXBS2K9XQPWdR9qPsq6FCwAi2j7w
From:	"Singh, Ajay" <ajaysingh@ti.com>
To:	<sjhill@realitydiluted.com>, "David Daney" <ddaney@avtrex.com>
Cc:	"moreau francis" <francis_moreau2000@yahoo.fr>,
	"zhan rongkai" <zhanrk@gmail.com>, <linux-mips@linux-mips.org>
Return-Path: <ajaysingh@ti.com>
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: 8330
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: ajaysingh@ti.com
Precedence: bulk
X-list: linux-mips
Content-Length: 987
Lines: 33

We are using uClibc-0.9.27 for MIPS target. Can you point out the issues
with uClibc-0.9.27 ??

~Ajay.

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of
sjhill@realitydiluted.com
Sent: Friday, July 01, 2005 8:30 PM
To: David Daney
Cc: moreau francis; zhan rongkai; linux-mips@linux-mips.org
Subject: Re: I built a mipsel-linux toolchain, but it doesn't work

> moreau francis wrote:
> > Could you develop please ? What kind of config/hack does Buildroot 
> > to be able to use GCC with uClibc ?
> > 
> 
> It is quite complicated, but you can find a summary on this web page:
> 
> http://www.google.com/search?q=uclibc+buildroot
> 
Here is the page for it:

   http://buildroot.uclibc.org/

The mipsel target is supported and will build for your needs. Do not use
uClibc-0.9.27 when you configure your buildroot system. Use the latest
uClibc snapshot. There are issues with uClibc-0.9.27 with MIPS targets.

-Steve


From wd@denx.de Sat Jul  2 16:41:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 16:41:31 +0100 (BST)
Received: from mailout03.sul.t-online.com ([IPv6:::ffff:194.25.134.81]:53900
	"EHLO mailout03.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8226095AbVGBPlP>; Sat, 2 Jul 2005 16:41:15 +0100
Received: from fwd23.aul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 1Dok7E-0000Ie-03; Sat, 02 Jul 2005 17:41:12 +0200
Received: from denx.de (VmKhU8ZdoehGzbfi5dIs+YOgFa6QQN-SE7Edrfjyk0P42GPJCXQEZJ@[84.150.110.36]) by fwd23.sul.t-online.de
	with esmtp id 1Dok6x-0wDy3U0; Sat, 2 Jul 2005 17:40:55 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id 5EE49428A7; Sat,  2 Jul 2005 17:40:54 +0200 (MEST)
Received: from atlas.denx.de (localhost.localdomain [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP id A2728353A36;
	Sat,  2 Jul 2005 17:39:45 +0200 (MEST)
To:	rolf liu <rolfliu@gmail.com>
Cc:	linux-mips@linux-mips.org
From:	Wolfgang Denk <wd@denx.de>
Subject: Re: glibc based toolchain for mips 
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Fri, 01 Jul 2005 16:09:26 PDT."
             <2db32b7205070116091240fcf4@mail.gmail.com> 
Date:	Sat, 02 Jul 2005 17:39:45 +0200
Message-Id: <20050702153945.A2728353A36@atlas.denx.de>
X-ID:	VmKhU8ZdoehGzbfi5dIs+YOgFa6QQN-SE7Edrfjyk0P42GPJCXQEZJ@t-dialin.net
X-TOI-MSGID: bf739ed4-0012-4d2a-8f97-a5a66c633c7c
Return-Path: <wd@denx.de>
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: 8331
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: wd@denx.de
Precedence: bulk
X-list: linux-mips
Content-Length: 838
Lines: 21

In message <2db32b7205070116091240fcf4@mail.gmail.com> you wrote:
> 
> The files in /opt/eldk/mips_4KCle are in little endian mips, for sure.=20
> What I want is a cross-development tools for i386-to-mipsel, including
> the corss gcc, binutils, other libs. I couldn't find such tools :(

Please read the documentation. You  will  find  these  tools  in  the
/opt/eldk/bin resp. /opt/eldk/usr/bin directories.

The README.html (or the DULG at http://www.denx.de/twiki/bin/view/DULG/Manual)
documents in detail what needs to be done to install and use the tools.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The sight of death frightens them [Earthers].
	-- Kras the Klingon, "Friday's Child", stardate 3497.2

From anemo@mba.ocn.ne.jp Sat Jul  2 16:54:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 16:54:33 +0100 (BST)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:6910 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8226095AbVGBPyP>; Sat, 2 Jul 2005 16:54:15 +0100
Received: from localhost (p8134-ipad01funabasi.chiba.ocn.ne.jp [61.207.82.134])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id BE32B108E; Sun,  3 Jul 2005 00:54:11 +0900 (JST)
Date:	Sun, 03 Jul 2005 00:59:21 +0900 (JST)
Message-Id: <20050703.005921.25910131.anemo@mba.ocn.ne.jp>
To:	djohnson+linuxmips@sw.starentnetworks.com
Cc:	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <17093.19241.353160.946039@cortez.sw.starentnetworks.com>
References: <17092.5345.75666.403044@cortez.sw.starentnetworks.com>
	<20050701.114358.21591461.nemoto@toshiba-tops.co.jp>
	<17093.19241.353160.946039@cortez.sw.starentnetworks.com>
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: <anemo@mba.ocn.ne.jp>
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: 8332
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: 641
Lines: 19

>>>>> On Fri, 1 Jul 2005 09:54:49 -0400, Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com> said:

dave> That'll do it.  My patch wasn't enough.  I added some sanity
dave> checks to get_wchan and it hit one while running overnight.

dave> The task being examined transitioned from !TASK_RUNNING to
dave> TASK_RUNNING while it was being examined. Doh!

dave> Definately not SMP/preempt safe as written today.

Perhaps you can make it SMP/preempt safe by doing stack_page test in
the unwinding loop as done on i386, etc.

But anyway I think just calling thread_saved_pc is enough.

Ralf, how do you think about this?

---
Atsushi Nemoto

From geert@linux-m68k.org Sat Jul  2 21:40:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Jul 2005 21:40:25 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:15767 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226105AbVGBUkH>;
	Sat, 2 Jul 2005 21:40:07 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j62Ke2pr017362;
	Sat, 2 Jul 2005 22:40:03 +0200 (MEST)
Date:	Sat, 2 Jul 2005 22:39:54 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
cc:	"'Maciej W. Rozycki'" <macro@linux-mips.org>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: top and SMP
In-Reply-To: <20050701172641Z8226172-3678+842@linux-mips.org>
Message-ID: <Pine.LNX.4.62.0507022238060.19703@numbat.sonytel.be>
References: <20050701172641Z8226172-3678+842@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8333
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 856
Lines: 22

On Fri, 1 Jul 2005, Bryan Althouse wrote:
> Looks like I am running procps version 2.0.7.  The latest is 3.2.5, so I am
> a bit out of date.  I would like to upgrade, but I am having trouble cross
> compiling the latest.  I get this error:
> 	Proc/libproc-3.2.5.so: undefined reference to '__ctype_b'

Is the version of glibc your cross-toolchain links against the same as the
version of glibc on the target?

Last time I saw that one was when trying to run `old' (i.e. dynamically linked
against an older glibc) binaries on a system with a new glibc.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From echristo@redhat.com Sun Jul  3 03:17:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Jul 2005 03:17:41 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:57220 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8226107AbVGCCRZ>;
	Sun, 3 Jul 2005 03:17:25 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j632HMua016564;
	Sat, 2 Jul 2005 22:17:22 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j632HHu21188;
	Sat, 2 Jul 2005 22:17:17 -0400
Received: from vpn26-4.sfbay.redhat.com (vpn26-4.sfbay.redhat.com [172.16.26.4])
	by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j632HEWM024711;
	Sat, 2 Jul 2005 22:17:15 -0400
Subject: Re: -march=r10000 Support for MIPS Targets (Old 3.4.x Patch;
	requires porting, assistance requested)
From:	Eric Christopher <echristo@redhat.com>
To:	Kumba <kumba@gentoo.org>
Cc:	gcc-patches@gcc.gnu.org,
	Linux MIPS List <linux-mips@linux-mips.org>
In-Reply-To: <42C4CBDF.1030609@gentoo.org>
References: <42C0D94F.3030809@gentoo.org>
	 <200506281007.12754.stevenb@suse.de>  <42C4CBDF.1030609@gentoo.org>
Content-Type: text/plain
Date:	Sat, 02 Jul 2005 19:17:13 -0700
Message-Id: <1120357033.5829.5.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@redhat.com>
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: 8334
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 411
Lines: 11

>  
> the newer define_insn_reservation.  Not really having the free time to 
> constantly rebuild gcc to test to see if numbers were placed appropriately, I've 
> looked for other means to get this patch converted.

There's at least some usefulness in getting the rest of the cpu specific
bits added and worrying about the pipeline description later. If you
want to submit those parts that'd be great.

-eric


From fabrizio@fazzino.it Sun Jul  3 11:30:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Jul 2005 11:31:15 +0100 (BST)
Received: from smtpa1.aruba.it ([IPv6:::ffff:62.149.128.206]:39657 "HELO
	smtpa1.aruba.it") by linux-mips.org with SMTP id <S8226116AbVGCKa7>;
	Sun, 3 Jul 2005 11:30:59 +0100
Received: (qmail 6786 invoked by uid 89); 3 Jul 2005 10:30:58 -0000
Received: by simscan 1.1.0 ppid: 6778, pid: 6784, t: 0.1984s
         scanners: clamav: 0.80/m:29/d:680
Received: from unknown (HELO ?192.168.32.1?) (fabrizio@fazzino.it@82.57.252.232)
  by smtp1.aruba.it with SMTP; 3 Jul 2005 10:30:57 -0000
Message-ID: <42C7BE64.7020102@fazzino.it>
Date:	Sun, 03 Jul 2005 12:31:00 +0200
From:	Fabrizio Fazzino <fabrizio@fazzino.it>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: it, it-it, en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: Assembly macro with parameters
References: <425573AD.9010702@fazzino.it> <20050407182549.GA24235@linux-mips.org> <4256B5BE.8070708@fazzino.it> <20050408165717.GA8157@nevyn.them.org> <42C429C3.2090905@fazzino.it> <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fabrizio@fazzino.it>
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: 8335
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: fabrizio@fazzino.it
Precedence: bulk
X-list: linux-mips
Content-Length: 2151
Lines: 62

Many thanks Maciej and David,
during these days I've learned a lot about stringification, a feature
that I had never used before.

In any case I didn't have to use this feature... I was just missing the
fact that the opcode evaluation didn't have to happen by declaring an
int variable (in this case the value is computed at runtime) but by the
preprocessor, so I solved my problem this way:

#define NEWOPCODE(base,rd,rs,rt) (base|(rs<<21)|(rt<<16)|(rd<<11))
#define myopcode(rd,rs,rt) asm(".long %0" : : "i" (NEWOPCODE(0xC4000000,rd,rs,rt)))

and then I call it simply as myopcode(10,8,9).

By the way, is there any quick way of writing a setreg(reg_num,reg_val)
C macro to set the value of a register?
And another one to read the value like a reg2var(reg_num,&result) to put
the value of a register inside my own C variable?
I have written my own versions for both but they have a 32-case switch
statement inside so they are not so efficient...

In any case thanks a lot for your suggestions, I've put acknowledgments
to macro@linux-mips.org inside my code!

	Fabrizio


David Daney wrote:
> 
> The arguments to the asm() statement are strings not char*.  They are evaluated at compile time not run time.
> 
> You will probably have to use the C preprocessor stringification and concatination operators ('#' and '##').
> 
> David Daney
> 

Maciej W. Rozycki wrote:
> 
>  This is untested, but it should be a reasonable starting point:
> 
> #define myopcode(rs,rt,rd) do { \
> 	int opcode_number = 0xC4000000 | (rs<<21) | (rt<<16) | (rd<<11); \
> 	asm(".word %0" : : "i" (opcode_number)); \
> } while (0)
> 
> But you may want to add code to tell GCC that these registers are used and 
> how, because otherwise you may have little use of your macro.  You'll 
> probably have to investigate the explicit register variable GCC feature 
> and cpp stringification.  It should be straightforward though rather 
> boring, so I'm leaving it as an exercise.
> 
>   Maciej
> 


-- 
============================================
    Fabrizio Fazzino - fabrizio@fazzino.it
      Fazzino.IT - http://www.fazzino.it
============================================



From mad@automagically.de Sun Jul  3 15:06:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Jul 2005 15:06:21 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.171]:44488
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226118AbVGCOGE>; Sun, 3 Jul 2005 15:06:04 +0100
Received: from pD95294ED.dip0.t-ipconnect.de [217.82.148.237] (helo=gaspode.madsworld.lan)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0ML2Dk-1Dp56m1X9L-0002mD; Sun, 03 Jul 2005 16:06:08 +0200
Received: from mad by gaspode.madsworld.lan with local (Exim 4.50)
	id 1Dp56p-0007jl-Ku
	for linux-mips@linux-mips.org; Sun, 03 Jul 2005 16:06:11 +0200
Date:	Sun, 3 Jul 2005 16:06:11 +0200
From:	Markus Dahms <mad@automagically.de>
To:	linux-mips@linux-mips.org
Subject: GIO is alive
Message-ID: <20050703140611.GA29571@gaspode.automagically.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:896705dcda322f33ae3752a7fdb3dc09
Return-Path: <mad@automagically.de>
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: 8336
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: mad@automagically.de
Precedence: bulk
X-list: linux-mips
Content-Length: 729
Lines: 18

Hi,

I'm playing around with the SGI GIO bus driver stuff removed from the
kernel almost two and a half years ago.
Recently I got a GIO card for my Indy ("SCSI based printer card" -
http://www.g-lenerz.de/storage/images/sgistuff/indy/printer.jpg), but
no idea what to do with it (and less than no information about it).
Mostly driven by educational reasons I reimplemented parts of the
bus driver as a kernel module for kernel 2.6.x.
It's propably useless, but if somebody interested in such stuff you
can get it at http://automagically.de/?gio where you
also can find some more information.
Of course it's incomplete and buggy but it should not crash the
kernel anymore ;-).
It would be nice if somebody could test it.

Markus


From im.provider@gmail.com Sun Jul  3 17:50:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Jul 2005 17:50:35 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.192]:63057 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226131AbVGCQuU> convert rfc822-to-8bit;
	Sun, 3 Jul 2005 17:50:20 +0100
Received: by wproxy.gmail.com with SMTP id i22so509326wra
        for <linux-mips@linux-mips.org>; Sun, 03 Jul 2005 09:50:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=FpoEZL/eHvUEiiqo2mWL7BL/s5FFsH/EqzJSRFP1wa8BY6zp688SGeFyKslW5WmNuY3q35Dly7cmreaECfeb1NYdre2HSAuCu31wUuBx6VU2XOfx3+ULTvAJU3igskL2y2oLsZaoC+aPY1rL6VWbLQtdWlUi3ZAS2kWtpN5nZR8=
Received: by 10.54.77.15 with SMTP id z15mr1633089wra;
        Sun, 03 Jul 2005 09:50:25 -0700 (PDT)
Received: by 10.54.52.20 with HTTP; Sun, 3 Jul 2005 09:50:24 -0700 (PDT)
Message-ID: <c36743ac0507030950320b3ed2@mail.gmail.com>
Date:	Mon, 4 Jul 2005 00:50:24 +0800
From:	"IM.Chan" <im.provider@gmail.com>
Reply-To: "IM.Chan" <im.provider@gmail.com>
To:	linux-mips@linux-mips.org
Subject: GCC Porting to ESS chips
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <im.provider@gmail.com>
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: 8337
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: im.provider@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 206
Lines: 9

Hi all,

I am wondering if there is a gcc porting to ESS chips available. I am
sorry if this is not the right mail list for the question.

Any advice and help will be greatly appreciated.

Many thanks.
IM.

From geert@linux-m68k.org Mon Jul  4 08:40:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 08:40:23 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:14328 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226140AbVGDHkG>;
	Mon, 4 Jul 2005 08:40:06 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j647eEpr002104;
	Mon, 4 Jul 2005 09:40:14 +0200 (MEST)
Date:	Mon, 4 Jul 2005 09:40:04 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Fabrizio Fazzino <fabrizio@fazzino.it>
cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Assembly macro with parameters
In-Reply-To: <42C7BE64.7020102@fazzino.it>
Message-ID: <Pine.LNX.4.62.0507040934360.11978@numbat.sonytel.be>
References: <425573AD.9010702@fazzino.it> <20050407182549.GA24235@linux-mips.org>
 <4256B5BE.8070708@fazzino.it> <20050408165717.GA8157@nevyn.them.org>
 <42C429C3.2090905@fazzino.it> <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl>
 <42C7BE64.7020102@fazzino.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8338
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1368
Lines: 33

On Sun, 3 Jul 2005, Fabrizio Fazzino wrote:
> In any case I didn't have to use this feature... I was just missing the
> fact that the opcode evaluation didn't have to happen by declaring an
> int variable (in this case the value is computed at runtime) but by the
> preprocessor, so I solved my problem this way:
> 
> #define NEWOPCODE(base,rd,rs,rt) (base|(rs<<21)|(rt<<16)|(rd<<11))
> #define myopcode(rd,rs,rt) asm(".long %0" : : "i"
> (NEWOPCODE(0xC4000000,rd,rs,rt)))
> 
> and then I call it simply as myopcode(10,8,9).
> 
> By the way, is there any quick way of writing a setreg(reg_num,reg_val)
> C macro to set the value of a register?
> And another one to read the value like a reg2var(reg_num,&result) to put
> the value of a register inside my own C variable?
> I have written my own versions for both but they have a 32-case switch
> statement inside so they are not so efficient...

As long as all arguments are constant and thus known at compile time. the
compiler will optimize away the switch completely (cfr. all those
{put,get}_user() routines).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From macro@linux-mips.org Mon Jul  4 13:04:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 13:05:05 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:30725 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226149AbVGDMEt>; Mon, 4 Jul 2005 13:04:49 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1E520F5969; Mon,  4 Jul 2005 14:04:55 +0200 (CEST)
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 30207-06; Mon,  4 Jul 2005 14:04:55 +0200 (CEST)
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 E3BA3E1CAF; Mon,  4 Jul 2005 14:04:54 +0200 (CEST)
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 j64C4vH7025098;
	Mon, 4 Jul 2005 14:04:58 +0200
Date:	Mon, 4 Jul 2005 13:05:03 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Geert Uytterhoeven <geert@linux-m68k.org>
Cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: top and SMP
In-Reply-To: <Pine.LNX.4.62.0507022238060.19703@numbat.sonytel.be>
Message-ID: <Pine.LNX.4.61L.0507041254430.32001@blysk.ds.pg.gda.pl>
References: <20050701172641Z8226172-3678+842@linux-mips.org>
 <Pine.LNX.4.62.0507022238060.19703@numbat.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/965/Sun Jul  3 21:23:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8339
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: 1274
Lines: 26

On Sat, 2 Jul 2005, Geert Uytterhoeven wrote:

> > Looks like I am running procps version 2.0.7.  The latest is 3.2.5, so I am
> > a bit out of date.  I would like to upgrade, but I am having trouble cross
> > compiling the latest.  I get this error:
> > 	Proc/libproc-3.2.5.so: undefined reference to '__ctype_b'
> 
> Is the version of glibc your cross-toolchain links against the same as the
> version of glibc on the target?
> 
> Last time I saw that one was when trying to run `old' (i.e. dynamically linked
> against an older glibc) binaries on a system with a new glibc.

 This is strange -- while there are such problems with static libraries 
(archives) consisting of objects built using headers of glibc 2.2.x when 
used for linking against static glibc 2.3.x, there should be none with 
shared objects.  That '__ctype_b' reference should get resolved using a 
versioned symbol that is still available for run-time linking from shared 
libc.  Perhaps that libproc has been built incorrectly, without a 
reference to libc?  Or there is a problem with binutils...

 Anyway, rebuilding libproc should fix the problem -- make sure `gcc' is 
used for creating shared libproc rather than `ld' (I hope its Makefiles do 
not use any wild shared library hackery).

  Maciej

From geert@linux-m68k.org Mon Jul  4 13:09:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 13:10:09 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:54216 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226149AbVGDMJy>;
	Mon, 4 Jul 2005 13:09:54 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j64CA1pr016298;
	Mon, 4 Jul 2005 14:10:01 +0200 (MEST)
Date:	Mon, 4 Jul 2005 14:09:52 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: top and SMP
In-Reply-To: <Pine.LNX.4.61L.0507041254430.32001@blysk.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.62.0507041405320.14192@numbat.sonytel.be>
References: <20050701172641Z8226172-3678+842@linux-mips.org>
 <Pine.LNX.4.62.0507022238060.19703@numbat.sonytel.be>
 <Pine.LNX.4.61L.0507041254430.32001@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8340
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1568
Lines: 36

On Mon, 4 Jul 2005, Maciej W. Rozycki wrote:
> On Sat, 2 Jul 2005, Geert Uytterhoeven wrote:
> > > Looks like I am running procps version 2.0.7.  The latest is 3.2.5, so I am
> > > a bit out of date.  I would like to upgrade, but I am having trouble cross
> > > compiling the latest.  I get this error:
> > > 	Proc/libproc-3.2.5.so: undefined reference to '__ctype_b'
> > 
> > Is the version of glibc your cross-toolchain links against the same as the
> > version of glibc on the target?
> > 
> > Last time I saw that one was when trying to run `old' (i.e. dynamically linked
> > against an older glibc) binaries on a system with a new glibc.
> 
>  This is strange -- while there are such problems with static libraries 
> (archives) consisting of objects built using headers of glibc 2.2.x when 
> used for linking against static glibc 2.3.x, there should be none with 
> shared objects.  That '__ctype_b' reference should get resolved using a 
> versioned symbol that is still available for run-time linking from shared 
> libc.  Perhaps that libproc has been built incorrectly, without a 
> reference to libc?  Or there is a problem with binutils...

Oops, I was wrong.

I was not running old applications, but linking an old *.a or *.o file using a
new glibc.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From macro@linux-mips.org Mon Jul  4 13:12:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 13:12:50 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:32529 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226154AbVGDMMd>; Mon, 4 Jul 2005 13:12:33 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id E0C0FF599D; Mon,  4 Jul 2005 14:12:39 +0200 (CEST)
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 22610-03; Mon,  4 Jul 2005 14:12:39 +0200 (CEST)
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 B0C97F5969; Mon,  4 Jul 2005 14:12:39 +0200 (CEST)
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 j64CCh0V025438;
	Mon, 4 Jul 2005 14:12:43 +0200
Date:	Mon, 4 Jul 2005 13:12:48 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Fabrizio Fazzino <fabrizio@fazzino.it>
Cc:	linux-mips@linux-mips.org
Subject: Re: Assembly macro with parameters
In-Reply-To: <42C7BE64.7020102@fazzino.it>
Message-ID: <Pine.LNX.4.61L.0507041306440.32001@blysk.ds.pg.gda.pl>
References: <425573AD.9010702@fazzino.it> <20050407182549.GA24235@linux-mips.org>
 <4256B5BE.8070708@fazzino.it> <20050408165717.GA8157@nevyn.them.org>
 <42C429C3.2090905@fazzino.it> <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl>
 <42C7BE64.7020102@fazzino.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/965/Sun Jul  3 21:23:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8341
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: 668
Lines: 15

On Sun, 3 Jul 2005, Fabrizio Fazzino wrote:

> By the way, is there any quick way of writing a setreg(reg_num,reg_val)
> C macro to set the value of a register?

 It would make no sense as GCC would still be free to use this register
for something else, therefore either destroying your "explicitly" assigned 
data or getting data already there destroyed.  You are really after asm 
constraints and explicit register variables as outlined in my previous 
response.  See GCC documentation for how to make use of these.

 BTW, how about adding support for opcodes you are interested in to 
binutils instead?  It would make interfacing them to GCC much easier.

  Maciej

From arianna@dsi.unimi.it Mon Jul  4 13:43:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 13:43:19 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:65234
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226154AbVGDMnC>; Mon, 4 Jul 2005 13:43:02 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j64Ch91r030678
	for <linux-mips@linux-mips.org>; Mon, 4 Jul 2005 14:43:09 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	linux-mips@linux-mips.org
Subject: IOC3 not working on SGI O2K
Date:	Mon, 4 Jul 2005 14:44:00 +0200
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507041444.00289.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8342
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 802
Lines: 32

Hi everybody,

I have a SGI O2K, and I'm trying to install linux.
I've downloaded vmlinux.ip27-20040428 from 
http://www.total-knowledge.com/progs/mips/kernels/ and it boots and mount a 
local root file system.
IOC3 ethernet card doesn't work.

Here are boot logs:
[.....]
[33] 0:1 0; <6> eth%d: link down 0000000004e00791
[.....]
[63] 0:1 0; 725e700004e00791
Found DS1981U NIC registration number 07:e0:04:70:5e, CRC 72.
Ethernet address is 08:00:69:0d:16:00
eth0: link down
eth0: using PHY 0, vendor 0x2000, model 0, rev 3.
eth0: IOC3 SSRAm has 128Kbytes.


IOC3 is on a board with 2 consoles and a SCSI port.
Could be this the problem? Is there any solution?

Thank you very much,
Arianna
-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From ralf@linux-mips.org Mon Jul  4 13:58:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 13:58:31 +0100 (BST)
Received: (from localhost user: 'ralf' uid#501 fake: STDIN
	(ralf@zet-pt.tunnel.tserv1.fmt.ipv6.he.net)) by linux-mips.org
	id <S8226154AbVGDM6Q>; Mon, 4 Jul 2005 13:58:16 +0100
Date:	Mon, 4 Jul 2005 13:58:16 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Arianna Arona <arianna@dsi.unimi.it>
Cc:	linux-mips@linux-mips.org
Subject: Re: IOC3 not working on SGI O2K
Message-ID: <20050704125816.GD3329@linux-mips.org>
References: <200507041444.00289.arianna@dsi.unimi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200507041444.00289.arianna@dsi.unimi.it>
User-Agent: Mutt/1.4.1i
Return-Path: <ralf@linux-mips.org>
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: 8343
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 567
Lines: 18

Arianna,

On Mon, Jul 04, 2005 at 02:44:00PM +0200, Arianna Arona wrote:

> Here are boot logs:
> [.....]
> [33] 0:1 0; <6> eth%d: link down 0000000004e00791
> [.....]
> [63] 0:1 0; 725e700004e00791
> Found DS1981U NIC registration number 07:e0:04:70:5e, CRC 72.
> Ethernet address is 08:00:69:0d:16:00
> eth0: link down
> eth0: using PHY 0, vendor 0x2000, model 0, rev 3.

You need to update the kernel or at least to apply this fix:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-cvs-patches&i=e3d7626b64e5384ac570b0d42c3ecf3f%40NO-ID-FOUND.mhonarc.org

  Ralf

From macro@linux-mips.org Mon Jul  4 14:08:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 14:08:49 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:42766 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226154AbVGDNIe>; Mon, 4 Jul 2005 14:08:34 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 0A8ABE1CA7; Mon,  4 Jul 2005 15:08:40 +0200 (CEST)
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 27549-05; Mon,  4 Jul 2005 15:08:39 +0200 (CEST)
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 AB786E1CA1; Mon,  4 Jul 2005 15:08:39 +0200 (CEST)
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 j64D8g7R027568;
	Mon, 4 Jul 2005 15:08:43 +0200
Date:	Mon, 4 Jul 2005 14:08:49 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:	David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: RFH:  What are the semantics of writeb() and friends?
In-Reply-To: <1120247593.12462.38.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61L.0507041326380.32001@blysk.ds.pg.gda.pl>
References: <01049E563C8ECC43AD6B53A5AF419B38098BD2@avtrex-server2.hq2.avtrex.com>
  <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl> 
 <1120218385.12446.16.camel@localhost.localdomain> 
 <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl> 
 <1120224708.12446.26.camel@localhost.localdomain> 
 <Pine.LNX.4.61L.0507011513320.30138@blysk.ds.pg.gda.pl>
 <1120247593.12462.38.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/965/Sun Jul  3 21:23:29 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8344
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: 2484
Lines: 60

On Fri, 1 Jul 2005, Alan Cox wrote:

> >  But that mentions compiler only, not CPU ordering!  I understand the BIU 
> > of the issuing CPU and any external hardware is still permitted to 
> > merge/reorder these accesses unless separated by wmb()/rmb()/mb() as 
> 
> I think the practical situation is that this implies ordering to the bus
> interface. It might be interesting to ask the powerpc people their
> experience but looking at most PCI drivers they assume this and it would
> be expensive not to do so on x86.

 Hmm, doing this OTOH would be expensive on platforms actually requiring 
explicit barriers for this to be the case.  The problem is only drivers 
know what they expect, e.g. you may need as much as:

	writel();
	mb();
	readl();

but only:

	readl();
	rmb();
	readl();

With barriers coded explicitly in drivers, you may control this, with ones 
inside these mmio functions/macros you need to use mb() everywhere as you 
don't know what the surrounding operations are going to be.  And mb() may 
be significantly more expensive than rmb().

 Of course to facilitate such explicit barriers for platforms where 
inter-processor ordering rules are different to ones for mmio a different 
set of operations would have to be defined -- actually we've already got 
one, mmiowb(), as a starting point.

> >  We have that iob() macro/call as well, so that you can push cycles out of 
> > the CPU domain immediately as well, which is equivalent to:
> 
> > 	mb(); 
> > 	make_host_complete_writes();
> 
> My feeling is the default readb etc are __readb + mb + make_hos...

 Hmm, barriers are normally expected to happen *before* affected 
operations, which is natural and often much faster as in the case of 
traditional MIPS write-back buffers, where there is no "flush" operation 
and mb() is just a tight loop spinning on the WB condition non-empty, 
e.g.: "0: bc0f 0b" till the buffer empties itself.  So I'd rather make 
readb() being mb() + make_host_complete_writes() + __readb().  But it 
would be more painful performance-wise than necessary for many cases, 
questioning the whole idea as any sane driver writer would prefer to use 
these double-underscore calls and schedule barriers as necessary manually 
anyway.

 But if it's indeed what's intended I'd prefer it to be documented 
somewhere in a reasonable place as there are people outside the Intel 
world which may not necessarily know which interfaces imply Intel 
semantics and which do not. ;-)

  Maciej

From ilya@total-knowledge.com Mon Jul  4 16:36:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Jul 2005 16:37:57 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:205.217.158.170]:50894
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8226097AbVGDPg6>; Mon, 4 Jul 2005 16:36:58 +0100
Received: (qmail 5716 invoked from network); 4 Jul 2005 08:37:02 -0700
Received: from c-24-6-216-150.hsd1.ca.comcast.net (HELO ?192.168.0.238?) (24.6.216.150)
  by alpha.total-knowledge.com with SMTP; 4 Jul 2005 08:37:02 -0700
Message-ID: <42C957A4.9090303@total-knowledge.com>
Date:	Mon, 04 Jul 2005 08:37:08 -0700
From:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Organization: Total Knowledge
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050620)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Arianna Arona <arianna@dsi.unimi.it>
CC:	linux-mips@linux-mips.org
Subject: Re: IOC3 not working on SGI O2K
References: <200507041444.00289.arianna@dsi.unimi.it>
In-Reply-To: <200507041444.00289.arianna@dsi.unimi.it>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@total-knowledge.com>
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: 8345
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: ilya@total-knowledge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 815
Lines: 35

I have uploaded my latest kernel to the website.
Try it.

    Ilya.

Arianna Arona wrote:

>Hi everybody,
>
>I have a SGI O2K, and I'm trying to install linux.
>I've downloaded vmlinux.ip27-20040428 from 
>http://www.total-knowledge.com/progs/mips/kernels/ and it boots and mount a 
>local root file system.
>IOC3 ethernet card doesn't work.
>
>Here are boot logs:
>[.....]
>[33] 0:1 0; <6> eth%d: link down 0000000004e00791
>[.....]
>[63] 0:1 0; 725e700004e00791
>Found DS1981U NIC registration number 07:e0:04:70:5e, CRC 72.
>Ethernet address is 08:00:69:0d:16:00
>eth0: link down
>eth0: using PHY 0, vendor 0x2000, model 0, rev 3.
>eth0: IOC3 SSRAm has 128Kbytes.
>
>
>IOC3 is on a board with 2 consoles and a SCSI port.
>Could be this the problem? Is there any solution?
>
>Thank you very much,
>Arianna
>  
>


From arianna@dsi.unimi.it Tue Jul  5 12:05:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 12:05:33 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:10207
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226240AbVGELFN>; Tue, 5 Jul 2005 12:05:13 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j65B5OKR019783
	for <linux-mips@linux-mips.org>; Tue, 5 Jul 2005 13:05:24 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	linux-mips@linux-mips.org
Subject: IOC3 and kernel panic
Date:	Tue, 5 Jul 2005 13:06:15 +0200
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507051306.15102.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8346
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 310
Lines: 21

I have some news.

executing:
# ifconfgi eth0 down
#ifconfig eth0 up

I have:

kernel panic - not syncing: could not identify cpu/level for irq 2

boot params were: bootp(): root=/dev/sdb1 nosmp

A.

-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From arianna@dsi.unimi.it Tue Jul  5 15:42:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 15:42:21 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:36760
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226256AbVGEOmG>; Tue, 5 Jul 2005 15:42:06 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j65EgI3K003674
	for <linux-mips@linux-mips.org>; Tue, 5 Jul 2005 16:42:18 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	linux-mips@linux-mips.org
Subject: 2.6.12 does not read MAC address
Date:	Tue, 5 Jul 2005 16:43:09 +0200
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507051643.09070.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8347
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 449
Lines: 19

Hi everybody,

my network problem are now due to MAC address.
Kernel does not read it and forcing the value via ifconfig does not solve the 
problem.

I need to merge the old driver, which detects MAC addr but eth0 link is down,
with the new one that does the contraty..... opsss.... I could have a not 
working at all driver.... :((

A.

-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From ilya@total-knowledge.com Tue Jul  5 15:57:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 15:57:57 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:205.217.158.170]:9170
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8226258AbVGEO5g>; Tue, 5 Jul 2005 15:57:36 +0100
Received: (qmail 27659 invoked from network); 5 Jul 2005 07:57:49 -0700
Received: from c-24-6-216-150.hsd1.ca.comcast.net (HELO ?192.168.0.238?) (24.6.216.150)
  by alpha.total-knowledge.com with SMTP; 5 Jul 2005 07:57:49 -0700
Message-ID: <42CA9FF3.8060504@total-knowledge.com>
Date:	Tue, 05 Jul 2005 07:57:55 -0700
From:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Organization: Total Knowledge
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050620)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Arianna Arona <arianna@dsi.unimi.it>
CC:	linux-mips@linux-mips.org
Subject: Re: 2.6.12 does not read MAC address
References: <200507051643.09070.arianna@dsi.unimi.it>
In-Reply-To: <200507051643.09070.arianna@dsi.unimi.it>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@total-knowledge.com>
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: 8348
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: ilya@total-knowledge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 895
Lines: 36

Yes, kerenl doesn't read mac address correctly on O2K. Some timeing
issue in the driver
as far as I can tell. None of my kernels ever could read it on O2K, even
though it works
just fine on O200.

No you are wrong. Forcing MAC address works just fine. At least it does
so here.
You just have to force it to correct value (i.e. the one origin was
using when it
was sending bootp/tftp packets.

Look at the logs at your boot server.

--
Ilya A. Volynets-Evenbakh
Total Knowledge, CTO
http://www.total-knowledge.com/

Arianna Arona wrote:

>Hi everybody,
>
>my network problem are now due to MAC address.
>Kernel does not read it and forcing the value via ifconfig does not solve the 
>problem.
>
>I need to merge the old driver, which detects MAC addr but eth0 link is down,
>with the new one that does the contraty..... opsss.... I could have a not 
>working at all driver.... :((
>
>A.
>
>  
>


From rolfliu@gmail.com Tue Jul  5 16:49:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 16:50:13 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.194]:48043 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226258AbVGEPtz> convert rfc822-to-8bit;
	Tue, 5 Jul 2005 16:49:55 +0100
Received: by wproxy.gmail.com with SMTP id i25so915715wra
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 08:50:05 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=qasI0x8iUjDT002NAaXuK94hZ3cKGM0zOPAs6VTnCJdUaQ9deXTLHbAVp5naVOdWxPN4HAWM0q1RjvzpKYK/RCC0KC+yJO6kVPrq0KNTSbxpEr2LcBobgWVKEYzLQ5nKB/buWGphmjhsghotLUGKpg+WFJOEnhmztCG9vyJkUB0=
Received: by 10.54.26.19 with SMTP id 19mr4662085wrz;
        Tue, 05 Jul 2005 08:50:04 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Tue, 5 Jul 2005 08:50:03 -0700 (PDT)
Message-ID: <2db32b7205070508504b675dd6@mail.gmail.com>
Date:	Tue, 5 Jul 2005 08:50:03 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120257851.5987.37.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8349
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2723
Lines: 67

Pete,
I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
didn't force it to use 372 timing, it just hangs up after it detect
the drive. If I used the 372 timing using the 2.4 trick, the kernel
just crashed. Any clue?
Thanks

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT371: IDE controller at PCI slot 0000:00:0b.0
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
HPT371: chipset revision 2
hpt: HPT372N detected, using 372N timing.
FREQ: 73 PLL: 35
HPT371: 100% native mode on irq 5
hpt: no known IDE timings, disabling DMA.
hpt: no known IDE timings, disabling DMA.
hdg: IBM-DTTA-350840, ATA DISK drive
CPU 0 Unable to handle kernel paging request at virtual address
00000000, epc == 8029fb20, ra == 8029fc0c
Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 00000000 00000000
$ 4   : 0000000c 00000000 00010000 18010017
$ 8   : 00000000 0000fc00 00000000 803a6000
$12   : 803ace64 fffffffb ffffffff 0000140d
$16   : 00000048 00000055 30070000 00000001
$20   : 804a1800 0000000c 8043a678 8043a5f8
$24   : 00000000 802a747c                  
$28   : 811de000 811dfe40 1000fc01 8029fc0c
Hi    : 0000018a
Lo    : 3d6edc00
epc   : 8029fb20 pci_bus_clock_list+0x0/0x38     Not tainted
ra    : 8029fc0c hpt372_tune_chipset+0xb4/0x138
Status: 1000fc03    KERNEL EXL IE 
Cause : 00800008
BadVA : 00000000
PrId  : 03030200
Modules linked in:
Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
Stack : 804a1800 00000005 8029f62c 80456bf0 00000000 00000000 804a1800 0000000c
        8043a678 00000001 00000000 803b0000 00000005 8029fcf8 8043a678 8043a5e8
        00000000 00000001 00000000 803b0000 00000005 8043a5f8 8043a678 8043a5e8
        00000000 00000001 00000000 803b0000 00000005 802abd0c 00000005 8043a5f8
        b0400074 b040006c 00000001 811dff30 00000000 00000000 00000000 8043a5e8
        ...
Call Trace:
 [<8029f62c>] hpt_minimum_revision+0x2c/0xec
 [<8029fcf8>] hpt3xx_tune_chipset+0x68/0x2e8
 [<802abd0c>] probe_hwif+0x8a4/0x910
 [<802ace2c>] probe_hwif_init_with_fixup+0x1c/0xcc
 [<802af8bc>] ide_setup_pci_device+0xa8/0xcc
 [<8024f09c>] idr_get_new+0x18/0x4c
 [<80422e38>] ide_scan_pcidev+0x84/0xc4
 [<801c5464>] proc_register+0x48/0x16c
 [<80422eb0>] ide_scan_pcibus+0x38/0xf8
 [<801c5874>] proc_mkdir_mode+0x54/0x80
 [<80422d98>] ide_init+0x68/0x84
 [<80422d7c>] ide_init+0x4c/0x84
 [<801004f8>] init+0x9c/0x264
 [<80105e20>] kernel_thread_helper+0x10/0x18
 [<80105e10>] kernel_thread_helper+0x0/0x18


Code: 02002821  080a7e5f  a3a20013 <90a20000> 10400008  308400ff 
00401821  10640007  00000000
Kernel panic - not syncing: Attempted to kill init!

From goldfinger@member.fsf.org Tue Jul  5 17:49:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 17:49:34 +0100 (BST)
Received: from host157-65.pool8257.interbusiness.it ([IPv6:::ffff:82.57.65.157]:43249
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8226265AbVGEQtH>; Tue, 5 Jul 2005 17:49:07 +0100
Received: by localhost.localdomain (Postfix, from userid 501)
	id AAE1D110F1C; Tue,  5 Jul 2005 20:48:56 +0200 (CEST)
Subject: Re: 2.6.12 does not read MAC address
From:	Michele Carla` <goldfinger@member.fsf.org>
To:	linux-mips@linux-mips.org
In-Reply-To: <42CA9FF3.8060504@total-knowledge.com>
References: <200507051643.09070.arianna@dsi.unimi.it>
	 <42CA9FF3.8060504@total-knowledge.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date:	Tue, 05 Jul 2005 20:48:56 +0200
Message-Id: <1120589336.3117.5.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Return-Path: <goldfinger@member.fsf.org>
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: 8350
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: goldfinger@member.fsf.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1219
Lines: 45

On Tue, 2005-07-05 at 07:57 -0700, Ilya A. Volynets-Evenbakh wrote:
> Yes, kerenl doesn't read mac address correctly on O2K. Some timeing
> issue in the driver
> as far as I can tell. None of my kernels ever could read it on O2K, even
> though it works
> just fine on O200.
> 
> No you are wrong. Forcing MAC address works just fine. At least it does
> so here.

it doesn't works also for me... I have not tried last kernel, but as
soon as possible I'm going to do it !

(some times it recognise menet MAC addresses, but it doesn't works)

> You just have to force it to correct value (i.e. the one origin was
> using when it
> was sending bootp/tftp packets.
> 
> Look at the logs at your boot server.
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge, CTO
> http://www.total-knowledge.com/
> 
> Arianna Arona wrote:
> 
> >Hi everybody,
> >
> >my network problem are now due to MAC address.
> >Kernel does not read it and forcing the value via ifconfig does not solve the 
> >problem.
> >
> >I need to merge the old driver, which detects MAC addr but eth0 link is down,
> >with the new one that does the contraty..... opsss.... I could have a not 
> >working at all driver.... :((
> >
> >A.
> >
> >  
> >
> 
> 
> 

From arianna@dsi.unimi.it Tue Jul  5 17:53:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 17:53:41 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:64688
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226262AbVGEQxV>; Tue, 5 Jul 2005 17:53:21 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j65GrVG3000640;
	Tue, 5 Jul 2005 18:53:31 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Subject: Re: 2.6.12 does not read MAC address
Date:	Tue, 5 Jul 2005 18:54:21 +0200
User-Agent: KMail/1.5.4
Cc:	linux-mips@linux-mips.org
References: <200507051643.09070.arianna@dsi.unimi.it> <42CA9FF3.8060504@total-knowledge.com>
In-Reply-To: <42CA9FF3.8060504@total-knowledge.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507051854.21868.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8351
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 602
Lines: 23

On Tuesday 05 July 2005 16:57, Ilya A. Volynets-Evenbakh wrote:
>
> No you are wrong. Forcing MAC address works just fine. At least it does
> so here.
> You just have to force it to correct value (i.e. the one origin was
> using when it was sending bootp/tftp packets.

I've forced it using: ifconfig eth0 hw ether 08:00:69:0d:16:00,
where 08:00:69:0d:16:00 is MAC address.
After that ifconfig command has right values, but no bits are transmitted.
The one I've used is the right way?

A.



-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From rolfliu@gmail.com Tue Jul  5 20:40:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 20:40:52 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.205]:50524 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226288AbVGETkh> convert rfc822-to-8bit;
	Tue, 5 Jul 2005 20:40:37 +0100
Received: by wproxy.gmail.com with SMTP id i25so963563wra
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 12:40:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=lLpxi9VtoBbJkKxgdzsnNmwTYS1X0TuCbPTdwm8PRQOmLz9P3Y26bgm06+5QdVg6YjfQ7Hz/IzM8VWRvxovLghlEsptekPjL2z9Cri3vLs5uGTKAGtJuIt8J0LXtsqhBl1iNZqiUhy4cvZyOACHi9J5CTSRpE8y00ZJD1H/KeK0=
Received: by 10.54.115.4 with SMTP id n4mr4873663wrc;
        Tue, 05 Jul 2005 12:40:54 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Tue, 5 Jul 2005 12:40:54 -0700 (PDT)
Message-ID: <2db32b72050705124078a48aed@mail.gmail.com>
Date:	Tue, 5 Jul 2005 12:40:54 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120266383.5987.46.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b720507011756247735d6@mail.gmail.com>
	 <1120266383.5987.46.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8352
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 676
Lines: 24

Pete,
To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
au1x00_uart.c config and just compiled in the 8250 support. When I
boot the kernel, nothing comes up through the console, which should be
provided by 8250 support, by 8250_early.c?

Any idea?

On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> 
> Basically.
> 
> > If I want
> > to add extra serial port support by 8250.c. There could be some
> > problem. Any idea?
> 
> Don't know, haven't tried it. In general, the au1x00 serial driver needs
> to be rewritten.
> 
> Pete
> 
>

From rolfliu@gmail.com Tue Jul  5 20:42:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 20:43:10 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.198]:19594 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226289AbVGETmz> convert rfc822-to-8bit;
	Tue, 5 Jul 2005 20:42:55 +0100
Received: by wproxy.gmail.com with SMTP id 70so1202633wra
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 12:43:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Rtg6vzxipcXmqJpAx8yM3L/laLMxkFAznex1D5FetRJ9ZAwtY1KYid3EIj2rd4NwmcPmU37sHEDoisevyWHM+yum39YFZ1IPXf3CuoxjFYk/Cz6KOZDg1wGgwo+aMP10on1/9utH7VyaQBtRpsSlTU3QJ+mimQtJv4IvW2Uy8wo=
Received: by 10.54.15.38 with SMTP id 38mr4914608wro;
        Tue, 05 Jul 2005 12:43:07 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Tue, 5 Jul 2005 12:43:07 -0700 (PDT)
Message-ID: <2db32b7205070512432bb11fcb@mail.gmail.com>
Date:	Tue, 5 Jul 2005 12:43:07 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Jon Anders Haugum <jonah@omegav.ntnu.no>
Subject: Re: can't find interrupt number under /proc/interrupts for the pci multi-port on db1550
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050628100935.S46441@invalid.ed.ntnu.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b720506271706201a66fb@mail.gmail.com>
	 <20050628100935.S46441@invalid.ed.ntnu.no>
Return-Path: <rolfliu@gmail.com>
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: 8353
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 923
Lines: 29

Jon,
did you make the board work under 2.6.x? I tried to turn off the
au1x00 uart, but the board does not work by just not using au1000.h.
Any idea?

thanks


On 6/28/05, Jon Anders Haugum <jonah@omegav.ntnu.no> wrote:
> On Mon, 27 Jun 2005, rolf liu wrote:
> > I am running 2.4.31 on db1550 with a pci multi-port board. the kernel
> > starts up ok. but after start-up, I can't find the corresponding
> > interrupt number for this board, which is irq 2. I can find the device
> > under /proc/devices and /proc/tty/driver, etc. So I am now sure if it
> > is working ok. Is there good (simple) method to test this serial port?
> 
> My guess is that you can get it working if you disable the built-in serial
> ports in the kernel.
> 
> I've attached a quick'n'dirty patch I made for 2.4.27 that makes it
> possible to use both internal and pci serial ports. It's a hack, but it
> works.
> 
> 
> --
> Jon Anders Haugum
> 
> 
>

From ralf@linux-mips.org Tue Jul  5 21:02:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 21:03:16 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:14093 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226290AbVGEUC5>; Tue, 5 Jul 2005 21:02:57 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j65K3Aj5029278;
	Tue, 5 Jul 2005 21:03:10 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j65K3969029277;
	Tue, 5 Jul 2005 21:03:09 +0100
Date:	Tue, 5 Jul 2005 21:03:09 +0100
From:	Ralf Baechle DL5RB <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
Message-ID: <20050705200308.GE18772@linux-mips.org>
References: <17092.5345.75666.403044@cortez.sw.starentnetworks.com> <20050701.114358.21591461.nemoto@toshiba-tops.co.jp> <17093.19241.353160.946039@cortez.sw.starentnetworks.com> <20050703.005921.25910131.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050703.005921.25910131.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8354
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 291
Lines: 9

On Sun, Jul 03, 2005 at 12:59:21AM +0900, Atsushi Nemoto wrote:

> Ralf, how do you think about this?

If the WCHAN column of ps axl is supposed to be any useful we need to
unwind the stack until we find the caller of the sleeping or scheduling
function.  Very useful for debugging.

  Ralf

From clem.taylor@gmail.com Tue Jul  5 22:33:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 22:33:16 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.194]:6386 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226293AbVGEVc7> convert rfc822-to-8bit;
	Tue, 5 Jul 2005 22:32:59 +0100
Received: by wproxy.gmail.com with SMTP id i25so985807wra
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 14:33:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=GlYeJNwcN4Z/SMvm6vapKABwGvlR4tyYiMm/2Mh9e5EtQ+ns8g3r0rgNBHozkH6tlONMWVXnZTlLZWP+i/XmeeXR6b2g35VOOpVW1KARcL1TZ1MaTAipNz/skd22ou4sOpoQYI1yBbLOKPEw7tuZshGe/4igF/1ZpzN4TDqz0tE=
Received: by 10.54.143.4 with SMTP id q4mr4973209wrd;
        Tue, 05 Jul 2005 14:33:11 -0700 (PDT)
Received: by 10.54.41.29 with HTTP; Tue, 5 Jul 2005 14:33:11 -0700 (PDT)
Message-ID: <ecb4efd1050705143364160c24@mail.gmail.com>
Date:	Tue, 5 Jul 2005 17:33:11 -0400
From:	Clem Taylor <clem.taylor@gmail.com>
Reply-To: Clem Taylor <clem.taylor@gmail.com>
To:	linux-mips@linux-mips.org
Subject: can't print a mmaped region in gdb: Cannot access memory at address ...
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <clem.taylor@gmail.com>
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: 8355
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: clem.taylor@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 504
Lines: 13

Hi,

I'm trying to debug some code with gdb that mmaps() PCI address space
and mmaps a kernel GFP_DMA buffer. Outside of gdb mmap() interface is
working just fine, but when I try to print the mmaped memory from gdb
I get a 'Cannot access memory at address ...'

Is this a kernel ptrace() issue or a gdb issue? I'm using linux-mips
2.6.11 from 2005.03.18 on an Alchemy Au1550. Google didn't turn up
anything interesting on this subject.

                           Thanks,
                           Clem

From michael@cubic.org Tue Jul  5 23:10:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 23:10:26 +0100 (BST)
Received: from c175189.adsl.hansenet.de ([IPv6:::ffff:213.39.175.189]:46348
	"EHLO gruft.cubic.org") by linux-mips.org with ESMTP
	id <S8226290AbVGEWKL>; Tue, 5 Jul 2005 23:10:11 +0100
Received: from cubic.org (starbase [192.168.10.1])
	by gruft.cubic.org (8.12.2/8.12.2) with ESMTP id j65MATm9024571
	for <linux-mips@linux-mips.org>; Wed, 6 Jul 2005 00:10:30 +0200
Message-ID: <42CAFFC4.9070807@cubic.org>
Date:	Tue, 05 Jul 2005 23:46:44 +0200
From:	Michael Stickel <michael@cubic.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
References: <2db32b720507011756247735d6@mail.gmail.com>	 <1120266383.5987.46.camel@localhost.localdomain> <2db32b72050705124078a48aed@mail.gmail.com>
In-Reply-To: <2db32b72050705124078a48aed@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <michael@cubic.org>
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: 8356
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: michael@cubic.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2667
Lines: 72

rolf liu wrote:

>Pete,
>To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
>au1x00_uart.c config and just compiled in the 8250 support. When I
>boot the kernel, nothing comes up through the console, which should be
>provided by 8250 support, by 8250_early.c?
>
You can't just enable the serial.c (8250). The UARTs for the Au1x00 are 
memory mapped, but are accessed thru the functions au_readx and 
au_writex. If you take a look at the au1x00_uart.c you can see that the 
functions for serial register access contains access to the au1x00 
registers thru au_readl and au_writel. The serial.c does some more 
things, that does not belong to 8250 (and successors), but to the way 
how the chips are attached to the bus. I see the need to write a more 
modular structure:

One 8250.c that does only the serial chip stuff and one module per 
chip-access-method (serial_io.c, serial_pci.c, serial_mm.c, 
serial_au1x00.c, ...). These modules must know how to access the 
registers, but not what they mean. 8250.c does not know how to access 
the registers, but what to do with it.

Thats teamwork.

That could be adopted to more chips that have a registers to access. I 
think about the i8255 3-port io chip or the i8254-CTC and there are many 
more.

There must be a callback for interrupts like it exists for the parallel 
port stuff.

Could look like that:
struct register_access_s
{
  void (*delete_resource) (struct register_access_s *);
  ...
  int (*writel) (struct register_access_s *bus, long reg, u32 value);
  int (*writew) (struct register_access_s *bus, long reg, u16 value);
  int (*writeb) (struct register_access_s *bus, long reg, u8 value);
  ...
  int (*readl) (struct register_access_s *bus, long reg, u32 *value);
  int (*readw) (struct register_access_s *bus, long reg, u16 *value);
  int (*readb) (struct register_access_s *bus, long reg, u8 *value);
  ...
  void *private;
};

struct register_access_s *create_au1x00_register_access (u32 
au1x00_register_address, size_t size, u32 irq);
struct register_access_s *create_io_register_access (u16 io_address, 
size_t size, u32 irq);
struct register_access_s *create_mm_register_access (void *vaddress, 
size_t size, u32 irq);

struct register_access_s *au1x00_uart0_regs = 
create_au1x00_register_access (UART0_ADDR, 8, AU1000_UART0_INT);
struct register_access_s *uart0_regs = create_io_register_access (0x3E0, 
8, 4);

register_8250 (au1x00_uart0_regs, ...);
register_8250 (uart0_regs, ...);

au1x00_uart0_regs->delete_resource (au1x00_uart0_regs);
...
uart3_regs->delete_resource (uart3_regs);

May be a chip can have more than one interrupts and does not have even one.

Michael



From rolfliu@gmail.com Tue Jul  5 23:40:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Jul 2005 23:41:07 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.192]:64952 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226293AbVGEWkw> convert rfc822-to-8bit;
	Tue, 5 Jul 2005 23:40:52 +0100
Received: by wproxy.gmail.com with SMTP id i25so997182wra
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 15:41:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nVa5+avkD7QhG17z0gdbieJGriiMH7kSW8al/BO4LEHM5slQDOxU6LeJUSol3y258S9mziAria7/6czxb8jUAcSVanw83AVCS15+NllnaIf8HAiB7ctS9TXEr81QsP25+5ErgXjBaDOXrzrS5Ny4AWoDb+RtwtGNPgknLx7Wqsg=
Received: by 10.54.18.22 with SMTP id 22mr5031603wrr;
        Tue, 05 Jul 2005 15:41:11 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Tue, 5 Jul 2005 15:41:10 -0700 (PDT)
Message-ID: <2db32b72050705154141ff0456@mail.gmail.com>
Date:	Tue, 5 Jul 2005 15:41:10 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Michael Stickel <michael@cubic.org>
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <42CAFFC4.9070807@cubic.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b720507011756247735d6@mail.gmail.com>
	 <1120266383.5987.46.camel@localhost.localdomain>
	 <2db32b72050705124078a48aed@mail.gmail.com>
	 <42CAFFC4.9070807@cubic.org>
Return-Path: <rolfliu@gmail.com>
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: 8357
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3090
Lines: 83

Mike,
Thanks for the comments.
Your way is foundamental change. Currently I just want to try if the
8250.c and au1x00_uart.c can work under the same system--both on-chip
uarts and exar uarts are available without too much coding.  Any
suggestions?


On 7/5/05, Michael Stickel <michael@cubic.org> wrote:
> rolf liu wrote:
> 
> >Pete,
> >To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> >au1x00_uart.c config and just compiled in the 8250 support. When I
> >boot the kernel, nothing comes up through the console, which should be
> >provided by 8250 support, by 8250_early.c?
> >
> You can't just enable the serial.c (8250). The UARTs for the Au1x00 are
> memory mapped, but are accessed thru the functions au_readx and
> au_writex. If you take a look at the au1x00_uart.c you can see that the
> functions for serial register access contains access to the au1x00
> registers thru au_readl and au_writel. The serial.c does some more
> things, that does not belong to 8250 (and successors), but to the way
> how the chips are attached to the bus. I see the need to write a more
> modular structure:
> 
> One 8250.c that does only the serial chip stuff and one module per
> chip-access-method (serial_io.c, serial_pci.c, serial_mm.c,
> serial_au1x00.c, ...). These modules must know how to access the
> registers, but not what they mean. 8250.c does not know how to access
> the registers, but what to do with it.
> 
> Thats teamwork.
> 
> That could be adopted to more chips that have a registers to access. I
> think about the i8255 3-port io chip or the i8254-CTC and there are many
> more.
> 
> There must be a callback for interrupts like it exists for the parallel
> port stuff.
> 
> Could look like that:
> struct register_access_s
> {
>  void (*delete_resource) (struct register_access_s *);
>  ...
>  int (*writel) (struct register_access_s *bus, long reg, u32 value);
>  int (*writew) (struct register_access_s *bus, long reg, u16 value);
>  int (*writeb) (struct register_access_s *bus, long reg, u8 value);
>  ...
>  int (*readl) (struct register_access_s *bus, long reg, u32 *value);
>  int (*readw) (struct register_access_s *bus, long reg, u16 *value);
>  int (*readb) (struct register_access_s *bus, long reg, u8 *value);
>  ...
>  void *private;
> };
> 
> struct register_access_s *create_au1x00_register_access (u32
> au1x00_register_address, size_t size, u32 irq);
> struct register_access_s *create_io_register_access (u16 io_address,
> size_t size, u32 irq);
> struct register_access_s *create_mm_register_access (void *vaddress,
> size_t size, u32 irq);
> 
> struct register_access_s *au1x00_uart0_regs =
> create_au1x00_register_access (UART0_ADDR, 8, AU1000_UART0_INT);
> struct register_access_s *uart0_regs = create_io_register_access (0x3E0,
> 8, 4);
> 
> register_8250 (au1x00_uart0_regs, ...);
> register_8250 (uart0_regs, ...);
> 
> au1x00_uart0_regs->delete_resource (au1x00_uart0_regs);
> ...
> uart3_regs->delete_resource (uart3_regs);
> 
> May be a chip can have more than one interrupts and does not have even one.
> 
> Michael
> 
> 
> 
>

From real.psyence@gmail.com Wed Jul  6 02:42:37 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 02:42:54 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.202]:63510 "EHLO
	rproxy.gmail.com") by linux-mips.org with ESMTP id <S8226300AbVGFBmh> convert rfc822-to-8bit;
	Wed, 6 Jul 2005 02:42:37 +0100
Received: by rproxy.gmail.com with SMTP id y7so1050199rne
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 18:42:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=B7LuoSNwBtKomeNjqKjz/RYMyK4UemmDXxQvz6Dbv3Sh1qKfooiIs9tU8z6WCRAHUDJURG26EknemS56N0cOx03/ANePkYsxYwYin3pCzQ5/wBe37sbMntzuz3mXqB7jg/6YLkyOJed8SfN4ogpDR1LYA8HN84LFcAUCxf+yYO0=
Received: by 10.38.104.15 with SMTP id b15mr4495440rnc;
        Tue, 05 Jul 2005 18:42:56 -0700 (PDT)
Received: by 10.38.104.78 with HTTP; Tue, 5 Jul 2005 18:42:56 -0700 (PDT)
Message-ID: <dbce930205070518422c21be21@mail.gmail.com>
Date:	Tue, 5 Jul 2005 21:42:56 -0400
From:	David Cummings <real.psyence@gmail.com>
Reply-To: David Cummings <real.psyence@gmail.com>
To:	linux-mips@linux-mips.org
Subject: broken ip27 kernel
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <real.psyence@gmail.com>
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: 8358
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: real.psyence@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 346
Lines: 9

Hello all,
   I have recently compiled kernel from cvs-source that will load from
arcload, but after "Entering Kernel" the machine hangs and the MSC
appears to be in a POD dex mode. I would  like to know if anyone is
familiar with this and if it's just a patch I'm missing or something.
Thanks
-Dave
-- 
The way that can be named is not the Way.

From anemo@mba.ocn.ne.jp Wed Jul  6 04:29:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 04:29:18 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:42245
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8226306AbVGFD3C>; Wed, 6 Jul 2005 04:29:02 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 6 Jul 2005 03:29:20 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id B6B721F2F9;
	Wed,  6 Jul 2005 12:29:13 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id A32C21F261;
	Wed,  6 Jul 2005 12:29:13 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j663TCoj038386;
	Wed, 6 Jul 2005 12:29:13 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Wed, 06 Jul 2005 12:29:12 +0900 (JST)
Message-Id: <20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
To:	ralf@linux-mips.org
Cc:	anemo@mba.ocn.ne.jp, djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050705200308.GE18772@linux-mips.org>
References: <17093.19241.353160.946039@cortez.sw.starentnetworks.com>
	<20050703.005921.25910131.anemo@mba.ocn.ne.jp>
	<20050705200308.GE18772@linux-mips.org>
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.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 8359
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: 790
Lines: 18

>>>>> On Tue, 5 Jul 2005 21:03:09 +0100, Ralf Baechle DL5RB <ralf@linux-mips.org> said:
ralf> If the WCHAN column of ps axl is supposed to be any useful we
ralf> need to unwind the stack until we find the caller of the
ralf> sleeping or scheduling function.  Very useful for debugging.

Yes, but many sleeping/scheduling (such as schedule_timeout(),
__down(), etc.)  are compiled without -fno-omit-frame-pointer, so
you can not find the caller of such functions anyway.

And some sleeping/scheduling functions which are compiled with
-fno-omit-frame-pointer are static or deprecated (sleep_on(), etc.)

You can find the caller of "schedule()" even with simple
thread_saved_pc().  I think it is enough so I do not think it is worth
to fix (and maintain) current minfo[].

---
Atsushi Nemoto

From ilya@total-knowledge.com Wed Jul  6 05:07:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 05:07:36 +0100 (BST)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:205.217.158.170]:51155
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8226306AbVGFEHQ>; Wed, 6 Jul 2005 05:07:16 +0100
Received: (qmail 10673 invoked from network); 5 Jul 2005 21:07:31 -0700
Received: from c-24-6-216-150.hsd1.ca.comcast.net (HELO ?192.168.0.238?) (24.6.216.150)
  by alpha.total-knowledge.com with SMTP; 5 Jul 2005 21:07:31 -0700
Message-ID: <42CB5908.7030005@total-knowledge.com>
Date:	Tue, 05 Jul 2005 21:07:36 -0700
From:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Organization: Total Knowledge
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050620)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	David Cummings <real.psyence@gmail.com>
CC:	linux-mips@linux-mips.org
Subject: Re: broken ip27 kernel
References: <dbce930205070518422c21be21@mail.gmail.com>
In-Reply-To: <dbce930205070518422c21be21@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@total-knowledge.com>
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: 8360
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: ilya@total-knowledge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 615
Lines: 21

http://www.total-knowledge.com/progs/mips/kernels
contains compiled kernel as of few days ago, as well as diff I used.
It runs just fin on my Origin2000 and was reported to run on O200 as well.

David Cummings wrote:

>Hello all,
>   I have recently compiled kernel from cvs-source that will load from
>arcload, but after "Entering Kernel" the machine hangs and the MSC
>appears to be in a POD dex mode. I would  like to know if anyone is
>familiar with this and if it's just a patch I'm missing or something.
>Thanks
>-Dave
>  
>

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com


From real.psyence@gmail.com Wed Jul  6 07:31:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 07:31:41 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.197]:6268 "EHLO
	rproxy.gmail.com") by linux-mips.org with ESMTP id <S8226312AbVGFGbY> convert rfc822-to-8bit;
	Wed, 6 Jul 2005 07:31:24 +0100
Received: by rproxy.gmail.com with SMTP id y7so1090381rne
        for <linux-mips@linux-mips.org>; Tue, 05 Jul 2005 23:31:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=DqTdwFuJGZ1DzAOdxejkgpzWTKKnvigZ1/Lnp9HQ9JnOOxQdbEoccjEHiFjbSq6xZY6Ucq8t3w5m7Axewyad4HJrCYMP0CbVe+7bp+epi3Ye3IQHaSJHSzk5tOaTAQpEAwVT5QRJbzEsgXXw6YnvlezVi04dsvWjV3Pcbtcweek=
Received: by 10.38.89.66 with SMTP id m66mr4778361rnb;
        Tue, 05 Jul 2005 23:31:44 -0700 (PDT)
Received: by 10.38.104.78 with HTTP; Tue, 5 Jul 2005 23:31:44 -0700 (PDT)
Message-ID: <dbce930205070523316dd9954b@mail.gmail.com>
Date:	Wed, 6 Jul 2005 02:31:44 -0400
From:	David Cummings <real.psyence@gmail.com>
Reply-To: David Cummings <real.psyence@gmail.com>
To:	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Subject: Re: broken ip27 kernel
Cc:	linux-mips@linux-mips.org
In-Reply-To: <42CB5908.7030005@total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <dbce930205070518422c21be21@mail.gmail.com>
	 <42CB5908.7030005@total-knowledge.com>
Return-Path: <real.psyence@gmail.com>
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: 8361
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: real.psyence@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1114
Lines: 34

I can boot your kernel, Ilya, just fine. I'd really like it to be able
to boot from sda1, so my config takes out nfsroot. I am using the
newest checkout from cvs, but I am having trouble applying your diff.
Either the Makefile and others have changed dramatically, or I am
using an incorrect command to patch. Thanks for any info,
-Dave

On 7/6/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> http://www.total-knowledge.com/progs/mips/kernels
> contains compiled kernel as of few days ago, as well as diff I used.
> It runs just fin on my Origin2000 and was reported to run on O200 as well.
> 
> David Cummings wrote:
> 
> >Hello all,
> >   I have recently compiled kernel from cvs-source that will load from
> >arcload, but after "Entering Kernel" the machine hangs and the MSC
> >appears to be in a POD dex mode. I would  like to know if anyone is
> >familiar with this and if it's just a patch I'm missing or something.
> >Thanks
> >-Dave
> >
> >
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


-- 
The way that can be named is not the Way.

From ppopov@embeddedalley.com Wed Jul  6 08:09:51 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 08:10:06 +0100 (BST)
Received: from smtp008.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.74]:15192
	"HELO smtp008.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226314AbVGFHJu>; Wed, 6 Jul 2005 08:09:50 +0100
Received: (qmail 18351 invoked from network); 6 Jul 2005 07:10:10 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp008.bizmail.sc5.yahoo.com with SMTP; 6 Jul 2005 07:10:10 -0000
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b72050705124078a48aed@mail.gmail.com>
References: <2db32b720507011756247735d6@mail.gmail.com>
	 <1120266383.5987.46.camel@localhost.localdomain>
	 <2db32b72050705124078a48aed@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Wed, 06 Jul 2005 00:10:17 -0700
Message-Id: <1120633817.5724.26.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8362
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: 1038
Lines: 35

On Tue, 2005-07-05 at 12:40 -0700, rolf liu wrote:
> Pete,
> To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> au1x00_uart.c config and just compiled in the 8250 support. When I
> boot the kernel, nothing comes up through the console, which should be
> provided by 8250 support, by 8250_early.c?
> 
> Any idea?

Yes. The 8250.c won't work with the au1x uart. I know I said in a
previous email that the 8250 "basically" does the same thing as the au1x
uart driver, but if the 8250 worked with the Au1x SoCs, why would we
even have the au1x serial driver in place?

Pete

> 
> On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> > 
> > Basically.
> > 
> > > If I want
> > > to add extra serial port support by 8250.c. There could be some
> > > problem. Any idea?
> > 
> > Don't know, haven't tried it. In general, the au1x00 serial driver needs
> > to be rewritten.
> > 
> > Pete
> > 
> >
> 


From ppopov@embeddedalley.com Wed Jul  6 08:11:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 08:12:03 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:50105
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226314AbVGFHLr>; Wed, 6 Jul 2005 08:11:47 +0100
Received: (qmail 99454 invoked from network); 6 Jul 2005 07:12:07 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 6 Jul 2005 07:12:07 -0000
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070508504b675dd6@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Wed, 06 Jul 2005 00:12:14 -0700
Message-Id: <1120633934.5724.29.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8363
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: 3067
Lines: 77

On Tue, 2005-07-05 at 08:50 -0700, rolf liu wrote:
> Pete,
> I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> didn't force it to use 372 timing, it just hangs up after it detect
> the drive. If I used the 372 timing using the 2.4 trick, the kernel
> just crashed. Any clue?

Other than the call trace you can see below, no, no clues. I would have
to spend some time debugging it and if it ever becomes a priority, I
will.

Pete

> Thanks
> 
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> HPT371: IDE controller at PCI slot 0000:00:0b.0
> PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> HPT371: chipset revision 2
> hpt: HPT372N detected, using 372N timing.
> FREQ: 73 PLL: 35
> HPT371: 100% native mode on irq 5
> hpt: no known IDE timings, disabling DMA.
> hpt: no known IDE timings, disabling DMA.
> hdg: IBM-DTTA-350840, ATA DISK drive
> CPU 0 Unable to handle kernel paging request at virtual address
> 00000000, epc == 8029fb20, ra == 8029fc0c
> Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
> Cpu 0
> $ 0   : 00000000 1000fc00 00000000 00000000
> $ 4   : 0000000c 00000000 00010000 18010017
> $ 8   : 00000000 0000fc00 00000000 803a6000
> $12   : 803ace64 fffffffb ffffffff 0000140d
> $16   : 00000048 00000055 30070000 00000001
> $20   : 804a1800 0000000c 8043a678 8043a5f8
> $24   : 00000000 802a747c                  
> $28   : 811de000 811dfe40 1000fc01 8029fc0c
> Hi    : 0000018a
> Lo    : 3d6edc00
> epc   : 8029fb20 pci_bus_clock_list+0x0/0x38     Not tainted
> ra    : 8029fc0c hpt372_tune_chipset+0xb4/0x138
> Status: 1000fc03    KERNEL EXL IE 
> Cause : 00800008
> BadVA : 00000000
> PrId  : 03030200
> Modules linked in:
> Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> Stack : 804a1800 00000005 8029f62c 80456bf0 00000000 00000000 804a1800 0000000c
>         8043a678 00000001 00000000 803b0000 00000005 8029fcf8 8043a678 8043a5e8
>         00000000 00000001 00000000 803b0000 00000005 8043a5f8 8043a678 8043a5e8
>         00000000 00000001 00000000 803b0000 00000005 802abd0c 00000005 8043a5f8
>         b0400074 b040006c 00000001 811dff30 00000000 00000000 00000000 8043a5e8
>         ...
> Call Trace:
>  [<8029f62c>] hpt_minimum_revision+0x2c/0xec
>  [<8029fcf8>] hpt3xx_tune_chipset+0x68/0x2e8
>  [<802abd0c>] probe_hwif+0x8a4/0x910
>  [<802ace2c>] probe_hwif_init_with_fixup+0x1c/0xcc
>  [<802af8bc>] ide_setup_pci_device+0xa8/0xcc
>  [<8024f09c>] idr_get_new+0x18/0x4c
>  [<80422e38>] ide_scan_pcidev+0x84/0xc4
>  [<801c5464>] proc_register+0x48/0x16c
>  [<80422eb0>] ide_scan_pcibus+0x38/0xf8
>  [<801c5874>] proc_mkdir_mode+0x54/0x80
>  [<80422d98>] ide_init+0x68/0x84
>  [<80422d7c>] ide_init+0x4c/0x84
>  [<801004f8>] init+0x9c/0x264
>  [<80105e20>] kernel_thread_helper+0x10/0x18
>  [<80105e10>] kernel_thread_helper+0x0/0x18
> 
> 
> Code: 02002821  080a7e5f  a3a20013 <90a20000> 10400008  308400ff 
> 00401821  10640007  00000000
> Kernel panic - not syncing: Attempted to kill init!
> 


From real.psyence@gmail.com Wed Jul  6 09:40:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 09:40:28 +0100 (BST)
Received: from rproxy.gmail.com ([IPv6:::ffff:64.233.170.206]:9439 "EHLO
	rproxy.gmail.com") by linux-mips.org with ESMTP id <S8226317AbVGFIkK> convert rfc822-to-8bit;
	Wed, 6 Jul 2005 09:40:10 +0100
Received: by rproxy.gmail.com with SMTP id y7so1104456rne
        for <linux-mips@linux-mips.org>; Wed, 06 Jul 2005 01:40:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tYMHqrRptDDxaNoN0gotQ0DeJzgbO0MQfwgpCH4BFhU7czL5bSy2GaKwTUi6NcAzijnjOCkykfl8Xw6cKNSpzZ5CHZAhhCAS6kc3atEDTIRPNi2q0CO5HCGHKYyqeTIGUAc9r7jpVfvNs7+KzJvDDxHCKW3BduZJTIw1qsI8cW4=
Received: by 10.38.181.12 with SMTP id d12mr4802088rnf;
        Wed, 06 Jul 2005 01:40:32 -0700 (PDT)
Received: by 10.38.104.78 with HTTP; Wed, 6 Jul 2005 01:40:32 -0700 (PDT)
Message-ID: <dbce930205070601407c8ce6a4@mail.gmail.com>
Date:	Wed, 6 Jul 2005 04:40:32 -0400
From:	David Cummings <real.psyence@gmail.com>
Reply-To: David Cummings <real.psyence@gmail.com>
To:	linux-mips@linux-mips.org,
	"Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
Subject: Re: broken ip27 kernel
In-Reply-To: <dbce930205070523316dd9954b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <dbce930205070518422c21be21@mail.gmail.com>
	 <42CB5908.7030005@total-knowledge.com>
	 <dbce930205070523316dd9954b@mail.gmail.com>
Return-Path: <real.psyence@gmail.com>
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: 8364
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: real.psyence@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1693
Lines: 47

Ok, the patch difficulty was my fault. With latest cvs source and the
20050703.diff applied, I can build a kernel, arcload and arcs itself
can both load said kernel, but I receive no output on the console. If
I drop out to a MSC console, it is in one of either POD MSC Dex or Unc
depending on kernel(and time perhaps?). I feel like I am missing
something, like console support or something. Thanks again...

On 7/6/05, David Cummings <real.psyence@gmail.com> wrote:
> I can boot your kernel, Ilya, just fine. I'd really like it to be able
> to boot from sda1, so my config takes out nfsroot. I am using the
> newest checkout from cvs, but I am having trouble applying your diff.
> Either the Makefile and others have changed dramatically, or I am
> using an incorrect command to patch. Thanks for any info,
> -Dave
> 
> On 7/6/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> > http://www.total-knowledge.com/progs/mips/kernels
> > contains compiled kernel as of few days ago, as well as diff I used.
> > It runs just fin on my Origin2000 and was reported to run on O200 as well.
> >
> > David Cummings wrote:
> >
> > >Hello all,
> > >   I have recently compiled kernel from cvs-source that will load from
> > >arcload, but after "Entering Kernel" the machine hangs and the MSC
> > >appears to be in a POD dex mode. I would  like to know if anyone is
> > >familiar with this and if it's just a patch I'm missing or something.
> > >Thanks
> > >-Dave
> > >
> > >
> >
> > --
> > Ilya A. Volynets-Evenbakh
> > Total Knowledge. CTO
> > http://www.total-knowledge.com
> >
> >
> 
> 
> --
> The way that can be named is not the Way.
> 


-- 
The way that can be named is not the Way.

From macro@linux-mips.org Wed Jul  6 09:58:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 09:58:43 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:47121 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226317AbVGFI60>; Wed, 6 Jul 2005 09:58:26 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id EAFADE1C98; Wed,  6 Jul 2005 10:58:44 +0200 (CEST)
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 07919-10; Wed,  6 Jul 2005 10:58:44 +0200 (CEST)
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 A9210E1C69; Wed,  6 Jul 2005 10:58:44 +0200 (CEST)
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 j668wjVf029011;
	Wed, 6 Jul 2005 10:58:46 +0200
Date:	Wed, 6 Jul 2005 09:58:50 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	ralf@linux-mips.org, djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
In-Reply-To: <20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.LNX.4.61L.0507060952500.9536@blysk.ds.pg.gda.pl>
References: <17093.19241.353160.946039@cortez.sw.starentnetworks.com>
 <20050703.005921.25910131.anemo@mba.ocn.ne.jp> <20050705200308.GE18772@linux-mips.org>
 <20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/968/Wed Jul  6 04:48:09 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8365
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: 378
Lines: 10

On Wed, 6 Jul 2005, Atsushi Nemoto wrote:

> Yes, but many sleeping/scheduling (such as schedule_timeout(),
> __down(), etc.)  are compiled without -fno-omit-frame-pointer, so
> you can not find the caller of such functions anyway.

 Of course you can -- __builtin_return_address().  It should be enough for 
`ps' to fetch useful data from "System.map", shouldn't it?

  Maciej

From ralf@linux-mips.org Wed Jul  6 10:01:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 10:01:41 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:14871 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226317AbVGFJBX>; Wed, 6 Jul 2005 10:01:23 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6691ecY007744;
	Wed, 6 Jul 2005 10:01:40 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6691cTr007743;
	Wed, 6 Jul 2005 10:01:38 +0100
Date:	Wed, 6 Jul 2005 10:01:38 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc:	djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
Message-ID: <20050706090138.GC3226@linux-mips.org>
References: <17093.19241.353160.946039@cortez.sw.starentnetworks.com> <20050703.005921.25910131.anemo@mba.ocn.ne.jp> <20050705200308.GE18772@linux-mips.org> <20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8366
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1261
Lines: 29

On Wed, Jul 06, 2005 at 12:29:12PM +0900, Atsushi Nemoto wrote:

> >>>>> On Tue, 5 Jul 2005 21:03:09 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> ralf> If the WCHAN column of ps axl is supposed to be any useful we
> ralf> need to unwind the stack until we find the caller of the
> ralf> sleeping or scheduling function.  Very useful for debugging.
> 
> Yes, but many sleeping/scheduling (such as schedule_timeout(),
> __down(), etc.)  are compiled without -fno-omit-frame-pointer, so
> you can not find the caller of such functions anyway.

Without additional information a framepointer isn't terribly useful on
MIPS.  Unfortunately it's stored at a non-constant offset in a function's
stackframe.

> And some sleeping/scheduling functions which are compiled with
> -fno-omit-frame-pointer are static or deprecated (sleep_on(), etc.)
> 
> You can find the caller of "schedule()" even with simple
> thread_saved_pc().  I think it is enough so I do not think it is worth
> to fix (and maintain) current minfo[].

The alternative would be to finally bite the bullet and add a wchan field
to thread_struct and initialize it in all the sleeping functions.

The IA-64 people have something like a DWARF-based frame unwinder but
that just seems to heavy.

  Ralf

From ralf@linux-mips.org Wed Jul  6 10:14:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 10:14:21 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:36872 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226322AbVGFJOG>; Wed, 6 Jul 2005 10:14:06 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j669ENtp008163;
	Wed, 6 Jul 2005 10:14:23 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j669EN1x008162;
	Wed, 6 Jul 2005 10:14:23 +0100
Date:	Wed, 6 Jul 2005 10:14:23 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
Message-ID: <20050706091423.GD3226@linux-mips.org>
References: <17093.19241.353160.946039@cortez.sw.starentnetworks.com> <20050703.005921.25910131.anemo@mba.ocn.ne.jp> <20050705200308.GE18772@linux-mips.org> <20050706.122912.71087098.nemoto@toshiba-tops.co.jp> <Pine.LNX.4.61L.0507060952500.9536@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507060952500.9536@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8367
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 622
Lines: 14

On Wed, Jul 06, 2005 at 09:58:50AM +0100, Maciej W. Rozycki wrote:

> > Yes, but many sleeping/scheduling (such as schedule_timeout(),
> > __down(), etc.)  are compiled without -fno-omit-frame-pointer, so
> > you can not find the caller of such functions anyway.
> 
>  Of course you can -- __builtin_return_address().  It should be enough for 
> `ps' to fetch useful data from "System.map", shouldn't it?

__builtin_return_address() is what those function could use themselves.
In this case it's about another piece of code unwinding the stackframe
until we hit a caller address that is not a scheduling function.

  Ralf

From arianna@dsi.unimi.it Wed Jul  6 13:46:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 13:47:10 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:58600
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226326AbVGFMqw>; Wed, 6 Jul 2005 13:46:52 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j66ClCwG023749
	for <linux-mips@linux-mips.org>; Wed, 6 Jul 2005 14:47:12 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	linux-mips@linux-mips.org
Subject: 2.6.12 DOES read MAC address
Date:	Wed, 6 Jul 2005 14:48:02 +0200
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507061448.02561.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8368
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 412
Lines: 17


I've compiled the kernel myself and now it reads MAC address at boot time.
Problem solved? NO. Ethernet card does not trasmit any packets on the net.

I have a question: how is your ethernet card? Mine is a card with network, 2 
consoles and a SCSI port in it. Could be this the problem?

Cheers,
A.

-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From ralf@linux-mips.org Wed Jul  6 14:09:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 14:09:30 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:17695 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226327AbVGFNJO>; Wed, 6 Jul 2005 14:09:14 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j66D9MTM017205;
	Wed, 6 Jul 2005 14:09:22 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j66D9MOq017204;
	Wed, 6 Jul 2005 14:09:22 +0100
Date:	Wed, 6 Jul 2005 14:09:22 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Arianna Arona <arianna@dsi.unimi.it>
Cc:	linux-mips@linux-mips.org
Subject: Re: 2.6.12 DOES read MAC address
Message-ID: <20050706130921.GJ3226@linux-mips.org>
References: <200507061448.02561.arianna@dsi.unimi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200507061448.02561.arianna@dsi.unimi.it>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8369
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 541
Lines: 13

On Wed, Jul 06, 2005 at 02:48:02PM +0200, Arianna Arona wrote:

> I've compiled the kernel myself and now it reads MAC address at boot time.
> Problem solved? NO. Ethernet card does not trasmit any packets on the net.
> 
> I have a question: how is your ethernet card? Mine is a card with network, 2 
> consoles and a SCSI port in it. Could be this the problem?

Same IOC3 card as every Origin.  We're looking into the issue.  Part of
the problems seems to be the hardware isn't behaving exactly the way I
thought it is meant to ...

  Ralf

From ths@networkno.de Wed Jul  6 14:39:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 14:40:02 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:7637 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8226327AbVGFNjr>;
	Wed, 6 Jul 2005 14:39:47 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1DqA8D-0002dR-00
	for linux-mips@linux-mips.org; Wed, 06 Jul 2005 15:40:05 +0200
Received: from ths by hattusa.textio with local (Exim 4.51)
	id 1DqA8C-0004UE-RN
	for linux-mips@linux-mips.org; Wed, 06 Jul 2005 15:40:04 +0200
Date:	Wed, 6 Jul 2005 15:40:04 +0200
To:	linux-mips@linux-mips.org
Subject: Re: 2.6.12 DOES read MAC address
Message-ID: <20050706134004.GS1645@hattusa.textio>
References: <200507061448.02561.arianna@dsi.unimi.it> <20050706130921.GJ3226@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050706130921.GJ3226@linux-mips.org>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8370
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 806
Lines: 19

Ralf Baechle wrote:
> On Wed, Jul 06, 2005 at 02:48:02PM +0200, Arianna Arona wrote:
> 
> > I've compiled the kernel myself and now it reads MAC address at boot time.
> > Problem solved? NO. Ethernet card does not trasmit any packets on the net.
> > 
> > I have a question: how is your ethernet card? Mine is a card with network, 2 
> > consoles and a SCSI port in it. Could be this the problem?
> 
> Same IOC3 card as every Origin.  We're looking into the issue.  Part of
> the problems seems to be the hardware isn't behaving exactly the way I
> thought it is meant to ...

JFTR, CVS HEAD works here, with one strangeness: The kernel fails to find
any autoconfiguration from dhcp. Specifying the parameters on the command
line works, and the interface seems to work fine once the machine is up.


Thiemo

From hellokishore@gmail.com Wed Jul  6 15:09:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 15:09:40 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.201]:4593 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226334AbVGFOJV>;
	Wed, 6 Jul 2005 15:09:21 +0100
Received: by zproxy.gmail.com with SMTP id 14so655149nzn
        for <linux-mips@linux-mips.org>; Wed, 06 Jul 2005 07:09:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type;
        b=Iyf3o84VZBZ2r93zz7Pyxg8Wygkt607Xpb1/K9K4Bl2gE+uxwhGHaLp7umv3UoF8PFxOmVsNqOJSqmXCeQut8TfrPIOowVW0tmiWo37QvNoeOH57xfjQtV0Dpea7eXQcPl4GHRlioYNjUtBggA2+M1cDGSvLkI2kAqtNfh9Jols=
Received: by 10.36.129.6 with SMTP id b6mr1682215nzd;
        Wed, 06 Jul 2005 07:09:38 -0700 (PDT)
Received: by 10.36.47.11 with HTTP; Wed, 6 Jul 2005 07:09:38 -0700 (PDT)
Message-ID: <f07e6e050706070924973b42@mail.gmail.com>
Date:	Wed, 6 Jul 2005 19:39:38 +0530
From:	Kishore K <hellokishore@gmail.com>
Reply-To: Kishore K <hellokishore@gmail.com>
To:	linux-mips@linux-mips.org
Subject: Booting linux on Malta board
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_22374_30420151.1120658978796"
Return-Path: <hellokishore@gmail.com>
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: 8371
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: hellokishore@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 28676
Lines: 405

------=_Part_22374_30420151.1120658978796
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi all,
I have a MIPS based malta board. For this I have two linux kernel
images. First one is built from Montavista 2.4.20 sources and the
second one is built from the 2.4.29 kernel sources downloaded from
linux-mips.org. In my setup, image is downloaded to the target malta
board by using load command in YAMON and root file system is mounted
on NFS.
If I use the image built from Montavista sources, my target is up and
running. On the otherhand if I use the image built from linux-2.4.29
sources, the board hangs after displaying the message "Linux started".

config file for 2.4.29 is enclosed along with this mail.

My malta board info
----------------------------

Board type/revision =3D 0x02 (Malta) / 0x00
Core board type/revision =3D 0x01 (CoreLV) / 0x01
FPGA revision =3D 0x0001
Processor Company ID/options=3D 0x01 (MIPS Technologies Inc.) / 0x00
Processor ID/revision =3D 0x80 (MIPS 4Kc) / 0x05
Endianness =3D big
CPU/Bus frequency =3D 125 MHz/ 63 MHz
Flash Memory size =3D 4 MByte
SDRAM size =3D 64 MByte
First free SDRAM address =3D 0x8009e380

Tool chain Information:
--------------------------------

mips-linux-gcc - 3.3.6
binutils - 2.15.94.0.2.2
uClibc-0.9.27

Tool chain is built using buildroot and same tool chain is used to
compile both the kernels.
Has anyone faced this problem? Can you please point out what could be
the problem ?

Same problem is observed when vanilla linux 2.4.25 source from
kernel.org is compiled.
Can we use vanilla linux kernel on malta, without any patches ?

TIA,
--kishore

------=_Part_22374_30420151.1120658978796
Content-Type: application/octet-stream; name="config-2-4-29"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="config-2-4-29"

Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9uJ3QgZWRpdA0KIw0K
Q09ORklHX01JUFM9eQ0KQ09ORklHX01JUFMzMj15DQojIENPTkZJR19NSVBTNjQgaXMgbm90IHNl
dA0KDQojDQojIENvZGUgbWF0dXJpdHkgbGV2ZWwgb3B0aW9ucw0KIw0KQ09ORklHX0VYUEVSSU1F
TlRBTD15DQoNCiMNCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQNCiMNCkNPTkZJR19NT0RVTEVT
PXkNCkNPTkZJR19NT0RWRVJTSU9OUz15DQpDT05GSUdfS01PRD15DQoNCiMNCiMgTWFjaGluZSBz
ZWxlY3Rpb24NCiMNCiMgQ09ORklHX0FDRVJfUElDQV82MSBpcyBub3Qgc2V0DQojIENPTkZJR19N
SVBTX0JPU1BPUlVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfRklDTU1QIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01JUFNfTUlSQUdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfREIxMDAwIGlz
IG5vdCBzZXQNCiMgQ09ORklHX01JUFNfREIxMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNf
REIxNTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfREIxNTUwIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01JUFNfREIxMjAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfUEIxMDAwIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01JUFNfUEIxMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfUEIxNTAw
IGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfUEIxNTUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01J
UFNfUEIxMjAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfSFlEUk9HRU4zIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01JUFNfWFhTMTUwMCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX01UWDEgaXMg
bm90IHNldA0KIyBDT05GSUdfQ09HRU5UX0NTQjI1MCBpcyBub3Qgc2V0DQojIENPTkZJR19CQUdF
VF9NSVBTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NBU0lPX0U1NSBpcyBub3Qgc2V0DQojIENPTkZJ
R19NSVBTX0NPQkFMVCBpcyBub3Qgc2V0DQojIENPTkZJR19ERUNTVEFUSU9OIGlzIG5vdCBzZXQN
CiMgQ09ORklHX01JUFNfRVY2NDEyMCBpcyBub3Qgc2V0DQojIENPTkZJR19NSVBTX0VWOTYxMDAg
aXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19JVlIgaXMgbm90IHNldA0KIyBDT05GSUdfSFBfTEFT
RVJKRVQgaXMgbm90IHNldA0KIyBDT05GSUdfSUJNX1dPUktQQUQgaXMgbm90IHNldA0KIyBDT05G
SUdfTEFTQVQgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19JVEU4MTcyIGlzIG5vdCBzZXQNCiMg
Q09ORklHX01JUFNfQVRMQVMgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQU19NQUdOVU1fNDAwMCBp
cyBub3Qgc2V0DQpDT05GSUdfTUlQU19NQUxUQT15DQojIENPTkZJR19NSVBTX1NFQUQgaXMgbm90
IHNldA0KIyBDT05GSUdfTU9NRU5DT19PQ0VMT1QgaXMgbm90IHNldA0KIyBDT05GSUdfTU9NRU5D
T19PQ0VMT1RfRyBpcyBub3Qgc2V0DQojIENPTkZJR19NT01FTkNPX09DRUxPVF9DIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX01PTUVOQ09fSkFHVUFSX0FUWCBpcyBub3Qgc2V0DQojIENPTkZJR19QTUNf
QklHX1NVUiBpcyBub3Qgc2V0DQojIENPTkZJR19QTUNfU1RSRVRDSCBpcyBub3Qgc2V0DQojIENP
TkZJR19QTUNfWU9TRU1JVEUgaXMgbm90IHNldA0KIyBDT05GSUdfRERCNTA3NCBpcyBub3Qgc2V0
DQojIENPTkZJR19EREI1NDc2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0REQjU0NzcgaXMgbm90IHNl
dA0KIyBDT05GSUdfTkVDX09TUFJFWSBpcyBub3Qgc2V0DQojIENPTkZJR19ORUNfRUFHTEUgaXMg
bm90IHNldA0KIyBDT05GSUdfT0xJVkVUVElfTTcwMCBpcyBub3Qgc2V0DQojIENPTkZJR19OSU5P
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NHSV9JUDIyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NHSV9J
UDI3IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NJQllURV9TQjF4eHhfU09DIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NOSV9STTIwMF9QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfVEFOQkFDX1RCMDIyNiBp
cyBub3Qgc2V0DQojIENPTkZJR19UQU5CQUNfVEIwMjI5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1RP
U0hJQkFfSk1SMzkyNyBpcyBub3Qgc2V0DQojIENPTkZJR19UT1NISUJBX1JCVFg0OTI3IGlzIG5v
dCBzZXQNCiMgQ09ORklHX1ZJQ1RPUl9NUEMzMFggaXMgbm90IHNldA0KIyBDT05GSUdfWkFPX0NB
UENFTExBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJR0hNRU0gaXMgbm90IHNldA0KQ09ORklHX1JX
U0VNX0dFTkVSSUNfU1BJTkxPQ0s9eQ0KIyBDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE0g
aXMgbm90IHNldA0KQ09ORklHX0JPT1RfRUxGMzI9eQ0KQ09ORklHX0hBVkVfU1REX1BDX1NFUklB
TF9QT1JUPXkNCkNPTkZJR19JODI1OT15DQpDT05GSUdfTUlQU19CT05JVE82ND15DQpDT05GSUdf
TUlQU19HVDY0MTIwPXkNCkNPTkZJR19NSVBTX01TQz15DQpDT05GSUdfTDFfQ0FDSEVfU0hJRlQ9
NQ0KQ09ORklHX05PTkNPSEVSRU5UX0lPPXkNCkNPTkZJR19TV0FQX0lPX1NQQUNFX1c9eQ0KQ09O
RklHX1NXQVBfSU9fU1BBQ0VfTD15DQpDT05GSUdfUENfS0VZQj15DQojIENPTkZJR19NSVBTX0FV
MTAwMCBpcyBub3Qgc2V0DQoNCiMNCiMgQ1BVIHNlbGVjdGlvbg0KIw0KQ09ORklHX0NQVV9NSVBT
MzI9eQ0KIyBDT05GSUdfQ1BVX01JUFM2NCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfUjMwMDAg
aXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1RYMzlYWCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVf
VlI0MVhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9SNDMwMCBpcyBub3Qgc2V0DQojIENPTkZJ
R19DUFVfUjRYMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1RYNDlYWCBpcyBub3Qgc2V0DQoj
IENPTkZJR19DUFVfUjUwMDAgaXMgbm90IHNldA0KIyBDT05GSUdfQ1BVX1I1NDMyIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0NQVV9SNjAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfTkVWQURBIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0NQVV9SODAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfUjEw
MDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NQVV9STTcwMDAgaXMgbm90IHNldA0KIyBDT05GSUdf
Q1BVX1JNOTAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfU0IxIGlzIG5vdCBzZXQNCkNPTkZJ
R19QQUdFX1NJWkVfNEtCPXkNCiMgQ09ORklHX1BBR0VfU0laRV8xNktCIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1BBR0VfU0laRV82NEtCIGlzIG5vdCBzZXQNCkNPTkZJR19DUFVfSEFTX1BSRUZFVENI
PXkNCiMgQ09ORklHX1ZUQUdfSUNBQ0hFIGlzIG5vdCBzZXQNCiMgQ09ORklHXzY0QklUX1BIWVNf
QUREUiBpcyBub3Qgc2V0DQojIENPTkZJR19DUFVfQURWQU5DRUQgaXMgbm90IHNldA0KQ09ORklH
X0NQVV9IQVNfTExTQz15DQojIENPTkZJR19DUFVfSEFTX0xMRFNDRCBpcyBub3Qgc2V0DQojIENP
TkZJR19DUFVfSEFTX1dCIGlzIG5vdCBzZXQNCkNPTkZJR19DUFVfSEFTX1NZTkM9eQ0KDQojDQoj
IEdlbmVyYWwgc2V0dXANCiMNCiMgQ09ORklHX0NQVV9MSVRUTEVfRU5ESUFOIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0JVSUxEX0VMRjY0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JJTkZNVF9JUklYIGlz
IG5vdCBzZXQNCkNPTkZJR19ORVQ9eQ0KQ09ORklHX1BDST15DQojIENPTkZJR19QQ0lfTkVXIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1BDSV9BVVRPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDSV9OQU1F
UyBpcyBub3Qgc2V0DQojIENPTkZJR19JU0EgaXMgbm90IHNldA0KIyBDT05GSUdfVEMgaXMgbm90
IHNldA0KIyBDT05GSUdfTUNBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NCVVMgaXMgbm90IHNldA0K
IyBDT05GSUdfSE9UUExVRyBpcyBub3Qgc2V0DQojIENPTkZJR19QQ01DSUEgaXMgbm90IHNldA0K
IyBDT05GSUdfSE9UUExVR19QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfU1lTVklQQyBpcyBub3Qg
c2V0DQojIENPTkZJR19CU0RfUFJPQ0VTU19BQ0NUIGlzIG5vdCBzZXQNCkNPTkZJR19TWVNDVEw9
eQ0KQ09ORklHX0tDT1JFX0VMRj15DQojIENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0JJTkZNVF9BT1VUIGlzIG5vdCBzZXQNCkNPTkZJR19CSU5GTVRfRUxGPXkNCiMgQ09O
RklHX01JUFMzMl9DT01QQVQgaXMgbm90IHNldA0KIyBDT05GSUdfTUlQUzMyX08zMiBpcyBub3Qg
c2V0DQojIENPTkZJR19NSVBTMzJfTjMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JJTkZNVF9FTEYz
MiBpcyBub3Qgc2V0DQojIENPTkZJR19CSU5GTVRfTUlTQyBpcyBub3Qgc2V0DQojIENPTkZJR19P
T01fS0lMTEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NNRExJTkVfQk9PTCBpcyBub3Qgc2V0DQoN
CiMNCiMgTWVtb3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQ0KIw0KIyBDT05GSUdfTVREIGlz
IG5vdCBzZXQNCg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQNCiMNCiMgQ09ORklHX1BBUlBP
UlQgaXMgbm90IHNldA0KDQojDQojIFBsdWcgYW5kIFBsYXkgY29uZmlndXJhdGlvbg0KIw0KIyBD
T05GSUdfUE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lTQVBOUCBpcyBub3Qgc2V0DQoNCiMNCiMg
QmxvY2sgZGV2aWNlcw0KIw0KIyBDT05GSUdfQkxLX0RFVl9GRCBpcyBub3Qgc2V0DQojIENPTkZJ
R19CTEtfREVWX1hEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUklERSBpcyBub3Qgc2V0DQojIENP
TkZJR19CTEtfQ1BRX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBu
b3Qgc2V0DQojIENPTkZJR19DSVNTX1NDU0lfVEFQRSBpcyBub3Qgc2V0DQojIENPTkZJR19DSVNT
X01PTklUT1JfVEhSRUFEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVU1FTSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW
X1NYOCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9MT09QPXkNCiMgQ09ORklHX0JMS19ERVZf
TkJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0JMS19ERVZfSU5JVFJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19TVEFUUyBpcyBub3Qgc2V0
DQoNCiMNCiMgTXVsdGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5kIExWTSkNCiMNCiMgQ09ORklH
X01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTUQgaXMgbm90IHNldA0KIyBDT05GSUdf
TURfTElORUFSIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX1JBSUQwIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01EX1JBSUQxIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX1JBSUQ1IGlzIG5vdCBzZXQNCiMg
Q09ORklHX01EX01VTFRJUEFUSCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0xWTSBpcyBu
b3Qgc2V0DQoNCiMNCiMgTmV0d29ya2luZyBvcHRpb25zDQojDQpDT05GSUdfUEFDS0VUPXkNCiMg
Q09ORklHX1BBQ0tFVF9NTUFQIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVExJTktfREVWIGlzIG5v
dCBzZXQNCkNPTkZJR19ORVRGSUxURVI9eQ0KIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0ZJTFRFUiBpcyBub3Qgc2V0DQpDT05GSUdfVU5JWD15DQpDT05GSUdf
SU5FVD15DQpDT05GSUdfSVBfTVVMVElDQVNUPXkNCkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9
eQ0KQ09ORklHX0lQX01VTFRJUExFX1RBQkxFUz15DQpDT05GSUdfSVBfUk9VVEVfRldNQVJLPXkN
CkNPTkZJR19JUF9ST1VURV9OQVQ9eQ0KQ09ORklHX0lQX1JPVVRFX01VTFRJUEFUSD15DQpDT05G
SUdfSVBfUk9VVEVfVE9TPXkNCiMgQ09ORklHX0lQX1JPVVRFX1ZFUkJPU0UgaXMgbm90IHNldA0K
Q09ORklHX0lQX1BOUD15DQpDT05GSUdfSVBfUE5QX0RIQ1A9eQ0KIyBDT05GSUdfSVBfUE5QX0JP
T1RQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX1BOUF9SQVJQIGlzIG5vdCBzZXQNCkNPTkZJR19O
RVRfSVBJUD1tDQpDT05GSUdfTkVUX0lQR1JFPW0NCkNPTkZJR19ORVRfSVBHUkVfQlJPQURDQVNU
PXkNCiMgQ09ORklHX0lQX01ST1VURSBpcyBub3Qgc2V0DQojIENPTkZJR19BUlBEIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0lORVRfRUNOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NZTl9DT09LSUVTIGlz
IG5vdCBzZXQNCg0KIw0KIyAgIElQOiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklH
X0lQX05GX0NPTk5UUkFDSz15DQpDT05GSUdfSVBfTkZfRlRQPXkNCiMgQ09ORklHX0lQX05GX0FN
QU5EQSBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9ORl9URlRQIGlzIG5vdCBzZXQNCkNPTkZJR19J
UF9ORl9JUkM9eQ0KQ09ORklHX0lQX05GX1FVRVVFPXkNCkNPTkZJR19JUF9ORl9JUFRBQkxFUz15
DQpDT05GSUdfSVBfTkZfTUFUQ0hfTElNSVQ9eQ0KQ09ORklHX0lQX05GX01BVENIX01BQz15DQpD
T05GSUdfSVBfTkZfTUFUQ0hfUEtUVFlQRT15DQpDT05GSUdfSVBfTkZfTUFUQ0hfTUFSSz15DQpD
T05GSUdfSVBfTkZfTUFUQ0hfTVVMVElQT1JUPXkNCkNPTkZJR19JUF9ORl9NQVRDSF9UT1M9eQ0K
IyBDT05GSUdfSVBfTkZfTUFUQ0hfUkVDRU5UIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9ORl9NQVRD
SF9FQ049eQ0KQ09ORklHX0lQX05GX01BVENIX0RTQ1A9eQ0KQ09ORklHX0lQX05GX01BVENIX0FI
X0VTUD15DQpDT05GSUdfSVBfTkZfTUFUQ0hfTEVOR1RIPXkNCkNPTkZJR19JUF9ORl9NQVRDSF9U
VEw9eQ0KQ09ORklHX0lQX05GX01BVENIX1RDUE1TUz15DQpDT05GSUdfSVBfTkZfTUFUQ0hfSEVM
UEVSPXkNCkNPTkZJR19JUF9ORl9NQVRDSF9TVEFURT15DQpDT05GSUdfSVBfTkZfTUFUQ0hfQ09O
TlRSQUNLPXkNCkNPTkZJR19JUF9ORl9NQVRDSF9VTkNMRUFOPXkNCkNPTkZJR19JUF9ORl9NQVRD
SF9PV05FUj15DQpDT05GSUdfSVBfTkZfRklMVEVSPXkNCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVK
RUNUPXkNCkNPTkZJR19JUF9ORl9UQVJHRVRfTUlSUk9SPXkNCkNPTkZJR19JUF9ORl9OQVQ9eQ0K
Q09ORklHX0lQX05GX05BVF9ORUVERUQ9eQ0KQ09ORklHX0lQX05GX1RBUkdFVF9NQVNRVUVSQURF
PXkNCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVESVJFQ1Q9eQ0KQ09ORklHX0lQX05GX05BVF9TTk1Q
X0JBU0lDPXkNCkNPTkZJR19JUF9ORl9OQVRfSVJDPXkNCkNPTkZJR19JUF9ORl9OQVRfRlRQPXkN
CkNPTkZJR19JUF9ORl9NQU5HTEU9eQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UT1M9eQ0KQ09ORklH
X0lQX05GX1RBUkdFVF9FQ049eQ0KQ09ORklHX0lQX05GX1RBUkdFVF9EU0NQPXkNCkNPTkZJR19J
UF9ORl9UQVJHRVRfTUFSSz15DQpDT05GSUdfSVBfTkZfVEFSR0VUX0xPRz15DQpDT05GSUdfSVBf
TkZfVEFSR0VUX1VMT0c9eQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UQ1BNU1M9eQ0KIyBDT05GSUdf
SVBfTkZfQVJQVEFCTEVTIGlzIG5vdCBzZXQNCg0KIw0KIyAgIElQOiBWaXJ0dWFsIFNlcnZlciBD
b25maWd1cmF0aW9uDQojDQojIENPTkZJR19JUF9WUyBpcyBub3Qgc2V0DQojIENPTkZJR19JUFY2
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0tIVFRQRCBpcyBub3Qgc2V0DQoNCiMNCiMgICAgU0NUUCBD
b25maWd1cmF0aW9uIChFWFBFUklNRU5UQUwpDQojDQojIENPTkZJR19JUF9TQ1RQIGlzIG5vdCBz
ZXQNCkNPTkZJR19BVE09eQ0KQ09ORklHX0FUTV9DTElQPXkNCkNPTkZJR19BVE1fQ0xJUF9OT19J
Q01QPXkNCiMgQ09ORklHX0FUTV9MQU5FIGlzIG5vdCBzZXQNCkNPTkZJR19BVE1fQlIyNjg0PXkN
CiMgQ09ORklHX0FUTV9CUjI2ODRfSVBGSUxURVIgaXMgbm90IHNldA0KIyBDT05GSUdfVkxBTl84
MDIxUSBpcyBub3Qgc2V0DQoNCiMNCiMgIA0KIw0KIyBDT05GSUdfSVBYIGlzIG5vdCBzZXQNCiMg
Q09ORklHX0FUQUxLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0DQpDT05G
SUdfQlJJREdFPXkNCiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0xMQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfRElWRVJUIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19XQU5fUk9VVEVSIGlz
IG5vdCBzZXQNCiMgQ09ORklHX05FVF9GQVNUUk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU
X0hXX0ZMT1dDT05UUk9MIGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVldWVp
bmcNCiMNCkNPTkZJR19ORVRfU0NIRUQ9eQ0KQ09ORklHX05FVF9TQ0hfQ0JRPXkNCkNPTkZJR19O
RVRfU0NIX0hUQj15DQojIENPTkZJR19ORVRfU0NIX0NTWiBpcyBub3Qgc2V0DQojIENPTkZJR19O
RVRfU0NIX0hGU0MgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1NDSF9BVE0gaXMgbm90IHNldA0K
Q09ORklHX05FVF9TQ0hfUFJJTz15DQpDT05GSUdfTkVUX1NDSF9SRUQ9eQ0KIyBDT05GSUdfTkVU
X1NDSF9TRlEgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1NDSF9URVFMIGlzIG5vdCBzZXQNCiMg
Q09ORklHX05FVF9TQ0hfVEJGIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9TQ0hfR1JFRCBpcyBu
b3Qgc2V0DQojIENPTkZJR19ORVRfU0NIX05FVEVNIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfU0NI
X0RTTUFSSz15DQpDT05GSUdfTkVUX1NDSF9JTkdSRVNTPXkNCkNPTkZJR19ORVRfUU9TPXkNCkNP
TkZJR19ORVRfRVNUSU1BVE9SPXkNCkNPTkZJR19ORVRfQ0xTPXkNCkNPTkZJR19ORVRfQ0xTX1RD
SU5ERVg9eQ0KQ09ORklHX05FVF9DTFNfUk9VVEU0PXkNCkNPTkZJR19ORVRfQ0xTX1JPVVRFPXkN
CkNPTkZJR19ORVRfQ0xTX0ZXPXkNCkNPTkZJR19ORVRfQ0xTX1UzMj15DQojIENPTkZJR19ORVRf
Q0xTX1JTVlAgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0NMU19SU1ZQNiBpcyBub3Qgc2V0DQpD
T05GSUdfTkVUX0NMU19QT0xJQ0U9eQ0KDQojDQojIE5ldHdvcmsgdGVzdGluZw0KIw0KIyBDT05G
SUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0DQoNCiMNCiMgVGVsZXBob255IFN1cHBvcnQNCiMNCiMg
Q09ORklHX1BIT05FIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BIT05FX0lYSiBpcyBub3Qgc2V0DQoj
IENPTkZJR19QSE9ORV9JWEpfUENNQ0lBIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvSURFL01GTS9S
TEwgc3VwcG9ydA0KIw0KIyBDT05GSUdfSURFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf
SEQgaXMgbm90IHNldA0KDQojDQojIFNDU0kgc3VwcG9ydA0KIw0KIyBDT05GSUdfU0NTSSBpcyBu
b3Qgc2V0DQoNCiMNCiMgRnVzaW9uIE1QVCBkZXZpY2Ugc3VwcG9ydA0KIw0KIyBDT05GSUdfRlVT
SU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZVU0lPTl9CT09UIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0ZVU0lPTl9JU0VOU0UgaXMgbm90IHNldA0KIyBDT05GSUdfRlVTSU9OX0NUTCBpcyBub3Qgc2V0
DQojIENPTkZJR19GVVNJT05fTEFOIGlzIG5vdCBzZXQNCg0KIw0KIyBJRUVFIDEzOTQgKEZpcmVX
aXJlKSBzdXBwb3J0IChFWFBFUklNRU5UQUwpDQojDQojIENPTkZJR19JRUVFMTM5NCBpcyBub3Qg
c2V0DQoNCiMNCiMgSTJPIGRldmljZSBzdXBwb3J0DQojDQojIENPTkZJR19JMk8gaXMgbm90IHNl
dA0KIyBDT05GSUdfSTJPX1BDSSBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fQkxPQ0sgaXMgbm90
IHNldA0KIyBDT05GSUdfSTJPX0xBTiBpcyBub3Qgc2V0DQojIENPTkZJR19JMk9fU0NTSSBpcyBu
b3Qgc2V0DQojIENPTkZJR19JMk9fUFJPQyBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29yayBkZXZp
Y2Ugc3VwcG9ydA0KIw0KQ09ORklHX05FVERFVklDRVM9eQ0KDQojDQojIEFSQ25ldCBkZXZpY2Vz
DQojDQojIENPTkZJR19BUkNORVQgaXMgbm90IHNldA0KQ09ORklHX0RVTU1ZPXkNCiMgQ09ORklH
X0JPTkRJTkcgaXMgbm90IHNldA0KIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1RVTiBpcyBub3Qgc2V0DQojIENPTkZJR19FVEhFUlRBUCBpcyBub3Qgc2V0DQoNCiMNCiMg
RXRoZXJuZXQgKDEwIG9yIDEwME1iaXQpDQojDQpDT05GSUdfTkVUX0VUSEVSTkVUPXkNCiMgQ09O
RklHX1NVTkxBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hBUFBZTUVBTCBpcyBub3Qgc2V0DQoj
IENPTkZJR19TVU5CTUFDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NVTlFFIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NVTkdFTSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SXzNDT00gaXMgbm90
IHNldA0KIyBDT05GSUdfTEFOQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9TTUMg
aXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9SQUNBTCBpcyBub3Qgc2V0DQojIENPTkZJ
R19IUDEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVNBIGlzIG5vdCBzZXQNCkNPTkZJR19O
RVRfUENJPXkNCkNPTkZJR19QQ05FVDMyPXkNCkNPTkZJR19BTUQ4MTExX0VUSD15DQojIENPTkZJ
R19BREFQVEVDX1NUQVJGSVJFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FQUklDT1QgaXMgbm90IHNl
dA0KIyBDT05GSUdfQjQ0IGlzIG5vdCBzZXQNCiMgQ09ORklHX0NTODl4MCBpcyBub3Qgc2V0DQoj
IENPTkZJR19UVUxJUCBpcyBub3Qgc2V0DQojIENPTkZJR19ERTRYNSBpcyBub3Qgc2V0DQojIENP
TkZJR19ER1JTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RNOTEwMiBpcyBub3Qgc2V0DQpDT05GSUdf
RUVQUk8xMDA9bQ0KIyBDT05GSUdfRUVQUk8xMDBfUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0Ux
MDAgaXMgbm90IHNldA0KIyBDT05GSUdfTE5FMzkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZFQUxO
WCBpcyBub3Qgc2V0DQojIENPTkZJR19OQVRTRU1JIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FMktf
UENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZPUkNFREVUSCBpcyBub3Qgc2V0DQojIENPTkZJR19O
RTMyMTAgaXMgbm90IHNldA0KIyBDT05GSUdfRVMzMjEwIGlzIG5vdCBzZXQNCiMgQ09ORklHXzgx
MzlDUCBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9PIGlzIG5vdCBzZXQNCiMgQ09ORklHXzgx
MzlUT09fUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHXzgxMzlUT09fVFVORV9UV0lTVEVSIGlzIG5v
dCBzZXQNCiMgQ09ORklHXzgxMzlUT09fODEyOSBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5X09M
RF9SWF9SRVNFVCBpcyBub3Qgc2V0DQojIENPTkZJR19TSVM5MDAgaXMgbm90IHNldA0KIyBDT05G
SUdfRVBJQzEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qgc2V0DQojIENP
TkZJR19TVU5EQU5DRV9NTUlPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RMQU4gaXMgbm90IHNldA0K
IyBDT05GSUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJQV9SSElORV9NTUlPIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1dJTkJPTkRfODQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xBTl9T
QUE5NzMwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9QT0NLRVQgaXMgbm90IHNldA0KDQojDQoj
IEV0aGVybmV0ICgxMDAwIE1iaXQpDQojDQojIENPTkZJR19BQ0VOSUMgaXMgbm90IHNldA0KIyBD
T05GSUdfREwySyBpcyBub3Qgc2V0DQojIENPTkZJR19FMTAwMCBpcyBub3Qgc2V0DQojIENPTkZJ
R19NWVJJX1NCVVMgaXMgbm90IHNldA0KIyBDT05GSUdfTlM4MzgyMCBpcyBub3Qgc2V0DQojIENP
TkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1lFTExPV0ZJTiBpcyBub3Qgc2V0DQoj
IENPTkZJR19SODE2OSBpcyBub3Qgc2V0DQojIENPTkZJR19TSzk4TElOIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1RJR09OMyBpcyBub3Qgc2V0DQojIENPTkZJR19GRERJIGlzIG5vdCBzZXQNCiMgQ09O
RklHX0hJUFBJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BMSVAgaXMgbm90IHNldA0KQ09ORklHX1BQ
UD15DQojIENPTkZJR19QUFBfTVVMVElMSU5LIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BQUF9GSUxU
RVIgaXMgbm90IHNldA0KIyBDT05GSUdfUFBQX0FTWU5DIGlzIG5vdCBzZXQNCkNPTkZJR19QUFBf
U1lOQ19UVFk9eQ0KQ09ORklHX1BQUF9ERUZMQVRFPXkNCiMgQ09ORklHX1BQUF9CU0RDT01QIGlz
IG5vdCBzZXQNCkNPTkZJR19QUFBPRT15DQpDT05GSUdfUFBQT0FUTT15DQojIENPTkZJR19TTElQ
IGlzIG5vdCBzZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRpbykNCiMNCiMgQ09O
RklHX05FVF9SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgVG9rZW4gUmluZyBkZXZpY2VzDQojDQoj
IENPTkZJR19UUiBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldA0KIyBDT05G
SUdfUkNQQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfU0hBUEVSIGlzIG5vdCBzZXQNCg0KIw0KIyBX
YW4gaW50ZXJmYWNlcw0KIw0KIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQNCg0KIw0KIyBBVE0gZHJp
dmVycw0KIw0KIyBDT05GSUdfQVRNX1RDUCBpcyBub3Qgc2V0DQojIENPTkZJR19BVE1fTEFOQUkg
aXMgbm90IHNldA0KIyBDT05GSUdfQVRNX0VOSSBpcyBub3Qgc2V0DQojIENPTkZJR19BVE1fRklS
RVNUUkVBTSBpcyBub3Qgc2V0DQojIENPTkZJR19BVE1fWkFUTSBpcyBub3Qgc2V0DQpDT05GSUdf
QVRNX05JQ1NUQVI9bQ0KQ09ORklHX0FUTV9OSUNTVEFSX1VTRV9TVU5JPXkNCkNPTkZJR19BVE1f
TklDU1RBUl9VU0VfSURUNzcxMDU9eQ0KIyBDT05GSUdfQVRNX0lEVDc3MjUyIGlzIG5vdCBzZXQN
CiMgQ09ORklHX0FUTV9BTUJBU1NBRE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTV9IT1JJWk9O
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTV9JQSBpcyBub3Qgc2V0DQojIENPTkZJR19BVE1fRk9S
RTIwMEVfTUFZQkUgaXMgbm90IHNldA0KIyBDT05GSUdfQVRNX0hFIGlzIG5vdCBzZXQNCg0KIw0K
IyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQNCiMNCiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQN
Cg0KIw0KIyBJckRBIChpbmZyYXJlZCkgc3VwcG9ydA0KIw0KIyBDT05GSUdfSVJEQSBpcyBub3Qg
c2V0DQoNCiMNCiMgSVNETiBzdWJzeXN0ZW0NCiMNCiMgQ09ORklHX0lTRE4gaXMgbm90IHNldA0K
DQojDQojIElucHV0IGNvcmUgc3VwcG9ydA0KIw0KIyBDT05GSUdfSU5QVVQgaXMgbm90IHNldA0K
IyBDT05GSUdfSU5QVVRfS0VZQkRFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9NT1VTRURF
ViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9KT1lERVYgaXMgbm90IHNldA0KIyBDT05GSUdf
SU5QVVRfRVZERVYgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfVUlOUFVUIGlzIG5vdCBzZXQN
Cg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KIyBDT05GSUdfVlQgaXMgbm90IHNldA0KQ09O
RklHX1NFUklBTD15DQpDT05GSUdfU0VSSUFMX0NPTlNPTEU9eQ0KIyBDT05GSUdfU0VSSUFMX0VY
VEVOREVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qgc2V0
DQpDT05GSUdfVU5JWDk4X1BUWVM9eQ0KQ09ORklHX1VOSVg5OF9QVFlfQ09VTlQ9MzINCg0KIw0K
IyBJMkMgc3VwcG9ydA0KIw0KIyBDT05GSUdfSTJDIGlzIG5vdCBzZXQNCg0KIw0KIyBNaWNlDQoj
DQojIENPTkZJR19CVVNNT1VTRSBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRSBpcyBub3Qgc2V0
DQoNCiMNCiMgSm95c3RpY2tzDQojDQojIENPTkZJR19JTlBVVF9HQU1FUE9SVCBpcyBub3Qgc2V0
DQoNCiMNCiMgSW5wdXQgY29yZSBzdXBwb3J0IGlzIG5lZWRlZCBmb3IgZ2FtZXBvcnRzDQojDQoN
CiMNCiMgSW5wdXQgY29yZSBzdXBwb3J0IGlzIG5lZWRlZCBmb3Igam95c3RpY2tzDQojDQojIENP
TkZJR19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQTUlfSEFORExFUiBpcyBub3Qg
c2V0DQojIENPTkZJR19JUE1JX1BBTklDX0VWRU5UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQTUlf
REVWSUNFX0lOVEVSRkFDRSBpcyBub3Qgc2V0DQojIENPTkZJR19JUE1JX0tDUyBpcyBub3Qgc2V0
DQojIENPTkZJR19JUE1JX1dBVENIRE9HIGlzIG5vdCBzZXQNCg0KIw0KIyBXYXRjaGRvZyBDYXJk
cw0KIw0KIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBDT05GSUdfU0N4MjAwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1NDeDIwMF9HUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FNRF9QTTc2
OCBpcyBub3Qgc2V0DQojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0DQpDT05GSUdfUlRDPXkNCiMg
Q09ORklHX0RUTEsgaXMgbm90IHNldA0KIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldA0KIyBDT05G
SUdfQVBQTElDT00gaXMgbm90IHNldA0KDQojDQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2
aWNlIGRyaXZlcg0KIw0KIyBDT05GSUdfRlRBUEUgaXMgbm90IHNldA0KIyBDT05GSUdfQUdQIGlz
IG5vdCBzZXQNCg0KIw0KIyBEaXJlY3QgUmVuZGVyaW5nIE1hbmFnZXIgKFhGcmVlODYgRFJJIHN1
cHBvcnQpDQojDQojIENPTkZJR19EUk0gaXMgbm90IHNldA0KDQojDQojIEZpbGUgc3lzdGVtcw0K
Iw0KIyBDT05GSUdfUVVPVEEgaXMgbm90IHNldA0KIyBDT05GSUdfUUZNVF9WMiBpcyBub3Qgc2V0
DQojIENPTkZJR19BVVRPRlNfRlMgaXMgbm90IHNldA0KQ09ORklHX0FVVE9GUzRfRlM9bQ0KIyBD
T05GSUdfUkVJU0VSRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMg
bm90IHNldA0KIyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5vdCBzZXQNCiMgQ09ORklH
X0FERlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQURGU19GU19SVyBpcyBub3Qgc2V0DQojIENP
TkZJR19BRkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0DQojIENP
TkZJR19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldA0K
IyBDT05GSUdfQkVGU19ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19CRlNfRlMgaXMgbm90IHNl
dA0KIyBDT05GSUdfRVhUM19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KQkQgaXMgbm90IHNldA0K
IyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZBVF9GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19NU0RPU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19VTVNET1NfRlMgaXMgbm90
IHNldA0KIyBDT05GSUdfVkZBVF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19FRlNfRlMgaXMgbm90
IHNldA0KIyBDT05GSUdfSkZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KRkZTMl9GUyBpcyBu
b3Qgc2V0DQpDT05GSUdfQ1JBTUZTPXkNCiMgQ09ORklHX1RNUEZTIGlzIG5vdCBzZXQNCkNPTkZJ
R19SQU1GUz15DQojIENPTkZJR19JU085NjYwX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pPTElF
VCBpcyBub3Qgc2V0DQojIENPTkZJR19aSVNPRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSkZTX0ZT
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGU19ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19KRlNf
U1RBVElTVElDUyBpcyBub3Qgc2V0DQojIENPTkZJR19NSU5JWF9GUyBpcyBub3Qgc2V0DQojIENP
TkZJR19WWEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05URlNfRlMgaXMgbm90IHNldA0KIyBD
T05GSUdfTlRGU19SVyBpcyBub3Qgc2V0DQojIENPTkZJR19IUEZTX0ZTIGlzIG5vdCBzZXQNCkNP
TkZJR19QUk9DX0ZTPXkNCiMgQ09ORklHX0RFVkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RF
VkZTX01PVU5UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFVkZTX0RFQlVHIGlzIG5vdCBzZXQNCkNP
TkZJR19ERVZQVFNfRlM9eQ0KIyBDT05GSUdfUU5YNEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1FOWDRGU19SVyBpcyBub3Qgc2V0DQojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0DQpDT05G
SUdfRVhUMl9GUz15DQojIENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VERl9G
UyBpcyBub3Qgc2V0DQojIENPTkZJR19VREZfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfVUZTX0ZT
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GU19XUklURSBpcyBub3Qgc2V0DQojIENPTkZJR19Y
RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfWEZTX1FVT1RBIGlzIG5vdCBzZXQNCiMgQ09ORklH
X1hGU19SVCBpcyBub3Qgc2V0DQojIENPTkZJR19YRlNfVFJBQ0UgaXMgbm90IHNldA0KIyBDT05G
SUdfWEZTX0RFQlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3b3JrIEZpbGUgU3lzdGVtcw0KIw0K
IyBDT05GSUdfQ09EQV9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19JTlRFUk1FWlpPX0ZTIGlzIG5v
dCBzZXQNCkNPTkZJR19ORlNfRlM9eQ0KQ09ORklHX05GU19WMz15DQojIENPTkZJR19ORlNfRElS
RUNUSU8gaXMgbm90IHNldA0KQ09ORklHX1JPT1RfTkZTPXkNCiMgQ09ORklHX05GU0QgaXMgbm90
IHNldA0KIyBDT05GSUdfTkZTRF9WMyBpcyBub3Qgc2V0DQojIENPTkZJR19ORlNEX1RDUCBpcyBu
b3Qgc2V0DQpDT05GSUdfU1VOUlBDPXkNCkNPTkZJR19MT0NLRD15DQpDT05GSUdfTE9DS0RfVjQ9
eQ0KIyBDT05GSUdfU01CX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0
DQojIENPTkZJR19OQ1BGU19QQUNLRVRfU0lHTklORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG
U19JT0NUTF9MT0NLSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1NUUk9ORyBpcyBub3Qg
c2V0DQojIENPTkZJR19OQ1BGU19ORlNfTlMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfT1My
X05TIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1NNQUxMRE9TIGlzIG5vdCBzZXQNCiMgQ09O
RklHX05DUEZTX05MUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19FWFRSQVMgaXMgbm90IHNl
dA0KIyBDT05GSUdfWklTT0ZTX0ZTIGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJ0aXRpb24gVHlwZXMN
CiMNCiMgQ09ORklHX1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfTVNET1Nf
UEFSVElUSU9OPXkNCiMgQ09ORklHX1NNQl9OTFMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTIGlz
IG5vdCBzZXQNCg0KIw0KIyBNdWx0aW1lZGlhIGRldmljZXMNCiMNCiMgQ09ORklHX1ZJREVPX0RF
ViBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQNCiMNCiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQN
Cg0KIw0KIyBVU0Igc3VwcG9ydA0KIw0KQ09ORklHX1VTQj15DQojIENPTkZJR19VU0JfREVCVUcg
aXMgbm90IHNldA0KDQojDQojIE1pc2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMNCiMNCkNPTkZJR19V
U0JfREVWSUNFRlM9eQ0KIyBDT05GSUdfVVNCX0JBTkRXSURUSCBpcyBub3Qgc2V0DQoNCiMNCiMg
VVNCIEhvc3QgQ29udHJvbGxlciBEcml2ZXJzDQojDQojIENPTkZJR19VU0JfRUhDSV9IQ0QgaXMg
bm90IHNldA0KQ09ORklHX1VTQl9VSENJX0FMVD15DQojIENPTkZJR19VU0JfT0hDSSBpcyBub3Qg
c2V0DQoNCiMNCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzDQojDQojIENPTkZJR19VU0JfQVVE
SU8gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0VNSTI2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT
Ql9CTFVFVE9PVEggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX01JREkgaXMgbm90IHNldA0KDQoj
DQojICAgU0NTSSBzdXBwb3J0IGlzIG5lZWRlZCBmb3IgVVNCIFN0b3JhZ2UNCiMNCiMgQ09ORklH
X1VTQl9TVE9SQUdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RFQlVHIGlzIG5v
dCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RBVEFGQUIgaXMgbm90IHNldA0KIyBDT05GSUdf
VVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9JU0Qy
MDAgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfRFBDTSBpcyBub3Qgc2V0DQojIENP
TkZJR19VU0JfU1RPUkFHRV9IUDgyMDBlIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdF
X1NERFIwOSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9TRERSNTUgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVNUFNIT1QgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X0FDTSBpcyBub3Qgc2V0DQpDT05GSUdfVVNCX1BSSU5URVI9eQ0KDQojDQojIFVTQiBIdW1hbiBJ
bnRlcmZhY2UgRGV2aWNlcyAoSElEKQ0KIw0KIyBDT05GSUdfVVNCX0hJRCBpcyBub3Qgc2V0DQoN
CiMNCiMgICAgIElucHV0IGNvcmUgc3VwcG9ydCBpcyBuZWVkZWQgZm9yIFVTQiBISUQgaW5wdXQg
bGF5ZXIgb3IgSElEQlAgc3VwcG9ydA0KIw0KIyBDT05GSUdfVVNCX0hJRElOUFVUIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX1VTQl9ISURERVYgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0tCRCBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfTU9VU0UgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0FJUFRF
SyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfV0FDT00gaXMgbm90IHNldA0KIyBDT05GSUdfVVNC
X0tCVEFCIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9QT1dFUk1BVEUgaXMgbm90IHNldA0KDQoj
DQojIFVTQiBJbWFnaW5nIGRldmljZXMNCiMNCiMgQ09ORklHX1VTQl9EQzJYWCBpcyBub3Qgc2V0
DQojIENPTkZJR19VU0JfTURDODAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TQ0FOTkVSIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9NSUNST1RFSyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf
SFBVU0JTQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBVU0IgTXVsdGltZWRpYSBkZXZpY2VzDQojDQoN
CiMNCiMgICBWaWRlbzRMaW51eCBzdXBwb3J0IGlzIG5lZWRlZCBmb3IgVVNCIE11bHRpbWVkaWEg
ZGV2aWNlIHN1cHBvcnQNCiMNCg0KIw0KIyBVU0IgTmV0d29yayBhZGFwdG9ycw0KIw0KIyBDT05G
SUdfVVNCX1BFR0FTVVMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX0tBV0VUSCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQ0FUQyBpcyBu
b3Qgc2V0DQojIENPTkZJR19VU0JfQ0RDRVRIRVIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1VT
Qk5FVCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIHBvcnQgZHJpdmVycw0KIw0KIyBDT05GSUdfVVNC
X1VTUzcyMCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIFNlcmlhbCBDb252ZXJ0ZXIgc3VwcG9ydA0K
Iw0KIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIE1pc2NlbGxhbmVv
dXMgZHJpdmVycw0KIw0KIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0DQojIENPTkZJR19V
U0JfQVVFUlNXQUxEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9USUdMIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1VTQl9CUkxWR0VSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNl
dA0KIyBDT05GSUdfVVNCX1NQRUVEVE9VQ0ggaXMgbm90IHNldA0KDQojDQojIFN1cHBvcnQgZm9y
IFVTQiBnYWRnZXRzDQojDQojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQNCg0KIw0KIyBC
bHVldG9vdGggc3VwcG9ydA0KIw0KIyBDT05GSUdfQkxVRVogaXMgbm90IHNldA0KDQojDQojIEtl
cm5lbCBoYWNraW5nDQojDQpDT05GSUdfQ1JPU1NDT01QSUxFPXkNCiMgQ09ORklHX1JVTlRJTUVf
REVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdfS0dEQiBpcyBub3Qgc2V0DQojIENPTkZJR19HREJf
Q09OU09MRSBpcyBub3Qgc2V0DQojIENPTkZJR19ERUJVR19JTkZPIGlzIG5vdCBzZXQNCiMgQ09O
RklHX01BR0lDX1NZU1JRIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JUFNfVU5DQUNIRUQgaXMgbm90
IHNldA0KQ09ORklHX0xPR19CVUZfU0hJRlQ9MA0KDQojDQojIENyeXB0b2dyYXBoaWMgb3B0aW9u
cw0KIw0KIyBDT05GSUdfQ1JZUFRPIGlzIG5vdCBzZXQNCg0KIw0KIyBMaWJyYXJ5IHJvdXRpbmVz
DQojDQojIENPTkZJR19DUkMzMiBpcyBub3Qgc2V0DQpDT05GSUdfWkxJQl9JTkZMQVRFPXkNCkNP
TkZJR19aTElCX0RFRkxBVEU9eQ0K
------=_Part_22374_30420151.1120658978796--

From sskowron@ET.PUT.Poznan.PL Wed Jul  6 16:22:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 16:22:28 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:54929
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226339AbVGFPWN>; Wed, 6 Jul 2005 16:22:13 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j66FMaT28820;
	Wed, 6 Jul 2005 17:22:36 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Wed, 6 Jul 2005 17:22:36 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j66FMZS18239;
	Wed, 6 Jul 2005 17:22:35 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Wed, 6 Jul 2005 17:22:35 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Arianna Arona <arianna@dsi.unimi.it>
cc:	linux-mips@linux-mips.org
Subject: Re: 2.6.12 DOES read MAC address
In-Reply-To: <200507061448.02561.arianna@dsi.unimi.it>
Message-ID: <Pine.GSO.4.10.10507061721540.18065-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8372
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 328
Lines: 10

> I have a question: how is your ethernet card? Mine is a card with network, 2 
> consoles and a SCSI port in it. Could be this the problem?

Are you sure about the SCSI port? Can you give me the SGI part#
(030-xxxx-xxx)? It should be stamped on the board. If it's 030-1155-xxx,
it's a CADduo and verified working.

Stanislaw



From ralf@linux-mips.org Wed Jul  6 16:47:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 16:48:12 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:19463 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226342AbVGFPrw>; Wed, 6 Jul 2005 16:47:52 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j66Fm4Wk024905;
	Wed, 6 Jul 2005 16:48:04 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j66Fm4LK024904;
	Wed, 6 Jul 2005 16:48:04 +0100
Date:	Wed, 6 Jul 2005 16:48:04 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Arianna Arona <arianna@dsi.unimi.it>, linux-mips@linux-mips.org
Subject: Re: 2.6.12 DOES read MAC address
Message-ID: <20050706154804.GQ3226@linux-mips.org>
References: <200507061448.02561.arianna@dsi.unimi.it> <Pine.GSO.4.10.10507061721540.18065-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10507061721540.18065-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8373
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 438
Lines: 12

On Wed, Jul 06, 2005 at 05:22:35PM +0200, Stanislaw Skowronek wrote:

> > I have a question: how is your ethernet card? Mine is a card with network, 2 
> > consoles and a SCSI port in it. Could be this the problem?
> 
> Are you sure about the SCSI port? Can you give me the SGI part#
> (030-xxxx-xxx)? It should be stamped on the board. If it's 030-1155-xxx,
> it's a CADduo and verified working.

It's eth0, so the onboard card.

  Ralf

From arianna@dsi.unimi.it Wed Jul  6 16:51:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 16:51:31 +0100 (BST)
Received: from mercurio.srv.dsi.unimi.it ([IPv6:::ffff:159.149.130.201]:38043
	"EHLO mercurio.srv.dsi.unimi.it") by linux-mips.org with ESMTP
	id <S8226342AbVGFPvQ>; Wed, 6 Jul 2005 16:51:16 +0100
Received: from thetys.sm.dsi.unimi.it (tethys.sm.dsi.unimi.it [159.149.132.22])
	by mercurio.srv.dsi.unimi.it (8.13.3/8.13.3) with ESMTP id j66FpXcT001584;
	Wed, 6 Jul 2005 17:51:33 +0200
From:	Arianna Arona <arianna@dsi.unimi.it>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Subject: Re: 2.6.12 DOES read MAC address
Date:	Wed, 6 Jul 2005 17:52:23 +0200
User-Agent: KMail/1.5.4
Cc:	linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10507061721540.18065-100000@helios.et.put.poznan.pl>
In-Reply-To: <Pine.GSO.4.10.10507061721540.18065-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507061752.23534.arianna@dsi.unimi.it>
X-DSI-MailScanner-Information: Please contact the staff for more information
X-DSI-MailScanner: Found to be clean
X-MailScanner-From: arianna@dsi.unimi.it
Return-Path: <arianna@dsi.unimi.it>
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: 8374
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: arianna@dsi.unimi.it
Precedence: bulk
X-list: linux-mips
Content-Length: 410
Lines: 17

On Wednesday 06 July 2005 17:22, Stanislaw Skowronek wrote:

> Are you sure about the SCSI port? Can you give me the SGI part#
> (030-xxxx-xxx)? It should be stamped on the board. If it's 030-1155-xxx,
> it's a CADduo and verified working.

there is a label "040-1388-002 REV. A BERMO USA 9912"

A.

-- 
Arianna Arona
Servizi Informatici
Dipartimento di Scienze dell'Informazione
Via Comelico 39
20135 Milano


From rolfliu@gmail.com Wed Jul  6 17:21:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 17:21:23 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.203]:15625 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226345AbVGFQVG> convert rfc822-to-8bit;
	Wed, 6 Jul 2005 17:21:06 +0100
Received: by wproxy.gmail.com with SMTP id i22so1087068wra
        for <linux-mips@linux-mips.org>; Wed, 06 Jul 2005 09:21:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=kEXoemsOFANWsPAiGNbGsujYpc7cZwMB9wkUFoJxk5lBokLFOX/Mo9kaTOafgFMQ0Oq7cc4qLpyO/LNIliymzZDKy3FkPIGO0cW99pxB4odrywH/PpyZNN+y2Uu57m09PCpxG0ClNevOJUoMog5L4deEmnq9elKk/7FcQDrPeIY=
Received: by 10.54.80.7 with SMTP id d7mr412528wrb;
        Wed, 06 Jul 2005 09:21:20 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Wed, 6 Jul 2005 09:21:20 -0700 (PDT)
Message-ID: <2db32b7205070609215b750fea@mail.gmail.com>
Date:	Wed, 6 Jul 2005 09:21:20 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: possible serial driver fixup for au1x00 in 2.6?
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120633817.5724.26.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b720507011756247735d6@mail.gmail.com>
	 <1120266383.5987.46.camel@localhost.localdomain>
	 <2db32b72050705124078a48aed@mail.gmail.com>
	 <1120633817.5724.26.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8375
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1404
Lines: 45

Hi Pete,
I just give 8250.c a dirty hack, letting it just manage the additional
serial ports. So there are two serial driver in the system at the same
time :(  Sound funny.

thanks for your comments. I will give the feadback when I get more :)


On 7/6/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Tue, 2005-07-05 at 12:40 -0700, rolf liu wrote:
> > Pete,
> > To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> > au1x00_uart.c config and just compiled in the 8250 support. When I
> > boot the kernel, nothing comes up through the console, which should be
> > provided by 8250 support, by 8250_early.c?
> >
> > Any idea?
> 
> Yes. The 8250.c won't work with the au1x uart. I know I said in a
> previous email that the 8250 "basically" does the same thing as the au1x
> uart driver, but if the 8250 worked with the Au1x SoCs, why would we
> even have the au1x serial driver in place?
> 
> Pete
> 
> >
> > On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > > On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > > > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> > >
> > > Basically.
> > >
> > > > If I want
> > > > to add extra serial port support by 8250.c. There could be some
> > > > problem. Any idea?
> > >
> > > Don't know, haven't tried it. In general, the au1x00 serial driver needs
> > > to be rewritten.
> > >
> > > Pete
> > >
> > >
> >
> 
>

From rolfliu@gmail.com Wed Jul  6 23:15:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 23:15:53 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.194]:39510 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226152AbVGFWPi> convert rfc822-to-8bit;
	Wed, 6 Jul 2005 23:15:38 +0100
Received: by wproxy.gmail.com with SMTP id i30so59264wra
        for <linux-mips@linux-mips.org>; Wed, 06 Jul 2005 15:15:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=YFm55Dv0yQCFuH8P3uDtTGFCuiIjZI/9JHdGu4nYvtRQ1l9AbUQCtMqp1xo/V1zxZrlY6/5XisLkP17fNg+D9DUsgPjWY0N5hmnz1PwwwKRZbuvKP5up078FFH0L1/df+U7UZTBDlr3qFqHhWorHC8ASzefrp+n78kJhTCnnCBo=
Received: by 10.54.16.77 with SMTP id 77mr90520wrp;
        Wed, 06 Jul 2005 15:15:57 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Wed, 6 Jul 2005 15:15:57 -0700 (PDT)
Message-ID: <2db32b72050706151542b4dd93@mail.gmail.com>
Date:	Wed, 6 Jul 2005 15:15:57 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120633934.5724.29.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120633934.5724.29.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8376
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3459
Lines: 87

Pete,
could you give me some clues how I can make hpt371n work under linux 2.6? 
Is there a need to force the 371n to use 372n timing? 
can just timing issue cause the kernel to crash (panic)? 

Thanks


On 7/6/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Tue, 2005-07-05 at 08:50 -0700, rolf liu wrote:
> > Pete,
> > I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> > didn't force it to use 372 timing, it just hangs up after it detect
> > the drive. If I used the 372 timing using the 2.4 trick, the kernel
> > just crashed. Any clue?
> 
> Other than the call trace you can see below, no, no clues. I would have
> to spend some time debugging it and if it ever becomes a priority, I
> will.
> 
> Pete
> 
> > Thanks
> >
> > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > HPT371: IDE controller at PCI slot 0000:00:0b.0
> > PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> > HPT371: chipset revision 2
> > hpt: HPT372N detected, using 372N timing.
> > FREQ: 73 PLL: 35
> > HPT371: 100% native mode on irq 5
> > hpt: no known IDE timings, disabling DMA.
> > hpt: no known IDE timings, disabling DMA.
> > hdg: IBM-DTTA-350840, ATA DISK drive
> > CPU 0 Unable to handle kernel paging request at virtual address
> > 00000000, epc == 8029fb20, ra == 8029fc0c
> > Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
> > Cpu 0
> > $ 0   : 00000000 1000fc00 00000000 00000000
> > $ 4   : 0000000c 00000000 00010000 18010017
> > $ 8   : 00000000 0000fc00 00000000 803a6000
> > $12   : 803ace64 fffffffb ffffffff 0000140d
> > $16   : 00000048 00000055 30070000 00000001
> > $20   : 804a1800 0000000c 8043a678 8043a5f8
> > $24   : 00000000 802a747c
> > $28   : 811de000 811dfe40 1000fc01 8029fc0c
> > Hi    : 0000018a
> > Lo    : 3d6edc00
> > epc   : 8029fb20 pci_bus_clock_list+0x0/0x38     Not tainted
> > ra    : 8029fc0c hpt372_tune_chipset+0xb4/0x138
> > Status: 1000fc03    KERNEL EXL IE
> > Cause : 00800008
> > BadVA : 00000000
> > PrId  : 03030200
> > Modules linked in:
> > Process swapper (pid: 1, threadinfo=811de000, task=80456bf0)
> > Stack : 804a1800 00000005 8029f62c 80456bf0 00000000 00000000 804a1800 0000000c
> >         8043a678 00000001 00000000 803b0000 00000005 8029fcf8 8043a678 8043a5e8
> >         00000000 00000001 00000000 803b0000 00000005 8043a5f8 8043a678 8043a5e8
> >         00000000 00000001 00000000 803b0000 00000005 802abd0c 00000005 8043a5f8
> >         b0400074 b040006c 00000001 811dff30 00000000 00000000 00000000 8043a5e8
> >         ...
> > Call Trace:
> >  [<8029f62c>] hpt_minimum_revision+0x2c/0xec
> >  [<8029fcf8>] hpt3xx_tune_chipset+0x68/0x2e8
> >  [<802abd0c>] probe_hwif+0x8a4/0x910
> >  [<802ace2c>] probe_hwif_init_with_fixup+0x1c/0xcc
> >  [<802af8bc>] ide_setup_pci_device+0xa8/0xcc
> >  [<8024f09c>] idr_get_new+0x18/0x4c
> >  [<80422e38>] ide_scan_pcidev+0x84/0xc4
> >  [<801c5464>] proc_register+0x48/0x16c
> >  [<80422eb0>] ide_scan_pcibus+0x38/0xf8
> >  [<801c5874>] proc_mkdir_mode+0x54/0x80
> >  [<80422d98>] ide_init+0x68/0x84
> >  [<80422d7c>] ide_init+0x4c/0x84
> >  [<801004f8>] init+0x9c/0x264
> >  [<80105e20>] kernel_thread_helper+0x10/0x18
> >  [<80105e10>] kernel_thread_helper+0x0/0x18
> >
> >
> > Code: 02002821  080a7e5f  a3a20013 <90a20000> 10400008  308400ff
> > 00401821  10640007  00000000
> > Kernel panic - not syncing: Attempted to kill init!
> >
> 
>

From ppopov@embeddedalley.com Wed Jul  6 23:21:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Jul 2005 23:21:51 +0100 (BST)
Received: from smtp003.bizmail.yahoo.com ([IPv6:::ffff:216.136.130.195]:11413
	"HELO smtp003.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226152AbVGFWVe>; Wed, 6 Jul 2005 23:21:34 +0100
Received: (qmail 63964 invoked from network); 6 Jul 2005 22:21:58 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp003.bizmail.yahoo.com with SMTP; 6 Jul 2005 22:21:57 -0000
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b72050706151542b4dd93@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120633934.5724.29.camel@localhost.localdomain>
	 <2db32b72050706151542b4dd93@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Wed, 06 Jul 2005 15:22:01 -0700
Message-Id: <1120688521.5724.115.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8377
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: 534
Lines: 17

On Wed, 2005-07-06 at 15:15 -0700, rolf liu wrote:
> Pete,
> could you give me some clues how I can make hpt371n work under linux 2.6? 
> Is there a need to force the 371n to use 372n timing? 

No idea. If I knew what the problem may be off the top of my head, I
would have just fixed it. The only thing I can tell you is that you'll
have to debug the problem, find the root cause, fix it, and then
hopefully send the list a patch :)

> can just timing issue cause the kernel to crash (panic)? 

I wouldn't rule out anything.

Pete



From rolfliu@gmail.com Thu Jul  7 00:12:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 00:12:29 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.193]:54599 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226160AbVGFXMO> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 00:12:14 +0100
Received: by wproxy.gmail.com with SMTP id 71so69108wri
        for <linux-mips@linux-mips.org>; Wed, 06 Jul 2005 16:12:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=r8yJSaVLsZXTc6SpW/saA7djCgG7m2zHhFuIVZLka1zBFXyuHF1w/K8qK0WOltRI2Gv9KBaQCJ1JyjI3b4wG67VkH+tjHJRJb00B9b/Ox6up7v+Deh1PMrJxx6R3RXHAfwlFvhRWnRYGiBNR5iSqhrMLWV7/HmljWUrjcFDzsJc=
Received: by 10.54.16.77 with SMTP id 77mr130694wrp;
        Wed, 06 Jul 2005 16:12:39 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Wed, 6 Jul 2005 16:12:39 -0700 (PDT)
Message-ID: <2db32b7205070616124fa47ef3@mail.gmail.com>
Date:	Wed, 6 Jul 2005 16:12:39 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: compiling error of linux 2.6.12 recent cvs head for db1550 using defconfig
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8378
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1166
Lines: 26

I use gcc 3.4.4 to compile the recent 2.6.12, got the following errors:

  CC      arch/mips/au1000/common/setup.o
In file included from include/asm/io.h:29,
                 from include/asm/mach-au1x00/au1000.h:43,
                 from arch/mips/au1000/common/setup.c:42:
include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration
of 'fixup_bigphys_addr' follows non-static declaration
include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared
inline after being called
include/asm/pgtable.h:363: warning: previous declaration of
'fixup_bigphys_addr' was here
include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit
declaration of function `__fixup_bigphys_addr'
arch/mips/au1000/common/setup.c: At top level:
arch/mips/au1000/common/setup.c:159: error: conflicting types for
'__fixup_bigphys_addr'
include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit
declaration of '__fixup_bigphys_addr' was here
make[1]: *** [arch/mips/au1000/common/setup.o] Error 1
make: *** [arch/mips/au1000/common] Error 2

Not sure if it is just compiler's problem

thanks

From ppopov@embeddedalley.com Thu Jul  7 01:07:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 01:07:51 +0100 (BST)
Received: from smtp008.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.74]:58712
	"HELO smtp008.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226160AbVGGAHg>; Thu, 7 Jul 2005 01:07:36 +0100
Received: (qmail 25007 invoked from network); 7 Jul 2005 00:08:00 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp008.bizmail.sc5.yahoo.com with SMTP; 7 Jul 2005 00:07:59 -0000
Subject: Re: compiling error of linux 2.6.12 recent cvs head for db1550
	using defconfig
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070616124fa47ef3@mail.gmail.com>
References: <2db32b7205070616124fa47ef3@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Wed, 06 Jul 2005 17:08:06 -0700
Message-Id: <1120694886.5724.134.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8379
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: 1433
Lines: 34


On Wed, 2005-07-06 at 16:12 -0700, rolf liu wrote:
> I use gcc 3.4.4 to compile the recent 2.6.12, got the following errors:
> 
>   CC      arch/mips/au1000/common/setup.o
> In file included from include/asm/io.h:29,
>                  from include/asm/mach-au1x00/au1000.h:43,
>                  from arch/mips/au1000/common/setup.c:42:
> include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration
> of 'fixup_bigphys_addr' follows non-static declaration
> include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared
> inline after being called
> include/asm/pgtable.h:363: warning: previous declaration of
> 'fixup_bigphys_addr' was here
> include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
> include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit
> declaration of function `__fixup_bigphys_addr'
> arch/mips/au1000/common/setup.c: At top level:
> arch/mips/au1000/common/setup.c:159: error: conflicting types for
> '__fixup_bigphys_addr'
> include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit
> declaration of '__fixup_bigphys_addr' was here
> make[1]: *** [arch/mips/au1000/common/setup.o] Error 1
> make: *** [arch/mips/au1000/common] Error 2
> 
> Not sure if it is just compiler's problem

No, it's not. Looks like Maciej's patch on Thursday broke the above. 

Maciej, I assume you built a kernel for one of the Au1x boards before
you applied the patch ;)?

Pete


From macro@linux-mips.org Thu Jul  7 12:21:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 12:22:03 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:14596 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226288AbVGGLVq>; Thu, 7 Jul 2005 12:21:46 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 71761E1C85; Thu,  7 Jul 2005 13:22:11 +0200 (CEST)
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 27741-01; Thu,  7 Jul 2005 13:22:11 +0200 (CEST)
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 24C58E1C84; Thu,  7 Jul 2005 13:22:11 +0200 (CEST)
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 j67BMD7V031310;
	Thu, 7 Jul 2005 13:22:13 +0200
Date:	Thu, 7 Jul 2005 12:22:18 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	rolf liu <rolfliu@gmail.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: compiling error of linux 2.6.12 recent cvs head for db1550 using
 defconfig
In-Reply-To: <1120694886.5724.134.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61L.0507071213480.3205@blysk.ds.pg.gda.pl>
References: <2db32b7205070616124fa47ef3@mail.gmail.com>
 <1120694886.5724.134.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/970/Wed Jul  6 18:00:45 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8381
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: 469
Lines: 12

On Wed, 6 Jul 2005, Pete Popov wrote:

> Maciej, I assume you built a kernel for one of the Au1x boards before
> you applied the patch ;)?

 Certainly not -- I don't maintain that part of the tree in any sense -- I 
don't even have any related hardware, so why should I bother?  I sent the 
patch for public review to let interested parties exactly to catch such 
problems -- I even mentioned explicitly I only did a minimal arrangement 
for the Au1000 code.

  Maciej

From macro@linux-mips.org Thu Jul  7 12:31:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 12:32:11 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:17424 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226288AbVGGLbz>; Thu, 7 Jul 2005 12:31:55 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 08099E1C85
	for <linux-mips@linux-mips.org>; Thu,  7 Jul 2005 13:32:21 +0200 (CEST)
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 05969-04 for <linux-mips@linux-mips.org>;
 Thu,  7 Jul 2005 13:32:20 +0200 (CEST)
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 CB28BE1C84
	for <linux-mips@linux-mips.org>; Thu,  7 Jul 2005 13:32:20 +0200 (CEST)
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 j67BWNGX031735
	for <linux-mips@linux-mips.org>; Thu, 7 Jul 2005 13:32:23 +0200
Date:	Thu, 7 Jul 2005 12:32:29 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050707091937Z8226163-3678+1737@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/970/Wed Jul  6 18:00:45 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8382
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: 560
Lines: 16

On Thu, 7 Jul 2005 ths@linux-mips.org wrote:

> Log message:
> 	Hack to make compiles for the other endianness easier.

 Why have you complicated it that much?  AFAIK:

cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -meb
cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mel

would work just fine with all GCC versions supported (i.e. including 
2.95.x).  It's true "-EL" and "-EB" are broken, also with 4.0.0 (not sure 
if afterwards) -- it's related to an incorrect setup for the default specs 
for Linux, but it can be avoided using these alternative options as above.

  Maciej

From ths@networkno.de Thu Jul  7 13:12:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 13:12:29 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:42400 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226161AbVGGMMM>;
	Thu, 7 Jul 2005 13:12:12 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DqVF6-0000s5-00; Thu, 07 Jul 2005 14:12:36 +0200
Received: from ths by hattusa.textio with local (Exim 4.51)
	id 1DqVF5-0007VW-Pu; Thu, 07 Jul 2005 14:12:35 +0200
Date:	Thu, 7 Jul 2005 14:12:35 +0200
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050707121235.GV1645@hattusa.textio>
References: <20050707091937Z8226163-3678+1737@linux-mips.org> <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8383
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 642
Lines: 20

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005 ths@linux-mips.org wrote:
> 
> > Log message:
> > 	Hack to make compiles for the other endianness easier.
> 
>  Why have you complicated it that much?  AFAIK:
> 
> cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -meb
> cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mel
> 
> would work just fine with all GCC versions supported (i.e. including 
> 2.95.x).  It's true "-EL" and "-EB" are broken, also with 4.0.0 (not sure 
> if afterwards) -- it's related to an incorrect setup for the default specs 
> for Linux, but it can be avoided using these alternative options as above.

-mel/-meb aren't documented.


Thiemo

From macro@linux-mips.org Thu Jul  7 13:18:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 13:19:16 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:7431 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226161AbVGGMS5>; Thu, 7 Jul 2005 13:18:57 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id C8F20E1C89; Thu,  7 Jul 2005 14:19:22 +0200 (CEST)
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 23367-05; Thu,  7 Jul 2005 14:19:22 +0200 (CEST)
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 9B4ECE1C88; Thu,  7 Jul 2005 14:19:22 +0200 (CEST)
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 j67CJPJU001168;
	Thu, 7 Jul 2005 14:19:25 +0200
Date:	Thu, 7 Jul 2005 13:19:31 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050707121235.GV1645@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
 <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/970/Wed Jul  6 18:00:45 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8384
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: 436
Lines: 15

On Thu, 7 Jul 2005, Thiemo Seufer wrote:

> -mel/-meb aren't documented.

 They are:

$ gcc -v --help 2>/dev/null | egrep 'mel|meb'
  -mel                      Use little-endian byte order
  -meb                      Use big-endian byte order

They are not in the info pages, but that should probably be considered an 
accidental omission.  Is using something that's documented but doesn't 
work, to the contrary, any better?

  Maciej

From ths@networkno.de Thu Jul  7 13:22:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 13:22:26 +0100 (BST)
Received: from mx01.qsc.de ([IPv6:::ffff:213.148.129.14]:33732 "EHLO
	mx01.qsc.de") by linux-mips.org with ESMTP id <S8226161AbVGGMWD>;
	Thu, 7 Jul 2005 13:22:03 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx01.qsc.de with esmtp (Exim 3.35 #1)
	id 1DqVOd-00047i-00; Thu, 07 Jul 2005 14:22:27 +0200
Received: from ths by hattusa.textio with local (Exim 4.51)
	id 1DqVOc-0007Yq-N0; Thu, 07 Jul 2005 14:22:26 +0200
Date:	Thu, 7 Jul 2005 14:22:26 +0200
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050707122226.GW1645@hattusa.textio>
References: <20050707091937Z8226163-3678+1737@linux-mips.org> <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio> <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8385
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 561
Lines: 19

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > -mel/-meb aren't documented.
> 
>  They are:
> 
> $ gcc -v --help 2>/dev/null | egrep 'mel|meb'
>   -mel                      Use little-endian byte order
>   -meb                      Use big-endian byte order
> 
> They are not in the info pages, but that should probably be considered an 
> accidental omission.  Is using something that's documented but doesn't 
> work, to the contrary, any better?

Probably not. It's just that I've never seen actual use of -mel/-meb yet.


Thiemo

From macro@linux-mips.org Thu Jul  7 14:00:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 14:00:58 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:57868 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226161AbVGGNAg>; Thu, 7 Jul 2005 14:00:36 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id E4D09E1C89; Thu,  7 Jul 2005 15:01:01 +0200 (CEST)
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 20841-10; Thu,  7 Jul 2005 15:01:01 +0200 (CEST)
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 9F03CE1C88; Thu,  7 Jul 2005 15:01:01 +0200 (CEST)
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 j67D14B4002646;
	Thu, 7 Jul 2005 15:01:04 +0200
Date:	Thu, 7 Jul 2005 14:01:11 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050707122226.GW1645@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
 <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/970/Wed Jul  6 18:00:45 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8386
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: 727
Lines: 17

On Thu, 7 Jul 2005, Thiemo Seufer wrote:

> > They are not in the info pages, but that should probably be considered an 
> > accidental omission.  Is using something that's documented but doesn't 
> > work, to the contrary, any better?
> 
> Probably not. It's just that I've never seen actual use of -mel/-meb yet.

 Good -- it means you haven't been watching over my shoulder. ;-)  I've 
used them several times for big-endian builds with my toolchain, which, as 
you may be aware, has been exclusively little-endian so far.

 And they are actually used to implement these "-EL" and "-EB" options.  
Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
generally imply target-specific options.

  Maciej

From ths@networkno.de Thu Jul  7 14:50:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 14:50:56 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:18880 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226309AbVGGNul>;
	Thu, 7 Jul 2005 14:50:41 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DqWmQ-0003Uy-00; Thu, 07 Jul 2005 15:51:06 +0200
Received: from ths by hattusa.textio with local (Exim 4.51)
	id 1DqWmQ-0007we-4J; Thu, 07 Jul 2005 15:51:06 +0200
Date:	Thu, 7 Jul 2005 15:51:06 +0200
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050707135105.GX1645@hattusa.textio>
References: <20050707091937Z8226163-3678+1737@linux-mips.org> <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio> <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio> <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8387
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 952
Lines: 23

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > > They are not in the info pages, but that should probably be considered an 
> > > accidental omission.  Is using something that's documented but doesn't 
> > > work, to the contrary, any better?
> > 
> > Probably not. It's just that I've never seen actual use of -mel/-meb yet.
> 
>  Good -- it means you haven't been watching over my shoulder. ;-)  I've 
> used them several times for big-endian builds with my toolchain, which, as 
> you may be aware, has been exclusively little-endian so far.
> 
>  And they are actually used to implement these "-EL" and "-EB" options.  
> Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> generally imply target-specific options.

Other gcc targets use IIRC -BE and -LE. It might be worthwile to document
-mel/-meb better, use them generally in gcc, and then mark the uppercase
options as deprecated.


Thiemo

From rolfliu@gmail.com Thu Jul  7 16:43:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 16:44:00 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.203]:22137 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226263AbVGGPnl> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 16:43:41 +0100
Received: by wproxy.gmail.com with SMTP id 50so224766wri
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 08:44:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=pv0z/ZjADZLtbhS8V6xr8SBkXHzfZzG9Qkb9BcvS+FJIC39oAR/BtP+Wyl6G0Hmssw/tjxbIMNVywoenYv3DN9nofCj9ipqZLVCpnYV0BfoJ7q1wQ8wQ77Bq0JkpRIXdof91lfnCH0rMafG83j/1fCbe3I5oPP9qQs5ZrcjqeD8=
Received: by 10.54.30.4 with SMTP id d4mr865493wrd;
        Thu, 07 Jul 2005 08:44:03 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 08:44:03 -0700 (PDT)
Message-ID: <2db32b7205070708447d967304@mail.gmail.com>
Date:	Thu, 7 Jul 2005 08:44:03 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: Do I need to deal with pcmcia-cs package for linux 2.6.12 mips?
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8388
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 265
Lines: 6

I am trying to compile the pcmcia support for db1550 based on linux
2.6.12 mips cvs head. My questions is if I need to deal with the extra
pcmcia-cs package from pcmcia-cs.sourceforge.net, or I just need to
choose the pcmcia support from `make menuconfig`?

thanks

From ralf@linux-mips.org Thu Jul  7 17:29:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 17:29:54 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:16656 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226309AbVGGQ3f>; Thu, 7 Jul 2005 17:29:35 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j67GU0NJ021402;
	Thu, 7 Jul 2005 17:30:00 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j67GTx2C021401;
	Thu, 7 Jul 2005 17:29:59 +0100
Date:	Thu, 7 Jul 2005 17:29:59 +0100
From:	Ralf Baechle DL5RB <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050707162959.GQ2822@linux-mips.org>
References: <20050707091937Z8226163-3678+1737@linux-mips.org> <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio> <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio> <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8389
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1196
Lines: 28

On Thu, Jul 07, 2005 at 02:01:11PM +0100, Maciej W. Rozycki wrote:
> Date:	Thu, 7 Jul 2005 14:01:11 +0100 (BST)
> From:	"Maciej W. Rozycki" <macro@linux-mips.org>
> To:	Thiemo Seufer <ths@networkno.de>
> Cc:	linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > > They are not in the info pages, but that should probably be considered an 
> > > accidental omission.  Is using something that's documented but doesn't 
> > > work, to the contrary, any better?
> > 
> > Probably not. It's just that I've never seen actual use of -mel/-meb yet.
> 
>  Good -- it means you haven't been watching over my shoulder. ;-)  I've 
> used them several times for big-endian builds with my toolchain, which, as 
> you may be aware, has been exclusively little-endian so far.
> 
>  And they are actually used to implement these "-EL" and "-EB" options.  
> Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> generally imply target-specific options.

-EB / -EL are traditionally the options that all MIPS compilers including
non-gcc compilers, seem to support.

  Ralf

From macro@linux-mips.org Thu Jul  7 17:42:01 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 17:42:17 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:777 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226315AbVGGQmB>; Thu, 7 Jul 2005 17:42:01 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 3E02DE1C99; Thu,  7 Jul 2005 18:42:26 +0200 (CEST)
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 26624-04; Thu,  7 Jul 2005 18:42:26 +0200 (CEST)
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 0D77BE1C91; Thu,  7 Jul 2005 18:42:26 +0200 (CEST)
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 j67GgUSm012951;
	Thu, 7 Jul 2005 18:42:30 +0200
Date:	Thu, 7 Jul 2005 17:42:39 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle DL5RB <ralf@linux-mips.org>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050707162959.GQ2822@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507071741320.3205@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
 <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl> <20050707162959.GQ2822@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/971/Thu Jul  7 12:08:01 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8390
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: 544
Lines: 14

On Thu, 7 Jul 2005, Ralf Baechle DL5RB wrote:

> >  And they are actually used to implement these "-EL" and "-EB" options.  
> > Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> > generally imply target-specific options.
> 
> -EB / -EL are traditionally the options that all MIPS compilers including
> non-gcc compilers, seem to support.

 That's probably why they are there in GCC at all, but they are rather 
inconsistent with the rest of GCC options and we rely on GCC for builds 
anyway, so who cares?

  Maciej

From alan@lxorguk.ukuu.org.uk Thu Jul  7 18:12:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 18:12:37 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:45486
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226309AbVGGRMW>; Thu, 7 Jul 2005 18:12:22 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j67HA3sI000325;
	Thu, 7 Jul 2005 18:10:03 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j67HA2N9000323;
	Thu, 7 Jul 2005 18:10:02 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	rolf liu <rolfliu@gmail.com>
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070508504b675dd6@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1120756200.317.14.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Thu, 07 Jul 2005 18:10:01 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
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: 8391
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: 402
Lines: 11

On Maw, 2005-07-05 at 16:50, rolf liu wrote:
> Pete,
> I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> didn't force it to use 372 timing, it just hangs up after it detect
> the drive. If I used the 372 timing using the 2.4 trick, the kernel
> just crashed. Any clue?

Fix has been in the -ac tree for ages. Its finally gotten to Linus for
2.6.13 tree so pull it out of there.



From rolfliu@gmail.com Thu Jul  7 18:19:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 18:19:58 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.201]:36301 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226309AbVGGRTk> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 18:19:40 +0100
Received: by wproxy.gmail.com with SMTP id 71so245749wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 10:19:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AwmT2azoy1j7C5WQmyIPmbHEGO/p2z1bo+ouW+ZdCc3u27VYqjHV7TWQIDyXIqM/kfc/nyQtTxfmiwF3XdyIHtCMjDzyDPIG2kL5PqsyLXBfdIJrms8Qj+Mt2hwkMmesgnQH79lM8ZU6d/k7DyS+TOrGg9VIfTUGSGAe8PyaaLw=
Received: by 10.54.38.10 with SMTP id l10mr912122wrl;
        Thu, 07 Jul 2005 10:19:35 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 10:19:35 -0700 (PDT)
Message-ID: <2db32b7205070710191e8bc3e7@mail.gmail.com>
Date:	Thu, 7 Jul 2005 10:19:35 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120756200.317.14.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8392
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 533
Lines: 19

Alan,
Could you point me to the -ac tree? 

thanks


On 7/7/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-07-05 at 16:50, rolf liu wrote:
> > Pete,
> > I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> > didn't force it to use 372 timing, it just hangs up after it detect
> > the drive. If I used the 372 timing using the 2.4 trick, the kernel
> > just crashed. Any clue?
> 
> Fix has been in the -ac tree for ages. Its finally gotten to Linus for
> 2.6.13 tree so pull it out of there.
> 
> 
>

From rolfliu@gmail.com Thu Jul  7 19:05:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 19:05:34 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.196]:46510 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226321AbVGGSFP> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 19:05:15 +0100
Received: by wproxy.gmail.com with SMTP id i27so255438wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 11:05:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=s/ag3U34RClZV7/KX4pAtApBVZJVEz0dmSI0UKzSWQNBze56qIjiLmdRs5HrNYmRMivAzqxz7IDwKZUKSdf1KhFtjWR8PevvtfS7krt/TxHADg1i5i7pri2ZlFku+UmQKd3RAm+7QdRmIZKaA/EKTqSdv4AgWXHOpxDN6r6TEUQ=
Received: by 10.54.141.1 with SMTP id o1mr950355wrd;
        Thu, 07 Jul 2005 11:05:38 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 11:05:38 -0700 (PDT)
Message-ID: <2db32b7205070711052c90e024@mail.gmail.com>
Date:	Thu, 7 Jul 2005 11:05:38 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120756200.317.14.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8393
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 702
Lines: 23

Compiling error for the -ac patch on 2.6.11.

There is no "ide_dma_start" in struct "ide_hwif_t", while the patch
tries to assign
"hwif->ide_dma_start = ...". Possibly could changed to "hwif->dma_start = ..." ?

thanks



On 7/7/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-07-05 at 16:50, rolf liu wrote:
> > Pete,
> > I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> > didn't force it to use 372 timing, it just hangs up after it detect
> > the drive. If I used the 372 timing using the 2.4 trick, the kernel
> > just crashed. Any clue?
> 
> Fix has been in the -ac tree for ages. Its finally gotten to Linus for
> 2.6.13 tree so pull it out of there.
> 
> 
>

From rolfliu@gmail.com Thu Jul  7 19:41:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 19:42:00 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.193]:62402 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226313AbVGGSlp> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 19:41:45 +0100
Received: by wproxy.gmail.com with SMTP id 70so264767wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 11:42:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mQpyRjRoqtaOOiHxDp2ep0/lV0OZohVmhg3BdbMJI+RTnRnzSHo8tkmUCdxsqoV+PirIKkaVWCBxYW7Ae6bLgo/hUyjXnA+OwEXw5yhCZKAr+qfprWcyviMhSepdMnZxWvaxJ8V2ZoPD8JABl7ldD26H8vnciP/Z1tUQJ+sJlJ0=
Received: by 10.54.33.65 with SMTP id g65mr988463wrg;
        Thu, 07 Jul 2005 11:42:14 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 11:42:14 -0700 (PDT)
Message-ID: <2db32b7205070711424c119780@mail.gmail.com>
Date:	Thu, 7 Jul 2005 11:42:14 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120756200.317.14.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8394
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 680
Lines: 23

Alan,
Tried your patch on db1550 and linux 2.6.12. It still doesn't work. 
During the boot-up, the kernel will hang up right after it prints out:

>>hdg: max request size: 128 KiB


Any suggestion?


On 7/7/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-07-05 at 16:50, rolf liu wrote:
> > Pete,
> > I tried to make HPT working on db1550 for linux 2.6.12 cvs head. If I
> > didn't force it to use 372 timing, it just hangs up after it detect
> > the drive. If I used the 372 timing using the 2.4 trick, the kernel
> > just crashed. Any clue?
> 
> Fix has been in the -ac tree for ages. Its finally gotten to Linus for
> 2.6.13 tree so pull it out of there.
> 
> 
>

From rolfliu@gmail.com Thu Jul  7 19:48:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 19:48:40 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.206]:30595 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226313AbVGGSsS> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 19:48:18 +0100
Received: by wproxy.gmail.com with SMTP id i31so263579wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 11:48:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WS9OfUrZWqV2sGr0B7m58WEnWoG9GlPlh6bvShbtDZuffTwYkAoV5+opvcasHzHGtsiQwoGgfpmsw3q5hwc+scK4EVhc6zZQm03GPTvrHJUIWg/LY5qjLIPygC3Zbi41F0zd7Fm7lehmUevIzVf9UbiQQ5qalL7eBZfOuchIytQ=
Received: by 10.54.36.46 with SMTP id j46mr971268wrj;
        Thu, 07 Jul 2005 11:48:42 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 11:48:42 -0700 (PDT)
Message-ID: <2db32b72050707114833af8dcf@mail.gmail.com>
Date:	Thu, 7 Jul 2005 11:48:42 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: compiling error of linux 2.6.12 recent cvs head for db1550 using defconfig
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120694886.5724.134.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070616124fa47ef3@mail.gmail.com>
	 <1120694886.5724.134.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8395
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1752
Lines: 46

Another error:

"No rule to make target `drivers/pcmcia/bulkmem.s`, needed by
`drivers/pcmcia/bulkmem.o`. Stop"

I think the rule is in the top level Makefile. Why this error comes out?

thanks


On 7/6/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> 
> On Wed, 2005-07-06 at 16:12 -0700, rolf liu wrote:
> > I use gcc 3.4.4 to compile the recent 2.6.12, got the following errors:
> >
> >   CC      arch/mips/au1000/common/setup.o
> > In file included from include/asm/io.h:29,
> >                  from include/asm/mach-au1x00/au1000.h:43,
> >                  from arch/mips/au1000/common/setup.c:42:
> > include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration
> > of 'fixup_bigphys_addr' follows non-static declaration
> > include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared
> > inline after being called
> > include/asm/pgtable.h:363: warning: previous declaration of
> > 'fixup_bigphys_addr' was here
> > include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
> > include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit
> > declaration of function `__fixup_bigphys_addr'
> > arch/mips/au1000/common/setup.c: At top level:
> > arch/mips/au1000/common/setup.c:159: error: conflicting types for
> > '__fixup_bigphys_addr'
> > include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit
> > declaration of '__fixup_bigphys_addr' was here
> > make[1]: *** [arch/mips/au1000/common/setup.o] Error 1
> > make: *** [arch/mips/au1000/common] Error 2
> >
> > Not sure if it is just compiler's problem
> 
> No, it's not. Looks like Maciej's patch on Thursday broke the above.
> 
> Maciej, I assume you built a kernel for one of the Au1x boards before
> you applied the patch ;)?
> 
> Pete
> 
>

From ppopov@embeddedalley.com Thu Jul  7 20:28:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 20:29:12 +0100 (BST)
Received: from smtp006.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.83]:15257
	"HELO smtp006.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226313AbVGGT25>; Thu, 7 Jul 2005 20:28:57 +0100
Received: (qmail 89543 invoked from network); 7 Jul 2005 19:29:01 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp006.bizmail.sc5.yahoo.com with SMTP; 7 Jul 2005 19:29:01 -0000
Subject: Re: compiling error of linux 2.6.12 recent cvs head for db1550
	using defconfig
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.61L.0507071213480.3205@blysk.ds.pg.gda.pl>
References: <2db32b7205070616124fa47ef3@mail.gmail.com>
	 <1120694886.5724.134.camel@localhost.localdomain>
	 <Pine.LNX.4.61L.0507071213480.3205@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 07 Jul 2005 12:29:07 -0700
Message-Id: <1120764548.5777.17.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8396
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: 660
Lines: 20

On Thu, 2005-07-07 at 12:22 +0100, Maciej W. Rozycki wrote:
> On Wed, 6 Jul 2005, Pete Popov wrote:
> 
> > Maciej, I assume you built a kernel for one of the Au1x boards before
> > you applied the patch ;)?
> 
>  Certainly not -- I don't maintain that part of the tree in any sense -- I 
> don't even have any related hardware, so why should I bother?  

Well, I understand you don't have the HW so you can't test the patch.
But at least it should compile, imho.

> I sent the 
> patch for public review to let interested parties exactly to catch such 
> problems -- I even mentioned explicitly I only did a minimal arrangement 
> for the Au1000 code.


Pete


From rolfliu@gmail.com Thu Jul  7 21:55:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 21:55:44 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.192]:49888 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226325AbVGGUz3> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 21:55:29 +0100
Received: by wproxy.gmail.com with SMTP id 57so290615wri
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 13:55:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=kykFUpgPqwwWCDQrVNB2h64cODqwqJuYHycF/FIksFA2zcFztxq58l4qaDXSLN63CSXSjeLLF50Ap3CFmN9LFpb1/iuraX5YqSmrU4GOQbXz+Pm+i47uQ39aVfputkEQK2cGkXG7PMQiHcvls6xSPbaJJfYuI+Y3cfpxzt4nqzY=
Received: by 10.54.101.2 with SMTP id y2mr1066630wrb;
        Thu, 07 Jul 2005 13:55:59 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 13:55:59 -0700 (PDT)
Message-ID: <2db32b7205070713553df6096a@mail.gmail.com>
Date:	Thu, 7 Jul 2005 13:55:59 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: insmod error for pcmcia support on db1550
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8397
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 467
Lines: 14

I compiled linux 2.6.12 with the pcmcia support. And I got 3 module
files: au1x00_ss.ko, pcmcia.ko, and pcmcia_core.ko.

I used" insmod au1x00_ss.ko", but system tells me:
>>insmod: QM_MODULES: Function not implemented

The same thing happens to pcmcia_core.ko and pcmcia.ko too.

What is the problem here? Do I need to recompile the module untilities
for the 2.6 kernels?

Also, when I typed "lspci -v", no information for the pcmcia showed up.

Thanks for comments

From ppopov@embeddedalley.com Thu Jul  7 22:01:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 22:02:14 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:32141
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226325AbVGGVB6>; Thu, 7 Jul 2005 22:01:58 +0100
Received: (qmail 85347 invoked from network); 7 Jul 2005 21:02:19 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 7 Jul 2005 21:02:18 -0000
Subject: Re: insmod error for pcmcia support on db1550
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070713553df6096a@mail.gmail.com>
References: <2db32b7205070713553df6096a@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 07 Jul 2005 14:02:23 -0700
Message-Id: <1120770143.5777.85.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8398
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: 796
Lines: 25

On Thu, 2005-07-07 at 13:55 -0700, rolf liu wrote:
> I compiled linux 2.6.12 with the pcmcia support. And I got 3 module
> files: au1x00_ss.ko, pcmcia.ko, and pcmcia_core.ko.
> 
> I used" insmod au1x00_ss.ko", but system tells me:
> >>insmod: QM_MODULES: Function not implemented
> 
> The same thing happens to pcmcia_core.ko and pcmcia.ko too.
> 
> What is the problem here? Do I need to recompile the module untilities
> for the 2.6 kernels?
> 
> Also, when I typed "lspci -v", no information for the pcmcia showed up.
> 
> Thanks for comments

Just my 2c: you have to do some work yourself before you ping the
mailing list. If you search on google for the above error, you'll find
the answer within 5 min.  

Yes, you do need a new modules loading package which you'll have to
compile.

Pete


From rolfliu@gmail.com Thu Jul  7 22:31:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 22:32:00 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.201]:48585 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226325AbVGGVbk> convert rfc822-to-8bit;
	Thu, 7 Jul 2005 22:31:40 +0100
Received: by wproxy.gmail.com with SMTP id i20so299783wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 14:32:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MWfXgjnj9sBo9+dDcgEVgTyGaiHhmoUyFZcHEE0cgAiiPpT1ebJ3w8zrDSSZHgbuGP9vWEYt1cBu2C//9NE7hh6kUPAnXedMFTFcGYvSyVkE+qqaxc/JA9cxphIpWw/JEG+EM1ZZt9YPMcjeD+OqUK3aCzskfmjJ0zIQwxbSYBQ=
Received: by 10.54.100.5 with SMTP id x5mr1087243wrb;
        Thu, 07 Jul 2005 14:32:11 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 14:32:10 -0700 (PDT)
Message-ID: <2db32b72050707143277bb0532@mail.gmail.com>
Date:	Thu, 7 Jul 2005 14:32:10 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: insmod error for pcmcia support on db1550
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120770143.5777.85.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070713553df6096a@mail.gmail.com>
	 <1120770143.5777.85.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8399
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 998
Lines: 31

Thanks.
I just joined the linux (mips) community a few weeks. :(
I will try google first next time.

On 7/7/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Thu, 2005-07-07 at 13:55 -0700, rolf liu wrote:
> > I compiled linux 2.6.12 with the pcmcia support. And I got 3 module
> > files: au1x00_ss.ko, pcmcia.ko, and pcmcia_core.ko.
> >
> > I used" insmod au1x00_ss.ko", but system tells me:
> > >>insmod: QM_MODULES: Function not implemented
> >
> > The same thing happens to pcmcia_core.ko and pcmcia.ko too.
> >
> > What is the problem here? Do I need to recompile the module untilities
> > for the 2.6 kernels?
> >
> > Also, when I typed "lspci -v", no information for the pcmcia showed up.
> >
> > Thanks for comments
> 
> Just my 2c: you have to do some work yourself before you ping the
> mailing list. If you search on google for the above error, you'll find
> the answer within 5 min.
> 
> Yes, you do need a new modules loading package which you'll have to
> compile.
> 
> Pete
> 
>

From alan@lxorguk.ukuu.org.uk Thu Jul  7 23:49:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Jul 2005 23:49:55 +0100 (BST)
Received: from [IPv6:::ffff:81.2.110.250] ([IPv6:::ffff:81.2.110.250]:47027
	"EHLO lxorguk.ukuu.org.uk") by linux-mips.org with ESMTP
	id <S8226319AbVGGWtj>; Thu, 7 Jul 2005 23:49:39 +0100
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lxorguk.ukuu.org.uk (8.12.11/8.12.11) with ESMTP id j67MlNYA001251;
	Thu, 7 Jul 2005 23:47:24 +0100
Received: (from alan@localhost)
	by localhost.localdomain (8.12.11/8.12.11/Submit) id j67MlMhu001250;
	Thu, 7 Jul 2005 23:47:23 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
From:	Alan Cox <alan@lxorguk.ukuu.org.uk>
To:	rolf liu <rolfliu@gmail.com>
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070711424c119780@mail.gmail.com>
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
	 <2db32b7205070711424c119780@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1120776436.317.57.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
Date:	Thu, 07 Jul 2005 23:47:17 +0100
Return-Path: <alan@lxorguk.ukuu.org.uk>
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: 8400
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: 376
Lines: 12

On Iau, 2005-07-07 at 19:42, rolf liu wrote:
> Alan,
> Tried your patch on db1550 and linux 2.6.12. It still doesn't work. 
> During the boot-up, the kernel will hang up right after it prints out:
> 
> >>hdg: max request size: 128 KiB

> Any suggestion?

Its got started if it gets that far because the LBA48 status has been
checked. What occurs if you boot with ide=nodma ?


From rolfliu@gmail.com Fri Jul  8 01:26:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 01:27:10 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.204]:11310 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226323AbVGHA0u> convert rfc822-to-8bit;
	Fri, 8 Jul 2005 01:26:50 +0100
Received: by wproxy.gmail.com with SMTP id i31so321626wra
        for <linux-mips@linux-mips.org>; Thu, 07 Jul 2005 17:27:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rZmt+YUOTF7Y1USzcojm++pU0WehXF0tKI3Qj2RhlkUom5LmFAqGFsg2H8tYL2eDZIsVGIO7fchblveaaGZQ2vxgjb8Igog26JLGHPQ6urje1lUvZaG90TGn+g39Nuk33I0rB9HF+lpZRBlQoRb79WkPO0OlQw8RLgGxGn2YSiQ=
Received: by 10.54.26.9 with SMTP id 9mr1200321wrz;
        Thu, 07 Jul 2005 17:27:15 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 7 Jul 2005 17:27:13 -0700 (PDT)
Message-ID: <2db32b7205070717271365dd35@mail.gmail.com>
Date:	Thu, 7 Jul 2005 17:27:13 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120776436.317.57.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
	 <2db32b7205070711424c119780@mail.gmail.com>
	 <1120776436.317.57.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8401
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 863
Lines: 27

I don't have hardware now and will try that option tomorrow. But I
remembered I got the same output before I applied your patch. I wonder
if using the PCI clock as the sole input can help. I read about the
source code provide by HighPoint Technologies. They use
"pci_write_config_byte(dev, 0x5b, 0x21);" instead of
"pci_write_config_byte(dev, 0x5b, 0x23);".

will let you know the result tomorrow.

Thanks



On 7/7/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Iau, 2005-07-07 at 19:42, rolf liu wrote:
> > Alan,
> > Tried your patch on db1550 and linux 2.6.12. It still doesn't work.
> > During the boot-up, the kernel will hang up right after it prints out:
> >
> > >>hdg: max request size: 128 KiB
> 
> > Any suggestion?
> 
> Its got started if it gets that far because the LBA48 status has been
> checked. What occurs if you boot with ide=nodma ?
> 
>

From ralf@linux-mips.org Fri Jul  8 13:02:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 13:02:28 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:4893 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226340AbVGHMCH>; Fri, 8 Jul 2005 13:02:07 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j68C2cPK002964;
	Fri, 8 Jul 2005 13:02:38 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j68C2cXh002963;
	Fri, 8 Jul 2005 13:02:38 +0100
Date:	Fri, 8 Jul 2005 13:02:38 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Cc:	linux-cvs@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050708120238.GA2816@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050708091711Z8226352-3678+1954@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8403
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 348
Lines: 15

On Fri, Jul 08, 2005 at 10:17:05AM +0100, ths@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/07/08 10:17:05
> 
> Modified files:
> 	include/asm-mips: checksum.h 
> 
> Log message:
> 	Protect noat assembly with .set push/pop and make it somewhat readable.

It doesn't need protction.

 Ralf

From macro@linux-mips.org Fri Jul  8 13:12:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 13:12:34 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:20753 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226340AbVGHMMP>; Fri, 8 Jul 2005 13:12:15 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 4E045E1CAE; Fri,  8 Jul 2005 14:12:45 +0200 (CEST)
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 11750-05; Fri,  8 Jul 2005 14:12:45 +0200 (CEST)
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 14512E1CA8; Fri,  8 Jul 2005 14:12:45 +0200 (CEST)
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 j68CCmP8028558;
	Fri, 8 Jul 2005 14:12:48 +0200
Date:	Fri, 8 Jul 2005 13:12:55 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050708120238.GA2816@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507081309530.25104@blysk.ds.pg.gda.pl>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
 <20050708120238.GA2816@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/971/Thu Jul  7 12:08:01 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8404
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: 321
Lines: 11

On Fri, 8 Jul 2005, Ralf Baechle wrote:

> > Log message:
> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> 
> It doesn't need protction.

 Are you absolutely sure future versions of GCC won't default to ".set 
noat" for inline asm?  I am not; in fact the opposite is not unlikely.

  Maciej

From linux-mips@packetvision.com Fri Jul  8 13:23:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 13:24:03 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.139]:35976
	"EHLO mra04.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8226359AbVGHMXj>; Fri, 8 Jul 2005 13:23:39 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 0B161133FDF
	for <linux-mips@linux-mips.org>; Fri,  8 Jul 2005 13:24:13 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra04.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 26987-01-94 for <linux-mips@linux-mips.org>;
 Fri,  8 Jul 2005 13:24:11 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id CB9A5133ADB
	for <linux-mips@linux-mips.org>; Fri,  8 Jul 2005 13:24:03 +0100 (BST)
Subject: Benchmarking RM9000
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	linux-mips@linux-mips.org
In-Reply-To: <20050708120238.GA2816@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	 <20050708120238.GA2816@linux-mips.org>
Content-Type: text/plain
Message-Id: <1120825549.28569.949.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Fri, 08 Jul 2005 13:25:49 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
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: 8405
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: 2206
Lines: 50

Hi,

I am doing some basic benchmarking tests on our RM9000 based platform,
running on just one of the two cores (non-smp kernel).

I would be very interesting in seeing some comparative data as we seem
to experience some performance problems.

Even if no data is available, any comments on this results will also be
appreciated.

Thanks,
Alex

----------------------------------------------------

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
                                                                                                                                                       
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          360.48  :       9.24  :       3.04
STRING SORT         :           31.23  :      13.95  :       2.16
BITFIELD            :      8.4132e+07  :      14.43  :       3.01
FP EMULATION        :          32.921  :      15.80  :       3.65
FOURIER             :            3383  :       3.85  :       2.16
ASSIGNMENT          :          4.2422  :      16.14  :       4.19
IDEA                :          1543.3  :      23.60  :       7.01
HUFFMAN             :          382.56  :      10.61  :       3.39
NEURAL NET          :          3.7153  :       5.97  :       2.51
LU DECOMPOSITION    :          209.28  :      10.84  :       7.83
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 14.242
FLOATING-POINT INDEX: 6.291
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.12-rc3
C compiler          : gcc version 3.3.5
libc                : libc-2.3.5.so
MEMORY INDEX        : 3.010
INTEGER INDEX       : 4.026
FLOATING-POINT INDEX: 3.489
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.



From richard@codesourcery.com Fri Jul  8 14:42:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 14:42:28 +0100 (BST)
Received: from admin.voldemort.codesourcery.com ([IPv6:::ffff:65.74.133.9]:65223
	"EHLO mail.codesourcery.com") by linux-mips.org with ESMTP
	id <S8226361AbVGHNmK>; Fri, 8 Jul 2005 14:42:10 +0100
Received: (qmail 20726 invoked by uid 1010); 8 Jul 2005 13:42:42 -0000
From:	Richard Sandiford <richard@codesourcery.com>
To:	Ralf Baechle DL5RB <ralf@linux-mips.org>
Mail-Followup-To: Ralf Baechle DL5RB <ralf@linux-mips.org>,"Maciej W. Rozycki" <macro@linux-mips.org>,  Thiemo Seufer <ths@networkno.de>,  linux-mips@linux-mips.org, richard@codesourcery.com
Cc:	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
	<Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl>
	<20050707121235.GV1645@hattusa.textio>
	<Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl>
	<20050707122226.GW1645@hattusa.textio>
	<Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
	<20050707162959.GQ2822@linux-mips.org>
Date:	Fri, 08 Jul 2005 14:42:38 +0100
In-Reply-To: <20050707162959.GQ2822@linux-mips.org> (Ralf Baechle DL5RB's
	message of "Thu, 7 Jul 2005 17:29:59 +0100")
Message-ID: <87zmsx4do1.fsf@talisman.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <richard@codesourcery.com>
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: 8406
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: richard@codesourcery.com
Precedence: bulk
X-list: linux-mips
Content-Length: 697
Lines: 16

Ralf Baechle DL5RB <ralf@linux-mips.org> writes:
> -EB / -EL are traditionally the options that all MIPS compilers including
> non-gcc compilers, seem to support.

Right.  I've always thought of them as the canonical options for gcc
as well.  I think the only reason internal compilers like cc1 have
-mel and -meb is because gcc's target options system has traditionally
required every target option to begin with "-m".  (That's no longer
a restriction in 4.1 FWIW.)

So contrary to what was said upthread, I've always treated
the omission of these options from invoke.texi as deliberate.
They're really internal compiler flags rather than user flags.
You should use -EL and -EB instead.

Richard

From richard@codesourcery.com Fri Jul  8 14:43:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 14:43:31 +0100 (BST)
Received: from admin.voldemort.codesourcery.com ([IPv6:::ffff:65.74.133.9]:712
	"EHLO mail.codesourcery.com") by linux-mips.org with ESMTP
	id <S8226362AbVGHNnN>; Fri, 8 Jul 2005 14:43:13 +0100
Received: (qmail 20781 invoked by uid 1010); 8 Jul 2005 13:43:48 -0000
From:	Richard Sandiford <richard@codesourcery.com>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Mail-Followup-To: "Maciej W. Rozycki" <macro@linux-mips.org>,Ralf Baechle <ralf@linux-mips.org>,  linux-mips@linux-mips.org, richard@codesourcery.com
Cc:	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	<20050708120238.GA2816@linux-mips.org>
	<Pine.LNX.4.61L.0507081309530.25104@blysk.ds.pg.gda.pl>
Date:	Fri, 08 Jul 2005 14:43:45 +0100
In-Reply-To: <Pine.LNX.4.61L.0507081309530.25104@blysk.ds.pg.gda.pl> (Maciej
	W. Rozycki's message of "Fri, 8 Jul 2005 13:12:55 +0100 (BST)")
Message-ID: <87vf3l4dm6.fsf@talisman.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <richard@codesourcery.com>
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: 8407
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: richard@codesourcery.com
Precedence: bulk
X-list: linux-mips
Content-Length: 373
Lines: 11

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 8 Jul 2005, Ralf Baechle wrote:
>> > Log message:
>> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
>> 
>> It doesn't need protction.
>
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?

Yes ;)  All hell would break loose otherwise. ;)

From ldarby@mips.com Fri Jul  8 14:54:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 14:55:02 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:37131 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8226355AbVGHNyq>;
	Fri, 8 Jul 2005 14:54:46 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1DqtbD-0008GS-00; Fri, 08 Jul 2005 15:13:03 +0100
Received: from kenton.mips.com ([192.168.192.199])
	by olympia.mips.com with smtp (Exim 3.36 #1 (Debian))
	id 1DqtJf-0000RF-00; Fri, 08 Jul 2005 14:54:55 +0100
Date:	Fri, 8 Jul 2005 14:54:54 +0100
From:	Laurence Darby <ldarby@mips.com>
To:	Alex Gonzalez <linux-mips@packetvision.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Benchmarking RM9000
Message-Id: <20050708145454.7d5f9c74.ldarby@mips.com>
In-Reply-To: <1120825549.28569.949.camel@euskadi.packetvision>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	<20050708120238.GA2816@linux-mips.org>
	<1120825549.28569.949.camel@euskadi.packetvision>
X-Mailer: Sylpheed version 2.0.0beta2 (GTK+ 2.6.4; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.878,
	required 4, AWL, BAYES_00)
Return-Path: <ldarby@mips.com>
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: 8408
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: ldarby@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 549
Lines: 21

Alex Gonzalez wrote:

> Hi,
> 
> I am doing some basic benchmarking tests on our RM9000 based platform,
> running on just one of the two cores (non-smp kernel).

<snip>

> TEST                : Iterations/sec.  : Old Index   : New Index
>                     :                  : Pentium 90* : AMD K6/233*
> --------------------:------------------:-------------:------------>
> NUMERIC SORT        :          360.48  :       9.24  :       3.04


I'd expect a K6 to be able to do more Iterations per second than a
Pentium 90, not fewer. 


Laurence


From ralf@linux-mips.org Fri Jul  8 14:55:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 14:55:51 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:5907 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226358AbVGHNzV>; Fri, 8 Jul 2005 14:55:21 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j68Dtqt7007446;
	Fri, 8 Jul 2005 14:55:52 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j68Dtq6M007445;
	Fri, 8 Jul 2005 14:55:52 +0100
Date:	Fri, 8 Jul 2005 14:55:52 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050708135551.GD2816@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org> <20050708120238.GA2816@linux-mips.org> <Pine.LNX.4.61L.0507081309530.25104@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507081309530.25104@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8409
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 454
Lines: 13

On Fri, Jul 08, 2005 at 01:12:55PM +0100, Maciej W. Rozycki wrote:

> > > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> > 
> > It doesn't need protction.
> 
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?  I am not; in fact the opposite is not unlikely.

Indeed - but everybody is free to shoot himself into the foot.  With
uzis even.  Does that make it a good idea?

  Ralf

From alex.gonzalez@packetvision.com Fri Jul  8 15:33:38 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 15:33:58 +0100 (BST)
Received: from mra03.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.88]:64654
	"EHLO mra03.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8226358AbVGHOdi>; Fri, 8 Jul 2005 15:33:38 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mra03.ex.eclipse.net.uk (Postfix) with ESMTP id D76C72E2B74
	for <linux-mips@linux-mips.org>; Fri,  8 Jul 2005 15:34:10 +0100 (BST)
Received: from mra03.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra03.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 09127-01-49 for <linux-mips@linux-mips.org>;
 Fri,  8 Jul 2005 15:34:10 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra03.ex.eclipse.net.uk (Postfix) with ESMTP id 337A52E2C16
	for <linux-mips@linux-mips.org>; Fri,  8 Jul 2005 15:34:02 +0100 (BST)
Subject: Re: Benchmarking RM9000
From:	Alex Gonzalez <alex.gonzalez@packetvision.com>
To:	linux-mips@linux-mips.org
Content-Type: text/plain
Message-Id: <1120833353.28569.957.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Fri, 08 Jul 2005 15:35:54 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <alex.gonzalez@packetvision.com>
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: 8410
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: alex.gonzalez@packetvision.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1026
Lines: 35

My understanding of these numbers is that they all refer to the target
under test.

So for that specific test, the target is 9.24 times quicker than a base
Pentium 90 and 3.04 times quicker than a AMD K6.

That makes the AMD three times quicker than the Pentium 90.

But then, I might have been trying to make sense of the numbers as it is
not clear enough in the documentation.

Alex

On Fri, 2005-07-08 at 14:54, Laurence Darby wrote:
> Alex Gonzalez wrote:
> 
> > Hi,
> > 
> > I am doing some basic benchmarking tests on our RM9000 based platform,
> > running on just one of the two cores (non-smp kernel).
> 
> <snip>
> 
> > TEST                : Iterations/sec.  : Old Index   : New Index
> >                     :                  : Pentium 90* : AMD K6/233*
> > --------------------:------------------:-------------:------------>
> > NUMERIC SORT        :          360.48  :       9.24  :       3.04
> 
> 
> I'd expect a K6 to be able to do more Iterations per second than a
> Pentium 90, not fewer. 
> 
> 
> Laurence


From linux-mips@packetvision.com Fri Jul  8 16:03:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 16:03:24 +0100 (BST)
Received: from mra05.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.155]:40893
	"EHLO mra05.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8226358AbVGHPDE>; Fri, 8 Jul 2005 16:03:04 +0100
Received: from localhost (localhost [127.0.0.1])
	by mra05.ex.eclipse.net.uk (Postfix) with ESMTP id A8F6BD4C4E;
	Fri,  8 Jul 2005 15:58:44 +0100 (BST)
Received: from mra05.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra05.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 28617-01-56; Fri,  8 Jul 2005 15:58:41 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra05.ex.eclipse.net.uk (Postfix) with ESMTP id 2202BD4ACB;
	Fri,  8 Jul 2005 15:35:45 +0100 (BST)
Subject: Re: Benchmarking RM9000
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050708130131.GC2816@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	 <20050708120238.GA2816@linux-mips.org>
	 <1120825549.28569.949.camel@euskadi.packetvision>
	 <20050708130131.GC2816@linux-mips.org>
Content-Type: text/plain
Message-Id: <1120833749.28569.965.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Fri, 08 Jul 2005 15:42:29 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
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: 8411
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: 1057
Lines: 30

The performance of our video application is well below our expectations.
We are still doing some profiling work on it, but we are also looking at
other possibilities.

What other benchmarking tool would you recommend?

Currently it's a NFS mounted system, but even if we could use a block
device the access speed wouldn't be more than 1.5 Mbps, so that is a
limitation for the benchmark.

Alex

On Fri, 2005-07-08 at 14:01, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 01:25:49PM +0100, Alex Gonzalez wrote:
> 
> > I am doing some basic benchmarking tests on our RM9000 based platform,
> > running on just one of the two cores (non-smp kernel).
> > 
> > I would be very interesting in seeing some comparative data as we seem
> > to experience some performance problems.
> 
> What exactly are those performance issues?
> 
> If I recall right how to read bytebench numbers, your Bytebench numbers
> are look roughly ok, at least in first approximation.  That benchmark
> has become uncommon so I don't have any numbers at hand to compare with.
> 
>   Ralf



From macro@linux-mips.org Fri Jul  8 16:04:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 16:04:39 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:32005 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226358AbVGHPEV>; Fri, 8 Jul 2005 16:04:21 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 94226F59BA; Fri,  8 Jul 2005 17:04:52 +0200 (CEST)
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 26863-10; Fri,  8 Jul 2005 17:04:52 +0200 (CEST)
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 5FF96F59A6; Fri,  8 Jul 2005 17:04:52 +0200 (CEST)
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 j68F4uR5001015;
	Fri, 8 Jul 2005 17:04:56 +0200
Date:	Fri, 8 Jul 2005 16:05:05 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Richard Sandiford <richard@codesourcery.com>
Cc:	Ralf Baechle DL5RB <ralf@linux-mips.org>,
	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <87zmsx4do1.fsf@talisman.home>
Message-ID: <Pine.LNX.4.61L.0507081553040.25104@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
 <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl> <20050707162959.GQ2822@linux-mips.org>
 <87zmsx4do1.fsf@talisman.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/972/Fri Jul  8 15:43:11 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8412
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: 2716
Lines: 66

On Fri, 8 Jul 2005, Richard Sandiford wrote:

> Right.  I've always thought of them as the canonical options for gcc
> as well.  I think the only reason internal compilers like cc1 have
> -mel and -meb is because gcc's target options system has traditionally
> required every target option to begin with "-m".  (That's no longer
> a restriction in 4.1 FWIW.)

 I'm not sure relaxing this restriction is actually a good idea -- there 
may be tools external to GCC that make this assumption for additional 
handling of options passed to GCC.  I could imagine libtool being 
sensitive, for example (but that's just an assumption -- I haven't checked 
it).  And this classification of options -- "-f*" for optimization tweaks 
and "-m*" for target-dependent ones -- seems to be useful for humans (or 
at least one), too, as one does not to have to resort to documentation for 
every option encountered in Makefiles to have an idea about it.

> So contrary to what was said upthread, I've always treated
> the omission of these options from invoke.texi as deliberate.

 OK, I stand corrected.

> They're really internal compiler flags rather than user flags.

 Which actually happen to work...

> You should use -EL and -EB instead.

 ... unlike these.

 FWIW, I prepared the following patch for GCC 3.4.x the other day -- would 
you care to verify whether it's still needed for 4.x?  It may be worth 
applying to 3.4, too -- I think the branch hasn't got closed yet, has it?

2005-07-08  Maciej W. Rozycki  <macro@mips.com>

	* config/mips/linux.h (CC1_SPEC): Override defaults from
	config/linux.h.

 Unfortunately it won't let us remove the newly introduced hackery from 
Linux as (unlike you) we need to support versions back to 2.95.x.  
Therefore I sustain my proposal to use "-mel" and "-meb" as more reliable 
-- I'm pretty sure they used to work for 2.95.x, too.

  Maciej

gcc-3.4.4-20050617-linux-cc1-spec-0.patch
--- gcc/gcc/config/mips/linux.h	30 Jul 2004 15:33:08 -0000
+++ gcc/gcc/config/mips/linux.h	17 Jun 2005 19:59:20 -0000
@@ -101,6 +101,16 @@ Boston, MA 02111-1307, USA.  */
 %{fPIC|fPIE|fpic|fpie:-D__PIC__ -D__pic__} \
 %{pthread:-D_REENTRANT}"
 
+/* Merged from linux.h and mips/mips.h.  */
+#undef CC1_SPEC
+#define CC1_SPEC "\
+%{profile:-p} \
+%{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1}}}}} \
+%{mips16*:%{!fno-section-relative-addressing:-fsection-relative-addressing -fno-common}} \
+%{fsection-relative-addressing:-fno-common} \
+%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
+%(subtarget_cc1_spec)"
+
 /* From iris5.h */
 /* -G is incompatible with -KPIC which is the default, so only allow objects
    in the small data section if the user explicitly asks for it.  */

From richard@codesourcery.com Fri Jul  8 16:39:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 16:39:20 +0100 (BST)
Received: from admin.voldemort.codesourcery.com ([IPv6:::ffff:65.74.133.9]:3016
	"EHLO mail.codesourcery.com") by linux-mips.org with ESMTP
	id <S8226365AbVGHPjG>; Fri, 8 Jul 2005 16:39:06 +0100
Received: (qmail 22200 invoked by uid 1010); 8 Jul 2005 15:39:40 -0000
From:	Richard Sandiford <richard@codesourcery.com>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Mail-Followup-To: "Maciej W. Rozycki" <macro@linux-mips.org>,Ralf Baechle DL5RB <ralf@linux-mips.org>,  Thiemo Seufer <ths@networkno.de>,  linux-mips@linux-mips.org, richard@codesourcery.com
Cc:	Ralf Baechle DL5RB <ralf@linux-mips.org>,
	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
	<Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl>
	<20050707121235.GV1645@hattusa.textio>
	<Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl>
	<20050707122226.GW1645@hattusa.textio>
	<Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl>
	<20050707162959.GQ2822@linux-mips.org> <87zmsx4do1.fsf@talisman.home>
	<Pine.LNX.4.61L.0507081553040.25104@blysk.ds.pg.gda.pl>
Date:	Fri, 08 Jul 2005 16:39:38 +0100
In-Reply-To: <Pine.LNX.4.61L.0507081553040.25104@blysk.ds.pg.gda.pl> (Maciej
	W. Rozycki's message of "Fri, 8 Jul 2005 16:05:05 +0100 (BST)")
Message-ID: <87pstt4891.fsf@talisman.home>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <richard@codesourcery.com>
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: 8413
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: richard@codesourcery.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1968
Lines: 44

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 8 Jul 2005, Richard Sandiford wrote:
>> Right.  I've always thought of them as the canonical options for gcc
>> as well.  I think the only reason internal compilers like cc1 have
>> -mel and -meb is because gcc's target options system has traditionally
>> required every target option to begin with "-m".  (That's no longer
>> a restriction in 4.1 FWIW.)
>
>  I'm not sure relaxing this restriction is actually a good idea -- there 
> may be tools external to GCC that make this assumption for additional
> handling of options passed to GCC.

Oh, I agree that targets shouldn't gratuitously add non -m options.
All I meant was that, if a target does decide to support compatibility
options like -EB or -EL (or -BE or -LE), the new intrastructure allows
you to do it directly, rather than introduce internal forwarding options
like -meb or -mel.  Forwarding options can cause the sort of confusion
we've seen here.

If we have a clean slate, and no compatibility worries, I agree that
it's better to use -m options across the board.

>  FWIW, I prepared the following patch for GCC 3.4.x the other day -- would 
> you care to verify whether it's still needed for 4.x?  It may be worth
> applying to 3.4, too -- I think the branch hasn't got closed yet, has it?

A quick look at the code suggests that it is still needed for 4.x, yes.

> 2005-07-08  Maciej W. Rozycki  <macro@mips.com>
>
> 	* config/mips/linux.h (CC1_SPEC): Override defaults from
> 	config/linux.h.

Looks reasonable, but I think you should just set SUBTARGET_CC1_SPEC
to the normal linux.h definition of CC1_SPEC.  There shouldn't be
any need to redefine CC1_SPEC itself (with all the mips.h duplication
that that implies).  It'll be easier to keep things in sync that way.

>  Unfortunately it won't let us remove the newly introduced hackery from 
> Linux as (unlike you) we need to support versions back to 2.95.x.

Understood.

Richard

From macro@linux-mips.org Fri Jul  8 16:59:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 16:59:29 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:27916 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226365AbVGHP7L>; Fri, 8 Jul 2005 16:59:11 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 0ACA2E1CB2; Fri,  8 Jul 2005 17:59:43 +0200 (CEST)
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 03664-02; Fri,  8 Jul 2005 17:59:42 +0200 (CEST)
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 AFFF6E1CA8; Fri,  8 Jul 2005 17:59:42 +0200 (CEST)
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 j68Fxln7003130;
	Fri, 8 Jul 2005 17:59:47 +0200
Date:	Fri, 8 Jul 2005 16:59:56 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Richard Sandiford <richard@codesourcery.com>
Cc:	Ralf Baechle DL5RB <ralf@linux-mips.org>,
	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <87pstt4891.fsf@talisman.home>
Message-ID: <Pine.LNX.4.61L.0507081652370.25104@blysk.ds.pg.gda.pl>
References: <20050707091937Z8226163-3678+1737@linux-mips.org>
 <Pine.LNX.4.61L.0507071227170.3205@blysk.ds.pg.gda.pl> <20050707121235.GV1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071314010.3205@blysk.ds.pg.gda.pl> <20050707122226.GW1645@hattusa.textio>
 <Pine.LNX.4.61L.0507071356450.3205@blysk.ds.pg.gda.pl> <20050707162959.GQ2822@linux-mips.org>
 <87zmsx4do1.fsf@talisman.home> <Pine.LNX.4.61L.0507081553040.25104@blysk.ds.pg.gda.pl>
 <87pstt4891.fsf@talisman.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/972/Fri Jul  8 15:43:11 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8414
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: 1102
Lines: 23

On Fri, 8 Jul 2005, Richard Sandiford wrote:

> > 2005-07-08  Maciej W. Rozycki  <macro@mips.com>
> >
> > 	* config/mips/linux.h (CC1_SPEC): Override defaults from
> > 	config/linux.h.
> 
> Looks reasonable, but I think you should just set SUBTARGET_CC1_SPEC
> to the normal linux.h definition of CC1_SPEC.  There shouldn't be
> any need to redefine CC1_SPEC itself (with all the mips.h duplication
> that that implies).  It'll be easier to keep things in sync that way.

 The problem is config/linux.h defines CC1_SPEC before config/mips.h is 
included and as a result the latter does not redefine it.  I feared 
changing "#ifdef CC1_SPEC ... #endif" to "#undef CC1_SPEC" would break 
other targets -- there are too many of them and the dependencies are too 
scattered for me to dare fiddling with this macro (proof-reading is futile 
and testing every configuration impossible).  At least this change is 
guaranteed to affect only Linux.  But I would encourage you, as the 
maintainer, to get a more consistent general arrangement and I can do 
testing for configurations I have access to.

  Maciej

From rolfliu@gmail.com Fri Jul  8 20:27:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 20:27:30 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.194]:25968 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226360AbVGHT1N> convert rfc822-to-8bit;
	Fri, 8 Jul 2005 20:27:13 +0100
Received: by wproxy.gmail.com with SMTP id i34so490209wra
        for <linux-mips@linux-mips.org>; Fri, 08 Jul 2005 12:27:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=jr+T7JPcqCgiNll7FLSWKAZrDl4je8EawpnlCm345h+q6a1Pn8jyyzneFpStn0G2cKg6oRX3+18RHLqntZjXg1aiKW7BPR8QQP6Ca+HQ3rI7z5s3KmI49kcplfMMk7MJAZG+SWIDq1YxM5yLYz79b658mGe58aPwaqNsRopwKOc=
Received: by 10.54.16.77 with SMTP id 77mr444407wrp;
        Fri, 08 Jul 2005 12:27:06 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 8 Jul 2005 12:27:06 -0700 (PDT)
Message-ID: <2db32b7205070812272ce04cb7@mail.gmail.com>
Date:	Fri, 8 Jul 2005 12:27:06 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: booting error on db1550 using linux 2.6.12 from linux-mips.org
Cc:	ppopov@embeddedalley.com,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1120776436.317.57.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205070114172483d2dd@mail.gmail.com>
	 <1120253048.5987.16.camel@localhost.localdomain>
	 <2db32b72050701153566c83bb6@mail.gmail.com>
	 <1120257851.5987.37.camel@localhost.localdomain>
	 <2db32b7205070508504b675dd6@mail.gmail.com>
	 <1120756200.317.14.camel@localhost.localdomain>
	 <2db32b7205070711424c119780@mail.gmail.com>
	 <1120776436.317.57.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8415
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 903
Lines: 31

Alan,

I tried ide=nodma as boot option. It doesn't work either. It stops at
the same place.

Then I used pci_write_config_byte(dev, 0x5b, 0x21); It works and can
boot with the hard disk.  I also tried to force the 372n timing with
the linux-mips cvs head, It also works fine.

I know using PCI Clock as the only timing could have some speed
problems. And forcing 372n timing is like a dirty hack.  Your
suggestion is really appreciated.

thanks



On 7/7/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Iau, 2005-07-07 at 19:42, rolf liu wrote:
> > Alan,
> > Tried your patch on db1550 and linux 2.6.12. It still doesn't work.
> > During the boot-up, the kernel will hang up right after it prints out:
> >
> > >>hdg: max request size: 128 KiB
> 
> > Any suggestion?
> 
> Its got started if it gets that far because the LBA48 status has been
> checked. What occurs if you boot with ide=nodma ?
> 
>

From rolfliu@gmail.com Fri Jul  8 23:20:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Jul 2005 23:20:33 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.202]:43385 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226366AbVGHWUP> convert rfc822-to-8bit;
	Fri, 8 Jul 2005 23:20:15 +0100
Received: by wproxy.gmail.com with SMTP id i21so521302wra
        for <linux-mips@linux-mips.org>; Fri, 08 Jul 2005 15:20:52 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=QzzpZt5IbHAzNN3gAtX8k7Ci3ZbvGSL4YNrB6h5NG3bwaRsP79yNruGiLONCZ4UcWGYa8TEP8s8jaHbhk0UHVX7kTLy7J2KmSKLIL4DLixJ5E6oX3l5lciJ/aGdogJrdTpQcOAcOBGg2/TNjDPYX26rQ8p7ipNJe5hEngG9oIWw=
Received: by 10.54.73.15 with SMTP id v15mr2117957wra;
        Fri, 08 Jul 2005 15:20:13 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 8 Jul 2005 15:20:13 -0700 (PDT)
Message-ID: <2db32b7205070815202bc409f0@mail.gmail.com>
Date:	Fri, 8 Jul 2005 15:20:13 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: glibc 2.3.5 cross building error
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8416
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2717
Lines: 49

I am trying to cross-compile glibc 2.3.5 with linuxthread. And got the
following errors.
It seems the linker is complaining it can't find the definition of
"__fork_block". But it is really defined in "fork.c", which is at the
same directory as register-atfork.c.

Thanks

******************
mipsel-unknown-linux-gnu-gcc -mabi=32   -shared -static-libgcc -Wl,-O1
 -Wl,-z,defs -Wl,-dynamic-linker=/home/rolf/toolchain/lib/ld.so.1 
-B/home/rolf/toolchain/glibc-build/csu/ 
-Wl,--version-script=/home/rolf/toolchain/glibc-build/libc.map
-Wl,-soname=libc.so.6  -nostdlib -nostartfiles -e __libc_main
-L/home/rolf/toolchain/glibc-build
-L/home/rolf/toolchain/glibc-build/math
-L/home/rolf/toolchain/glibc-build/elf
-L/home/rolf/toolchain/glibc-build/dlfcn
-L/home/rolf/toolchain/glibc-build/nss
-L/home/rolf/toolchain/glibc-build/nis
-L/home/rolf/toolchain/glibc-build/rt
-L/home/rolf/toolchain/glibc-build/resolv
-L/home/rolf/toolchain/glibc-build/crypt
-L/home/rolf/toolchain/glibc-build/linuxthreads
-Wl,-rpath-link=/home/rolf/toolchain/glibc-build:/home/rolf/toolchain/glibc-build/math:/home/rolf/toolchain/glibc-build/elf:/home/rolf/toolchain/glibc-build/dlfcn:/home/rolf/toolchain/glibc-build/nss:/home/rolf/toolchain/glibc-build/nis:/home/rolf/toolchain/glibc-build/rt:/home/rolf/toolchain/glibc-build/resolv:/home/rolf/toolchain/glibc-build/crypt:/home/rolf/toolchain/glibc-build/linuxthreads
-o /home/rolf/toolchain/glibc-build/libc.so -T
/home/rolf/toolchain/glibc-build/shlib.lds
/home/rolf/toolchain/glibc-build/csu/abi-note.o
/home/rolf/toolchain/glibc-build/elf/soinit.os
/home/rolf/toolchain/glibc-build/libc_pic.os
/home/rolf/toolchain/glibc-build/elf/sofini.os
/home/rolf/toolchain/glibc-build/elf/interp.os
/home/rolf/toolchain/glibc-build/elf/ld.so -lgcc
/home/rolf/toolchain/glibc-build/libc_pic.os: In function `list_add_tail':
../linuxthreads/sysdeps/pthread/list.h:59: undefined reference to `__fork_block'
../linuxthreads/sysdeps/pthread/list.h:59: undefined reference to `__fork_block'
../linuxthreads/sysdeps/pthread/list.h:59: undefined reference to `__fork_block'
/home/rolf/toolchain/glibc-build/libc_pic.os: In function
`*__GI___register_atfork':
../linuxthreads/sysdeps/unix/sysv/linux/register-atfork.c:84:
undefined reference to `__fork_block'
../linuxthreads/sysdeps/unix/sysv/linux/register-atfork.c:73:
undefined reference to `__fork_block'
/home/rolf/toolchain/glibc-build/libc_pic.os:../linuxthreads/sysdeps/unix/sysv/linux/unregister-atfork.c:35:
more undefined references to `__fork_block' follow
collect2: ld returned 1 exit status
make[1]: *** [/home/rolf/toolchain/glibc-build/libc.so] Error 1
make[1]: Leaving directory `/home/rolf/toolchain/glibc-2.3.5'
make: *** [all] Error 2

From nacc@us.ibm.com Sat Jul  9 01:11:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 01:11:52 +0100 (BST)
Received: from e2.ny.us.ibm.com ([IPv6:::ffff:32.97.182.142]:38036 "EHLO
	e2.ny.us.ibm.com") by linux-mips.org with ESMTP id <S8226366AbVGIAL0>;
	Sat, 9 Jul 2005 01:11:26 +0100
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j690BnHp013337;
	Fri, 8 Jul 2005 20:11:49 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j690BnCf223990;
	Fri, 8 Jul 2005 20:11:49 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j690Bce1012258;
	Fri, 8 Jul 2005 20:11:38 -0400
Received: from joust (joust.beaverton.ibm.com [9.47.17.68])
	by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j690BceE012080;
	Fri, 8 Jul 2005 20:11:38 -0400
Received: by joust (Postfix, from userid 1000)
	id 28D554F916; Fri,  8 Jul 2005 17:11:27 -0700 (PDT)
Date:	Fri, 8 Jul 2005 17:11:27 -0700
From:	Nishanth Aravamudan <nacc@us.ibm.com>
To:	ralf@linux-mips.org
Cc:	linux-mips@linux-mips.org,
	Kernel-Janitors <kernel-janitors@lists.osdl.org>
Subject: [PATCH 7/14] mips: replace timespectojiffies() with timespec_to_jiffies()
Message-ID: <20050709001127.GM2596@us.ibm.com>
References: <20050709000324.GD2596@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050709000324.GD2596@us.ibm.com>
X-Operating-System: Linux 2.6.13-rc2 (i686)
User-Agent: Mutt/1.5.9i
Return-Path: <nacc@us.ibm.com>
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: 8417
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: nacc@us.ibm.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1244
Lines: 43

From: Nishanth Aravamudan <nacc@us.ibm.com>

Description: Replace custom timespectojiffies() function with generic
standard one.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

---

 irixsig.c |   14 +-------------
 1 files changed, 1 insertion(+), 13 deletions(-)

diff -urp 2.6.13-rc2-kj/arch/mips/kernel/irixsig.c 2.6.13-rc2-kj-dev/arch/mips/kernel/irixsig.c
--- 2.6.13-rc2-kj/arch/mips/kernel/irixsig.c	2005-07-06 07:57:02.000000000 -0700
+++ 2.6.13-rc2-kj-dev/arch/mips/kernel/irixsig.c	2005-07-06 13:30:34.000000000 -0700
@@ -441,18 +441,6 @@ struct irix5_siginfo {
 	} stuff;
 };
 
-static inline unsigned long timespectojiffies(struct timespec *value)
-{
-	unsigned long sec = (unsigned) value->tv_sec;
-	long nsec = value->tv_nsec;
-
-	if (sec > (LONG_MAX / HZ))
-		return LONG_MAX;
-	nsec += 1000000000L / HZ - 1;
-	nsec /= 1000000000L / HZ;
-	return HZ * sec + nsec;
-}
-
 asmlinkage int irix_sigpoll_sys(unsigned long *set, struct irix5_siginfo *info,
 				struct timespec *tp)
 {
@@ -490,7 +478,7 @@ asmlinkage int irix_sigpoll_sys(unsigned
 			error = -EINVAL;
 			goto out;
 		}
-		expire = timespectojiffies(tp)+(tp->tv_sec||tp->tv_nsec);
+		expire = timespec_to_jiffies(tp)+(tp->tv_sec||tp->tv_nsec);
 	}
 
 	while(1) {

From fabrizio@fazzino.it Sat Jul  9 08:21:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 08:21:52 +0100 (BST)
Received: from smtpa1.aruba.it ([IPv6:::ffff:62.149.128.206]:30701 "HELO
	smtpa2.aruba.it") by linux-mips.org with SMTP id <S8226376AbVGIHVf>;
	Sat, 9 Jul 2005 08:21:35 +0100
Received: (qmail 21245 invoked by uid 89); 9 Jul 2005 07:22:08 -0000
Received: by simscan 1.1.0 ppid: 21236, pid: 21241, t: 0.1636s
         scanners: clamav: 0.80/m:29/d:680
Received: from unknown (HELO ?192.168.32.1?) (fabrizio@fazzino.it@82.57.252.179)
  by smtp2.aruba.it with SMTP; 9 Jul 2005 07:22:08 -0000
Message-ID: <42CF7B20.5010101@fazzino.it>
Date:	Sat, 09 Jul 2005 09:22:08 +0200
From:	Fabrizio Fazzino <fabrizio@fazzino.it>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: it, it-it, en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: Assembly macro with parameters
References: <425573AD.9010702@fazzino.it> <20050407182549.GA24235@linux-mips.org> <4256B5BE.8070708@fazzino.it> <20050408165717.GA8157@nevyn.them.org> <42C429C3.2090905@fazzino.it> <Pine.LNX.4.61L.0507010927130.30138@blysk.ds.pg.gda.pl> <42C7BE64.7020102@fazzino.it> <Pine.LNX.4.61L.0507041306440.32001@blysk.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.61L.0507041306440.32001@blysk.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <fabrizio@fazzino.it>
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: 8418
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: fabrizio@fazzino.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1136
Lines: 35

Maciej W. Rozycki wrote:
> Fabrizio Fazzino wrote:
> 
>>By the way, is there any quick way of writing a setreg(reg_num,reg_val)
>>C macro to set the value of a register?

Hi guys,
just to let you know that I solved my problem this way:

    // Set a register to the desired value
    #define setreg(regnum,value) asm("move $" #regnum ", %0" : : "r"(value) : "$" #regnum)

    // Move the content of a register to the desired variable
    #define reg2var(regnum,var) asm("sw $" #regnum ", %0" : "=m"(*var) : : "memory")

>  BTW, how about adding support for opcodes you are interested in to 
> binutils instead?  It would make interfacing them to GCC much easier.

The CPU I'm working on will never "exist"... I'm just simulating it
as VHDL code, so I just needed a quick-and-dirty way of generating
inside my very short test programs the new opcodes added as an extension.

Thanks to all for your precious support!

Cheers and regards,

         Fabrizio


-- 
============================================
    Fabrizio Fazzino - fabrizio@fazzino.it
      Fazzino.IT - http://www.fazzino.it
============================================


From ths@networkno.de Sat Jul  9 10:33:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 10:33:46 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:60623 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226381AbVGIJd3>;
	Sat, 9 Jul 2005 10:33:29 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DrBim-0000Sf-00
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 11:34:04 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1DrBim-0006rO-8c
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 11:34:04 +0200
Date:	Sat, 9 Jul 2005 11:34:04 +0200
To:	linux-mips@linux-mips.org
Subject: Current SGI Octane status
Message-ID: <20050709093403.GB1586@hattusa.textio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8419
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 9472
Lines: 166

Hello All,

I tried current CVS HEAD plus the patches from
ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/
on an SMP Octane with 2x195 MHz R10000 and ESI graphics.

Results:

- Local console works.
- IOC3 networking works, with 2MB/s maximum for a 30MB http transfer
- Serial console works, but start of output is delayed. The driver
  probably lacks transfer bootstrap, and starts transmisssion only when
  the first buffer is full.
- Rebooting for SMP works, but this patch apparently broke arcload (hangs
  after "Entering Kernel").
- Serial console and framebuffer initializations seem to be mutually
  exclusive, that's impractical if you plan to route console (debug)
  output over serial while working on the graphics console.
- 'echo "foo" >/dev/fb0' kills the machine.

The dmesg for a serial boot is appended.


Thiemo


[4294667.296000] Linux version 2.6.12-ip30 (ths@hattusa) (gcc version 4.0.1 20050701 (prerelease) (Debian 4.0.0-12)) #21 SMP Sat Jul 9 10:41:57 CEST 2005
[4294667.296000] ARCH: SGI-IP30
[4294667.296000] PROMLIB: ARC firmware Version 64 Revision 0
[4294667.296000] CPU revision is: 00000927
[4294667.296000] FPU revision is: 00000900
[4294667.296000] Silicon Graphics Octane (IP30) support: (c) 2004, 2005 Stanislaw Skowronek.
[4294667.296000] xtalk: Detected XBow (revision 1.2) at 0.
[4294667.296000] xtalk: Detected Heart (revision E) at 8.
[4294667.296000] xtalk: Detected HQ4 / ImpactSR (revision B) at 12.
[4294667.296000] xtalk: Detected Bridge (revision C) at 15.
[4294667.296000] BRIDGE chip at xtalk:15, initializing...
[4294667.296000] Determined physical RAM map:
[4294667.296000]  memory: 0000000000004000 @ 0000000000000000 (reserved)
[4294667.296000]  memory: 00000000004c6000 @ 0000000020004000 (reserved)
[4294667.296000]  memory: 0000000000a36000 @ 00000000204ca000 (usable)
[4294667.296000]  memory: 0000000000100000 @ 0000000020f00000 (ROM data)
[4294667.296000]  memory: 000000003f000000 @ 0000000021000000 (usable)
[4294667.296000] On node 0 totalpages: 393216
[4294667.296000]   DMA zone: 393216 pages, LIFO batch:31
[4294667.296000]   Normal zone: 0 pages, LIFO batch:1
[4294667.296000]   HighMem zone: 0 pages, LIFO batch:1
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: root=xio(0)pci(15)scsi(0)disk(1)rdisk(0)partition(0) root=/dev/sda1 console=ttyS0
[4294667.296000] Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes.
[4294667.296000] Primary data cache 32kB, 2-way, linesize 32 bytes.
[4294667.296000] Unified secondary cache 1024kB 2-way, linesize 128 bytes.
[4294667.296000] Synthesized TLB refill handler (41 instructions).
[4294667.296000] Synthesized TLB load handler fastpath (55 instructions).
[4294667.296000] Synthesized TLB store handler fastpath (55 instructions).
[4294667.296000] Synthesized TLB modify handler fastpath (54 instructions).
[4294667.296000] IP30: interrupt controller initialized.
[4294667.296000] PID hash table entries: 4096 (order: 12, 131072 bytes)
[4294667.296000] IP30: initializing timer.
[4294667.296000] 194 MHz CPU detected
[4294667.296000] Using 97.492 MHz high precision timer.
[4294667.296000] Console: colour dummy device 80x25
[4294667.306000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[4294667.325000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[4294667.560000] Memory: 1017476k/1042648k available (3180k kernel code, 24828k reserved, 1222k data, 248k init, 0k highmem)
[4294667.561000] Calibrating delay loop... 193.53 BogoMIPS (lpj=96768)
[4294667.578000] Mount-cache hash table entries: 256
[4294667.579000] Checking for 'wait' instruction...  unavailable.
[4294667.579000] Checking for the multiply/shift bug... no.
[4294667.579000] Checking for the daddi bug... no.
[4294667.579000] Checking for the daddiu bug... no.
[4294667.580000] CPU revision is: 00000927
[4294667.580000] FPU revision is: 00000900
[4294667.580000] Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes.
[4294667.580000] Primary data cache 32kB, 2-way, linesize 32 bytes.
[4294667.580000] Unified secondary cache 1024kB 2-way, linesize 128 bytes.
[4294667.582000] Synthesized TLB refill handler (41 instructions).
[4294667.582000] Calibrating delay loop... 194.56 BogoMIPS (lpj=97280)
[4294667.599000] Brought up 2 CPUs
[4294667.599000] CPU0 attaching sched-domain:
[4294667.599000]  domain 0: span 3
[4294667.599000]   groups: 1 2
[4294667.599000] CPU1 attaching sched-domain:
[4294667.599000]  domain 0: span 3
[4294667.599000]   groups: 2 1
[4294667.603000] NET: Registered protocol family 16
[4294667.609000] SCSI subsystem initialized
[4294667.610000] IP30: HEART ATTACK! Caught errors: 0x1040!
[4294667.610000]     interrupt #63
[4294667.610000]     interrupt #57
[4294667.622000] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[4294667.623000] Initializing Cryptographic API
[4294667.623000] PCI: Fixing ioc3 in [bus:slot.fn] 0000:00:02.0
[4294667.623000] PCI: Fixing rad1 in [bus:slot.fn] 0000:00:03.0
[4294667.711000] Console: switching to colour frame buffer device 160x64
[4294667.711000] fb0: ImpactSR 1RSS frame buffer device
[4294667.848000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
[4294667.850000] io scheduler noop registered
[4294667.850000] io scheduler anticipatory registered
[4294667.850000] io scheduler deadline registered
[4294667.850000] io scheduler cfq registered
[4294667.854000] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
[4294667.856000] loop: loaded (max 8 devices)
[4294667.856000] tun: Universal TUN/TAP device driver, 1.6
[4294667.856000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[4294667.857000] qla1280: QLA1040 found on PCI bus 0, dev 0
[4294667.857000] PCI: Enabling device 0000:00:00.0 (0006 -> 0007)
[4294668.577000] scsi(0:0): Resetting SCSI BUS
[4294668.579000] scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter
[4294668.579000]        Firmware version:  7.65.00, Driver version 3.25
[4294670.747000]   Vendor: SEAGATE   Model: ST318275LC        Rev: 0001
[4294670.747000]   Type:   Direct-Access                      ANSI SCSI revision: 02
[4294670.748000] scsi(0:0:1:0): Sync: period 10, offset 12, Wide
[4294672.921000] qla1280: QLA1040 found on PCI bus 0, dev 1
[4294672.921000] PCI: Enabling device 0000:00:01.0 (0006 -> 0007)
[4294673.653000] scsi(1:0): Resetting SCSI BUS
[4294673.656000] scsi1 : QLogic QLA1040 PCI to SCSI Host Adapter
[4294673.656000]        Firmware version:  7.65.00, Driver version 3.25
[4294678.158000] SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
[4294678.160000] SCSI device sda: drive cache: write back
[4294678.162000] SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
[4294678.164000] SCSI device sda: drive cache: write back
[4294678.164000]  sda: sda1 sda2 sda9 sda11
[4294678.182000] Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
[4294678.183000] mice: PS/2 mouse device common for all mice
[4294678.183000] md: raid0 personality registered as nr 2
[4294678.183000] md: raid1 personality registered as nr 3
[4294678.183000] md: raid5 personality registered as nr 4
[4294678.183000] raid5: measuring checksumming speed
[4294678.188000]    8regs     :   500.000 MB/sec
[4294678.193000]    8regs_prefetch:   476.000 MB/sec
[4294678.198000]    32regs    :   496.000 MB/sec
[4294678.203000]    32regs_prefetch:   476.000 MB/sec
[4294678.203000] raid5: using function: 8regs (500.000 MB/sec)
[4294678.203000] md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
[4294678.203000] Advanced Linux Sound Architecture Driver Version 1.0.9rc2  (Thu Mar 24 10:33:39 2005 UTC).
[4294678.208000] ALSA device list:
[4294678.208000]   #0: SGI RAD Pro Audio at 0x1fa00000
[4294679.420000] IOC3 part: [030-0891-003], serial: [DJK972] => class IP30 system
[4294679.421000] ttyS0 at IOC3 0x1f620178 (irq = 64) is a 16550A
[4294679.423000] ttyS1 at IOC3 0x1f620170 (irq = 64) is a 16550A
[4294679.428000] Ethernet address is 08:00:69:0a:fc:0f.
[4294679.441000] eth0: link up, 100Mbps, half-duplex, lpa 0x00A1
[4294679.442000] eth0: Using PHY 1, vendor 0x15f42, model 2, rev 3.
[4294679.443000] eth0: IOC3 SSRAM has 128 kbyte.
[4294679.444000] IOC3 Master Driver loaded for 0000:00:02.0
[4294679.445000] NET: Registered protocol family 2
[4294679.548000] atkbd.c: keyboard reset failed on ioc3/serio0kbd
[4294680.035000] atkbd.c: keyboard reset failed on ioc3/serio0aux
[4294680.429000] IP: routing cache hash table of 8192 buckets, 128Kbytes
[4294680.431000] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[4294680.463000] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[4294680.471000] TCP: Hash tables configured (established 262144 bind 65536)
[4294680.472000] NET: Registered protocol family 1
[4294680.473000] NET: Registered protocol family 17
[4294680.474000] NET: Registered protocol family 15
[4294680.476000] md: Autodetecting RAID arrays.
[4294680.477000] md: autorun ...
[4294680.478000] md: ... autorun DONE.
[4294680.506000] kjournald starting.  Commit interval 5 seconds
[4294680.581000] EXT3-fs: mounted filesystem with ordered data mode.
[4294680.662000] VFS: Mounted root (ext3 filesystem) readonly.
[4294680.736000] Freeing prom memory: 1024kb freed
[4294680.796000] Freeing unused kernel memory: 1272k freed
[4294683.050000] Adding 907664k swap on /dev/sda2.  Priority:-1 extents:1
[4294683.389000] EXT3 FS on sda1, internal journal

From sskowron@ET.PUT.Poznan.PL Sat Jul  9 17:36:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 17:36:49 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:40189 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226401AbVGIQga>; Sat, 9 Jul 2005 17:36:30 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j69GbBS25358;
	Sat, 9 Jul 2005 18:37:12 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sat, 9 Jul 2005 18:37:10 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j69Gb8o25243;
	Sat, 9 Jul 2005 18:37:08 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Sat, 9 Jul 2005 18:37:08 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Thiemo Seufer <ths@networkno.de>
cc:	linux-mips@linux-mips.org
Subject: Re: Current SGI Octane status
In-Reply-To: <20050709093403.GB1586@hattusa.textio>
Message-ID: <Pine.GSO.4.10.10507091833390.24862-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8420
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 902
Lines: 32

> - IOC3 networking works, with 2MB/s maximum for a 30MB http transfer

This is strange. Ask Ralf.

> - Serial console works, but start of output is delayed. The driver
>   probably lacks transfer bootstrap, and starts transmisssion only when
>   the first buffer is full.

Yuck. What should be done about it?

> - Rebooting for SMP works, but this patch apparently broke arcload (hangs
>   after "Entering Kernel").

This was an unrelated problem, fixed.

> - Serial console and framebuffer initializations seem to be mutually
>   exclusive, that's impractical if you plan to route console (debug)
>   output over serial while working on the graphics console.

Heh, I work on the graphics console using the graphics console. It's more
funny.

> - 'echo "foo" >/dev/fb0' kills the machine.

Oops.

I return -EINVAL in read and write on ImpactSR. Sick. Do you know where it
fails, exactly?

Stanislaw



From ths@networkno.de Sat Jul  9 21:53:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 21:53:46 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:32180 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226406AbVGIUx2>;
	Sat, 9 Jul 2005 21:53:28 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DrMKt-0002Cq-00
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 22:54:07 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1DrMKs-00017h-Rm
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 22:54:06 +0200
Date:	Sat, 9 Jul 2005 22:54:06 +0200
To:	linux-mips@linux-mips.org
Subject: Origin 200 Status
Message-ID: <20050709205406.GF1586@hattusa.textio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8421
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 13261
Lines: 236

Hello All,

testing a single-node O200 SMP with current CVS and the patches from
ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/ , plus the
icache flush cache patch from Ralf, plus the PCI detection workaround
for ip27 gave

- working serial console
- working RTC
- ethernet with ~2.5 MB throughput

and a stable system. The IOC3 detection shows some weirdness:

[4294678.019000] IOC3 part: [], serial: [] => class IP27 BaseIO
[4294678.020000] ioc3_probe : request_irq fails for IRQ 0x4
[4294678.020000]  ttyS0 at IOC3 0x8620178 (irq = 0) is a 16550A
[4294678.027000] ttyS1 at IOC3 0x8620170 (irq = 0) is a 16550A

but this doesn't seem to have consequences for the serial console.


Thiemo


[4294667.296000] Linux version 2.6.12-ip30 (ths@hattusa) (gcc version 4.0.1 20050701 (prerelease) (Debian 4.0.0-12)) #220 SMP Sat Jul 9 22:39:47 CEST 2005
[4294667.296000] ARCH: SGI-IP27
[4294667.296000] PROMLIB: ARC firmware Version 64 Revision 0
[4294667.296000] Discovered 2 cpus on 1 nodes
[4294667.296000] node_distance: router_a NULL
[4294667.296000] ************** Topology ********************
[4294667.296000]     00 
[4294667.296000] 00  255 
[4294667.296000] CPU revision is: 00000e23
[4294667.296000] FPU revision is: 00000900
[4294667.296000] IP27: Running on node 0.
[4294667.296000] Node 0 has a primary CPU, CPU is running.
[4294667.296000] Node 0 has a secondary CPU, CPU is running.
[4294667.296000] Machine is in M mode.
[4294667.296000] Cpu 0, Nasid 0x0: partnum 0xc002 is a bridge
[4294667.296000] CPU 0 clock is 270MHz.
[4294667.296000] Determined physical RAM map:
[4294667.296000] On node 0 totalpages: 262144
[4294667.296000]   DMA zone: 262144 pages, LIFO batch:31
[4294667.296000]   Normal zone: 0 pages, LIFO batch:1
[4294667.296000]   HighMem zone: 0 pages, LIFO batch:1
[4294667.296000] Built 1 zonelists
[4294667.296000] Kernel command line: root=dksc(0,1,0) root=/dev/sda1
[4294667.296000] Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes.
[4294667.296000] Primary data cache 32kB, 2-way, linesize 32 bytes.
[4294667.296000] Unified secondary cache 4096kB 2-way, linesize 128 bytes.
[4294667.296000] Synthesized TLB refill handler (41 instructions).
[4294667.296000] Synthesized TLB load handler fastpath (55 instructions).
[4294667.296000] Synthesized TLB store handler fastpath (55 instructions).
[4294667.296000] Synthesized TLB modify handler fastpath (54 instructions).
[4294667.296000] PID hash table entries: 4096 (order: 12, 131072 bytes)
[4294667.330000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[4294667.352000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[4294667.895000] Memory: 1023476k/1048576k available (2893k kernel code, 25100k reserved, 1244k data, 232k init, 0k highmem)
[4294667.898000] Calibrating delay loop... 402.43 BogoMIPS (lpj=201216)
[4294667.919000] Mount-cache hash table entries: 256
[4294667.922000] Checking for 'wait' instruction...  unavailable.
[4294667.924000] Checking for the multiply/shift bug... no.
[4294667.926000] Checking for the daddi bug... no.
[4294667.928000] Checking for the daddiu bug... no.
[4294667.930000] REPLICATION: ON nasid 0, ktext from nasid 0, kdata from nasid 0
[4294667.932000] CPU revision is: 00000e23
[4294667.932000] FPU revision is: 00000900
[4294667.932000] Primary instruction cache 32kB, physically tagged, 2-way, linesize 64 bytes.
[4294667.932000] Primary data cache 32kB, 2-way, linesize 32 bytes.
[4294667.933000] Unified secondary cache 4096kB 2-way, linesize 128 bytes.
[4294667.935000] Synthesized TLB refill handler (41 instructions).
[4294667.935000] CPU 1 clock is 270MHz.
[4294667.936000] Calibrating delay loop... 400.38 BogoMIPS (lpj=200192)
[4294667.956000] Brought up 2 CPUs
[4294667.957000] CPU0 attaching sched-domain:
[4294667.957000]  domain 0: span 00000000,00000003
[4294667.957000]   groups: 00000000,00000001 00000000,00000002
[4294667.957000] CPU1 attaching sched-domain:
[4294667.957000]  domain 0: span 00000000,00000003
[4294667.957000]   groups: 00000000,00000002 00000000,00000001
[4294667.960000] NET: Registered protocol family 16
[4294667.966000] SCSI subsystem initialized
[4294667.976000] devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
[4294667.977000] devfs: boot_options: 0x0
[4294667.979000] Initializing Cryptographic API
[4294668.099000] Real Time Clock Driver v1.09b
[4294668.100000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
[4294668.103000] io scheduler noop registered
[4294668.105000] io scheduler anticipatory registered
[4294668.108000] io scheduler deadline registered
[4294668.110000] io scheduler cfq registered
[4294668.114000] loop: loaded (max 8 devices)
[4294668.116000] qla1280: QLA1040 found on PCI bus 0, dev 0
[4294668.117000] PCI: Enabling device 0000:00:00.0 (0006 -> 0007)
[4294668.732000] scsi(0:0): Resetting SCSI BUS
[4294668.736000] scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter
[4294668.736000]        Firmware version:  7.65.00, Driver version 3.25
[4294671.026000]   Vendor: SEAGATE   Model: ST318275LC        Rev: 0001
[4294671.058000]   Type:   Direct-Access                      ANSI SCSI revision: 02
[4294671.061000] scsi(0:0:3:0): Sync: period 10, offset 12, Wide
[4294671.073000]   Vendor: SEAGATE   Model: ST318275LC        Rev: 0001
[4294671.105000]   Type:   Direct-Access                      ANSI SCSI revision: 02
[4294671.109000] scsi(0:0:4:0): Sync: period 10, offset 12, Wide
[4294671.121000]   Vendor: SEAGATE   Model: ST318275LC        Rev: 0001
[4294671.153000]   Type:   Direct-Access                      ANSI SCSI revision: 02
[4294671.157000] scsi(0:0:5:0): Sync: period 10, offset 12, Wide
[4294671.168000]   Vendor: SEAGATE   Model: ST318275LC        Rev: 0001
[4294671.200000]   Type:   Direct-Access                      ANSI SCSI revision: 02
[4294671.204000] scsi(0:0:6:0): Sync: period 10, offset 12, Wide
[4294672.542000] qla1280: QLA1040 found on PCI bus 0, dev 1
[4294672.543000] PCI: Enabling device 0000:00:01.0 (0006 -> 0007)
[4294673.159000] scsi(1:0): Resetting SCSI BUS
[4294673.163000] scsi1 : QLogic QLA1040 PCI to SCSI Host Adapter
[4294673.163000]        Firmware version:  7.65.00, Driver version 3.25
[4294677.449000] SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.453000] SCSI device sda: drive cache: write back
[4294677.456000] SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.459000] SCSI device sda: drive cache: write back
[4294677.460000]  /dev/scsi/host0/bus0/target3/lun0: p1 p2 p3 p9 p11
[4294677.484000] Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
[4294677.490000] SCSI device sdb: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.493000] SCSI device sdb: drive cache: write back
[4294677.496000] SCSI device sdb: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.499000] SCSI device sdb: drive cache: write back
[4294677.500000]  /dev/scsi/host0/bus0/target4/lun0: p1 p2 p3 p9 p11
[4294677.523000] Attached scsi disk sdb at scsi0, channel 0, id 4, lun 0
[4294677.529000] SCSI device sdc: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.532000] SCSI device sdc: drive cache: write back
[4294677.534000] SCSI device sdc: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.537000] SCSI device sdc: drive cache: write back
[4294677.538000]  /dev/scsi/host0/bus0/target5/lun0: p1 p2 p3 p9 p11
[4294677.564000] Attached scsi disk sdc at scsi0, channel 0, id 5, lun 0
[4294677.570000] SCSI device sdd: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.573000] SCSI device sdd: drive cache: write back
[4294677.575000] SCSI device sdd: 35566480 512-byte hdwr sectors (18210 MB)
[4294677.578000] SCSI device sdd: drive cache: write back
[4294677.579000]  /dev/scsi/host0/bus0/target6/lun0: p1 p2 p3 p9 p11
[4294677.603000] Attached scsi disk sdd at scsi0, channel 0, id 6, lun 0
[4294677.604000] Attached scsi generic sg0 at scsi0, channel 0, id 3, lun 0,  type 0
[4294677.606000] Attached scsi generic sg1 at scsi0, channel 0, id 4, lun 0,  type 0
[4294677.607000] Attached scsi generic sg2 at scsi0, channel 0, id 5, lun 0,  type 0
[4294677.608000] Attached scsi generic sg3 at scsi0, channel 0, id 6, lun 0,  type 0
[4294677.609000] md: linear personality registered as nr 1
[4294677.610000] md: raid0 personality registered as nr 2
[4294677.611000] md: raid1 personality registered as nr 3
[4294677.612000] md: raid10 personality registered as nr 9
[4294677.613000] md: raid5 personality registered as nr 4
[4294677.614000] raid5: measuring checksumming speed
[4294677.620000]    8regs     :   688.000 MB/sec
[4294677.626000]    8regs_prefetch:   656.000 MB/sec
[4294677.632000]    32regs    :   684.000 MB/sec
[4294677.638000]    32regs_prefetch:   656.000 MB/sec
[4294677.639000] raid5: using function: 8regs (688.000 MB/sec)
[4294677.657000] raid6: int64x1    179 MB/s
[4294677.675000] raid6: int64x2    246 MB/s
[4294677.693000] raid6: int64x4    312 MB/s
[4294677.711000] raid6: int64x8    199 MB/s
[4294677.712000] raid6: using algorithm int64x4 (312 MB/s)
[4294677.713000] md: raid6 personality registered as nr 8
[4294677.714000] md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
[4294677.728000] device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
[4294678.019000] IOC3 part: [], serial: [] => class IP27 BaseIO
[4294678.020000] ioc3_probe : request_irq fails for IRQ 0x4
[4294678.020000]  ttyS0 at IOC3 0x8620178 (irq = 0) is a 16550A
[4294678.027000] ttyS1 at IOC3 0x8620170 (irq = 0) is a 16550A
[4294678.033000] Ethernet address is 08:00:69:0d:52:e7.
[4294678.047000] eth0: link up, 100Mbps, half-duplex, lpa 0x40A1
[4294678.048000] eth0: Using PHY 31, vendor 0x20005c0, model 0, rev 1.
[4294678.049000] eth0: IOC3 SSRAM has 128 kbyte.
[4294678.050000] IOC3 Master Driver loaded for 0000:00:02.0
[4294678.051000] NET: Registered protocol family 2
[4294678.065000] IP: routing cache hash table of 4096 buckets, 64Kbytes
[4294678.068000] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[4294678.094000] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[4294678.102000] TCP: Hash tables configured (established 262144 bind 65536)
[4294678.103000] NET: Registered protocol family 1
[4294678.104000] NET: Registered protocol family 17
[4294678.105000] NET: Registered protocol family 15
[4294678.109000] devfs_mk_dev: could not append to parent for md/0
[4294678.110000] md: Autodetecting RAID arrays.
[4294678.213000] md: autorun ...
[4294678.214000] md: considering sdd3 ...
[4294678.215000] md:  adding sdd3 ...
[4294678.216000] md: sdd1 has different UUID to sdd3
[4294678.217000] md:  adding sdc3 ...
[4294678.218000] md: sdc1 has different UUID to sdd3
[4294678.219000] md:  adding sdb3 ...
[4294678.220000] md: sdb1 has different UUID to sdd3
[4294678.221000] md: created md0
[4294678.222000] md: bind<sdb3>
[4294678.223000] md: bind<sdc3>
[4294678.224000] md: bind<sdd3>
[4294678.225000] md: running: <sdd3><sdc3><sdb3>
[4294678.231000] raid5: device sdd3 operational as raid disk 2
[4294678.232000] raid5: device sdc3 operational as raid disk 1
[4294678.233000] raid5: device sdb3 operational as raid disk 0
[4294678.237000] raid5: allocated 3218kB for md0
[4294678.238000] raid5: raid level 5 set md0 active with 3 out of 3 devices, algorithm 2
[4294678.239000] RAID5 conf printout:
[4294678.240000]  --- rd:3 wd:3 fd:0
[4294678.241000]  disk 0, o:1, dev:sdb3
[4294678.242000]  disk 1, o:1, dev:sdc3
[4294678.243000]  disk 2, o:1, dev:sdd3
[4294678.244000] md: considering sdd1 ...
[4294678.245000] md:  adding sdd1 ...
[4294678.246000] md:  adding sdc1 ...
[4294678.247000] md:  adding sdb1 ...
[4294678.249000] devfs_mk_dev: could not append to parent for md/1
[4294678.250000] md: created md1
[4294678.251000] md: bind<sdb1>
[4294678.252000] md: bind<sdc1>
[4294678.253000] md: bind<sdd1>
[4294678.255000] md: running: <sdd1><sdc1><sdb1>
[4294678.260000] raid5: device sdd1 operational as raid disk 2
[4294678.261000] raid5: device sdc1 operational as raid disk 1
[4294678.262000] raid5: device sdb1 operational as raid disk 0
[4294678.266000] raid5: allocated 3218kB for md1
[4294678.267000] raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
[4294678.268000] RAID5 conf printout:
[4294678.269000]  --- rd:3 wd:3 fd:0
[4294678.270000]  disk 0, o:1, dev:sdb1
[4294678.271000]  disk 1, o:1, dev:sdc1
[4294678.272000]  disk 2, o:1, dev:sdd1
[4294678.273000] md: ... autorun DONE.
[4294678.297000] kjournald starting.  Commit interval 5 seconds
[4294678.299000] EXT3-fs: mounted filesystem with ordered data mode.
[4294678.300000] VFS: Mounted root (ext3 filesystem) readonly.
[4294678.301000] Freeing unused kernel memory: 232k freed
[4294681.162000] Adding 506036k swap on /dev/sda2.  Priority:-1 extents:1
[4294681.183000] Adding 506036k swap on /dev/sdb2.  Priority:-2 extents:1
[4294681.205000] Adding 506036k swap on /dev/sdc2.  Priority:-3 extents:1
[4294681.225000] Adding 506036k swap on /dev/sdd2.  Priority:-4 extents:1
[4294681.465000] EXT3 FS on sda1, internal journal
[4294687.981000] kjournald starting.  Commit interval 5 seconds
[4294688.013000] EXT3 FS on md0, internal journal
[4294688.016000] EXT3-fs: mounted filesystem with ordered data mode.

From ths@networkno.de Sat Jul  9 22:19:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Jul 2005 22:20:06 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:27831 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226409AbVGIVTu>;
	Sat, 9 Jul 2005 22:19:50 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DrMkP-0002bS-00
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 23:20:29 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1DrMkP-0001Nw-DV
	for linux-mips@linux-mips.org; Sat, 09 Jul 2005 23:20:29 +0200
Date:	Sat, 9 Jul 2005 23:20:29 +0200
To:	linux-mips@linux-mips.org
Subject: Re: Current SGI Octane status
Message-ID: <20050709212029.GG1586@hattusa.textio>
References: <20050709093403.GB1586@hattusa.textio> <Pine.GSO.4.10.10507091833390.24862-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10507091833390.24862-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8422
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 397
Lines: 19

Stanislaw Skowronek wrote:
> > - IOC3 networking works, with 2MB/s maximum for a 30MB http transfer
> 
> This is strange. Ask Ralf.

Up to 2.5 Mb actually. Still well below wat it should be.

[snip]
> > - 'echo "foo" >/dev/fb0' kills the machine.
> 
> Oops.
> 
> I return -EINVAL in read and write on ImpactSR. Sick. Do you know where it
> fails, exactly?

Haven't had a closer look yet.


Thiemo

From sskowron@ET.PUT.Poznan.PL Sun Jul 10 07:13:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Jul 2005 07:13:31 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:46747
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226229AbVGJGNP>; Sun, 10 Jul 2005 07:13:15 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6A6DwT27493;
	Sun, 10 Jul 2005 08:13:58 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Sun, 10 Jul 2005 08:13:57 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6A6Dvx07147;
	Sun, 10 Jul 2005 08:13:57 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Sun, 10 Jul 2005 08:13:56 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Thiemo Seufer <ths@networkno.de>
cc:	linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
In-Reply-To: <20050709205406.GF1586@hattusa.textio>
Message-ID: <Pine.GSO.4.10.10507100808410.6614-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8423
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 1154
Lines: 29

> [4294678.019000] IOC3 part: [], serial: [] => class IP27 BaseIO

This is not really weird, the IOC3 on the IP27 board has no NICs. We'd
have to trace the BRIDGE NICs or even HUB NICs to get the serials, so I
decided that it's an overkill. Although it will be required for reliably
detecting MENET (which has a serial# NIC on the BRIDGE).

> [4294678.020000] ioc3_probe : request_irq fails for IRQ 0x4

This is weird. This means the keyboard will not be operational, and I wish
somebody (Ralf) looks into this. The IOC3 on IP27 BaseIO is a dual-slot
device (takes two IRQs, the INTA and INTA+2).

> [4294678.020000]  ttyS0 at IOC3 0x8620178 (irq = 0) is a 16550A
> [4294678.027000] ttyS1 at IOC3 0x8620170 (irq = 0) is a 16550A

Serial ports will not use IRQs on IP27 unless somebody does dynirqs for
this arch. Nevertheless, if you pass 0 to register_serial() it will use
polling. Note that this is exactly the way IP27 always handled the serial
ports in ioc3-eth.c, so shed no tears :)

> [4294678.033000] Ethernet address is 08:00:69:0d:52:e7.

Good news this works. Anyone with Origin 2000 that had problems with MAC
NICs care to test?

Stanislaw



From olh@suse.de Sun Jul 10 20:34:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Jul 2005 20:34:49 +0100 (BST)
Received: from ns1.suse.de ([IPv6:::ffff:195.135.220.2]:56722 "EHLO
	mx1.suse.de") by linux-mips.org with ESMTP id <S8226431AbVGJTe2>;
	Sun, 10 Jul 2005 20:34:28 +0100
Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.suse.de (Postfix) with ESMTP id 0BFBFEDFA;
	Sun, 10 Jul 2005 21:35:13 +0200 (CEST)
Date:	Sun, 10 Jul 2005 19:35:12 +0000
From:	Olaf Hering <olh@suse.de>
To:	Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Cc:	linux-mips@linux-mips.org
Subject: [PATCH 4/82] remove linux/version.h include from arch/mips
Message-ID:  <20050710193512.4.TqwKKi2359.2247.olh@nectarine.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-DOS:	I got your 640K Real Mode Right Here Buddy!
X-Homeland-Security: You are not supposed to read this line! You are a terrorist!
User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise)
In-Reply-To: <20050710193508.0.PmFpst2252.2247.olh@nectarine.suse.de>  
Return-Path: <olh@suse.de>
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: 8424
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: olh@suse.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1663
Lines: 46


changing CONFIG_LOCALVERSION rebuilds too much, for no appearent reason.

Signed-off-by: Olaf Hering <olh@suse.de>

arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h |    1 -
arch/mips/pmc-sierra/yosemite/ht-irq.c            |    1 -
arch/mips/pmc-sierra/yosemite/ht.c                |    1 -
3 files changed, 3 deletions(-)

Index: linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h
+++ linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h
@@ -34,7 +34,6 @@
#include <linux/pci.h>
#include <linux/kernel.h>
#include <linux/slab.h>
-#include <linux/version.h>
#include <asm/pci.h>
#include <asm/io.h>
#include <linux/init.h>
Index: linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/ht-irq.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/mips/pmc-sierra/yosemite/ht-irq.c
+++ linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/ht-irq.c
@@ -26,7 +26,6 @@
#include <linux/types.h>
#include <linux/pci.h>
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/init.h>
#include <asm/pci.h>

Index: linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/ht.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/mips/pmc-sierra/yosemite/ht.c
+++ linux-2.6.13-rc2-mm1/arch/mips/pmc-sierra/yosemite/ht.c
@@ -28,7 +28,6 @@
#include <linux/pci.h>
#include <linux/kernel.h>
#include <linux/slab.h>
-#include <linux/version.h>
#include <asm/pci.h>
#include <asm/io.h>


From ralf@linux-mips.org Mon Jul 11 08:51:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 08:52:00 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:18185 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226444AbVGKHvl>; Mon, 11 Jul 2005 08:51:41 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6B7qTMj002065;
	Mon, 11 Jul 2005 08:52:30 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6ANEKqT020991;
	Mon, 11 Jul 2005 00:14:20 +0100
Date:	Mon, 11 Jul 2005 00:14:19 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Alex Gonzalez <linux-mips@packetvision.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Benchmarking RM9000
Message-ID: <20050710231419.GA28518@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org> <20050708120238.GA2816@linux-mips.org> <1120825549.28569.949.camel@euskadi.packetvision> <20050708130131.GC2816@linux-mips.org> <1120833749.28569.965.camel@euskadi.packetvision>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1120833749.28569.965.camel@euskadi.packetvision>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8425
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 745
Lines: 20

On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:

> The performance of our video application is well below our expectations.
> We are still doing some profiling work on it, but we are also looking at
> other possibilities.
> 
> What other benchmarking tool would you recommend?
> 
> Currently it's a NFS mounted system, but even if we could use a block
> device the access speed wouldn't be more than 1.5 Mbps, so that is a
> limitation for the benchmark.

As a shot into the dark ...

Make sure you exploit the RM9000's write-gathering capabilities when
writing into the frame buffer.  If the frame buffer happens to be on
a PCI device you're probably performing uncached writes which will
slow down the thing to a crawl.

  Ralf

From ralf@linux-mips.org Mon Jul 11 09:44:40 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 09:44:57 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:5151 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226446AbVGKIok>; Mon, 11 Jul 2005 09:44:40 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6B8jTiJ006580
	for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 09:45:29 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6B8jTjA006579
	for linux-mips@linux-mips.org; Mon, 11 Jul 2005 09:45:29 +0100
Date:	Mon, 11 Jul 2005 09:45:29 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050711084529.GB2765@linux-mips.org>
References: <20050711083532Z8226446-3678+2437@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050711083532Z8226446-3678+2437@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8426
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 447
Lines: 20

On Mon, Jul 11, 2005 at 09:35:31AM +0100, ths@linux-mips.org wrote:
> From:	ths@linux-mips.org
> To:	linux-cvs-patches@linux-mips.org
> Subject: CVS Update@linux-mips.org: linux
> Date:	Mon, 11 Jul 2005 09:35:31 +0100
> 
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/07/11 09:35:25
> 
> Modified files:
> 	.              : Makefile 
> 
> Log message:
> 	Use the mainline way to handle this.

Yanked.

  Ralf

From ldarby@mips.com Mon Jul 11 12:09:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 12:09:55 +0100 (BST)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:6674 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8226444AbVGKLJf>;
	Mon, 11 Jul 2005 12:09:35 +0100
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1DrwSD-0006bQ-00; Mon, 11 Jul 2005 12:28:05 +0100
Received: from kenton.mips.com ([192.168.192.199])
	by olympia.mips.com with smtp (Exim 3.36 #1 (Debian))
	id 1DrwAi-0005pT-00; Mon, 11 Jul 2005 12:10:00 +0100
Date:	Mon, 11 Jul 2005 12:09:59 +0100
From:	Laurence Darby <ldarby@mips.com>
To:	Alex Gonzalez <linux-mips@packetvision.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Benchmarking RM9000
Message-Id: <20050711120959.564da2f4.ldarby@mips.com>
In-Reply-To: <1120833749.28569.965.camel@euskadi.packetvision>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	<20050708120238.GA2816@linux-mips.org>
	<1120825549.28569.949.camel@euskadi.packetvision>
	<20050708130131.GC2816@linux-mips.org>
	<1120833749.28569.965.camel@euskadi.packetvision>
X-Mailer: Sylpheed version 2.0.0beta2 (GTK+ 2.6.4; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MTUK-Scanner:	Found to be clean
X-MTUK-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.878,
	required 4, AWL, BAYES_00)
Return-Path: <ldarby@mips.com>
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: 8427
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: ldarby@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 652
Lines: 23

Alex Gonzalez wrote:

> The performance of our video application is well below our
> expectations. We are still doing some profiling work on it, but we
> are also looking at other possibilities.
> 
> What other benchmarking tool would you recommend?


There's lmbench, available only from 
http://ftp.debian.org/debian/pool/non-free/l/lmbench/lmbench_2.0-patch2.orig.tar.gz
(the debian package itself doesn't work, and its main ftp site seems to
be down)

glxgears is nice and simple for 3d bmarks.

mplayer may be useful with its -benchmark option. Its docs, though
mostly x86 specific, are still interesting for video performance
issues.


Laurence


From D.Mierzejewski@icm.edu.pl Mon Jul 11 12:54:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 12:54:51 +0100 (BST)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:24244 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8226453AbVGKLye>;
	Mon, 11 Jul 2005 12:54:34 +0100
Received: from fs.icm.edu.pl (fs.icm.edu.pl [192.168.1.165])
	by atol.icm.edu.pl (8.13.1/8.13.1/rzm-5.1/icm) with ESMTP id j6BBtLpK005645
	for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 13:55:21 +0200
Received: from ws-gradcol1.icm.edu.pl (ws-gradcol1.icm.edu.pl [192.168.1.26])
	by fs.icm.edu.pl (8.13.3/8.13.2/rzm-2.9.4/icm) with ESMTP id j6BBtLK9026934
	for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 13:55:21 +0200 (CEST)
Received: by ws-gradcol1.icm.edu.pl (Postfix, from userid 5242)
	id 6D5149203F; Mon, 11 Jul 2005 13:55:21 +0200 (CEST)
Date:	Mon, 11 Jul 2005 13:55:21 +0200
From:	"Dominik 'Rathann' Mierzejewski" <D.Mierzejewski@icm.edu.pl>
To:	linux-mips@linux-mips.org
Subject: Re: Benchmarking RM9000
Message-ID: <20050711115521.GA18416@ws-gradcol1.icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20050708091711Z8226352-3678+1954@linux-mips.org> <20050708120238.GA2816@linux-mips.org> <1120825549.28569.949.camel@euskadi.packetvision> <20050708130131.GC2816@linux-mips.org> <1120833749.28569.965.camel@euskadi.packetvision> <20050711120959.564da2f4.ldarby@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050711120959.564da2f4.ldarby@mips.com>
User-Agent: Mutt/1.5.9i
X-Rcpt-To: <linux-mips@linux-mips.org>
X-Classes: vf: <linux-mips@linux-mips.org>, vh: , sf: <linux-mips@linux-mips.org>, sh:  (MDrzm)
X-Filtry: w sprawie filtracji wirusow i spamu pisz do: spam@icm.edu.pl
X-Scanned-By: MIMEDefang 2.51 on 192.168.1.242
Return-Path: <D.Mierzejewski@icm.edu.pl>
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: 8428
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: D.Mierzejewski@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 883
Lines: 26

On Mon, Jul 11, 2005 at 12:09:59PM +0100, Laurence Darby wrote:
> Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our
> > expectations. We are still doing some profiling work on it, but we
> > are also looking at other possibilities.
> > 
> > What other benchmarking tool would you recommend?
[...] 
> mplayer may be useful with its -benchmark option. Its docs, though
> mostly x86 specific, are still interesting for video performance
> issues.

If you do use mplayer, please send all useful feedback to
mplayer-users at mplayerhq.hu, too, please.

We (MPlayer team) are always interested in mplayer operation on other
architectures.

Regards,
R.

-- 
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl>
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810

From ralf@linux-mips.org Mon Jul 11 14:56:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 14:56:46 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:14615 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226463AbVGKN4a>; Mon, 11 Jul 2005 14:56:30 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BDvJUX002838;
	Mon, 11 Jul 2005 14:57:19 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BDvI4Z002837;
	Mon, 11 Jul 2005 14:57:18 +0100
Date:	Mon, 11 Jul 2005 14:57:18 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
Message-ID: <20050711135718.GU2765@linux-mips.org>
References: <20050709205406.GF1586@hattusa.textio> <Pine.GSO.4.10.10507100808410.6614-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10507100808410.6614-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8429
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1278
Lines: 30

On Sun, Jul 10, 2005 at 08:13:56AM +0200, Stanislaw Skowronek wrote:

> > [4294678.019000] IOC3 part: [], serial: [] => class IP27 BaseIO
> 
> This is not really weird, the IOC3 on the IP27 board has no NICs. We'd
> have to trace the BRIDGE NICs or even HUB NICs to get the serials, so I
> decided that it's an overkill. Although it will be required for reliably
> detecting MENET (which has a serial# NIC on the BRIDGE).

Of course there's a NIC.  The driver has no special handling for IP27 and
is capable of reading the NICs on some machines at least.  That would be
a rather suprising ability if there was no NIC associated with that IOC3 ;-)

(A while ago I recall a few second hand Origins were being sold on eBay
with NICs removed ...)

> > [4294678.020000] ioc3_probe : request_irq fails for IRQ 0x4
> 
> This is weird. This means the keyboard will not be operational, and I wish
> somebody (Ralf) looks into this. The IOC3 on IP27 BaseIO is a dual-slot
> device (takes two IRQs, the INTA and INTA+2).

All information that I have says only INTA is being used for IP27.  It
will probably take a bit of testing.

I haven't yet had any complaints about keyboard and mouse being non-
functional on IP27 - even though my Origin has 4 keyboard and 4 mouse
ports ;-)

   Ralf

From sskowron@ET.PUT.Poznan.PL Mon Jul 11 15:07:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 15:07:29 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:10713 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226463AbVGKOHN>; Mon, 11 Jul 2005 15:07:13 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6BE85S14079;
	Mon, 11 Jul 2005 16:08:06 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Mon, 11 Jul 2005 16:08:04 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6BE81Y23782;
	Mon, 11 Jul 2005 16:08:01 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Mon, 11 Jul 2005 16:08:00 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Ralf Baechle <ralf@linux-mips.org>
cc:	linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
In-Reply-To: <20050711135718.GU2765@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10507111605570.23550-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8430
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 857
Lines: 20

> Of course there's a NIC.  The driver has no special handling for IP27 and
> is capable of reading the NICs on some machines at least.  That would be
> a rather suprising ability if there was no NIC associated with that IOC3 ;-)

There is only a MAC NIC on a machine ths has. Remember that the Octane
does not have the BaseIO NIC at the IOC3; both NICs placed there are
actually hacks because of XBOW MicroLAN bug.

> > This is weird. This means the keyboard will not be operational, and I wish
> > somebody (Ralf) looks into this. The IOC3 on IP27 BaseIO is a dual-slot
> > device (takes two IRQs, the INTA and INTA+2).
> All information that I have says only INTA is being used for IP27.  It
> will probably take a bit of testing.

Yeah, change the interrupt assignments in ioc3.c, plug in a keyboard and
try. If it works, everybody wins :)

Stanislaw



From ralf@linux-mips.org Mon Jul 11 15:11:17 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 15:11:33 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:39702 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226451AbVGKOLR>; Mon, 11 Jul 2005 15:11:17 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BEC6Ag003431;
	Mon, 11 Jul 2005 15:12:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BEC51s003430;
	Mon, 11 Jul 2005 15:12:05 +0100
Date:	Mon, 11 Jul 2005 15:12:05 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Nishanth Aravamudan <nacc@us.ibm.com>
Cc:	linux-mips@linux-mips.org,
	Kernel-Janitors <kernel-janitors@lists.osdl.org>
Subject: Re: [PATCH 7/14] mips: replace timespectojiffies() with timespec_to_jiffies()
Message-ID: <20050711141205.GV2765@linux-mips.org>
References: <20050709000324.GD2596@us.ibm.com> <20050709001127.GM2596@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050709001127.GM2596@us.ibm.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8431
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 185
Lines: 8

On Fri, Jul 08, 2005 at 05:11:27PM -0700, Nishanth Aravamudan wrote:

> Description: Replace custom timespectojiffies() function with generic
> standard one.

Applied.  Thanks,

  Ralf

From yuasa@hh.iij4u.or.jp Mon Jul 11 16:00:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:00:36 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:32714 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226453AbVGKPAT>;
	Mon, 11 Jul 2005 16:00:19 +0100
Received: MO(mo00)id j6BF1B6W016168; Tue, 12 Jul 2005 00:01:11 +0900 (JST)
Received: MDO(mdo01) id j6BF1AlN022593; Tue, 12 Jul 2005 00:01:11 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j6BF1ACk022334
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 12 Jul 2005 00:01:10 +0900 (JST)
Date:	Tue, 12 Jul 2005 00:01:08 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove obsolete config in
 arch/mips/vr41xx/Kconfig
Message-Id: <20050712000108.6f7781d7.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8432
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 780
Lines: 23

Hi Ralf,

This patch has removed a obsolete config in arch/mips/vr41xx/Kconfig.
Please apply this patch.

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig
--- a-orig/arch/mips/vr41xx/Kconfig	2005-03-19 06:53:56.000000000 +0900
+++ a/arch/mips/vr41xx/Kconfig	2005-07-11 23:50:58.561618112 +0900
@@ -94,12 +94,6 @@
 	tristate "Add General-purpose I/O unit support of NEC VR4100 series"
 	depends on MACH_VR41XX
 
-config VRC4171
-	tristate "Add NEC VRC4171 companion chip support"
-	depends on MACH_VR41XX && ISA
-	help
-	  The NEC VRC4171/4171A is a companion chip for NEC VR4111/VR4121.
-
 config VRC4173
 	tristate "Add NEC VRC4173 companion chip support"
 	depends on MACH_VR41XX && PCI_VR41XX

From yuasa@hh.iij4u.or.jp Mon Jul 11 16:19:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:19:37 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:1486 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226453AbVGKPTT>;
	Mon, 11 Jul 2005 16:19:19 +0100
Received: MO(mo00)id j6BFKBPO018699; Tue, 12 Jul 2005 00:20:11 +0900 (JST)
Received: MDO(mdo00) id j6BFKB45022885; Tue, 12 Jul 2005 00:20:11 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j6BFKAl3016031
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 12 Jul 2005 00:20:10 +0900 (JST)
Date:	Tue, 12 Jul 2005 00:20:08 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove obsolete ksyms.c
Message-Id: <20050712002008.613323b7.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8433
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1801
Lines: 46

Hi Ralf,

This patch has removed a obsolete ksyms.c file for vr41xx.
Please apply this patch.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/ksyms.c a/arch/mips/vr41xx/common/ksyms.c
--- a-orig/arch/mips/vr41xx/common/ksyms.c	2005-01-15 10:31:06.000000000 +0900
+++ a/arch/mips/vr41xx/common/ksyms.c	1970-01-01 09:00:00.000000000 +0900
@@ -1,33 +0,0 @@
-/*
- *   ksyms.c, Export NEC VR4100 series specific functions needed for loadable modules.
- *
- *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org)
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#include <linux/module.h>
-
-#include <asm/vr41xx/vr41xx.h>
-
-EXPORT_SYMBOL(vr41xx_get_vtclock_frequency);
-EXPORT_SYMBOL(vr41xx_get_tclock_frequency);
-
-EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle);
-EXPORT_SYMBOL(vr41xx_read_rtclong1_counter);
-EXPORT_SYMBOL(vr41xx_set_rtclong2_cycle);
-EXPORT_SYMBOL(vr41xx_read_rtclong2_counter);
-EXPORT_SYMBOL(vr41xx_set_tclock_cycle);
-EXPORT_SYMBOL(vr41xx_read_tclock_counter);

From linux-mips@packetvision.com Mon Jul 11 16:42:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:42:33 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([IPv6:::ffff:212.104.129.139]:11484
	"EHLO mra04.ex.eclipse.net.uk") by linux-mips.org with ESMTP
	id <S8226467AbVGKPmQ>; Mon, 11 Jul 2005 16:42:16 +0100
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 9D9F9133E27
	for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 16:43:10 +0100 (BST)
Received: from mra04.ex.eclipse.net.uk ([127.0.0.1])
 by localhost (mra04.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 08014-01-98 for <linux-mips@linux-mips.org>;
 Mon, 11 Jul 2005 16:43:08 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 1F8A8133E7E
	for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 16:41:58 +0100 (BST)
Subject: Re: Benchmarking RM9000
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	linux-mips@linux-mips.org
In-Reply-To: <20050710231419.GA28518@linux-mips.org>
References: <20050708091711Z8226352-3678+1954@linux-mips.org>
	 <20050708120238.GA2816@linux-mips.org>
	 <1120825549.28569.949.camel@euskadi.packetvision>
	 <20050708130131.GC2816@linux-mips.org>
	 <1120833749.28569.965.camel@euskadi.packetvision>
	 <20050710231419.GA28518@linux-mips.org>
Content-Type: text/plain
Message-Id: <1121096632.28569.1107.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Mon, 11 Jul 2005 16:43:52 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
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: 8434
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: 6163
Lines: 123

Thanks for all the feedback.

I enclose new results from the lmbench testing.

Answering some suggestions,

I won't use gmplayer as a benchmarking tool. The platform has no
graphics adapter. We're developing a streaming video application in an
embedded platform (no hdd either).

I'll check that the driver is using the write-gather functionality to
move data from/to the ethernet adapter.

As before, I'd appreciate some other results from modern systems to
compare with.

Regards,
Alex

-------------------------------------------------


 
                 L M B E N C H  3 . 0   S U M M A R Y
                 ------------------------------------
                 (Alpha software, do not distribute)
 
Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
192.168.1 Linux 2.6.12-          mips-linux-gnu  985     4    32 1.4200    1
 
Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
192.168.1 Linux 2.6.12-  985 0.19 0.49 4.29 150. 25.4 0.65 3.76 828. 5032 16.K
 
Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr
                          bit   add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
192.168.1 Linux 2.6.12- 1.0200 1.0200 4.1500   43.5   41.5
 
Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 6.0700   22.3   41.7
 
Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 9.1100   37.4   62.0
 
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
192.168.1 Linux 2.6.12- 0.8400 5.6600 8.2600   22.6  235.2    58.9   242.3
 
*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
192.168.1 Linux 2.6.12- 0.840 6.775 13.4              38.0       143.
                                                                                                                                                       
File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
192.168.1 Linux 2.6.12-                              4926.0 0.622 2.59860  16.6
                                                                                                                                                       
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
192.168.1 Linux 2.6.12- 141. 292. 57.2  140.5  224.7   97.1   88.2 224. 155.4
                                                                                                                                                       
Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
192.168.1 Linux 2.6.12-   985 3.0750   45.4  109.5       254.9



On Mon, 2005-07-11 at 00:14, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our expectations.
> > We are still doing some profiling work on it, but we are also looking at
> > other possibilities.
> > 
> > What other benchmarking tool would you recommend?
> > 
> > Currently it's a NFS mounted system, but even if we could use a block
> > device the access speed wouldn't be more than 1.5 Mbps, so that is a
> > limitation for the benchmark.
> 
> As a shot into the dark ...
> 
> Make sure you exploit the RM9000's write-gathering capabilities when
> writing into the frame buffer.  If the frame buffer happens to be on
> a PCI device you're probably performing uncached writes which will
> slow down the thing to a crawl.
> 
>   Ralf



From ralf@linux-mips.org Mon Jul 11 16:44:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:45:11 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:36893 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226469AbVGKPos>; Mon, 11 Jul 2005 16:44:48 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BFjZAP006807;
	Mon, 11 Jul 2005 16:45:35 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BFjYSt006806;
	Mon, 11 Jul 2005 16:45:34 +0100
Date:	Mon, 11 Jul 2005 16:45:34 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove obsolete config in arch/mips/vr41xx/Kconfig
Message-ID: <20050711154534.GD2765@linux-mips.org>
References: <20050712000108.6f7781d7.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050712000108.6f7781d7.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8435
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 196
Lines: 8

On Tue, Jul 12, 2005 at 12:01:08AM +0900, Yoichi Yuasa wrote:

> This patch has removed a obsolete config in arch/mips/vr41xx/Kconfig.
> Please apply this patch.

Applied.  Thanks Yoichi,

  Ralf

From ralf@linux-mips.org Mon Jul 11 16:46:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:46:29 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:5386 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226469AbVGKPqM>; Mon, 11 Jul 2005 16:46:12 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BFkwgq006890;
	Mon, 11 Jul 2005 16:46:58 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BFkw2c006889;
	Mon, 11 Jul 2005 16:46:58 +0100
Date:	Mon, 11 Jul 2005 16:46:58 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove obsolete ksyms.c
Message-ID: <20050711154658.GE2765@linux-mips.org>
References: <20050712002008.613323b7.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050712002008.613323b7.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8436
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 206
Lines: 10

On Tue, Jul 12, 2005 at 12:20:08AM +0900, Yoichi Yuasa wrote:

> This patch has removed a obsolete ksyms.c file for vr41xx.
> Please apply this patch.

It's dead, Jim ;-)

Applied.  Thanks Yoichi,

   Ralf

From yuasa@hh.iij4u.or.jp Mon Jul 11 16:47:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:47:48 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:3327 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226453AbVGKPr1>;
	Mon, 11 Jul 2005 16:47:27 +0100
Received: MO(mo01)id j6BFmKKb007931; Tue, 12 Jul 2005 00:48:20 +0900 (JST)
Received: MDO(mdo00) id j6BFmJTf023427; Tue, 12 Jul 2005 00:48:19 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j6BFmIX8018581
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 12 Jul 2005 00:48:18 +0900 (JST)
Date:	Tue, 12 Jul 2005 00:48:16 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove obsolete rtc.c
Message-Id: <20050712004816.7b7fb347.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8437
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 8719
Lines: 331

Hi Ralf,

This patch has removed obsolete rtc.c file for vr41xx.
Please apply this patch.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/rtc.c a/arch/mips/vr41xx/common/rtc.c
--- a-orig/arch/mips/vr41xx/common/rtc.c	2005-06-21 22:56:32.000000000 +0900
+++ a/arch/mips/vr41xx/common/rtc.c	1970-01-01 09:00:00.000000000 +0900
@@ -1,317 +0,0 @@
-/*
- *  rtc.c, RTC(has only timer function) routines for NEC VR4100 series.
- *
- *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#include <linux/init.h>
-#include <linux/irq.h>
-#include <linux/smp.h>
-#include <linux/types.h>
-
-#include <asm/io.h>
-#include <asm/time.h>
-#include <asm/vr41xx/vr41xx.h>
-
-static uint32_t rtc1_base;
-static uint32_t rtc2_base;
-
-static uint64_t previous_elapsedtime;
-static unsigned int remainder_per_sec;
-static unsigned int cycles_per_sec;
-static unsigned int cycles_per_jiffy;
-static unsigned long epoch_time;
-
-#define CYCLES_PER_JIFFY	(CLOCK_TICK_RATE / HZ)
-#define REMAINDER_PER_SEC	(CLOCK_TICK_RATE - (CYCLES_PER_JIFFY * HZ))
-#define CYCLES_PER_100USEC	((CLOCK_TICK_RATE + (10000 / 2)) / 10000)
-
-#define ETIMELREG_TYPE1		KSEG1ADDR(0x0b0000c0)
-#define TCLKLREG_TYPE1		KSEG1ADDR(0x0b0001c0)
-
-#define ETIMELREG_TYPE2		KSEG1ADDR(0x0f000100)
-#define TCLKLREG_TYPE2		KSEG1ADDR(0x0f000120)
-
-/* RTC 1 registers */
-#define ETIMELREG		0x00
-#define ETIMEMREG		0x02
-#define ETIMEHREG		0x04
-/* RFU */
-#define ECMPLREG		0x08
-#define ECMPMREG		0x0a
-#define ECMPHREG		0x0c
-/* RFU */
-#define RTCL1LREG		0x10
-#define RTCL1HREG		0x12
-#define RTCL1CNTLREG		0x14
-#define RTCL1CNTHREG		0x16
-#define RTCL2LREG		0x18
-#define RTCL2HREG		0x1a
-#define RTCL2CNTLREG		0x1c
-#define RTCL2CNTHREG		0x1e
-
-/* RTC 2 registers */
-#define TCLKLREG		0x00
-#define TCLKHREG		0x02
-#define TCLKCNTLREG		0x04
-#define TCLKCNTHREG		0x06
-/* RFU */
-#define RTCINTREG		0x1e
- #define TCLOCK_INT		0x08
- #define RTCLONG2_INT		0x04
- #define RTCLONG1_INT		0x02
- #define ELAPSEDTIME_INT	0x01
-
-#define read_rtc1(offset)	readw(rtc1_base + (offset))
-#define write_rtc1(val, offset)	writew((val), rtc1_base + (offset))
-
-#define read_rtc2(offset)	readw(rtc2_base + (offset))
-#define write_rtc2(val, offset)	writew((val), rtc2_base + (offset))
-
-static inline uint64_t read_elapsedtime_counter(void)
-{
-	uint64_t first, second;
-	uint32_t first_mid, first_low;
-	uint32_t second_mid, second_low;
-
-	do {
-		first_low = (uint32_t)read_rtc1(ETIMELREG);
-		first_mid = (uint32_t)read_rtc1(ETIMEMREG);
-		first = (uint64_t)read_rtc1(ETIMEHREG);
-		second_low = (uint32_t)read_rtc1(ETIMELREG);
-		second_mid = (uint32_t)read_rtc1(ETIMEMREG);
-		second = (uint64_t)read_rtc1(ETIMEHREG);
-	} while (first_low != second_low || first_mid != second_mid ||
-	         first != second);
-
-	return (first << 32) | (uint64_t)((first_mid << 16) | first_low);
-}
-
-static inline void write_elapsedtime_counter(uint64_t time)
-{
-	write_rtc1((uint16_t)time, ETIMELREG);
-	write_rtc1((uint16_t)(time >> 16), ETIMEMREG);
-	write_rtc1((uint16_t)(time >> 32), ETIMEHREG);
-}
-
-static inline void write_elapsedtime_compare(uint64_t time)
-{
-	write_rtc1((uint16_t)time, ECMPLREG);
-	write_rtc1((uint16_t)(time >> 16), ECMPMREG);
-	write_rtc1((uint16_t)(time >> 32), ECMPHREG);
-}
-
-void vr41xx_set_rtclong1_cycle(uint32_t cycles)
-{
-	write_rtc1((uint16_t)cycles, RTCL1LREG);
-	write_rtc1((uint16_t)(cycles >> 16), RTCL1HREG);
-}
-
-uint32_t vr41xx_read_rtclong1_counter(void)
-{
-	uint32_t first_high, first_low;
-	uint32_t second_high, second_low;
-
-	do {
-		first_low = (uint32_t)read_rtc1(RTCL1CNTLREG);
-		first_high = (uint32_t)read_rtc1(RTCL1CNTHREG);
-		second_low = (uint32_t)read_rtc1(RTCL1CNTLREG);
-		second_high = (uint32_t)read_rtc1(RTCL1CNTHREG);
-	} while (first_low != second_low || first_high != second_high);
-
-	return (first_high << 16) | first_low;
-}
-
-void vr41xx_set_rtclong2_cycle(uint32_t cycles)
-{
-	write_rtc1((uint16_t)cycles, RTCL2LREG);
-	write_rtc1((uint16_t)(cycles >> 16), RTCL2HREG);
-}
-
-uint32_t vr41xx_read_rtclong2_counter(void)
-{
-	uint32_t first_high, first_low;
-	uint32_t second_high, second_low;
-
-	do {
-		first_low = (uint32_t)read_rtc1(RTCL2CNTLREG);
-		first_high = (uint32_t)read_rtc1(RTCL2CNTHREG);
-		second_low = (uint32_t)read_rtc1(RTCL2CNTLREG);
-		second_high = (uint32_t)read_rtc1(RTCL2CNTHREG);
-	} while (first_low != second_low || first_high != second_high);
-
-	return (first_high << 16) | first_low;
-}
-
-void vr41xx_set_tclock_cycle(uint32_t cycles)
-{
-	write_rtc2((uint16_t)cycles, TCLKLREG);
-	write_rtc2((uint16_t)(cycles >> 16), TCLKHREG);
-}
-
-uint32_t vr41xx_read_tclock_counter(void)
-{
-	uint32_t first_high, first_low;
-	uint32_t second_high, second_low;
-
-	do {
-		first_low = (uint32_t)read_rtc2(TCLKCNTLREG);
-		first_high = (uint32_t)read_rtc2(TCLKCNTHREG);
-		second_low = (uint32_t)read_rtc2(TCLKCNTLREG);
-		second_high = (uint32_t)read_rtc2(TCLKCNTHREG);
-	} while (first_low != second_low || first_high != second_high);
-
-	return (first_high << 16) | first_low;
-}
-
-static void vr41xx_timer_ack(void)
-{
-	uint64_t cur;
-
-	write_rtc2(ELAPSEDTIME_INT, RTCINTREG);
-
-	previous_elapsedtime += (uint64_t)cycles_per_jiffy;
-	cycles_per_sec += cycles_per_jiffy;
-
-	if (cycles_per_sec >= CLOCK_TICK_RATE) {
-		cycles_per_sec = 0;
-		remainder_per_sec = REMAINDER_PER_SEC;
-	}
-
-	cycles_per_jiffy = 0;
-
-	do {
-		cycles_per_jiffy += CYCLES_PER_JIFFY;
-		if (remainder_per_sec > 0) {
-			cycles_per_jiffy++;
-			remainder_per_sec--;
-		}
-
-		cur = read_elapsedtime_counter();
-	} while (cur >= previous_elapsedtime + (uint64_t)cycles_per_jiffy);
-
-	write_elapsedtime_compare(previous_elapsedtime + (uint64_t)cycles_per_jiffy);
-}
-
-static void vr41xx_hpt_init(unsigned int count)
-{
-}
-
-static unsigned int vr41xx_hpt_read(void)
-{
-	uint64_t cur;
-
-	cur = read_elapsedtime_counter();
-
-	return (unsigned int)cur;
-}
-
-static unsigned long vr41xx_gettimeoffset(void)
-{
-	uint64_t cur;
-	unsigned long gap;
-
-	cur = read_elapsedtime_counter();
-	gap = (unsigned long)(cur - previous_elapsedtime);
-	gap = gap / CYCLES_PER_100USEC * 100;	/* usec */
-
-	return gap;
-}
-
-static unsigned long vr41xx_get_time(void)
-{
-	uint64_t counts;
-
-	counts = read_elapsedtime_counter();
-	counts >>= 15;
-
-	return epoch_time + (unsigned long)counts;
-
-}
-
-static int vr41xx_set_time(unsigned long sec)
-{
-	if (sec < epoch_time)
-		return -EINVAL;
-
-	sec -= epoch_time;
-
-	write_elapsedtime_counter((uint64_t)sec << 15);
-
-	return 0;
-}
-
-void vr41xx_set_epoch_time(unsigned long time)
-{
-	epoch_time = time;
-}
-
-static void __init vr41xx_time_init(void)
-{
-	switch (current_cpu_data.cputype) {
-	case CPU_VR4111:
-	case CPU_VR4121:
-		rtc1_base = ETIMELREG_TYPE1;
-		rtc2_base = TCLKLREG_TYPE1;
-		break;
-	case CPU_VR4122:
-	case CPU_VR4131:
-	case CPU_VR4133:
-		rtc1_base = ETIMELREG_TYPE2;
-		rtc2_base = TCLKLREG_TYPE2;
-		break;
-	default:
-		panic("Unexpected CPU of NEC VR4100 series");
-		break;
-	}
-
-	mips_timer_ack = vr41xx_timer_ack;
-
-	mips_hpt_init = vr41xx_hpt_init;
-	mips_hpt_read = vr41xx_hpt_read;
-	mips_hpt_frequency = CLOCK_TICK_RATE;
-
-	if (epoch_time == 0)
-		epoch_time = mktime(1970, 1, 1, 0, 0, 0);
-
-	rtc_get_time = vr41xx_get_time;
-	rtc_set_time = vr41xx_set_time;
-}
-
-static void __init vr41xx_timer_setup(struct irqaction *irq)
-{
-	do_gettimeoffset = vr41xx_gettimeoffset;
-
-	remainder_per_sec = REMAINDER_PER_SEC;
-	cycles_per_jiffy = CYCLES_PER_JIFFY;
-
-	if (remainder_per_sec > 0) {
-		cycles_per_jiffy++;
-		remainder_per_sec--;
-	}
-
-	previous_elapsedtime = read_elapsedtime_counter();
-	write_elapsedtime_compare(previous_elapsedtime + (uint64_t)cycles_per_jiffy);
-	write_rtc2(ELAPSEDTIME_INT, RTCINTREG);
-
-	setup_irq(ELAPSEDTIME_IRQ, irq);
-}
-
-static void __init vr41xx_rtc_init(void)
-{
-	board_time_init = vr41xx_time_init;
-	board_timer_setup = vr41xx_timer_setup;
-}


From ralf@linux-mips.org Mon Jul 11 16:51:14 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:51:30 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:57093 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226473AbVGKPvO>; Mon, 11 Jul 2005 16:51:14 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BFq09N007097;
	Mon, 11 Jul 2005 16:52:00 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BFq093007096;
	Mon, 11 Jul 2005 16:52:00 +0100
Date:	Mon, 11 Jul 2005 16:52:00 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove obsolete rtc.c
Message-ID: <20050711155200.GF2765@linux-mips.org>
References: <20050712004816.7b7fb347.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050712004816.7b7fb347.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8438
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 222
Lines: 8

On Tue, Jul 12, 2005 at 12:48:16AM +0900, Yoichi Yuasa wrote:

> This patch has removed obsolete rtc.c file for vr41xx.
> Please apply this patch.

Sure.  Happy hour, get two patches applied for half the price ;-)

  Ralf

From yuasa@hh.iij4u.or.jp Mon Jul 11 16:53:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:53:25 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:22995 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226472AbVGKPxH>;
	Mon, 11 Jul 2005 16:53:07 +0100
Received: MO(mo00)id j6BFs1hZ022853; Tue, 12 Jul 2005 00:54:01 +0900 (JST)
Received: MDO(mdo00) id j6BFs0V7023492; Tue, 12 Jul 2005 00:54:00 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j6BFrxS4019061
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 12 Jul 2005 00:54:00 +0900 (JST)
Date:	Tue, 12 Jul 2005 00:53:57 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: add EXPORT_SYMBOL to irq.c
Message-Id: <20050712005357.32221bc7.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8439
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 756
Lines: 29

Hi Ralf,

This patch has added EXPORT_SYMBOL to irq.c.
Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/irq.c a/arch/mips/vr41xx/common/irq.c
--- a-orig/arch/mips/vr41xx/common/irq.c	2005-06-02 23:37:13.000000000 +0900
+++ a/arch/mips/vr41xx/common/irq.c	2005-07-12 00:49:23.597771624 +0900
@@ -18,6 +18,7 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 #include <linux/interrupt.h>
+#include <linux/module.h>
 
 #include <asm/irq_cpu.h>
 #include <asm/system.h>
@@ -56,6 +57,8 @@
 	return retval;
 }
 
+EXPORT_SYMBOL_GPL(cascade_irq);
+
 asmlinkage void irq_dispatch(unsigned int irq, struct pt_regs *regs)
 {
 	irq_cascade_t *cascade;

From yuasa@hh.iij4u.or.jp Mon Jul 11 16:56:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:56:34 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:13760 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226475AbVGKP4S>;
	Mon, 11 Jul 2005 16:56:18 +0100
Received: MO(mo01)id j6BFvBVj008924; Tue, 12 Jul 2005 00:57:11 +0900 (JST)
Received: MDO(mdo01) id j6BFvBVl023265; Tue, 12 Jul 2005 00:57:11 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j6BFvAUW019331
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Tue, 12 Jul 2005 00:57:10 +0900 (JST)
Date:	Tue, 12 Jul 2005 00:57:08 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCh 2.6] vr41xx: cleaning include in icu.c
Message-Id: <20050712005708.0f6a0eb3.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8440
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 727
Lines: 29

Hi Ralf,

This patch has cleaned includes in icu.c.
Please apply.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/icu.c a/arch/mips/vr41xx/common/icu.c
--- a-orig/arch/mips/vr41xx/common/icu.c	2005-06-02 23:33:02.000000000 +0900
+++ a/arch/mips/vr41xx/common/icu.c	2005-07-12 00:49:23.597771624 +0900
@@ -30,7 +30,6 @@
  */
 #include <linux/errno.h>
 #include <linux/init.h>
-#include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/irq.h>
 #include <linux/module.h>
@@ -39,8 +38,6 @@
 
 #include <asm/cpu.h>
 #include <asm/io.h>
-#include <asm/irq.h>
-#include <asm/irq_cpu.h>
 #include <asm/vr41xx/vr41xx.h>
 
 static void __iomem *icu1_base;

From ralf@linux-mips.org Mon Jul 11 16:56:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:57:25 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:1288 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226478AbVGKP4T>; Mon, 11 Jul 2005 16:56:19 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BFv6bH007314;
	Mon, 11 Jul 2005 16:57:06 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BFv6e7007313;
	Mon, 11 Jul 2005 16:57:06 +0100
Date:	Mon, 11 Jul 2005 16:57:06 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: add EXPORT_SYMBOL to irq.c
Message-ID: <20050711155706.GG2765@linux-mips.org>
References: <20050712005357.32221bc7.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050712005357.32221bc7.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8441
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 160
Lines: 8

On Tue, Jul 12, 2005 at 12:53:57AM +0900, Yoichi Yuasa wrote:

> This patch has added EXPORT_SYMBOL to irq.c.
> Please apply.

Applied,  Thanks Yoichi,

  Ralf

From ralf@linux-mips.org Mon Jul 11 16:58:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 16:58:47 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:3590 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226484AbVGKP6a>; Mon, 11 Jul 2005 16:58:30 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BFxGhj007428;
	Mon, 11 Jul 2005 16:59:16 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BFxGhE007427;
	Mon, 11 Jul 2005 16:59:16 +0100
Date:	Mon, 11 Jul 2005 16:59:16 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCh 2.6] vr41xx: cleaning include in icu.c
Message-ID: <20050711155916.GH2765@linux-mips.org>
References: <20050712005708.0f6a0eb3.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050712005708.0f6a0eb3.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8442
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 140
Lines: 7

On Tue, Jul 12, 2005 at 12:57:08AM +0900, Yoichi Yuasa wrote:

> This patch has cleaned includes in icu.c.

Applied, Thanks Yoichi,

  Ralf

From ralf@linux-mips.org Mon Jul 11 18:30:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 18:30:30 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:51976 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226487AbVGKRaP>; Mon, 11 Jul 2005 18:30:15 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BHV4pX010916;
	Mon, 11 Jul 2005 18:31:04 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BHV48C010915;
	Mon, 11 Jul 2005 18:31:04 +0100
Date:	Mon, 11 Jul 2005 18:31:04 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	linux-mips@linux-mips.org
Cc:	linux-cvs@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050711173104.GM2765@linux-mips.org>
References: <20050711170613Z8226486-3678+2546@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050711170613Z8226486-3678+2546@linux-mips.org>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8443
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 227
Lines: 11

On Mon, Jul 11, 2005 at 06:06:07PM +0100, macro@linux-mips.org wrote:

> Modified files:
> 	arch/mips/configs: decstation_defconfig 
> 
> Log message:
> 	Who needs module versions?

Generally considered a good idea ...

  Ralf

From macro@linux-mips.org Mon Jul 11 18:43:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 18:43:47 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:53772 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226487AbVGKRn1>; Mon, 11 Jul 2005 18:43:27 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1AD54E1C65; Mon, 11 Jul 2005 19:44:17 +0200 (CEST)
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 31636-10; Mon, 11 Jul 2005 19:44:16 +0200 (CEST)
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 CA9EEE1C64; Mon, 11 Jul 2005 19:44:16 +0200 (CEST)
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 j6BHiLnx030212;
	Mon, 11 Jul 2005 19:44:21 +0200
Date:	Mon, 11 Jul 2005 18:44:31 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050711173104.GM2765@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl>
References: <20050711170613Z8226486-3678+2546@linux-mips.org>
 <20050711173104.GM2765@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/976/Mon Jul 11 12:09:22 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8444
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: 383
Lines: 13

On Mon, 11 Jul 2005, Ralf Baechle wrote:

> > Log message:
> > 	Who needs module versions?
> 
> Generally considered a good idea ...

 Generally most useful for binary-only modules.  Do we have any for the 
DECstation?  If you update "vmlinux", you can also update modules.  Other 
platforms get away without versioning by default -- I see no reason to be 
different here.

  Maciej

From ralf@linux-mips.org Mon Jul 11 18:52:46 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 18:53:07 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:13580 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226487AbVGKRwq>; Mon, 11 Jul 2005 18:52:46 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6BHrbmb011727;
	Mon, 11 Jul 2005 18:53:37 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BHrbPo011726;
	Mon, 11 Jul 2005 18:53:37 +0100
Date:	Mon, 11 Jul 2005 18:53:37 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050711175337.GN2765@linux-mips.org>
References: <20050711170613Z8226486-3678+2546@linux-mips.org> <20050711173104.GM2765@linux-mips.org> <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8445
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 901
Lines: 21

On Mon, Jul 11, 2005 at 06:44:31PM +0100, Maciej W. Rozycki wrote:

> > Generally considered a good idea ...
> 
>  Generally most useful for binary-only modules.  Do we have any for the 
> DECstation?  If you update "vmlinux", you can also update modules.  Other 
> platforms get away without versioning by default -- I see no reason to be 
> different here.

If there's a mistake that people can do they will rarely miss that
opportunity.  Desperate users tend to move modules from their
distribution into a kernel built from CVS or change kernel config options
and somehow manage to keep a few modules built with the old options etc.
It's no fun receiving bug reports only to later figure out it was just
a silly pilot error, so for anything that's going to the net I really
keep that option on.

Of course I'd disable it for a closed appliance nor do I keep it turned
on for my own builds.

  Ralf

From macro@linux-mips.org Mon Jul 11 19:04:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 19:04:51 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:40455 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226500AbVGKSEe>; Mon, 11 Jul 2005 19:04:34 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 8DCBDF5A4C; Mon, 11 Jul 2005 20:05:22 +0200 (CEST)
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 04504-05; Mon, 11 Jul 2005 20:05:22 +0200 (CEST)
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 D696CF59A1; Mon, 11 Jul 2005 20:05:21 +0200 (CEST)
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 j6BI5QY2031323;
	Mon, 11 Jul 2005 20:05:26 +0200
Date:	Mon, 11 Jul 2005 19:05:36 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050711175337.GN2765@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507111903270.22410@blysk.ds.pg.gda.pl>
References: <20050711170613Z8226486-3678+2546@linux-mips.org>
 <20050711173104.GM2765@linux-mips.org> <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl>
 <20050711175337.GN2765@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/976/Mon Jul 11 12:09:22 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8446
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: 723
Lines: 22

On Mon, 11 Jul 2005, Ralf Baechle wrote:

> If there's a mistake that people can do they will rarely miss that
> opportunity.  Desperate users tend to move modules from their
> distribution into a kernel built from CVS or change kernel config options
> and somehow manage to keep a few modules built with the old options etc.

 Hmm...

> It's no fun receiving bug reports only to later figure out it was just
> a silly pilot error, so for anything that's going to the net I really
> keep that option on.

 Well, I receive virtually zero bug reports for the DECstation.  The code 
must be perfect. ;-)

> Of course I'd disable it for a closed appliance nor do I keep it turned
> on for my own builds.

 We'll see.

  Maciej

From Kise53@taiwan.com Mon Jul 11 19:35:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 19:35:44 +0100 (BST)
Received: from pa150.siedlce.sdi.tpnet.pl ([IPv6:::ffff:213.25.251.150]:60933
	"HELO pa150.siedlce.sdi.tpnet.pl") by linux-mips.org with SMTP
	id <S8226486AbVGKSf2>; Mon, 11 Jul 2005 19:35:28 +0100
Message-ID: <d8c201c58645$cf2aa10b$d9cc5ea3@taiwan.com>
From:	William goetz <Kise53@taiwan.com>
To:	linux-mips@linux-mips.org
Subject: RE: Open position available
Date:	Mon, 11 Jul 2005 18:23:58 +0000
MIME-Version: 1.0
Content-Type: text/plain;
    format=flowed;
    charset="iso-8859-1";
    reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express V6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Return-Path: <Kise53@taiwan.com>
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: 8447
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: Kise53@taiwan.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1102
Lines: 17

Would you like to get rich working part-time from home? Do you want to get extra income?
Want to have extra income so that you could get out of debt?
No special skills required! No fees to start! We will train you.
Your personal coach will explain you how to put the internet and your computer to work for you.
Flexible Work Hours. Work whenever and wherever you want.
You can start part time until you're ready to go full-time or start full time right away.
Our company is designed to take advantage of the exploding internet technology market.
We provide continuous support from the team of successful people.
Keep in mind that there are no fees or packages to buy to join our firm.
Work Smarter, Not Harder! You CAN make a difference in your financial future!
We will need 10 - 15 hours per week commitment. No fee to join our company!
Our extensive training and support is what makes this position so easy to run for you.

APPLY NOW to get more information about this exciting opportunity.
To continue with the application please fill out the form at:

http://www.globaltransfer.org/vacancies.html

From rolfliu@gmail.com Mon Jul 11 19:57:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 19:57:20 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.193]:57604 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226534AbVGKS5E> convert rfc822-to-8bit;
	Mon, 11 Jul 2005 19:57:04 +0100
Received: by wproxy.gmail.com with SMTP id i32so892442wra
        for <linux-mips@linux-mips.org>; Mon, 11 Jul 2005 11:57:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=OUdwODkjc9h5bqgSiXb+ctoYn4OEWDRcWetokhuqnboft00qOarlKHf4yxZTL0zLg5V6g4ukyfP/ggnCgAM83gRkfYXzIecizKl2KwDCUY074cqNCRppv9OHJHSCEFptnUe6TwtRY6334hIsSd6btN7JyNanCY+dfN98MABkx/w=
Received: by 10.54.26.9 with SMTP id 9mr4254840wrz;
        Mon, 11 Jul 2005 11:57:31 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Mon, 11 Jul 2005 11:57:31 -0700 (PDT)
Message-ID: <2db32b7205071111574ed8c4da@mail.gmail.com>
Date:	Mon, 11 Jul 2005 11:57:31 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: Help needed on db1550 for pcmcia support
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8448
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 539
Lines: 16

I compiled linux 2.6.12-mipscvs with the pcmcia support and got the three files:

pcmcia_core.ko, pcmcia.ko, and au1x00_ss.ko.

I use "insmod pcmcia_core.ko; insmod pcmcia.ko; insmod au1x00_ss.ko"
to install the three modules.

Because I want to use the Compact Flash through the PCMCIA, I compiled
ide_cs.ko and use "insmod ide_cs.ko" to install it.

When I type "lspci -v", there is no information about the pcmcia.
Also, cardctl showed "open_sock(): no such device".

I googled around the wedsite, got no luck for this problem.

thanks

From ths@networkno.de Mon Jul 11 20:24:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Jul 2005 20:25:07 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:50607 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226554AbVGKTYu>;
	Mon, 11 Jul 2005 20:24:50 +0100
Received: from port-195-158-170-192.dynamic.qsc.de ([195.158.170.192] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1Ds3uO-0007UB-00
	for linux-mips@linux-mips.org; Mon, 11 Jul 2005 21:25:40 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1Ds3uO-0004yZ-AT
	for linux-mips@linux-mips.org; Mon, 11 Jul 2005 21:25:40 +0200
Date:	Mon, 11 Jul 2005 21:25:40 +0200
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050711192540.GN1586@hattusa.textio>
References: <20050711170613Z8226486-3678+2546@linux-mips.org> <20050711173104.GM2765@linux-mips.org> <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl> <20050711175337.GN2765@linux-mips.org> <Pine.LNX.4.61L.0507111903270.22410@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507111903270.22410@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8449
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 733
Lines: 21

Maciej W. Rozycki wrote:
> On Mon, 11 Jul 2005, Ralf Baechle wrote:
> 
> > If there's a mistake that people can do they will rarely miss that
> > opportunity.  Desperate users tend to move modules from their
> > distribution into a kernel built from CVS or change kernel config options
> > and somehow manage to keep a few modules built with the old options etc.
> 
>  Hmm...
> 
> > It's no fun receiving bug reports only to later figure out it was just
> > a silly pilot error, so for anything that's going to the net I really
> > keep that option on.
> 
>  Well, I receive virtually zero bug reports for the DECstation.  The code 
> must be perfect. ;-)

I hope to change that with a 2.6 DECstation kernel for Debian. :-)


Thiemo

From ralf@linux-mips.org Tue Jul 12 08:12:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 08:12:33 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:22283 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226517AbVGLHMM>; Tue, 12 Jul 2005 08:12:12 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6C7D7mR002013;
	Tue, 12 Jul 2005 08:13:07 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BMRtdB002980;
	Mon, 11 Jul 2005 23:27:55 +0100
Date:	Mon, 11 Jul 2005 23:27:55 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: Current SGI Octane status
Message-ID: <20050711222755.GA2952@linux-mips.org>
References: <20050709093403.GB1586@hattusa.textio> <Pine.GSO.4.10.10507091833390.24862-100000@helios.et.put.poznan.pl> <20050709212029.GG1586@hattusa.textio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050709212029.GG1586@hattusa.textio>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8450
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 587
Lines: 17

On Sat, Jul 09, 2005 at 11:20:29PM +0200, Thiemo Seufer wrote:

> Stanislaw Skowronek wrote:
> > > - IOC3 networking works, with 2MB/s maximum for a 30MB http transfer
> > 
> > This is strange. Ask Ralf.
> 
> Up to 2.5 Mb actually. Still well below wat it should be.

I suspect it may be related to the RRB allocation.  The driver used to be
even slower until I made it use a second RRB by using the BRIDGE virtual
device feature.

Obviously all the funky RRB stuff of the BRIDGE has no public documentation.
However the SN1 / SN2 bits in the kernel tree should be rather close.

  Ralf

From ralf@linux-mips.org Tue Jul 12 08:12:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 08:13:27 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:24586 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226519AbVGLHMP>; Tue, 12 Jul 2005 08:12:15 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6C7D7mT002013;
	Tue, 12 Jul 2005 08:13:08 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6BMZC2e003003;
	Mon, 11 Jul 2005 23:35:12 +0100
Date:	Mon, 11 Jul 2005 23:35:12 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
Message-ID: <20050711223512.GA2808@linux-mips.org>
References: <20050711135718.GU2765@linux-mips.org> <Pine.GSO.4.10.10507111605570.23550-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10507111605570.23550-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8451
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1058
Lines: 24

On Mon, Jul 11, 2005 at 04:08:00PM +0200, Stanislaw Skowronek wrote:

> > Of course there's a NIC.  The driver has no special handling for IP27 and
> > is capable of reading the NICs on some machines at least.  That would be
> > a rather suprising ability if there was no NIC associated with that IOC3 ;-)
> 
> There is only a MAC NIC on a machine ths has. Remember that the Octane
> does not have the BaseIO NIC at the IOC3; both NICs placed there are
> actually hacks because of XBOW MicroLAN bug.

I was speaking of IP27, obviously.

> > > This is weird. This means the keyboard will not be operational, and I wish
> > > somebody (Ralf) looks into this. The IOC3 on IP27 BaseIO is a dual-slot
> > > device (takes two IRQs, the INTA and INTA+2).
> > All information that I have says only INTA is being used for IP27.  It
> > will probably take a bit of testing.
> 
> Yeah, change the interrupt assignments in ioc3.c, plug in a keyboard and
> try. If it works, everybody wins :)

I could do - but the plane ticket to plug the keyboard is on you ;-)

  Ralf

From sskowron@ET.PUT.Poznan.PL Tue Jul 12 08:19:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 08:20:00 +0100 (BST)
Received: from corvus.et.put.poznan.pl ([IPv6:::ffff:150.254.11.9]:6786 "EHLO
	corvus.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226519AbVGLHTp>; Tue, 12 Jul 2005 08:19:45 +0100
Received: from corvus (corvus.et.put.poznan.pl [150.254.11.9])
	by corvus.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6C7KgS22181;
	Tue, 12 Jul 2005 09:20:42 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by corvus.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 12 Jul 2005 09:20:41 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6C7Kep28186;
	Tue, 12 Jul 2005 09:20:40 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 12 Jul 2005 09:20:39 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Ralf Baechle <ralf@linux-mips.org>
cc:	linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
In-Reply-To: <20050711223512.GA2808@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10507120918170.27888-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8452
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 237
Lines: 11

> I was speaking of IP27, obviously.

I was explaining that not every IOC3 will have a Serial# NIC :)

> I could do - but the plane ticket to plug the keyboard is on you ;-)

I'm going to visit Bayern this month anyway :)))

Stanislaw



From sskowron@ET.PUT.Poznan.PL Tue Jul 12 08:20:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 08:20:49 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:42193
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226526AbVGLHUX>; Tue, 12 Jul 2005 08:20:23 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6C7LMT00076;
	Tue, 12 Jul 2005 09:21:22 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 12 Jul 2005 09:21:21 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6C7LLI28287;
	Tue, 12 Jul 2005 09:21:21 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 12 Jul 2005 09:21:21 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	Ralf Baechle <ralf@linux-mips.org>
cc:	Thiemo Seufer <ths@networkno.de>, linux-mips@linux-mips.org
Subject: Re: Current SGI Octane status
In-Reply-To: <20050711222755.GA2952@linux-mips.org>
Message-ID: <Pine.GSO.4.10.10507120920560.27888-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8453
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 427
Lines: 14

> I suspect it may be related to the RRB allocation.  The driver used to be
> even slower until I made it use a second RRB by using the BRIDGE virtual
> device feature.

I can work on this.

> Obviously all the funky RRB stuff of the BRIDGE has no public documentation.
> However the SN1 / SN2 bits in the kernel tree should be rather close.

If you believe that public documentation is important, think again :))

Stanislaw



From ralf@linux-mips.org Tue Jul 12 08:22:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 08:22:20 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:55583 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226537AbVGLHWC>; Tue, 12 Jul 2005 08:22:02 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6C7Mu93003966;
	Tue, 12 Jul 2005 08:22:56 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6C7MuPs003965;
	Tue, 12 Jul 2005 08:22:56 +0100
Date:	Tue, 12 Jul 2005 08:22:56 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc:	linux-mips@linux-mips.org
Subject: Re: Origin 200 Status
Message-ID: <20050712072255.GA3350@linux-mips.org>
References: <20050711223512.GA2808@linux-mips.org> <Pine.GSO.4.10.10507120918170.27888-100000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10507120918170.27888-100000@helios.et.put.poznan.pl>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8454
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 379
Lines: 15

On Tue, Jul 12, 2005 at 09:20:39AM +0200, Stanislaw Skowronek wrote:

> > I was speaking of IP27, obviously.
> 
> I was explaining that not every IOC3 will have a Serial# NIC :)

Well, in a paragraph mentioning IP27 ...

> > I could do - but the plane ticket to plug the keyboard is on you ;-)
> 
> I'm going to visit Bayern this month anyway :)))

Wrong airport then :)

  Ralf

From anemo@mba.ocn.ne.jp Tue Jul 12 09:27:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 09:28:07 +0100 (BST)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:64285
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8226402AbVGLI1u>; Tue, 12 Jul 2005 09:27:50 +0100
Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 12 Jul 2005 08:28:49 UT
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1])
	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 3E3181F489;
	Tue, 12 Jul 2005 17:28:43 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 28CA71F487;
	Tue, 12 Jul 2005 17:28:43 +0900 (JST)
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id j6C8Sgoj068449;
	Tue, 12 Jul 2005 17:28:42 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date:	Tue, 12 Jul 2005 17:28:42 +0900 (JST)
Message-Id: <20050712.172842.79300034.nemoto@toshiba-tops.co.jp>
To:	ralf@linux-mips.org
Cc:	djohnson+linuxmips@sw.starentnetworks.com,
	linux-mips@linux-mips.org
Subject: Re: preempt_schedule_irq missing from mfinfo[]?
From:	Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20050706090138.GC3226@linux-mips.org>
References: <20050705200308.GE18772@linux-mips.org>
	<20050706.122912.71087098.nemoto@toshiba-tops.co.jp>
	<20050706090138.GC3226@linux-mips.org>
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.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 8455
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: 875
Lines: 25

>>>>> On Wed, 6 Jul 2005 10:01:38 +0100, Ralf Baechle <ralf@linux-mips.org> said:
>> You can find the caller of "schedule()" even with simple
>> thread_saved_pc().  I think it is enough so I do not think it is
>> worth to fix (and maintain) current minfo[].

ralf> The alternative would be to finally bite the bullet and add a
ralf> wchan field to thread_struct and initialize it in all the
ralf> sleeping functions.

ralf> The IA-64 people have something like a DWARF-based frame
ralf> unwinder but that just seems to heavy.

Another alternative would be:

1.  Using KALLSYMS feature in kernel to obtain an address in
__sched/__lock function.  This might solve static function (and
maintainance) issue.

2.  Unwinding stack based on "addiu sp,sp,-NN" instruction in prologue
of the function.  This might solve omit-frame-pointer issue.

Anybody try? :-)

---
Atsushi Nemoto

From geert@linux-m68k.org Tue Jul 12 09:39:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 09:39:42 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:5251 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226402AbVGLIj1>;
	Tue, 12 Jul 2005 09:39:27 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j6C8eKpr028539;
	Tue, 12 Jul 2005 10:40:20 +0200 (MEST)
Date:	Tue, 12 Jul 2005 10:40:16 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Ralf Baechle <ralf@linux-mips.org>
cc:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Origin 200 Status
In-Reply-To: <20050712072255.GA3350@linux-mips.org>
Message-ID: <Pine.LNX.4.62.0507121039340.4187@numbat.sonytel.be>
References: <20050711223512.GA2808@linux-mips.org>
 <Pine.GSO.4.10.10507120918170.27888-100000@helios.et.put.poznan.pl>
 <20050712072255.GA3350@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8456
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 842
Lines: 27

On Tue, 12 Jul 2005, Ralf Baechle wrote:
> On Tue, Jul 12, 2005 at 09:20:39AM +0200, Stanislaw Skowronek wrote:
> > > I was speaking of IP27, obviously.
> > 
> > I was explaining that not every IOC3 will have a Serial# NIC :)
> 
> Well, in a paragraph mentioning IP27 ...
> 
> > > I could do - but the plane ticket to plug the keyboard is on you ;-)
> > 
> > I'm going to visit Bayern this month anyway :)))
> 
> Wrong airport then :)

You misunderstood: he's going to pick you up in his private jet, to fly to your
keyboard connector...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From linux@cantastic.de Tue Jul 12 10:40:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 10:41:14 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.187]:56257
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226433AbVGLJk7>; Tue, 12 Jul 2005 10:40:59 +0100
Received: from p54A2AB5C.dip0.t-ipconnect.de [84.162.171.92] (helo=[192.168.178.44])
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0ML25U-1DsHH0140Y-0005o4; Tue, 12 Jul 2005 11:41:54 +0200
Message-ID: <42D39096.7010500@cantastic.de>
Date:	Tue, 12 Jul 2005 11:42:46 +0200
From:	=?ISO-8859-15?Q?Ralf_R=F6sch?= <linux@cantastic.de>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To:	Alex Gonzalez <linux-mips@packetvision.com>
CC:	linux-mips@linux-mips.org
Subject: Re: Benchmarking RM9000
References: <20050708091711Z8226352-3678+1954@linux-mips.org>	 <20050708120238.GA2816@linux-mips.org>	 <1120825549.28569.949.camel@euskadi.packetvision>	 <20050708130131.GC2816@linux-mips.org>	 <1120833749.28569.965.camel@euskadi.packetvision>	 <20050710231419.GA28518@linux-mips.org> <1121096632.28569.1107.camel@euskadi.packetvision>
In-Reply-To: <1121096632.28569.1107.camel@euskadi.packetvision>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:fe0074b40cafaf3a4e4a4699a3836908
Return-Path: <linux@cantastic.de>
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: 8457
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@cantastic.de
Precedence: bulk
X-list: linux-mips
Content-Length: 4943
Lines: 95


>As before, I'd appreciate some other results from modern systems to
>compare with.
>
>  
>
Alex, below you can find our LMBENCH 3.0-a4 test results. 
Our machine is a Toshiba TX4937 based system (in the hope "modern enough") running with 
333MHz CPU-Clock and 133 MHz SDRAM-Clock (64bit).
The bench was run on the Debian based mipsel-distribution.
I'm surprised about the big difference in test results compared to your RM9000 system.
I would expect that your system should be much faster and I think there must be
a blocking part (hardware, software)  in your system. 

Regards
  Ralf (Roesch)

                 L M B E N C H  3 . 0   S U M M A R Y

                 ------------------------------------

         (Alpha software, do not distribute)

Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes  
--------- ------------- ----------------------- ---- ----- ----- ------ ----
debian-mi  Linux 2.6.12        mipsel-linux-gnu  326     4    32 1.0700    1

Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
debian-mi  Linux 2.6.12  326 0.41 1.22 8.37 9.96 78.1 1.85 7.77 1437 8018 36.K

Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr  
                          bit   add    mul    div    mod   
--------- ------------- ------ ------ ------ ------ ------ 
debian-mi  Linux 2.6.12 3.0600 0.0500   18.3  122.4  124.8

Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------ 
debian-mi  Linux 2.6.12   15.6   15.1   64.9  126.7

Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------ 
debian-mi  Linux 2.6.12   24.7   24.2  106.5  217.8

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
debian-mi  Linux 2.6.12 1.1100   29.8   28.4   71.2   18.6    70.2    24.5

*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
debian-mi  Linux 2.6.12 1.110  16.4 35.3  73.8 205.7 146.8 313.1 560.

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
debian-mi  Linux 2.6.12  252.1  349.2  753.6  536.2   69.0K 1.830 5.18150  44.3

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
debian-mi  Linux 2.6.12 41.0 42.0 36.5   55.7  166.1   89.8   89.0 166. 153.4

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
debian-mi  Linux 2.6.12   326 6.3470  125.0  127.1       302.4    No L2 cache?



From macro@linux-mips.org Tue Jul 12 12:15:34 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 12:15:50 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:54801 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226468AbVGLLPe>; Tue, 12 Jul 2005 12:15:34 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id EBEC5E1C87; Tue, 12 Jul 2005 13:16:30 +0200 (CEST)
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 02865-10; Tue, 12 Jul 2005 13:16:30 +0200 (CEST)
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 A9DFEE1C80; Tue, 12 Jul 2005 13:16:30 +0200 (CEST)
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 j6CBGVGt005551;
	Tue, 12 Jul 2005 13:16:32 +0200
Date:	Tue, 12 Jul 2005 12:16:38 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Thiemo Seufer <ths@networkno.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050711192540.GN1586@hattusa.textio>
Message-ID: <Pine.LNX.4.61L.0507121212480.14155@blysk.ds.pg.gda.pl>
References: <20050711170613Z8226486-3678+2546@linux-mips.org>
 <20050711173104.GM2765@linux-mips.org> <Pine.LNX.4.61L.0507111840580.22410@blysk.ds.pg.gda.pl>
 <20050711175337.GN2765@linux-mips.org> <Pine.LNX.4.61L.0507111903270.22410@blysk.ds.pg.gda.pl>
 <20050711192540.GN1586@hattusa.textio>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8458
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: 322
Lines: 11

On Mon, 11 Jul 2005, Thiemo Seufer wrote:

> >  Well, I receive virtually zero bug reports for the DECstation.  The code 
> > must be perfect. ;-)
> 
> I hope to change that with a 2.6 DECstation kernel for Debian. :-)

 Oh, no, no, no...  I definitely object you making the code imperfect.  
Over my dead body!

  Maciej

From sskowron@ET.PUT.Poznan.PL Tue Jul 12 15:05:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 15:05:52 +0100 (BST)
Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:44188
	"EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8226468AbVGLOF3>; Tue, 12 Jul 2005 15:05:29 +0100
Received: from athena (athena.et.put.poznan.pl [150.254.29.137])
	by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6CE6TT29354
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 16:06:29 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by athena.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 12 Jul 2005 16:06:29 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id j6CE6Sg09506
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 16:06:28 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date:	Tue, 12 Jul 2005 16:06:28 +0200 (MET DST)
From:	Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To:	linux-mips@linux-mips.org
Subject: Looking for a MIPS64 device
Message-ID: <Pine.GSO.4.10.10507121559350.8704-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.PL>
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: 8459
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: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips
Content-Length: 858
Lines: 23

%hi16(all),

I'm looking for a MIPS64 device with FPU, and 40-bit physical address
space. I need I/O coherency (this is important!). I'd be glad if the
performance was good, but I'm not really bent on it.

This is for a research project in reconfigurable computing. I'd prefer
MIPS devices because they are elegant (the other choice is probably either
PowerPC or x86_64, which is really scary) and power-efficient. The project
is partially supported by Xilinx Inc.

I tried contacting Broadcom, when the project was conducted at the Poznan
University of Technology (my employer), however no contact was established
(not even a "go away, you're ugly"). Same went for PMC-Sierra.

Do you know of any MIPS64 device with FPU (and MMU, but it goes without
saying) that can be purchased in small quantities for a project like this?

Cheers,

Stanislaw Skowronek



From giometti@enneenne.com Tue Jul 12 15:21:02 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 15:21:18 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:31360 "EHLO
	gundam.enneenne.com") by linux-mips.org with ESMTP
	id <S8226489AbVGLOVC>; Tue, 12 Jul 2005 15:21:02 +0100
Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DsLe7-000465-00
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 16:22:03 +0200
Date:	Tue, 12 Jul 2005 16:22:02 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips@linux-mips.org
Subject: power management status for au1100
Message-ID: <20050712142202.GB9234@gundam.enneenne.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <giometti@enneenne.com>
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: 8460
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 588
Lines: 19

Hello,

I'm just looking at linux support for power management on au1100 CPU
and I found that there are a lot of problems on enabling it... it
seems that current support cames from 2.4 series.

Is anybody dealing with it? I'd like to cooperate in order to have a
functional support.

Thanks in advance,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

From macro@linux-mips.org Tue Jul 12 16:29:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 16:29:25 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:39948 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226642AbVGLP3J>; Tue, 12 Jul 2005 16:29:09 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 9307BE1C85
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 17:30:05 +0200 (CEST)
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 31920-05 for <linux-mips@linux-mips.org>;
 Tue, 12 Jul 2005 17:30:05 +0200 (CEST)
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 F0BFDE1C84
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 17:30:04 +0200 (CEST)
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 j6CFU7x1015406
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 17:30:07 +0200
Date:	Tue, 12 Jul 2005 16:30:17 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050712145438Z8226641-3678+2759@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507121626370.14155@blysk.ds.pg.gda.pl>
References: <20050712145438Z8226641-3678+2759@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8461
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: 513
Lines: 19

On Tue, 12 Jul 2005 ralf@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: interrupt.h 
> 
> Log message:
> 	Use ei / di MIPS32 R2 instructions if available.

 Are you sure you don't want something like:

	andi	$1, \\flags, 1
	beqz    $1, 1f                                     
	 di                                                     
	ei                                                      
1:                                                             

instead for local_irq_restore?

  Maciej

From fthain@telegraphics.com.au Tue Jul 12 16:30:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 16:30:51 +0100 (BST)
Received: from loopy.telegraphics.com.au ([IPv6:::ffff:202.45.126.152]:48027
	"EHLO loopy.telegraphics.com.au") by linux-mips.org with ESMTP
	id <S8226648AbVGLPad>; Tue, 12 Jul 2005 16:30:33 +0100
Received: by loopy.telegraphics.com.au (Postfix, from userid 1001)
	id A392972E95; Wed, 13 Jul 2005 01:31:25 +1000 (EST)
Received: from localhost (localhost [127.0.0.1])
	by loopy.telegraphics.com.au (Postfix) with ESMTP id 9D1E22AA01;
	Wed, 13 Jul 2005 01:31:25 +1000 (EST)
Date:	Wed, 13 Jul 2005 01:31:25 +1000 (EST)
From:	Finn Thain <fthain@telegraphics.com.au>
To:	Jeff Garzik <jgarzik@pobox.com>
Cc:	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Ralf Baechle <ralf@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/m68k <linux-m68k@vger.kernel.org>,
	Linux/m68k on Mac <linux-mac68k@mac.linux-m68k.org>,
	Linux MIPS <linux-mips@linux-mips.org>,
	Linux net <linux-net@vger.kernel.org>
Subject: Re: [PATCH] macsonic/jazzsonic drivers update (part 2)
In-Reply-To: <42BEEC32.7040807@pobox.com>
Message-ID: <Pine.LNX.4.61.0507130122220.4355@loopy.telegraphics.com.au>
References: <200503070210.j272ARii023023@hera.kernel.org>
 <Pine.LNX.4.62.0503221807160.20753@numbat.sonytel.be> <20050323100139.GB8813@linux-mips.org>
 <Pine.LNX.4.61.0506121454410.1470@loopy.telegraphics.com.au>
 <20050615114158.GA9411@linux-mips.org> <Pine.LNX.4.61.0506152220460.22046@loopy.telegraphics.com.au>
 <20050615142717.GD9411@linux-mips.org> <Pine.LNX.4.61.0506160218310.24328@loopy.telegraphics.com.au>
 <Pine.LNX.4.61.0506160336410.24908@loopy.telegraphics.com.au>
 <20050616092257.GE5202@linux-mips.org> <Pine.LNX.4.61.0506162129450.31164@loopy.telegraphics.com.au>
 <Pine.LNX.4.61.0506270227510.1015@loopy.telegraphics.com.au>
 <42BEEC32.7040807@pobox.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <fthain@telegraphics.com.au>
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: 8462
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: fthain@telegraphics.com.au
Precedence: bulk
X-list: linux-mips
Content-Length: 6945
Lines: 210



On Sun, 26 Jun 2005, Jeff Garzik wrote:

> Patch looks OK to me.  Comments:
> 
> 1) Either Geert or Ralf can merge this, with my ACK.
> 
> 2) Would be nice to get it tested on the machines you list as untested.
> 
> 3) [possible problem in driver, not your changes] I wonder if IRQ_HANDLED is
> ever returned for shared interrupts?  I don't know enough about the platform
> interrupt architecture to answer this question.
> 
> 4) Remove casts to/from void.  This is especially noticable in all the casts
> of the netdev_priv() return value.
>
> 5) If it doesn't cause too much patch noise, consider using enums rather than
> #defines, for numeric constants.  This gives the compiler more type
> information and makes the symbols visible in a debugger.  This is a
> -maintainer preference- issue overall, so don't sweat it if you disagree.


This patch removes the unecessary void* casts introduced in the first patch.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>


--- a/drivers/net/jazzsonic.c	Sun Jul 10 22:11:40 2005
+++ linux/drivers/net/jazzsonic.c	Sun Jul 10 22:22:39 2005
@@ -93,7 +93,7 @@
 	static unsigned version_printed;
 	unsigned int silicon_revision;
 	unsigned int val;
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int err = -ENODEV;
 	int i;
 
@@ -145,7 +145,7 @@
 
 	/* Allocate the entire chunk of memory for the descriptors.
            Note that this cannot cross a 64K boundary. */
-	if ((lp->descriptors = (void *) dma_alloc_coherent(lp->device,
+	if ((lp->descriptors = dma_alloc_coherent(lp->device,
 				SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode),
 				&lp->descriptors_laddr, GFP_KERNEL)) == NULL) {
 		printk(KERN_ERR "%s: couldn't alloc DMA memory for descriptors.\n", lp->device->bus_id);
@@ -211,7 +211,7 @@
 	if (!dev)
 		return -ENOMEM;
 
-	lp = (struct sonic_local *) netdev_priv(dev);
+	lp = netdev_priv(dev);
 	lp->device = device;
 	SET_NETDEV_DEV(dev, device);
  	SET_MODULE_OWNER(dev);
@@ -267,7 +267,7 @@
 static int __devexit jazz_sonic_device_remove (struct device *device)
 {
 	struct net_device *dev = device->driver_data;
-	struct sonic_local* lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local* lp = netdev_priv(dev);
 
 	unregister_netdev (dev);
 	dma_free_coherent(lp->device, SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode),
--- a/drivers/net/macsonic.c	Sun Jul 10 22:11:40 2005
+++ linux/drivers/net/macsonic.c	Sun Jul 10 22:23:06 2005
@@ -135,11 +135,11 @@
 
 int __init macsonic_init(struct net_device* dev)
 {
-	struct sonic_local* lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local* lp = netdev_priv(dev);
 
 	/* Allocate the entire chunk of memory for the descriptors.
            Note that this cannot cross a 64K boundary. */
-	if ((lp->descriptors = (void *) dma_alloc_coherent(lp->device,
+	if ((lp->descriptors = dma_alloc_coherent(lp->device,
 	            SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode),
 	            &lp->descriptors_laddr, GFP_KERNEL)) == NULL) {
 		printk(KERN_ERR "%s: couldn't alloc DMA memory for descriptors.\n", lp->device->bus_id);
@@ -183,7 +183,7 @@
 
 int __init mac_onboard_sonic_ethernet_addr(struct net_device* dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	const int prom_addr = ONBOARD_SONIC_PROM_BASE;
 	int i;
 
@@ -255,7 +255,7 @@
 {
 	/* Bwahahaha */
 	static int once_is_more_than_enough;
-	struct sonic_local* lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local* lp = netdev_priv(dev);
 	int sr;
 	int commslot = 0;
 	
@@ -416,7 +416,7 @@
 {
 	static int slots;
 	struct nubus_dev* ndev = NULL;
-	struct sonic_local* lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local* lp = netdev_priv(dev);
 	unsigned long base_addr, prom_addr;
 	u16 sonic_dcr;
 	int id = -1;
@@ -536,7 +536,7 @@
 	if (!dev)
 		return -ENOMEM;
 
-	lp = (struct sonic_local *) netdev_priv(dev);
+	lp = netdev_priv(dev);
 	lp->device = device;
 	SET_NETDEV_DEV(dev, device);
  	SET_MODULE_OWNER(dev);
@@ -582,7 +582,7 @@
 static int __devexit mac_sonic_device_remove (struct device *device)
 {
 	struct net_device *dev = device->driver_data;
-	struct sonic_local* lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local* lp = netdev_priv(dev);
 
 	unregister_netdev (dev);
 	dma_free_coherent(lp->device, SIZEOF_SONIC_DESC * SONIC_BUS_SCALE(lp->dma_bitmode),
--- a/drivers/net/sonic.c	Sun Jul 10 22:11:40 2005
+++ linux/drivers/net/sonic.c	Sun Jul 10 22:26:14 2005
@@ -44,7 +44,7 @@
  */
 static int sonic_open(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int i;
 	
 	if (sonic_debug > 2)
@@ -131,7 +131,7 @@
  */
 static int sonic_close(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int i;
 
 	if (sonic_debug > 2)
@@ -177,7 +177,7 @@
 
 static void sonic_tx_timeout(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int i;
 	/* Stop the interrupts for this */
 	SONIC_WRITE(SONIC_IMR, 0);
@@ -221,7 +221,7 @@
 
 static int sonic_send_packet(struct sk_buff *skb, struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	dma_addr_t laddr;
 	int length;
 	int entry = lp->next_tx;
@@ -297,7 +297,7 @@
 static irqreturn_t sonic_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	struct net_device *dev = (struct net_device *) dev_id;
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int status;
 
 	if (dev == NULL) {
@@ -436,7 +436,7 @@
  */
 static void sonic_rx(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int status;
 	int entry = lp->cur_rx;
 
@@ -539,7 +539,7 @@
  */
 static struct net_device_stats *sonic_get_stats(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 
 	/* read the tally counter from the SONIC and reset them */
 	lp->stats.rx_crc_errors += SONIC_READ(SONIC_CRCT);
@@ -558,7 +558,7 @@
  */
 static void sonic_multicast_list(struct net_device *dev)
 {
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	unsigned int rcr;
 	struct dev_mc_list *dmi = dev->mc_list;
 	unsigned char *addr;
@@ -604,7 +604,7 @@
 static int sonic_init(struct net_device *dev)
 {
 	unsigned int cmd;
-	struct sonic_local *lp = (struct sonic_local *) netdev_priv(dev);
+	struct sonic_local *lp = netdev_priv(dev);
 	int i;
 
 	/*

From dan@embeddedalley.com Tue Jul 12 16:55:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 16:55:56 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:8205 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226647AbVGLPzj>; Tue, 12 Jul 2005 16:55:39 +0100
Received: from [192.168.1.109] (adsl-71-128-175-242.dsl.pltn13.pacbell.net [71.128.175.242])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6CFgvmN015581;
	Tue, 12 Jul 2005 11:42:58 -0400
In-Reply-To: <20050712142202.GB9234@gundam.enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8aee3747cc5c0d3ed94deb5b256bab94@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: power management status for au1100
Date:	Tue, 12 Jul 2005 08:56:31 -0700
To:	Rodolfo Giometti <giometti@linux.it>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
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: 8463
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@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1218
Lines: 31


On Jul 12, 2005, at 7:22 AM, Rodolfo Giometti wrote:

> I'm just looking at linux support for power management on au1100 CPU
> and I found that there are a lot of problems on enabling it... it
> seems that current support cames from 2.4 series.

I provided most of the recent generic updates for the Au1xxx power
management in the 2.4.  It's quite a challenge since you also need
hardware support for external peripheral control (which should be
in the drivers) and a cooperating boot rom for deep sleep.

> Is anybody dealing with it? I'd like to cooperate in order to have a
> functional support.

I'm sure there are some custom derivatives of this around.  I'm
not actively working on it since I don't have a project that requires
the features.  I don't really have the time to do so, either :-)

The one thing to keep in mind is we probably shouldn't promote
any of the variable processor frequency, as Alchemy has warned
they don't qualify parts at anything but their stated operating values.
You can run the processors at different frequencies, but this can
require different external components to support it, not something
we should be dynamically changing for a particular system design.

Thanks.


	-- Dan


From earlm@mips.com Tue Jul 12 18:21:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 18:22:10 +0100 (BST)
Received: from 209-232-97-206.ded.pacbell.net ([IPv6:::ffff:209.232.97.206]:44247
	"EHLO dns0.mips.com") by linux-mips.org with ESMTP
	id <S8226641AbVGLRVw> convert rfc822-to-8bit; Tue, 12 Jul 2005 18:21:52 +0100
Received: from mercury.mips.com (sbcns-dmz [209.232.97.193])
	by dns0.mips.com (8.12.11/8.12.11) with ESMTP id j6CHMh47013930;
	Tue, 12 Jul 2005 10:22:43 -0700 (PDT)
Received: from exchange.MIPS.COM (exchange [192.168.20.29])
	by mercury.mips.com (8.12.9/8.12.11) with ESMTP id j6CHMgjp000873;
	Tue, 12 Jul 2005 10:22:42 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: RE: Looking for a MIPS64 device
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date:	Tue, 12 Jul 2005 10:22:43 -0700
Message-ID: <3CB54817FDF733459B230DD27C690CEC010491B9@Exchange.MIPS.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Looking for a MIPS64 device
Thread-Index: AcWG6xpMjhUXKa/7R7iH2UwV9mIrGgAGw2nQ
From:	"Mitchell, Earl" <earlm@mips.com>
To:	"Stanislaw Skowronek" <sskowron@et.put.poznan.pl>,
	<linux-mips@linux-mips.org>
X-Scanned-By: MIMEDefang 2.39
Return-Path: <earlm@mips.com>
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: 8464
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: earlm@mips.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1346
Lines: 48


You can try vendors on this page ...

http://www.mips.com/content/Ecosystem/Chips/ProductCatalog/chipSelector?do=1&mips64=on&vendorId=*&freq=0

-earlm


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Stanislaw
> Skowronek
> Sent: Tuesday, July 12, 2005 7:06 AM
> To: linux-mips@linux-mips.org
> Subject: Looking for a MIPS64 device
> 
> 
> %hi16(all),
> 
> I'm looking for a MIPS64 device with FPU, and 40-bit physical address
> space. I need I/O coherency (this is important!). I'd be glad if the
> performance was good, but I'm not really bent on it.
> 
> This is for a research project in reconfigurable computing. I'd prefer
> MIPS devices because they are elegant (the other choice is 
> probably either
> PowerPC or x86_64, which is really scary) and 
> power-efficient. The project
> is partially supported by Xilinx Inc.
> 
> I tried contacting Broadcom, when the project was conducted 
> at the Poznan
> University of Technology (my employer), however no contact 
> was established
> (not even a "go away, you're ugly"). Same went for PMC-Sierra.
> 
> Do you know of any MIPS64 device with FPU (and MMU, but it 
> goes without
> saying) that can be purchased in small quantities for a 
> project like this?
> 
> Cheers,
> 
> Stanislaw Skowronek
> 
> 
> 
> 

From giometti@enneenne.com Tue Jul 12 19:09:12 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 19:09:35 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:61313 "EHLO
	gundam.enneenne.com") by linux-mips.org with ESMTP
	id <S8226651AbVGLSJM>; Tue, 12 Jul 2005 19:09:12 +0100
Received: from giometti by gundam.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DsPCv-0005cl-00
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 20:10:13 +0200
Date:	Tue, 12 Jul 2005 20:10:13 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips@linux-mips.org
Subject: Re: power management status for au1100
Message-ID: <20050712181013.GC9234@gundam.enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H"
Content-Disposition: inline
In-Reply-To: <20050712142202.GB9234@gundam.enneenne.com>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <giometti@enneenne.com>
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: 8465
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 5785
Lines: 168


--4SFOXa2GPu3tIq4H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Looking at linux-2.6.10 I notice that the function
startup_match20_interrupt() has been mofified as follow:

    #ifdef CONFIG_PM
   -void startup_match20_interrupt(void)
   +void startup_match20_interrupt(void (*handler)(int, void *, struct
   pt_regs *))
    {
   +       static struct irqaction action;
   +       /* This is a big problem.... since we didn't use request_irq
   +          when kernel/irq.c calls probe_irq_xxx this interrupt will
   +          be probed for usage. This will end up disabling the device :(
   +
   +       Give it a bogus "action" pointer -- this will keep it from
   +          getting auto-probed!
   +
   +       By setting the status to match that of request_irq() we
   +       can avoid it.  --cgray
   +       */
   +       action.dev_id =3D handler;
   +       action.flags =3D 0;
   +       action.mask =3D 0;
   +       action.name =3D "Au1xxx TOY";
   +       action.handler =3D handler;
   +       action.next =3D NULL;
   +
   +       irq_desc[AU1000_TOY_MATCH2_INT].action =3D &action;
   +       irq_desc[AU1000_TOY_MATCH2_INT].status
   +                &=3D ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING |
   IRQ_INPROGRESS);
   +
           local_enable_irq(AU1000_TOY_MATCH2_INT);
    }
    #endif

and the irq dispatcher has been modified as follow:

           irq =3D au_ffs(intc0_req1) - 1;
           intc0_req1 &=3D ~(1<<irq);
   -#ifdef CONFIG_PM
   -       if (irq =3D=3D AU1000_TOY_MATCH2_INT) {
   -               mask_and_ack_rise_edge_irq(irq);
   -               counter0_irq(irq, NULL, regs);
   -               local_enable_irq(irq);
   -       }
   -       else
   -#endif
   -       {
   -               do_IRQ(irq, regs);
   -       }
   +       do_IRQ(irq, regs);
    }
     =20
Well, running old code on my au1100 I have no problem but using new one I
got:

   Linux version 2.6.12 (giometti@vvonth) (gcc version 3.4.3) #29 Tue Jul 1=
2 19:41:24 CEST 2005
   CPU revision is: 02030204
   AMD Alchemy WWPC Board
   (PRId 02030204) @ 396MHZ
   BCLK switching enabled!
   Determined physical RAM map:
    memory: 04000000 @ 00000000 (usable)
   Built 1 zonelists
   Kernel command line: console=3DttyS0,115200 root=3D/dev/nfs rw nfsroot=
=3D192.168.32.254:/home/develop/embedded/mipsel/distro/_geek ip=3D192.168.3=
2.23:192.168.32.254::255.255.255.0:wwpc:eth0:off
   Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 by=
tes.
   Primary data cache 16kB, 4-way, linesize 32 bytes.
   Synthesized TLB refill handler (20 instructions).
   Synthesized TLB load handler fastpath (32 instructions).
   Synthesized TLB store handler fastpath (32 instructions).
   Synthesized TLB modify handler fastpath (31 instructions).
   PID hash table entries: 512 (order: 9, 8192 bytes)
   calculating r4koff... 00060ae0(396000)
   CPU frequency 396.00 MHz
   Console: colour dummy device 80x25
   Break instruction in kernel code in arch/mips/kernel/traps.c::do_bp, lin=
e 629[#1]:
   Cpu 0
   $ 0   : 00000000 10007c00 00000000 000f41fa
   $ 4   : 80462000 000f41fa 00000000 00000000
   $ 8   : 26aa8a40 000f41fa 80462000 00000000
   $12   : 0000006e fffffffa ffffffff 0000000a
   $16   : 00000af8 804d0000 80461ef0 804d0000
   $20   : 80461e18 80462000 00000002 00000000
   $24   : 00000001 80461dea                 =20
   $28   : 80460000 80461e08 83fc92b8 8010277c
   Hi    : 000f41fa
   Lo    : 26aa8a40
   epc   : 80148b28 run_posix_cpu_timers+0x804/0x86c     Not tainted
   ra    : 8010277c counter0_irq+0x98/0x168
   Status: 10007c03    KERNEL EXL IE=20
   Cause : 00808024
   PrId  : 02030204
   Modules linked in:
   Process swapper (pid: 0, threadinfo=3D80460000, task=3D80462000)
   Stack : 000003f4 000003f4 38313932 804c8934 80461e18 80461e18 00000000 0=
0000000
           80462000 00000000 00000af8 804d0000 80461ef0 804d0000 00000b1b 0=
0000011
           00000002 00000000 83fc92b8 8010277c 804de270 00000013 804de270 8=
0461ec8
           804cf9d4 00000000 00000000 00000001 80461ef0 80150964 804e0000 8=
0435d90
           00000002 10007c00 804a4220 00000011 804cf9d4 804e0000 80461ef0 8=
3f43c00
           ...
   Call Trace:
    [<8010277c>] counter0_irq+0x98/0x168
    [<80150964>] handle_IRQ_event+0x7c/0x134
    [<80150b24>] __do_IRQ+0x108/0x194
    [<804be264>] uart_set_options+0xe0/0x178
    [<8010600c>] do_IRQ+0x1c/0x34
    [<80101390>] au1000_IRQ+0x150/0x1a0
    [<801292d8>] __call_console_drivers+0x80/0xac
    [<80416fc4>] _etext+0x0/0x8f03c
    [<804a6700>] start_kernel+0x11c/0x254
    [<804a6710>] start_kernel+0x12c/0x254
    [<804a6134>] unknown_bootoption+0x0/0x310


   Code: aea30140  08052103  aea4013c <0200000d> 080520de  8ea4013c  240400=
1e  24050001  0c04e2c9=20
   Kernel panic - not syncing: Aiee, killing interrupt handler!

I suppose the problem is when function startup_match20_interrupt()
tries to install the irq handler for the counter0.

Why did you modify such function?

Where could be the problem in the new code?

Should we come back to the old code? ;-p

Thanks,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--4SFOXa2GPu3tIq4H
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC1AeFQaTCYNJaVjMRAsLlAJ48XrghsRDlwUJaPEt/ogPlWf2YxwCg0okm
XZKTUCFS+CD/9gzycFFnE5c=
=jyfE
-----END PGP SIGNATURE-----

--4SFOXa2GPu3tIq4H--

From bryan.althouse@3phoenix.com Tue Jul 12 19:14:47 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 19:15:05 +0100 (BST)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:21150 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8226651AbVGLSOr>; Tue, 12 Jul 2005 19:14:47 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (sccrmhc13) with SMTP
          id <2005071218154201300k2uihe>; Tue, 12 Jul 2005 18:15:42 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: mips64  crosstool
Date:	Tue, 12 Jul 2005 14:15:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcWEo3u2Inwh4UBxQ0mDfgvpEG82RwCP0cLwAAqXrIA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050712181447Z8226651-3678+2808@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
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: 8466
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 570
Lines: 18


Is anyone using crosstool to produce a 64 bit mips compiler?  

I need to produce a gcc that will accept the -mabi=64 option. I have been
able to generate a 32bit gcc with crosstool, using
TARGET=mips-unknown-linux-gnu.  Must I change this to
TARGET=mips64-unkown-linux-gnu to create a 64bit compiler?  I have tried
this, but crosstool will fail.  It appears as if -mabi=n32 is passed to the
native gcc during the build-glibc-headers step.  This of course causes the
native gcc to give up.

Are there any patches for mips64 tool chain build?  

Thanks to all.
Bryan




From dan@embeddededge.com Tue Jul 12 19:51:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 19:51:52 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:32013 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226662AbVGLSvg>; Tue, 12 Jul 2005 19:51:36 +0100
Received: from [192.168.1.109] (adsl-71-128-175-242.dsl.pltn13.pacbell.net [71.128.175.242])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6CIcsmN015946;
	Tue, 12 Jul 2005 14:38:55 -0400
In-Reply-To: <20050712181013.GC9234@gundam.enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddededge.com>
Subject: Re: power management status for au1100
Date:	Tue, 12 Jul 2005 11:52:30 -0700
To:	Rodolfo Giometti <giometti@linux.it>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddededge.com>
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: 8467
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@embeddededge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 572
Lines: 24


On Jul 12, 2005, at 11:10 AM, Rodolfo Giometti wrote:

> Looking at linux-2.6.10 I notice that the function
> startup_match20_interrupt() has been mofified as follow:

This is an update AMD/Alchemy wanted so if you weren't using
power management the timer would be available for other uses.

> Where could be the problem in the new code?

I don't know.  I suspect some of it didn't get moved forward
properly.

> Should we come back to the old code? ;-p

Now that you know the reason for the change, perhaps we
should try to make it work properly :-)

Thanks.


	-- Dan


From djohnson@sw.starentnetworks.com Tue Jul 12 23:04:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Jul 2005 23:04:29 +0100 (BST)
Received: from pasta.sw.starentnetworks.com ([IPv6:::ffff:12.33.234.10]:54411
	"EHLO pasta.sw.starentnetworks.com") by linux-mips.org with ESMTP
	id <S8226651AbVGLWEN>; Tue, 12 Jul 2005 23:04:13 +0100
Received: from cortez.sw.starentnetworks.com (cortez.sw.starentnetworks.com [12.33.233.12])
	by pasta.sw.starentnetworks.com (Postfix) with ESMTP id 8462F14B6C0
	for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 18:05:09 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17108.16021.215526.97259@cortez.sw.starentnetworks.com>
Date:	Tue, 12 Jul 2005 18:05:09 -0400
From:	Dave Johnson <djohnson+linuxmips@sw.starentnetworks.com>
To:	linux-mips@linux-mips.org
Subject: elf_core_dump() from binfmt_elfo32.c trashes heap
X-Mailer: VM 7.07 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Return-Path: <djohnson@sw.starentnetworks.com>
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: 8468
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: djohnson+linuxmips@sw.starentnetworks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2106
Lines: 68


64bit kernel, o32 userspace.

The call to elf_core_copy_regs() from elf_core_dump() is writing
beyond the end of prstatus because the wrong copy function is being
called:

slab error in cache_free_debugcheck(): cache `size-256': double free, or memory outside object was overwritten
Call Trace:
 [<ffffffff8016f77c>] __slab_error+0x2c/0x38
 [<ffffffff80171c50>] cache_free_debugcheck+0x290/0x318
 [<ffffffff80171c1c>] cache_free_debugcheck+0x25c/0x318
 [<ffffffff80172d80>] kfree+0x98/0x168
 [<ffffffff80172ce8>] kfree+0x0/0x168
 [<ffffffff8011a250>] elf_core_dump+0x508/0xb58
 [<ffffffff8019b394>] do_coredump+0x234/0x260
 [<ffffffff80144a28>] __dequeue_signal+0x0/0x2c0
 [<ffffffff80147118>] get_signal_to_deliver+0x210/0x390
 [<ffffffff80116d10>] do_signal32+0x80/0x288
 [<ffffffff80145f80>] kill_something_info+0x48/0x128
 [<ffffffff8011727c>] sys32_rt_sigprocmask+0xfc/0x1c0
 [<ffffffff80106ed4>] do_notify_resume+0x3c/0x48
 [<ffffffff801039cc>] work_notifysig+0xc/0x14
 [<ffffffff8011a9c0>] handle_sys+0x120/0x13c

a80000013ff0b2b8: redzone 1: 0x170fc2a5, redzone 2: 0x7a120.

redzone 2 has been overwritten.

--

Running binfmt_elfo32.c through the pre-processor reveals that
elf_core_copy_regs() is calling dump_regs() instead of
elf32_core_copy_regs().


In arch/mips/kernel/binfmt_elfo32.c:

#undef ELF_CORE_COPY_REGS
#define ELF_CORE_COPY_REGS(_dest,_regs) elf32_core_copy_regs(_dest,_regs);

Those 2 have no effect because elf_core_copy_regs() has already been
defined inline by including 'linux/elfcore.h' at the top of
binfmt_elfo32.c.

Changing elf32_core_copy_regs to a static also reveals the problem:

  CC      arch/mips/kernel/binfmt_elfo32.o
arch/mips/kernel/binfmt_elfo32.c:116: warning: `elf32_core_copy_regs' defined but not used


--

There's probably 10 different ways to fix this by re-ordering
#includes/#defines in arch/mips/kernel/binfmt_elfo32.c.

--

I found a reference to this in the mailing list from Jan/Feb 2005, but
the proposed patch didn't seem to get applied.

Suggestions on the best way to fix this?  Was that patch no good?


-- 
Dave Johnson
Starent Networks


From clem.taylor@gmail.com Wed Jul 13 01:24:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 01:25:03 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.203]:23105 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226667AbVGMAYs> convert rfc822-to-8bit;
	Wed, 13 Jul 2005 01:24:48 +0100
Received: by wproxy.gmail.com with SMTP id i36so59999wra
        for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 17:25:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=qrl4TWR1DRwUTqjh4UxvKhTPrgDSFoTZ8G4RlRYX1PJytB114KQBu6SEkFpNTEQahLEw79mnnO+Z5KUrEtpSZa2gC8N1e6tmw43CCRU7IAeRXh1/iGuBz4EnorYW9TJbhvTosGl6D7laOxdP6yXtX6Uan1HoArhMXDj4ZJoYkt0=
Received: by 10.54.106.13 with SMTP id e13mr136832wrc;
        Tue, 12 Jul 2005 17:25:46 -0700 (PDT)
Received: by 10.54.41.29 with HTTP; Tue, 12 Jul 2005 17:25:46 -0700 (PDT)
Message-ID: <ecb4efd105071217254e68b9e2@mail.gmail.com>
Date:	Tue, 12 Jul 2005 20:25:46 -0400
From:	Clem Taylor <clem.taylor@gmail.com>
Reply-To: Clem Taylor <clem.taylor@gmail.com>
To:	linux-mips@linux-mips.org
Subject: reboot gets stuck in a TLB exception on Au1550 based board
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <clem.taylor@gmail.com>
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: 8469
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: clem.taylor@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1632
Lines: 39

I was wondering if anyone else has a problem with reboot not working
on a Au1550? When I issue a reboot, the kernel prints "** Resetting
Integrated Peripherals", but the system doesn't reboot.

My BDI shows that the PC it is in the exception handling in the early
part of the yamon startup code. After taking the exception, if I say
'go 0xBFC00000', then the Au boots up just fine. The PC ends up at
0xbfc00424 which is an jump to self in the exception handling code in
yamon:

.org 0x400
        /* 0xBFC00400 Catch other exceptions, except EJTAG debug */
        /* Check for interrupt */
        MFC0(   k0, C0_CAUSE )
        and     k0, C0_CAUSE_CODE_MSK
        srl     k0, C0_CAUSE_CODE_SHF
        subu    k0, C0_CAUSE_CODE_INT
        beq     k0, zero, interrupt
        nop
        /* Not an interrupt */
1:
        b       1b             <=- PC ends up here after reboot.
        nop

k0 (reg 26) == 2, which I think is a TLB load or instruction fetch exception.

One difference between the stock db1x00 code and my code is that
arch/mips/au1000/db1x00/board_setup.c:board_reset() does a write to
the BCSR.SYSTEM_CONTROL[SW_RST]. I don't have the FPGA on my hardware,
but it looks like the code is wrong anyway, because the BCSR is at
0xAF000000 on the db1550, not 0xAE000000. If I take my kernel/root
image and run it on the dbau1550 board, reboot works (but in that case
it is running a different version of yamon).

I was wondering if anyone might have a clue what is going on or some
suggestions on what I can do to continue debugging this?

                               Thanks,
                               Clem

From dan@embeddedalley.com Wed Jul 13 01:45:49 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 01:46:05 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:16142 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226667AbVGMApt>; Wed, 13 Jul 2005 01:45:49 +0100
Received: from [192.168.1.109] (adsl-71-128-175-242.dsl.pltn13.pacbell.net [71.128.175.242])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6D0X7mN016492;
	Tue, 12 Jul 2005 20:33:08 -0400
In-Reply-To: <ecb4efd105071217254e68b9e2@mail.gmail.com>
References: <ecb4efd105071217254e68b9e2@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b5f7ad7b7c6ca0a1a80a3b8cb41a964c@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: reboot gets stuck in a TLB exception on Au1550 based board
Date:	Tue, 12 Jul 2005 17:46:44 -0700
To:	Clem Taylor <clem.taylor@gmail.com>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
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: 8470
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@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1308
Lines: 45


On Jul 12, 2005, at 5:25 PM, Clem Taylor wrote:

> I was wondering if anyone else has a problem with reboot not working
> on a Au1550?

What kernel and what version of YAMON?

I just happened to have a shell prompt on the Au1550 with 2.4.31
and YAMON ROM Monitor, Revision 02.24DB1550.

Reboot worked just fine, got me back to the YAMON prompt and
booted Linux.

>  When I issue a reboot, the kernel prints "** Resetting
> Integrated Peripherals", but the system doesn't reboot.

Do you know what peripherals may have been running
when you did the reboot?  I was using an NFS root file system
and had AC97 audio running.

> My BDI shows ....

What happens if you don't have the BDI connected?  Often,
boot roms step on debugger set up that the BDI does, causing
confusion on both parties.

> One difference between the stock db1x00 code and my code ....

Oh, now you tell me :-)  Custom hardware and different code,
I wonder why it doesn't work? :-)

It seems that if the hardware, YAMON, and Linux are all compatible,
there isn't any trouble.  Yes, I was using the Db1550.

> I was wondering if anyone might have a clue what is going on or some
> suggestions on what I can do to continue debugging this?

Only you know what is different, so you may want to look in those
places first.

Have fun!

	-- Dan


From ihollo@tom.com Wed Jul 13 03:19:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 03:19:42 +0100 (BST)
Received: from smtpr6.tom.com ([IPv6:::ffff:202.108.252.136]:54610 "HELO
	tom.com") by linux-mips.org with SMTP id <S8226522AbVGMCTU>;
	Wed, 13 Jul 2005 03:19:20 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp14 (Coremail) with SMTP id GACKXGN61EJXACac.1
	for <linux-mips@linux-mips.org>; Wed, 13 Jul 2005 10:20:21 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <42D47A74.9070709@tom.com>
Date:	Wed, 13 Jul 2005 10:20:36 +0800
From:	IHOLLO <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: ADM5120: linux-2.4.31-adm.diff.bz2 does not support PCI bus?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ihollo@tom.com>
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: 8471
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: ihollo@tom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1932
Lines: 46

Hi,

I am now working on a board with ADM5120 processor and want a kernel 
newer than 2.4.18, so I tried the linux-2.4.31-adm.diff.bz2 patch 
against vanilla 2.4.31 (http://www.linux-mips.org/wiki/ADMtek#Linux_2.4) 
but failed to compile it with PCI Bus support (It compiles OK without 
CONFIG_PCI). The compile error looks like this:

......
/opt/xyz/buildfarm/build_mipsel/staging_dir/bin/mipsel-linux-uclibc-ld 
-m elf32ltsmip -G 0 -static -n -T arch/mips/ld.script 
arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o 
init/version.o init/do_mounts.o \
        --start-group \
        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o 
mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o 
arch/mips/pci/pci-core.o \
         drivers/char/char.o drivers/block/block.o drivers/misc/misc.o 
drivers/net/net.o drivers/pci/driver.o drivers/mtd/mtdlink.o 
drivers/media/media.o \
        net/network.o \
        arch/mips/lib/lib.a /opt/xyz/linux-2.4/linux-2.4.31/lib/lib.a 
arch/mips/am5120/am5120.o \
        --end-group \
        -o vmlinux
drivers/pci/driver.o(.text+0x2218): In function `pci_fixup_device':
: undefined reference to `pcibios_fixups'
drivers/pci/driver.o(.text+0x222c): In function `pci_fixup_device':
: undefined reference to `pcibios_fixups'
drivers/pci/driver.o(.text.init+0x6d4): In function `pci_do_scan_bus':
: undefined reference to `pcibios_fixup_bus'
drivers/pci/driver.o(.text.init+0x6d4): In function `pci_do_scan_bus':
: relocation truncated to fit: R_MIPS_26 against `pcibios_fixup_bus'
drivers/pci/driver.o(.text.init+0xa98): In function `pci_init':
: undefined reference to `pcibios_init'
drivers/pci/driver.o(.text.init+0xa98): In function `pci_init':
: relocation truncated to fit: R_MIPS_26 against `pcibios_init'
make: *** [vmlinux] Error 1

Is PCI Bus supported by this patch? Or, is there any new kernel 
availible for ADM5120?

Thanks very much.

Zhuang Yuyao


From clem.taylor@gmail.com Wed Jul 13 03:23:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 03:24:03 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.199]:35832 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226517AbVGMCXs> convert rfc822-to-8bit;
	Wed, 13 Jul 2005 03:23:48 +0100
Received: by wproxy.gmail.com with SMTP id i22so69534wra
        for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 19:24:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SYbinsB8Rj9t9jVSNK60FJdJe1U1o+Z4FKxQ00RMCninOHfpB7Ckhmu9eQ7gACz/thajvvy7pA9OeNRpmxgrKPdBKU5/fO3o4cL1S1W9m7SKKFmny3+sM/ubPSO3Z4Pdv/QI14cGnK4wiGCXmkH23gNXav3pWLy7uSuzlr4zpOw=
Received: by 10.54.115.3 with SMTP id n3mr157587wrc;
        Tue, 12 Jul 2005 19:24:51 -0700 (PDT)
Received: by 10.54.41.29 with HTTP; Tue, 12 Jul 2005 19:24:51 -0700 (PDT)
Message-ID: <ecb4efd1050712192448e247b1@mail.gmail.com>
Date:	Tue, 12 Jul 2005 22:24:51 -0400
From:	Clem Taylor <clem.taylor@gmail.com>
Reply-To: Clem Taylor <clem.taylor@gmail.com>
To:	linux-mips@linux-mips.org
Subject: Re: reboot gets stuck in a TLB exception on Au1550 based board [resolved but not explained]
In-Reply-To: <ecb4efd105071217254e68b9e2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <ecb4efd105071217254e68b9e2@mail.gmail.com>
Return-Path: <clem.taylor@gmail.com>
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: 8472
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: clem.taylor@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 738
Lines: 14

On 7/12/05, Clem Taylor <clem.taylor@gmail.com> wrote:
> I was wondering if anyone else has a problem with reboot not working
> on a Au1550? When I issue a reboot, the kernel prints "** Resetting
> Integrated Peripherals", but the system doesn't reboot.

It seems that my problem was related to turning off sys_auxpll, which
is the clock source for the PCI bus. If I just comment out the write
to sys_auxpll in au1000_restart() then the reboot seems to work just
fine. I'm not sure why disabling the PCI clock would cause yamon to
take a TLB fault... I guess I need to hook up the analyzer and see
what happens to the PCI devices when the PCI clock goes away.

                      Thanks for the suggestions,
                      Clem

From maxim.osipov@gmail.com Wed Jul 13 05:40:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 05:40:53 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.193]:25936 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226533AbVGMEk2> convert rfc822-to-8bit;
	Wed, 13 Jul 2005 05:40:28 +0100
Received: by zproxy.gmail.com with SMTP id 12so58174nzp
        for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 21:41:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=E4PgcbvG5rhW3jdczoklVsBS1BtLfGiPQEZ1xmLegJoHQ72NkW4DbYHMQD9IcfrHnGnOwYcpy3OBSOlRc2LJ5rBe2BM7L8ACPP15T2Hx//VJhNAd04eaYLaPqBgHqxvF5CfB94aA473bVTt98eiHQUdyzAtG/6wo6g3Ay03biNc=
Received: by 10.36.157.15 with SMTP id f15mr552760nze;
        Tue, 12 Jul 2005 21:41:27 -0700 (PDT)
Received: by 10.36.68.6 with HTTP; Tue, 12 Jul 2005 21:41:27 -0700 (PDT)
Message-ID: <6097c4905071221414a929ed2@mail.gmail.com>
Date:	Wed, 13 Jul 2005 08:41:27 +0400
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Subject: Re: mips64 crosstool
Cc:	Linux/MIPS Development <linux-mips@linux-mips.org>
In-Reply-To: <20050712181447Z8226651-3678+2808@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <20050712181447Z8226651-3678+2808@linux-mips.org>
Return-Path: <maxim.osipov@gmail.com>
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: 8473
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: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 962
Lines: 31

When I was looking at crosstool, it had problems with miltiarch
support for mips. If you want to produce mips64 only tools, you'll
need patches from Maciej which are not there also. And take a look
into build matrix :)

Conclusion - mips is not very well supported in crosstool.

BR,
Maxim

On 7/12/05, Bryan Althouse <bryan.althouse@3phoenix.com> wrote:
> 
> Is anyone using crosstool to produce a 64 bit mips compiler?
> 
> I need to produce a gcc that will accept the -mabi=64 option. I have been
> able to generate a 32bit gcc with crosstool, using
> TARGET=mips-unknown-linux-gnu.  Must I change this to
> TARGET=mips64-unkown-linux-gnu to create a 64bit compiler?  I have tried
> this, but crosstool will fail.  It appears as if -mabi=n32 is passed to the
> native gcc during the build-glibc-headers step.  This of course causes the
> native gcc to give up.
> 
> Are there any patches for mips64 tool chain build?
> 
> Thanks to all.
> Bryan
> 
> 
> 
> 
>

From yyuasa@gmail.com Wed Jul 13 07:39:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 07:39:47 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.199]:33739 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226671AbVGMGjb> convert rfc822-to-8bit;
	Wed, 13 Jul 2005 07:39:31 +0100
Received: by zproxy.gmail.com with SMTP id n29so67339nzf
        for <linux-mips@linux-mips.org>; Tue, 12 Jul 2005 23:40:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Q31+cmtjkL/nbvRq2iu/Iqz6FoHT+Od9UABSjBbE+JSvvJG2hy9hrOFH1lwVtO6JohOvW3tzk0T5PkP1jtvht+Fh0SgNM//EJaj8IWklO8Z52k86493wN9GICqJxAP0wxJWIHePBsq4E/E52BRLOwRK723G1Quu9q2tLdmsBhvs=
Received: by 10.36.222.26 with SMTP id u26mr634305nzg;
        Tue, 12 Jul 2005 23:40:31 -0700 (PDT)
Received: by 10.36.57.12 with HTTP; Tue, 12 Jul 2005 23:40:31 -0700 (PDT)
Message-ID: <4955666b05071223405849abf6@mail.gmail.com>
Date:	Wed, 13 Jul 2005 15:40:31 +0900
From:	Yoichi Yuasa <yyuasa@gmail.com>
Reply-To: Yoichi Yuasa <yyuasa@gmail.com>
To:	IHOLLO <ihollo@tom.com>
Subject: Re: ADM5120: linux-2.4.31-adm.diff.bz2 does not support PCI bus?
Cc:	linux-mips@linux-mips.org
In-Reply-To: <42D47A74.9070709@tom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <42D47A74.9070709@tom.com>
Return-Path: <yyuasa@gmail.com>
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: 8474
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: yyuasa@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 445
Lines: 14

Hi,

2005/7/13, IHOLLO <ihollo@tom.com>:
> Hi,
> 
> I am now working on a board with ADM5120 processor and want a kernel
> newer than 2.4.18, so I tried the linux-2.4.31-adm.diff.bz2 patch
> against vanilla 2.4.31 (http://www.linux-mips.org/wiki/ADMtek#Linux_2.4)
> but failed to compile it with PCI Bus support (It compiles OK without
> CONFIG_PCI). The compile error looks like this:

Did you turn on New PCI bus code(CONFIG_PCI_NEW)?

Yoichi

From turja@mbnet.fi Wed Jul 13 08:10:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 08:11:11 +0100 (BST)
Received: from fep19.inet.fi ([IPv6:::ffff:194.251.242.244]:22705 "EHLO
	fep19.inet.fi") by linux-mips.org with ESMTP id <S8226671AbVGMHKy>;
	Wed, 13 Jul 2005 08:10:54 +0100
Received: from [127.0.0.1] ([80.223.109.59]) by fep19.inet.fi with ESMTP
          id <20050713071159.YWHU20441.fep19.inet.fi@[127.0.0.1]>
          for <linux-mips@linux-mips.org>; Wed, 13 Jul 2005 10:11:59 +0300
Message-ID: <42D4BF49.4040907@mbnet.fi>
Date:	Wed, 13 Jul 2005 10:14:17 +0300
From:	Mikael Nousiainen <turja@mbnet.fi>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: New VINO video drivers for Indy
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <turja@mbnet.fi>
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: 8475
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: turja@mbnet.fi
Precedence: bulk
X-list: linux-mips
Content-Length: 276
Lines: 10

I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).

For more information, see the webpage:
http://www.mbnet.fi/~turja/vino/

Please test the driver and report the results so that bugs
(yes, I can promise there are lots of them :) can be squashed.




From ihollo@tom.com Wed Jul 13 10:34:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 10:34:36 +0100 (BST)
Received: from smtpr1.tom.com ([IPv6:::ffff:202.108.255.195]:15845 "HELO
	tom.com") by linux-mips.org with SMTP id <S8226470AbVGMJeI>;
	Wed, 13 Jul 2005 10:34:08 +0100
Received: from [192.168.10.105] (unknown [218.94.38.156])
	by bjapp5 (Coremail) with SMTP id iMBgikXg1EJPACac.1
	for <yyuasa@gmail.com>; Wed, 13 Jul 2005 17:35:05 +0800 (CST)
X-Originating-IP: [218.94.38.156]
Message-ID: <42D4E053.6020708@tom.com>
Date:	Wed, 13 Jul 2005 17:35:15 +0800
From:	IHOLLO <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Yoichi Yuasa <yyuasa@gmail.com>
CC:	linux-mips@linux-mips.org
Subject: ADM5120: MIPS-I or MIPS32? WAS(Re: ADM5120: linux-2.4.31-adm.diff.bz2
 does not support PCI bus?)
References: <42D47A74.9070709@tom.com> <4955666b05071223405849abf6@mail.gmail.com>
In-Reply-To: <4955666b05071223405849abf6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ihollo@tom.com>
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: 8476
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: ihollo@tom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1190
Lines: 43

Thanks Yoichi, that is exactly what you suggested, turn on New PCI bus 
code(CONFIG_PCI_NEW) then the kernel can be compiled  now.

Here is another question: What CPU type should I choose to compile 
applications for ADM5120? the spec says it is MIPS32, but I can not run 
MIPS32 applications on my board while MIPS-I executable works just fine.

#file busybox (works fine. compiled as mips-I)
busybox: ELF 32-bit LSB MIPS-I executable, MIPS, version 1 (SYSV), 
dynamically linked (uses shared libs), stripped

#file busybox (can not execute this program. compiled as mips32)
busybox: ELF 32-bit LSB executable, MIPS, version 1 (SYSV), dynamically 
linked (uses shared libs), stripped


Yoichi Yuasa wrote:

>Hi,
>
>2005/7/13, IHOLLO <ihollo@tom.com>:
>  
>
>>Hi,
>>
>>I am now working on a board with ADM5120 processor and want a kernel
>>newer than 2.4.18, so I tried the linux-2.4.31-adm.diff.bz2 patch
>>against vanilla 2.4.31 (http://www.linux-mips.org/wiki/ADMtek#Linux_2.4)
>>but failed to compile it with PCI Bus support (It compiles OK without
>>CONFIG_PCI). The compile error looks like this:
>>    
>>
>
>Did you turn on New PCI bus code(CONFIG_PCI_NEW)?
>
>Yoichi
>
>
>
>  
>



From jaypee@hotpop.com Wed Jul 13 17:02:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Jul 2005 17:02:34 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:55682 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226533AbVGMQCP> convert rfc822-to-8bit; Wed, 13 Jul 2005 17:02:15 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id DDD5113E8C3D
	for <linux-mips@linux-mips.org>; Wed, 13 Jul 2005 16:03:11 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-2.hotpop.com (Postfix) with ESMTP id 3378A13E8BFB
	for <linux-mips@linux-mips.org>; Wed, 13 Jul 2005 16:03:05 +0000 (UTC)
Date:	Wed, 13 Jul 2005 16:00:00 +0000
From:	jaypee@hotpop.com
Subject: Au1550 ethernet throughput low
To:	linux-mips <linux-mips@linux-mips.org>
X-Mailer: Balsa 2.3.3
Message-Id: <1121270402l.7656l.3l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8478
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: 817
Lines: 32

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
I've got a au1550 board based largely on the pb1550. The ethernet  
throughput is ~66Mbps using the 2.6 kernel. This also consumes a
lot of cpu cycles to send.

We have older designs using au1000 and mvista 2.4 kernel that achieve  
full line rate throughput without using a lot of the cpu.

Can someone with a pb/db1550 and linux 2.6 do a quick test to verify
that is is not a 2.6 kernel problem, and is a problem with our HW/SW.

If anyone can do the same with a 2.4 kernel too that would be great.

Thanks,
JP

- -- 
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC1TqCZDxnKy3oOpYRAhwaAKCoY/3lEX/DksOEq42FfxlsF2rjEgCeNI0G
/72t16fNrA4XvX+KVumsNDw=
=yoD8
-----END PGP SIGNATURE-----




From ppopov@embeddedalley.com Thu Jul 14 01:17:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 01:17:37 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:62302
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226704AbVGNARS>; Thu, 14 Jul 2005 01:17:18 +0100
Received: (qmail 21400 invoked from network); 14 Jul 2005 00:18:26 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 14 Jul 2005 00:18:26 -0000
Subject: Re: compiling error of linux 2.6.12 recent cvs head for db1550
	using defconfig
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205070616124fa47ef3@mail.gmail.com>
References: <2db32b7205070616124fa47ef3@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Wed, 13 Jul 2005 17:18:35 -0700
Message-Id: <1121300315.4797.318.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8479
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: 1351
Lines: 34


Try again, I just fixed it and one other compile error in 2.6.13-rc3.

Pete

On Wed, 2005-07-06 at 16:12 -0700, rolf liu wrote:
> I use gcc 3.4.4 to compile the recent 2.6.12, got the following errors:
> 
>   CC      arch/mips/au1000/common/setup.o
> In file included from include/asm/io.h:29,
>                  from include/asm/mach-au1x00/au1000.h:43,
>                  from arch/mips/au1000/common/setup.c:42:
> include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration
> of 'fixup_bigphys_addr' follows non-static declaration
> include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared
> inline after being called
> include/asm/pgtable.h:363: warning: previous declaration of
> 'fixup_bigphys_addr' was here
> include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
> include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit
> declaration of function `__fixup_bigphys_addr'
> arch/mips/au1000/common/setup.c: At top level:
> arch/mips/au1000/common/setup.c:159: error: conflicting types for
> '__fixup_bigphys_addr'
> include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit
> declaration of '__fixup_bigphys_addr' was here
> make[1]: *** [arch/mips/au1000/common/setup.o] Error 1
> make: *** [arch/mips/au1000/common] Error 2
> 
> Not sure if it is just compiler's problem
> 
> thanks
> 


From ajaysingh@ti.com Thu Jul 14 06:02:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 06:03:07 +0100 (BST)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:27839 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8226704AbVGNFCs> convert rfc822-to-8bit;
	Thu, 14 Jul 2005 06:02:48 +0100
Received: from dlep30.itg.ti.com ([157.170.139.157])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j6E53rIx001362;
	Thu, 14 Jul 2005 00:03:53 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep30.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6E53q3W022523;
	Thu, 14 Jul 2005 00:03:53 -0500 (CDT)
Received: from dbde01.ent.ti.com (localhost [127.0.0.1])
	by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6E53gWF013130;
	Thu, 14 Jul 2005 00:03:52 -0500 (CDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Au1550 ethernet throughput low
Date:	Thu, 14 Jul 2005 10:32:22 +0530
Message-ID: <A8A67F242940E246A515077CF9ECACC16B16C4@dbde01.ent.ti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Au1550 ethernet throughput low
Thread-Index: AcWHxJN7otZhA6qjRj+as9e/GuOp8AAbHDbg
From:	"Singh, Ajay" <ajaysingh@ti.com>
To:	<jaypee@hotpop.com>, "linux-mips" <linux-mips@linux-mips.org>
Return-Path: <ajaysingh@ti.com>
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: 8480
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: ajaysingh@ti.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1116
Lines: 42

Is your driver on Linux 2.6 NAPI enabled ? And is CONFIG_PREEMPT=y?

-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of jaypee@hotpop.com
Sent: Wednesday, July 13, 2005 9:30 PM
To: linux-mips
Subject: Au1550 ethernet throughput low

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
I've got a au1550 board based largely on the pb1550. The ethernet
throughput is ~66Mbps using the 2.6 kernel. This also consumes a lot of
cpu cycles to send.

We have older designs using au1000 and mvista 2.4 kernel that achieve
full line rate throughput without using a lot of the cpu.

Can someone with a pb/db1550 and linux 2.6 do a quick test to verify
that is is not a 2.6 kernel problem, and is a problem with our HW/SW.

If anyone can do the same with a 2.4 kernel too that would be great.

Thanks,
JP

- --
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC1TqCZDxnKy3oOpYRAhwaAKCoY/3lEX/DksOEq42FfxlsF2rjEgCeNI0G
/72t16fNrA4XvX+KVumsNDw=
=yoD8
-----END PGP SIGNATURE-----





From matej.kupljen@ultra.si Thu Jul 14 13:49:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 13:49:21 +0100 (BST)
Received: from deliver-1.mx.triera.net ([IPv6:::ffff:213.161.0.31]:34500 "HELO
	deliver-1.mx.triera.net") by linux-mips.org with SMTP
	id <S8226719AbVGNMtD>; Thu, 14 Jul 2005 13:49:03 +0100
Received: from localhost (in-2.mx.triera.net [213.161.0.26])
	by deliver-1.mx.triera.net (Postfix) with ESMTP id AC995C04D;
	Thu, 14 Jul 2005 14:49:58 +0200 (CEST)
Received: from smtp.triera.net (smtp.triera.net [213.161.0.30])
	by in-2.mx.triera.net (Postfix) with SMTP id 0A6941BC08D;
	Thu, 14 Jul 2005 14:50:01 +0200 (CEST)
Received: from orionlinux.starfleet.com (cmb58-52.dial-up.arnes.si [153.5.49.52])
	by smtp.triera.net (Postfix) with ESMTP id 117DF1A18AD;
	Thu, 14 Jul 2005 14:50:00 +0200 (CEST)
Subject: Re: Au1550 ethernet throughput low
From:	Matej Kupljen <matej.kupljen@ultra.si>
To:	jaypee@hotpop.com
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121270402l.7656l.3l@cavan>
References: <1121270402l.7656l.3l@cavan>
Content-Type: text/plain
Organization: Ultra d.o.o.
Date:	Thu, 14 Jul 2005 17:02:26 +0200
Message-Id: <1121353347.10582.3.camel@orionlinux.starfleet.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Triera AV Service
Return-Path: <matej.kupljen@ultra.si>
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: 8481
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: 531
Lines: 18

Hi

> I've got a au1550 board based largely on the pb1550. The ethernet  
> throughput is ~66Mbps using the 2.6 kernel. This also consumes a
> lot of cpu cycles to send.

I get low throughput with DB1200 also, although I did not measure
it (yet). I noticed very slow NFS mounted rootfs and I get a lot of:
NFS server not responding, still trying
NFS server O.K.
(Something like that, I do not have the board here right now).

AMD supplies smc9111 driver in smc9111.c/h. Should I use
this driver or is smc9x.c/h better?

BR,
Matej


From jaypee@hotpop.com Thu Jul 14 15:40:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 15:40:38 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:28845 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226372AbVGNOkT> convert rfc822-to-8bit; Thu, 14 Jul 2005 15:40:19 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id 2EE961416454
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 14:41:17 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-1.hotpop.com (Postfix) with ESMTP id DD8941A0234
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 13:52:54 +0000 (UTC)
Date:	Thu, 14 Jul 2005 13:52:36 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	linux-mips <linux-mips@linux-mips.org>
References: <A8A67F242940E246A515077CF9ECACC16B16C4@dbde01.ent.ti.com>
In-Reply-To: <A8A67F242940E246A515077CF9ECACC16B16C4@dbde01.ent.ti.com>
	(from ajaysingh@ti.com on Thu Jul 14 06:02:22 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121349173l.5178l.0l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8482
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: 768
Lines: 30

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 14/07/05 06:02:22, Singh, Ajay wrote:
> Is your driver on Linux 2.6 NAPI enabled ? And is CONFIG_PREEMPT=y?

Turning preempt on made no difference, maybe a little worse.

I put a scope on the TX enable line and it is high for ~100us and low  
~50us. With the 2.4 kernel on au1000 it is high all the time.

This to me suggest there is some thing wrong in the au1000_eth driver/
interrupt handling/ packet scheduling in 2.6 as it is not keeping the  
DMA buffers full.


- -- 
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC1m41ZDxnKy3oOpYRAhooAJ9W7J8ZpXywqW0jPxc0b8hI3iS/DwCfZzWM
6lp6Z7cHYwW3WWW87SJrZPI=
=1No0
-----END PGP SIGNATURE-----




From ppopov@embeddedalley.com Thu Jul 14 16:05:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:05:47 +0100 (BST)
Received: from smtp004.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.81]:28804
	"HELO smtp004.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226686AbVGNPF2>; Thu, 14 Jul 2005 16:05:28 +0100
Received: (qmail 17192 invoked from network); 14 Jul 2005 15:06:40 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp004.bizmail.sc5.yahoo.com with SMTP; 14 Jul 2005 15:06:40 -0000
Subject: Re: Au1550 ethernet throughput low
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Matej Kupljen <matej.kupljen@ultra.si>
Cc:	jaypee@hotpop.com, linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121353347.10582.3.camel@orionlinux.starfleet.com>
References: <1121270402l.7656l.3l@cavan>
	 <1121353347.10582.3.camel@orionlinux.starfleet.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 08:06:46 -0700
Message-Id: <1121353606.4797.346.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8483
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: 835
Lines: 27

On Thu, 2005-07-14 at 17:02 +0200, Matej Kupljen wrote:
> Hi
> 
> > I've got a au1550 board based largely on the pb1550. The ethernet  
> > throughput is ~66Mbps using the 2.6 kernel. This also consumes a
> > lot of cpu cycles to send.

Completely different ethernet drivers. The 1550 throughput should be
very good. I haven't noticed any issues with 2.6 on my db1550 but I
haven't run netperf lately. I'll do it when I have a little time.

Pete

> I get low throughput with DB1200 also, although I did not measure
> it (yet). I noticed very slow NFS mounted rootfs and I get a lot of:
> NFS server not responding, still trying
> NFS server O.K.
> (Something like that, I do not have the board here right now).
> 
> AMD supplies smc9111 driver in smc9111.c/h. Should I use
> this driver or is smc9x.c/h better?
> 
> BR,
> Matej
> 
> 


From rolfliu@gmail.com Thu Jul 14 16:31:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:32:11 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.194]:54878 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226686AbVGNPb4> convert rfc822-to-8bit;
	Thu, 14 Jul 2005 16:31:56 +0100
Received: by wproxy.gmail.com with SMTP id i36so445200wra
        for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 08:33:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=NGmPp9BVCNUFJv9QQaX3tRMEbAlltM8hLN4aqpiED+XnlmTKql6ZhCpZdNE1fpLP0MvYdcG3CDJeeiRk1WHdrlSLR+G/7lk0c9kK/ZDSmjrEjxNMmH3nRHQnPTCp41xw5uN8/wUiQSZG3pVWBsLlAZWDSb7+HuXNggWNo8skgXA=
Received: by 10.54.33.62 with SMTP id g62mr789838wrg;
        Thu, 14 Jul 2005 08:32:17 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 14 Jul 2005 08:32:17 -0700 (PDT)
Message-ID: <2db32b7205071408327b005e4e@mail.gmail.com>
Date:	Thu, 14 Jul 2005 08:32:17 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: What is the current USB support status on DB1550?
Cc:	rolf liu <rolfliu@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8484
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 92
Lines: 5

Are both usb host and usb gadget support as well? And the On the Go feature?

Thanks 

rolf

From macro@linux-mips.org Thu Jul 14 16:33:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:34:11 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:58378 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226686AbVGNPdv>; Thu, 14 Jul 2005 16:33:51 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3093AE1CBE
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 17:34:53 +0200 (CEST)
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 03335-08 for <linux-mips@linux-mips.org>;
 Thu, 14 Jul 2005 17:34:53 +0200 (CEST)
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 EDC8FE1CBC
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 17:34:52 +0200 (CEST)
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 j6EFYuR3001123
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 17:34:56 +0200
Date:	Thu, 14 Jul 2005 16:35:05 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <20050714001711Z8226701-3678+2977@linux-mips.org>
Message-ID: <Pine.LNX.4.61L.0507141120450.31857@blysk.ds.pg.gda.pl>
References: <20050714001711Z8226701-3678+2977@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/978/Thu Jul 14 13:37:27 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8485
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: 367
Lines: 13

On Thu, 14 Jul 2005 ppopov@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: pgtable.h 
> 	include/asm-mips/mach-au1x00: ioremap.h 
> 
> Log message:
> 	Fix the fixup_bigphys_addr compile problem.

 Hmm, I think you should include <ioremap.h> instead as that's the header 
and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.

  Maciej

From ppopov@embeddedalley.com Thu Jul 14 16:48:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:49:01 +0100 (BST)
Received: from smtp008.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.74]:14263
	"HELO smtp008.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226686AbVGNPso>; Thu, 14 Jul 2005 16:48:44 +0100
Received: (qmail 89899 invoked from network); 14 Jul 2005 15:49:46 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp008.bizmail.sc5.yahoo.com with SMTP; 14 Jul 2005 15:49:46 -0000
Subject: Re: What is the current USB support status on DB1550?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205071408327b005e4e@mail.gmail.com>
References: <2db32b7205071408327b005e4e@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 08:49:52 -0700
Message-Id: <1121356192.4797.362.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8486
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: 310
Lines: 10

On Thu, 2005-07-14 at 08:32 -0700, rolf liu wrote:
> Are both usb host and usb gadget support as well? And the On the Go feature?

Host only. We couldn't make gadget work due to interrupt latency
requirements by the HW that couldn't be reliably achieved with Linux.
But gadget does work on the Au1200.

Pete



From ppopov@embeddedalley.com Thu Jul 14 16:49:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:49:57 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:10363
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226701AbVGNPtl>; Thu, 14 Jul 2005 16:49:41 +0100
Received: (qmail 16913 invoked from network); 14 Jul 2005 15:50:54 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 14 Jul 2005 15:50:53 -0000
Subject: Re: CVS Update@linux-mips.org: linux
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.61L.0507141120450.31857@blysk.ds.pg.gda.pl>
References: <20050714001711Z8226701-3678+2977@linux-mips.org>
	 <Pine.LNX.4.61L.0507141120450.31857@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 08:51:00 -0700
Message-Id: <1121356260.4797.364.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8487
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: 564
Lines: 18

On Thu, 2005-07-14 at 16:35 +0100, Maciej W. Rozycki wrote:
> On Thu, 14 Jul 2005 ppopov@linux-mips.org wrote:
> 
> > Modified files:
> > 	include/asm-mips: pgtable.h 
> > 	include/asm-mips/mach-au1x00: ioremap.h 
> > 
> > Log message:
> > 	Fix the fixup_bigphys_addr compile problem.
> 
>  Hmm, I think you should include <ioremap.h> instead as that's the header 
> and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.

I think I did and it couldn't pick up the right one since we have the
generic one and then the cpu specific version.

Pete


From macro@linux-mips.org Thu Jul 14 16:57:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 16:58:11 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:16906 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226709AbVGNP5w>; Thu, 14 Jul 2005 16:57:52 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 89590E1CBE; Thu, 14 Jul 2005 17:58:58 +0200 (CEST)
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 21427-10; Thu, 14 Jul 2005 17:58:58 +0200 (CEST)
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 520EFE1CBC; Thu, 14 Jul 2005 17:58:58 +0200 (CEST)
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 j6EFx1VT001854;
	Thu, 14 Jul 2005 17:59:01 +0200
Date:	Thu, 14 Jul 2005 16:59:11 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: CVS Update@linux-mips.org: linux
In-Reply-To: <1121356260.4797.364.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.61L.0507141653440.31857@blysk.ds.pg.gda.pl>
References: <20050714001711Z8226701-3678+2977@linux-mips.org> 
 <Pine.LNX.4.61L.0507141120450.31857@blysk.ds.pg.gda.pl>
 <1121356260.4797.364.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/978/Thu Jul 14 13:37:27 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8488
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: 520
Lines: 13

On Thu, 14 Jul 2005, Pete Popov wrote:

> >  Hmm, I think you should include <ioremap.h> instead as that's the header 
> > and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.
> 
> I think I did and it couldn't pick up the right one since we have the
> generic one and then the cpu specific version.

 That would be strange -- the system-specific one (note it's not 
CPU-specific) should precede the generic one in the inclusion path list.  
And how does <asm/io.h> pick the right one then?

  Maciej

From ppopov@embeddedalley.com Thu Jul 14 16:59:52 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 17:00:10 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:60296
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226719AbVGNP7w>; Thu, 14 Jul 2005 16:59:52 +0100
Received: (qmail 25153 invoked from network); 14 Jul 2005 16:01:04 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 14 Jul 2005 16:01:04 -0000
Subject: Re: CVS Update@linux-mips.org: linux
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <Pine.LNX.4.61L.0507141653440.31857@blysk.ds.pg.gda.pl>
References: <20050714001711Z8226701-3678+2977@linux-mips.org>
	 <Pine.LNX.4.61L.0507141120450.31857@blysk.ds.pg.gda.pl>
	 <1121356260.4797.364.camel@localhost.localdomain>
	 <Pine.LNX.4.61L.0507141653440.31857@blysk.ds.pg.gda.pl>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 09:01:10 -0700
Message-Id: <1121356870.4797.369.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8489
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: 748
Lines: 19

On Thu, 2005-07-14 at 16:59 +0100, Maciej W. Rozycki wrote:
> On Thu, 14 Jul 2005, Pete Popov wrote:
> 
> > >  Hmm, I think you should include <ioremap.h> instead as that's the header 
> > > and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.
> > 
> > I think I did and it couldn't pick up the right one since we have the
> > generic one and then the cpu specific version.
> 
>  That would be strange -- the system-specific one (note it's not 
> CPU-specific) should precede the generic one in the inclusion path list.  
> And how does <asm/io.h> pick the right one then?

No idea, didn't spend enough time on it. I'll do another compile with
ioremap.h instead and see what the problem was and if it can be easily
fixed.

Pete


From rolfliu@gmail.com Thu Jul 14 17:03:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 17:03:56 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.201]:29791 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226711AbVGNQDj> convert rfc822-to-8bit;
	Thu, 14 Jul 2005 17:03:39 +0100
Received: by wproxy.gmail.com with SMTP id 68so453484wri
        for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 09:04:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RFqsvf2gX3JGgcq07Dh/rB1B2wBZxnQKroFHHGv5B4qn2mc1VMh5p1Q/74zL7jDjJrhAJxvHMGSPeYMF9cIL7zjFqb9TfHdsw0MYfHT1VklDc2Nn+eKLjVS4S3lwUxTuuOOKZZTt7lsJk+s6OJyRczlWJiwl/ndGqWYnMExWLVg=
Received: by 10.54.106.13 with SMTP id e13mr798423wrc;
        Thu, 14 Jul 2005 09:04:16 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 14 Jul 2005 09:04:16 -0700 (PDT)
Message-ID: <2db32b7205071409044c9f9317@mail.gmail.com>
Date:	Thu, 14 Jul 2005 09:04:16 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: What is the current USB support status on DB1550?
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <1121356192.4797.362.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205071408327b005e4e@mail.gmail.com>
	 <1121356192.4797.362.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8490
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 475
Lines: 16

Is there big difference between Au1200 and Au1550? Any constrant on Au1550 ?
Thanks


On 7/14/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Thu, 2005-07-14 at 08:32 -0700, rolf liu wrote:
> > Are both usb host and usb gadget support as well? And the On the Go feature?
> 
> Host only. We couldn't make gadget work due to interrupt latency
> requirements by the HW that couldn't be reliably achieved with Linux.
> But gadget does work on the Au1200.
> 
> Pete
> 
> 
>

From ppopov@embeddedalley.com Thu Jul 14 17:10:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 17:10:58 +0100 (BST)
Received: from smtp003.bizmail.yahoo.com ([IPv6:::ffff:216.136.130.195]:57527
	"HELO smtp003.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226711AbVGNQKl>; Thu, 14 Jul 2005 17:10:41 +0100
Received: (qmail 61101 invoked from network); 14 Jul 2005 16:11:44 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp003.bizmail.yahoo.com with SMTP; 14 Jul 2005 16:11:43 -0000
Subject: Re: What is the current USB support status on DB1550?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	rolf liu <rolfliu@gmail.com>
Cc:	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-Reply-To: <2db32b7205071409044c9f9317@mail.gmail.com>
References: <2db32b7205071408327b005e4e@mail.gmail.com>
	 <1121356192.4797.362.camel@localhost.localdomain>
	 <2db32b7205071409044c9f9317@mail.gmail.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 09:11:49 -0700
Message-Id: <1121357509.4797.371.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8491
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: 659
Lines: 26

On Thu, 2005-07-14 at 09:04 -0700, rolf liu wrote:
> Is there big difference between Au1200 and Au1550? 

Sure. Take a look at the marketing pdfs from AMD, they provide a concise
description.

Pete

> Any constrant on Au1550 ?
> Thanks
> 
> 
> On 7/14/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > On Thu, 2005-07-14 at 08:32 -0700, rolf liu wrote:
> > > Are both usb host and usb gadget support as well? And the On the Go feature?
> > 
> > Host only. We couldn't make gadget work due to interrupt latency
> > requirements by the HW that couldn't be reliably achieved with Linux.
> > But gadget does work on the Au1200.
> > 
> > Pete
> > 
> > 
> >
> 


From jaypee@hotpop.com Thu Jul 14 17:12:48 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 17:13:08 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:6542 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226711AbVGNQMs> convert rfc822-to-8bit; Thu, 14 Jul 2005 17:12:48 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id 7704B14090C8
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 16:13:47 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-1.hotpop.com (Postfix) with ESMTP id 0EAB51A0237
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 15:15:43 +0000 (UTC)
Date:	Thu, 14 Jul 2005 15:15:42 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	linux-mips <linux-mips@linux-mips.org>
References: <1121270402l.7656l.3l@cavan>
	<1121353347.10582.3.camel@orionlinux.starfleet.com>
In-Reply-To: <1121353347.10582.3.camel@orionlinux.starfleet.com> (from
	matej.kupljen@ultra.si on Thu Jul 14 16:02:26 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121354144l.5178l.2l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8492
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: 1199
Lines: 43

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I've got a au1550 board based largely on the pb1550. The ethernet
> throughput is ~66Mbps using the 2.6 kernel. This also consumes a
> lot of cpu cycles to send.

I put a test into YAMON and I can get full line rate out no problem.

I think this narrows it down to a problem with the kernel or my port
of it.

The actual au1000_eth driver doesn't do much work other than copy a  
packet into cache aligned buffer. It must be more to do with the  
scheduling of sending a new packet. tx_ack.

The kernel I'm using is a snapshot linux-mips CVS of 2.6.11-rc5.
Can anyone tell me if there improvements/fixes to this area since then?

Clem sent me the output of a test. In which he is getting 11MBs
I'm assuming the B is bytes in which case that is as near line rate as
dammit.

Clem you said were using 2.6.11 was that a kernel.org kernel or one
from linux-mips.org?

thnks for running the test clem.


- -- 
JP
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC1oGgZDxnKy3oOpYRAvw4AJ4kkGrJ/DneIqfkXYfyrKqJ5k2u1wCgo0oQ
0BYyAl8y5rBzgh1dBczJKpY=
=icdF
-----END PGP SIGNATURE-----




From kevin.m.turner@pobox.com Thu Jul 14 21:48:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 21:48:47 +0100 (BST)
Received: from orb.pobox.com ([IPv6:::ffff:207.8.226.5]:8630 "EHLO
	orb.pobox.com") by linux-mips.org with ESMTP id <S8226738AbVGNUsY>;
	Thu, 14 Jul 2005 21:48:24 +0100
Received: from orb (localhost [127.0.0.1])
	by orb.pobox.com (Postfix) with ESMTP id A1DDA1FB3
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 16:49:26 -0400 (EDT)
Received: from troglodyte.asianpear (c-24-21-141-200.hsd1.or.comcast.net [24.21.141.200])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 4603287
	for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 16:49:26 -0400 (EDT)
Subject: Re: What is the current USB support status on DB1550?
From:	Kevin Turner <kevin.m.turner@pobox.com>
To:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121356192.4797.362.camel@localhost.localdomain>
References: <2db32b7205071408327b005e4e@mail.gmail.com>
	 <1121356192.4797.362.camel@localhost.localdomain>
Content-Type: text/plain
Date:	Thu, 14 Jul 2005 13:49:34 -0700
Message-Id: <1121374174.30104.7.camel@troglodyte.asianpear>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 
Content-Transfer-Encoding: 7bit
Return-Path: <kevin.m.turner@pobox.com>
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: 8493
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: kevin.m.turner@pobox.com
Precedence: bulk
X-list: linux-mips
Content-Length: 462
Lines: 16

On Thu, 2005-07-14 at 08:49 -0700, Pete Popov wrote:
> Host only. We couldn't make gadget work due to interrupt latency
> requirements by the HW that couldn't be reliably achieved with Linux.
> But gadget does work on the Au1200.

Is the Au1500 in the same boat as the DB1550?  Do the hardware
requirements apply to all boards with that SOC, or is it somewhat
board-dependent?

Thanks,

 - Kevin

-- 
The moon is first quarter, 49.5% illuminated, 7.3 days old.


From ppopov@embeddedalley.com Thu Jul 14 22:21:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 22:21:49 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:24991
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226740AbVGNVVa>; Thu, 14 Jul 2005 22:21:30 +0100
Received: (qmail 26680 invoked from network); 14 Jul 2005 21:22:44 -0000
Received: from unknown (HELO ?192.168.1.101?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 14 Jul 2005 21:22:44 -0000
Subject: Re: What is the current USB support status on DB1550?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Kevin Turner <kevin.m.turner@pobox.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121374174.30104.7.camel@troglodyte.asianpear>
References: <2db32b7205071408327b005e4e@mail.gmail.com>
	 <1121356192.4797.362.camel@localhost.localdomain>
	 <1121374174.30104.7.camel@troglodyte.asianpear>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Thu, 14 Jul 2005 14:22:50 -0700
Message-Id: <1121376170.16115.30.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8494
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: 757
Lines: 21

On Thu, 2005-07-14 at 13:49 -0700, Kevin Turner wrote:
> On Thu, 2005-07-14 at 08:49 -0700, Pete Popov wrote:
> > Host only. We couldn't make gadget work due to interrupt latency
> > requirements by the HW that couldn't be reliably achieved with Linux.
> > But gadget does work on the Au1200.
> 
> Is the Au1500 in the same boat as the DB1550? 

The Db1550 is the reference board for the Au1550.

>  Do the hardware
> requirements apply to all boards with that SOC, or is it somewhat
> board-dependent?

All boards with the 1100, 1500, or 1550. The Au1200 gadget works, but
the usb controller on the SOC is different. We've made the other CPUs
work before but it was on top of RTLinux, different/proprietary usb
stack, and a lot of debug and tuning.

Pete


From rolfliu@gmail.com Thu Jul 14 22:51:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Jul 2005 22:51:59 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.207]:50337 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226701AbVGNVvl> convert rfc822-to-8bit;
	Thu, 14 Jul 2005 22:51:41 +0100
Received: by wproxy.gmail.com with SMTP id i31so517684wra
        for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 14:52:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RXh5j+AVqALvdq7KFNo0ZcerD/L/HnrL2fOH2F+WtZ9xRYV0LsJ2jXiRQZckpMB/8zcq5E4Oud9svfeOdc0wug1Om5tl8rPXbNMzJG9S7ijUZ0OozKRzl/c7fWOSUxz8kwGRqB3kga6oaInp6Ab2qkH+q3GJvBjVaYVsag18fQQ=
Received: by 10.54.106.13 with SMTP id e13mr906168wrc;
        Thu, 14 Jul 2005 14:52:50 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Thu, 14 Jul 2005 14:52:50 -0700 (PDT)
Message-ID: <2db32b720507141452df44769@mail.gmail.com>
Date:	Thu, 14 Jul 2005 14:52:50 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	ppopov@embeddedalley.com
Subject: Re: What is the current USB support status on DB1550?
Cc:	Kevin Turner <kevin.m.turner@pobox.com>,
	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121376170.16115.30.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <2db32b7205071408327b005e4e@mail.gmail.com>
	 <1121356192.4797.362.camel@localhost.localdomain>
	 <1121374174.30104.7.camel@troglodyte.asianpear>
	 <1121376170.16115.30.camel@localhost.localdomain>
Return-Path: <rolfliu@gmail.com>
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: 8495
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1904
Lines: 61

The drive is identified in the file "devices".
Pete,
I can't get my netac flash drive working on db1550. Could you tell me
what went wrong?

I mount the usbfs as "mount none /proc/bus/usb  -t usbfs".
In /proc/bus/usb, I don't see "drivers", only "001" and "devices".

Under /proc/scsc/usb-storage, there is file "0", which gives the
information for this drive:
Host scsi0: usb-storage
Vendor: Netac
Product: OnlyDisk
Serial number: None
Protocol: Transparent SCSI
Transport: Bulk

The output from usb-storage debug keeps showing
"Bad target number", since the device->id is not 0 and the flags is 0.
Any suggestion on this part? 

...
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (1:0)
usb-storage: scsi cmd done, result=0x40000
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Bad target number (2:0)
usb-storage: scsi cmd done, result=0x40000
...

Thanks


On 7/14/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Thu, 2005-07-14 at 13:49 -0700, Kevin Turner wrote:
> > On Thu, 2005-07-14 at 08:49 -0700, Pete Popov wrote:
> > > Host only. We couldn't make gadget work due to interrupt latency
> > > requirements by the HW that couldn't be reliably achieved with Linux.
> > > But gadget does work on the Au1200.
> >
> > Is the Au1500 in the same boat as the DB1550?
> 
> The Db1550 is the reference board for the Au1550.
> 
> >  Do the hardware
> > requirements apply to all boards with that SOC, or is it somewhat
> > board-dependent?
> 
> All boards with the 1100, 1500, or 1550. The Au1200 gadget works, but
> the usb controller on the SOC is different. We've made the other CPUs
> work before but it was on top of RTLinux, different/proprietary usb
> stack, and a lot of debug and tuning.
> 
> Pete
> 
> 
>

From clem.taylor@gmail.com Fri Jul 15 01:12:19 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 01:12:38 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.204]:7695 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226701AbVGOAMT> convert rfc822-to-8bit;
	Fri, 15 Jul 2005 01:12:19 +0100
Received: by wproxy.gmail.com with SMTP id i28so535761wra
        for <linux-mips@linux-mips.org>; Thu, 14 Jul 2005 17:13:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=X0dT8E0K9DjW6Sj349p+wvfAfvc/iGxZN2CtO1kksKh7okaZK3Duci5gVv7xcwV0B1x8ipKXVkMIyt/kfpA7Y3GO2HnUoGwSxGNnVt7ydLTvBKy+IBBguTHgvIQjeWyVYUmRyAtYYWpWvGN7uL+JvsiZxGpSSIqB4F+C8uOlg2A=
Received: by 10.54.98.8 with SMTP id v8mr847978wrb;
        Thu, 14 Jul 2005 17:13:29 -0700 (PDT)
Received: by 10.54.41.29 with HTTP; Thu, 14 Jul 2005 17:13:29 -0700 (PDT)
Message-ID: <ecb4efd1050714171318ce81aa@mail.gmail.com>
Date:	Thu, 14 Jul 2005 20:13:29 -0400
From:	Clem Taylor <clem.taylor@gmail.com>
Reply-To: Clem Taylor <clem.taylor@gmail.com>
To:	"jaypee@hotpop.com" <jaypee@hotpop.com>
Subject: Re: Au1550 ethernet throughput low
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <1121354144l.5178l.2l@cavan>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <1121270402l.7656l.3l@cavan>
	 <1121353347.10582.3.camel@orionlinux.starfleet.com>
	 <1121354144l.5178l.2l@cavan>
Return-Path: <clem.taylor@gmail.com>
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: 8496
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: clem.taylor@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1734
Lines: 37

On 7/14/05, jaypee@hotpop.com <jaypee@hotpop.com> wrote:
> Clem you said were using 2.6.11 was that a kernel.org kernel or one
> from linux-mips.org?

The source I'm using originated from http://www.linux-mips.org/. It
was checked out from the head of
':pserver:cvs@ftp.linux-mips.org:/home/cvs' on 2005.03.18. At the time
of checkout, the linux-mips tree was missing a 2.6.11 tag. The closest
tag was linux_2_6_11_rc5, but the code is 2.6.11.

I'm thinking about switching to 2.6.12 next week so I can get PCI
shutdown support.

> Clem sent me the output of a test. In which he is getting 11MBs
> I'm assuming the B is bytes in which case that is as near line rate as dammit.

Yeah, UDP is running at near line rate, but it does consume a bunch of
CPU. I'm running our 1550s at 492MHz, but I have to run the memory at
123MHz (DDR). I just ran the test again, here's what ttcp said:

udp recv on au1550
ttcp -u -r -s -n 16384 -l 32768 -A 32768 -v -b 262144 -f M
ttcp-r: buflen=32768, nbuf=16384, align=32768/0, port=5001,
sockbufsize=262144  udp
ttcp-r: 536608768 bytes in 44.72 real seconds = 11.44 MB/sec +++
ttcp-r: 536608768 bytes in 17.41 CPU seconds = 29.39 MB/cpu sec
ttcp-r: 16378 I/O calls, msec/call = 2.80, calls/sec = 366.21
ttcp-r: 0.1user 17.2sys 0:44real 38% 0i+0d 0maxrss 0+7pf 16344+13csw

udp xmit on au1550
ttcp -u -t -n 16384 -s -l 32768 -A 32768 -v -b 262144 -f M  gort
ttcp-t: buflen=32768, nbuf=16384, align=32768/0, port=5001,
sockbufsize=262144  udp
ttcp-t: 536870912 bytes in 44.76 real seconds = 11.44 MB/sec +++
ttcp-t: 536870912 bytes in 15.26 CPU seconds = 33.56 MB/cpu sec
ttcp-t: 16390 I/O calls, msec/call = 2.80, calls/sec = 366.14
ttcp-t: 0.1user 15.1sys 0:44real 34% 0i+0d 0maxrss 0+8pf 3272+10csw

From jaypee@hotpop.com Fri Jul 15 09:20:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 09:21:00 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:21679 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226643AbVGOIUn> convert rfc822-to-8bit; Fri, 15 Jul 2005 09:20:43 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id 2179014242C8
	for <linux-mips@linux-mips.org>; Fri, 15 Jul 2005 08:21:48 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-3.hotpop.com (Postfix) with ESMTP
	id 3A83A16DB4A2; Fri, 15 Jul 2005 08:21:43 +0000 (UTC)
Date:	Fri, 15 Jul 2005 08:21:38 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	Clem Taylor <clem.taylor@gmail.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
References: <1121270402l.7656l.3l@cavan>
	<1121353347.10582.3.camel@orionlinux.starfleet.com>
	<1121354144l.5178l.2l@cavan> <ecb4efd1050714171318ce81aa@mail.gmail.com>
In-Reply-To: <ecb4efd1050714171318ce81aa@mail.gmail.com> (from
	clem.taylor@gmail.com on Fri Jul 15 01:13:29 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121415711l.5178l.3l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8497
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: 1757
Lines: 55

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15/07/05 01:13:29, Clem Taylor wrote:
> The source I'm using originated from http://www.linux-mips.org/. It
> was checked out from the head of
> ':pserver:cvs@ftp.linux-mips.org:/home/cvs' on 2005.03.18. At the time
> of checkout, the linux-mips tree was missing a 2.6.11 tag. The closest
> tag was linux_2_6_11_rc5, but the code is 2.6.11.

Mine was checked out at the latest was 2.6.11 rc3.

> Yeah, UDP is running at near line rate, but it does consume a bunch of
> CPU. I'm running our 1550s at 492MHz, but I have to run the memory at
> 123MHz (DDR). I just ran the test again, here's what ttcp said:
> 

Same here expect memory is at 166

> udp recv on au1550
> ttcp -u -r -s -n 16384 -l 32768 -A 32768 -v -b 262144 -f M
> ttcp-r: buflen=32768, nbuf=16384, align=32768/0, port=5001,
> sockbufsize=262144  udp
> ttcp-r: 536608768 bytes in 44.72 real seconds = 11.44 MB/sec +++
> ttcp-r: 536608768 bytes in 17.41 CPU seconds = 29.39 MB/cpu sec
> ttcp-r: 16378 I/O calls, msec/call = 2.80, calls/sec = 366.21
> ttcp-r: 0.1user 17.2sys 0:44real 38% 0i+0d 0maxrss 0+7pf 16344+13csw
> 

That looks ok though (Well it would be good enough for my application).

Yours is using ~30% cpu to send 100Mbps.
Mine is using 100% to send 66Mbps.

I've just checked out and  merged the latest CVS.
There were a few compile problems but I'll iron them out today and see  
if that solves the problem. It is encouraging that someone has this
working though.

Thanks again

- -- 
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC13IfZDxnKy3oOpYRAtrpAKDXFwbVpxD0c4g6aWvknTrzYddLMQCdFmvP
m8mDpiQYKerMjxJr9YhH/lg=
=qDeX
-----END PGP SIGNATURE-----




From bruno.randolf@4g-systems.biz Fri Jul 15 10:17:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 10:18:21 +0100 (BST)
Received: from grey.subnet.at ([IPv6:::ffff:193.170.141.20]:58897 "EHLO
	grey.subnet.at") by linux-mips.org with ESMTP id <S8226646AbVGOJR4>;
	Fri, 15 Jul 2005 10:17:56 +0100
Received: from ip6-localhost ([193.170.141.4]) by grey.subnet.at ; Fri, 15 Jul 2005 11:19:07 +0200
From:	Bruno Randolf <bruno.randolf@4g-systems.biz>
To:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
Date:	Fri, 15 Jul 2005 11:17:44 +0200
User-Agent: KMail/1.8.1
Cc:	Clem Taylor <clem.taylor@gmail.com>,
	linux-mips <linux-mips@linux-mips.org>
References: <1121270402l.7656l.3l@cavan> <ecb4efd1050714171318ce81aa@mail.gmail.com> <1121415711l.5178l.3l@cavan>
In-Reply-To: <1121415711l.5178l.3l@cavan>
Organization: 4G Systems
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart2206017.K2ni6TNPXm";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200507151117.49012.bruno.randolf@4g-systems.biz>
Return-Path: <bruno.randolf@4g-systems.biz>
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: 8498
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: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips
Content-Length: 741
Lines: 28

--nextPart2206017.K2ni6TNPXm
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 15 July 2005 10:21, jaypee@hotpop.com wrote:
> Yours is using ~30% cpu to send 100Mbps.
> Mine is using 100% to send 66Mbps.

i remember that ethernet thruput dropped from nearly 100Mbps to about=20
60-70Mbps on our Au1500 based board, when we enabled CONFIG_NONCOHERENT_IO.=
=2E.

bruno

--nextPart2206017.K2ni6TNPXm
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBC1388fg2jtUL97G4RAiD2AKCvT11QQLax1XXT5olChEol3raS1QCfU8WT
AjB/tuW/zyzA28M9LA+ovEQ=
=F5l0
-----END PGP SIGNATURE-----

--nextPart2206017.K2ni6TNPXm--

From mad@automagically.de Fri Jul 15 11:59:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 11:59:32 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.183]:16834
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226652AbVGOK7N>; Fri, 15 Jul 2005 11:59:13 +0100
Received: from pD95299FB.dip0.t-ipconnect.de [217.82.153.251] (helo=gaspode.madsworld.lan)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0MKxQS-1DtNvg3WSE-00066d; Fri, 15 Jul 2005 13:00:28 +0200
Received: from mad by gaspode.madsworld.lan with local (Exim 4.50)
	id 1DtNvZ-00046Z-Qy; Fri, 15 Jul 2005 13:00:21 +0200
Date:	Fri, 15 Jul 2005 13:00:21 +0200
From:	Markus Dahms <mad@automagically.de>
To:	Mikael Nousiainen <turja@mbnet.fi>
Cc:	linux-mips@linux-mips.org
Subject: Re: New VINO video drivers for Indy
Message-ID: <20050715110021.GA15740@gaspode.automagically.de>
References: <42D4BF49.4040907@mbnet.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42D4BF49.4040907@mbnet.fi>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:896705dcda322f33ae3752a7fdb3dc09
Return-Path: <mad@automagically.de>
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: 8499
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: mad@automagically.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1255
Lines: 40

Hello Mikael,

> I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).

That's what I've already waited for. Slowly 2.6.x should get usable for
SGI machines :).

> Please test the driver and report the results so that bugs
> (yes, I can promise there are lots of them :) can be squashed.

I only get a bla[nc]k image using the patched camsource or xawtv from
from Debian Sarge with my IndyCam[1] :(. With the old driver for
2.4.x I got some more results (striped, but at least an image...).
I hope you could give me some hints where to start debugging...

| SGI VINO driver version 0.0.1
| VINO with chip ID 11, revision 0 found
| Philips SAA7191 driver version 0.0.1
| SAA7191 initialized
| SGI IndyCam driver version 0.0.1
| IndyCam v1.0 detected
| IndyCam initialized

What I noticed, too:

* you should really include a directory in your package, I (most people?)
  did 'cd src/; tar zxvf vino-0.0.1.tar.gz' and screwed up my source
  directory a bit.
* (not so important) I cross-compile all kernel-related stuff. Although
  'make -C $MIPSKERNELDIR SUBDIRS=`pwd`' is not as difficult, there
  COULD be support for cross-compiling in the Makefile.

Markus

[1] yes, I opened the cover ;). channel was correct, too.

> 
> 
> 
> 

From bootsy_4mt@yahoo.com Fri Jul 15 13:26:13 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 13:26:34 +0100 (BST)
Received: from web33712.mail.mud.yahoo.com ([IPv6:::ffff:68.142.201.209]:37041
	"HELO web33712.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8226652AbVGOM0N>; Fri, 15 Jul 2005 13:26:13 +0100
Received: (qmail 60447 invoked by uid 60001); 15 Jul 2005 12:27:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=b92fbGV9oXgi9aeVElgErdeRpFCr02JR3s19tncUqrmoOVhPI7djtdpEJVQd4bB/TCE9/NPgrDGpKfj2uEGAopg8PGx1adnmTkOZuBNzf8VnAxam9uSwbi5VG4QdkbgB60193EK7f2f8L6LhdyqpNS2kmWLfPS9hlYMvLXST2MI=  ;
Message-ID: <20050715122723.60445.qmail@web33712.mail.mud.yahoo.com>
Received: from [212.108.17.165] by web33712.mail.mud.yahoo.com via HTTP; Fri, 15 Jul 2005 13:27:22 BST
Date:	Fri, 15 Jul 2005 13:27:22 +0100 (BST)
From:	Martin Nichols <bootsy_4mt@yahoo.com>
Subject: U-Boot on DbAu1100
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <bootsy_4mt@yahoo.com>
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: 8500
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: bootsy_4mt@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 341
Lines: 16

Hi,

Has anyone got U-Boot 1.1.2 working little endian on
the DbAu1100 board. If so what toolchain version did
you use to build it?

Thanks and regards,

Martin.


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

From Frances@mylaeus.ch Fri Jul 15 15:27:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 15:27:38 +0100 (BST)
Received: from chello084010225018.chello.pl ([IPv6:::ffff:84.10.225.18]:64522
	"HELO chello084010225018.chello.pl") by linux-mips.org with SMTP
	id <S8226683AbVGOO1U>; Fri, 15 Jul 2005 15:27:20 +0100
Received: from [191.203.143.72] (port=4399 helo=[sideband])
    by chello084010225018.chello.pl with esmtp 
    id 97970013threader109071
    for linux-mips@linux-mips.org; Fri, 15 Jul 2005 16:29:44 +0200
Mime-Version: 1.0 (Apple Message framework v728)
Content-Transfer-Encoding: 7bit
Message-Id: <370529554.58507119875@chello084010225018.chello.pl>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To:	linux-mips@linux-mips.org
From:	Pauline <Frances@mylaeus.ch>
Subject: Back To Happy And Healthy Life . . .
Date:	Fri, 15 Jul 2005 16:29:43 +0200
X-Mailer: Apple Mail (2.728)
Return-Path: <Frances@mylaeus.ch>
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: 8501
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: Frances@mylaeus.ch
Precedence: bulk
X-list: linux-mips
Content-Length: 275
Lines: 11

Want to make women adore you? Click here.
http://bgfky.n28gro5gkfnd96n.sottedbbfhm.com



The discipline of desire is the background of character.    
If you are not criticized, you may not be doing much.  
A poet more than thirty years old is simply an overgrown child. 




From yuasa@hh.iij4u.or.jp Fri Jul 15 16:15:07 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 16:15:23 +0100 (BST)
Received: from mo00.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:12738 "EHLO
	mo00.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226727AbVGOPPH>;
	Fri, 15 Jul 2005 16:15:07 +0100
Received: MO(mo00)id j6FFGOjJ015281; Sat, 16 Jul 2005 00:16:24 +0900 (JST)
Received: MDO(mdo00) id j6FFGN5T010835; Sat, 16 Jul 2005 00:16:24 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox00) id j6FFGM4Z002435
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sat, 16 Jul 2005 00:16:23 +0900 (JST)
Date:	Sat, 16 Jul 2005 00:16:21 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	ppopov@linux-mips.org
Cc:	yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-Id: <20050716001621.6d9d607a.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20050714174806Z8226711-3678+3079@linux-mips.org>
References: <20050714174806Z8226711-3678+3079@linux-mips.org>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8502
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 6111
Lines: 171

Hi Pete,

On Thu, 14 Jul 2005 18:48:00 +0100
ppopov@linux-mips.org wrote:

> 
> Log message:
> 	Philips PNX8550 support: MIPS32-like core with 2 Trimedias on it.

I think the following include path is better.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c a/arch/mips/philips/pnx8550/common/gdb_hook.c
--- a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/gdb_hook.c	2005-07-15 23:44:03.361056952 +0900
@@ -31,7 +31,7 @@
 #include <asm/serial.h>
 #include <asm/io.h>
 
-#include <asm/mach-pnx8550/uart.h>
+#include <uart.h>
 
 static struct serial_state rs_table[RS_TABLE_SIZE] = {
 	SERIAL_PORT_DFNS	/* Defined in serial.h */
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/int.c a/arch/mips/philips/pnx8550/common/int.c
--- a-orig/arch/mips/philips/pnx8550/common/int.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/int.c	2005-07-15 23:44:32.008701848 +0900
@@ -35,8 +35,8 @@
 
 #include <asm/io.h>
 #include <asm/gdb-stub.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <uart.h>
 
 extern asmlinkage void cp0_irqdispatch(void);
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/pci.c a/arch/mips/philips/pnx8550/common/pci.c
--- a-orig/arch/mips/philips/pnx8550/common/pci.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/pci.c	2005-07-15 23:44:52.444595120 +0900
@@ -24,9 +24,9 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 
-#include <asm/mach-pnx8550/pci.h>
-#include <asm/mach-pnx8550/glb.h>
-#include <asm/mach-pnx8550/nand.h>
+#include <pci.h>
+#include <glb.h>
+#include <nand.h>
 
 static struct resource pci_io_resource = {
 	"pci IO space",
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/platform.c a/arch/mips/philips/pnx8550/common/platform.c
--- a-orig/arch/mips/philips/pnx8550/common/platform.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/platform.c	2005-07-15 23:45:16.826888448 +0900
@@ -17,9 +17,9 @@
 #include <linux/init.h>
 #include <linux/resource.h>
 
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/usb.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <usb.h>
+#include <uart.h>
 
 static struct resource pnx8550_usb_ohci_resources[] = {
 	[0] = {
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/proc.c a/arch/mips/philips/pnx8550/common/proc.c
--- a-orig/arch/mips/philips/pnx8550/common/proc.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/proc.c	2005-07-15 23:45:33.076418144 +0900
@@ -24,8 +24,8 @@
 
 #include <asm/io.h>
 #include <asm/gdb-stub.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <uart.h>
 
 
 static int pnx8550_timers_read (char* page, char** start, off_t offset, int count, int* eof, void* data)
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/prom.c a/arch/mips/philips/pnx8550/common/prom.c
--- a-orig/arch/mips/philips/pnx8550/common/prom.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/prom.c	2005-07-15 23:45:44.729646584 +0900
@@ -15,7 +15,7 @@
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <uart.h>
 
 /* #define DEBUG_CMDLINE */
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/reset.c a/arch/mips/philips/pnx8550/common/reset.c
--- a-orig/arch/mips/philips/pnx8550/common/reset.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/reset.c	2005-07-15 23:45:55.884950720 +0900
@@ -23,7 +23,7 @@
 #include <linux/config.h>
 #include <linux/slab.h>
 #include <asm/reboot.h>
-#include <asm/mach-pnx8550/glb.h>
+#include <glb.h>
 
 void pnx8550_machine_restart(char *command)
 {
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/setup.c a/arch/mips/philips/pnx8550/common/setup.c
--- a-orig/arch/mips/philips/pnx8550/common/setup.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/setup.c	2005-07-15 23:43:38.693806944 +0900
@@ -33,11 +33,11 @@
 #include <asm/pgtable.h>
 #include <asm/time.h>
 
-#include <asm/mach-pnx8550/glb.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/pci.h>
-#include <asm/mach-pnx8550/uart.h>
-#include <asm/mach-pnx8550/nand.h>
+#include <glb.h>
+#include <int.h>
+#include <pci.h>
+#include <uart.h>
+#include <nand.h>
 
 extern void prom_printf(char *fmt, ...);
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/time.c a/arch/mips/philips/pnx8550/common/time.c
--- a-orig/arch/mips/philips/pnx8550/common/time.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/time.c	2005-07-15 23:46:11.606560672 +0900
@@ -31,8 +31,8 @@
 #include <asm/div64.h>
 #include <asm/debug.h>
 
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/cm.h>
+#include <int.h>
+#include <cm.h>
 
 extern unsigned int mips_hpt_frequency;
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c a/arch/mips/philips/pnx8550/jbs/board_setup.c
--- a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c	2005-07-15 02:47:59.000000000 +0900
+++ a/arch/mips/philips/pnx8550/jbs/board_setup.c	2005-07-15 23:46:28.102052976 +0900
@@ -39,7 +39,7 @@
 #include <asm/reboot.h>
 #include <asm/pgtable.h>
 
-#include <asm/mach-pnx8550/glb.h>
+#include <glb.h>
 
 /* CP0 hazard avoidance. */
 #define BARRIER __asm__ __volatile__(".set noreorder\n\t" \
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/jbs/irqmap.c a/arch/mips/philips/pnx8550/jbs/irqmap.c
--- a-orig/arch/mips/philips/pnx8550/jbs/irqmap.c	2005-07-15 02:47:59.000000000 +0900
+++ a/arch/mips/philips/pnx8550/jbs/irqmap.c	2005-07-15 23:46:38.463477800 +0900
@@ -26,7 +26,7 @@
  */
 
 #include <linux/init.h>
-#include <asm/mach-pnx8550/int.h>
+#include <int.h>
 
 char irq_tab_jbs[][5] __initdata = {
  [8] =	{ -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff},



From yuasa@hh.iij4u.or.jp Fri Jul 15 16:18:39 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 16:18:56 +0100 (BST)
Received: from mo01.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:21744 "EHLO
	mo01.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226727AbVGOPSj>;
	Fri, 15 Jul 2005 16:18:39 +0100
Received: MO(mo01)id j6FFJuoL000447; Sat, 16 Jul 2005 00:19:56 +0900 (JST)
Received: MDO(mdo00) id j6FFJugF010902; Sat, 16 Jul 2005 00:19:56 +0900 (JST)
Received: from stratos (h086.p498.iij4u.or.jp [210.149.242.86])
	by mbox.iij4u.or.jp (4U-MR/mbox01) id j6FFJtKQ013579
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Sat, 16 Jul 2005 00:19:55 +0900 (JST)
Date:	Sat, 16 Jul 2005 00:19:53 +0900
From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To:	Ralf Baechle <ralf@linux-mips.org>
Cc:	yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH 2.6] vr41xx: remove obsolete GIU driver
Message-Id: <20050716001953.7c5e7568.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 8503
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 10813
Lines: 402

Hi Ralf,

This patch has removed obsolete GIU driver for vr41xx.
Please apply this patch.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig
--- a-orig/arch/mips/vr41xx/Kconfig	2005-07-12 01:04:41.874172000 +0900
+++ a/arch/mips/vr41xx/Kconfig	2005-07-15 00:54:46.087700888 +0900
@@ -90,10 +90,6 @@
 	bool "Add PCI control unit support of NEC VR4100 series"
 	depends on MACH_VR41XX && PCI
 
-config GPIO_VR41XX
-	tristate "Add General-purpose I/O unit support of NEC VR4100 series"
-	depends on MACH_VR41XX
-
 config VRC4173
 	tristate "Add NEC VRC4173 companion chip support"
 	depends on MACH_VR41XX && PCI_VR41XX
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/Makefile a/arch/mips/vr41xx/common/Makefile
--- a-orig/arch/mips/vr41xx/common/Makefile	2005-06-02 23:33:02.000000000 +0900
+++ a/arch/mips/vr41xx/common/Makefile	2005-07-15 00:54:10.118169088 +0900
@@ -3,7 +3,6 @@
 #
 
 obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o irq.o pmu.o
-obj-$(CONFIG_GPIO_VR41XX)	+= giu.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/giu.c a/arch/mips/vr41xx/common/giu.c
--- a-orig/arch/mips/vr41xx/common/giu.c	2005-06-02 23:33:02.000000000 +0900
+++ a/arch/mips/vr41xx/common/giu.c	1970-01-01 09:00:00.000000000 +0900
@@ -1,363 +0,0 @@
-/*
- *  giu.c, General-purpose I/O Unit Interrupt routines for NEC VR4100 series.
- *
- *  Copyright (C) 2002 MontaVista Software Inc.
- *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
- *  Copyright (C) 2003-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
- *
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  - Added support for NEC VR4133.
- *  - Removed board_irq_init.
- */
-#include <linux/errno.h>
-#include <linux/init.h>
-#include <linux/irq.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/smp.h>
-#include <linux/types.h>
-
-#include <asm/cpu.h>
-#include <asm/io.h>
-#include <asm/vr41xx/vr41xx.h>
-
-#define GIUIOSELL_TYPE1	KSEG1ADDR(0x0b000100)
-#define GIUIOSELL_TYPE2	KSEG1ADDR(0x0f000140)
-
-#define GIUIOSELL	0x00
-#define GIUIOSELH	0x02
-#define GIUINTSTATL	0x08
-#define GIUINTSTATH	0x0a
-#define GIUINTENL	0x0c
-#define GIUINTENH	0x0e
-#define GIUINTTYPL	0x10
-#define GIUINTTYPH	0x12
-#define GIUINTALSELL	0x14
-#define GIUINTALSELH	0x16
-#define GIUINTHTSELL	0x18
-#define GIUINTHTSELH	0x1a
-#define GIUFEDGEINHL	0x20
-#define GIUFEDGEINHH	0x22
-#define GIUREDGEINHL	0x24
-#define GIUREDGEINHH	0x26
-
-static uint32_t giu_base;
-
-#define read_giuint(offset)		readw(giu_base + (offset))
-#define write_giuint(val, offset)	writew((val), giu_base + (offset))
-
-#define GIUINT_HIGH_OFFSET	16
-
-static inline uint16_t set_giuint(uint8_t offset, uint16_t set)
-{
-	uint16_t res;
-
-	res = read_giuint(offset);
-	res |= set;
-	write_giuint(res, offset);
-
-	return res;
-}
-
-static inline uint16_t clear_giuint(uint8_t offset, uint16_t clear)
-{
-	uint16_t res;
-
-	res = read_giuint(offset);
-	res &= ~clear;
-	write_giuint(res, offset);
-
-	return res;
-}
-
-static unsigned int startup_giuint_low_irq(unsigned int irq)
-{
-	unsigned int pin;
-
-	pin = GIU_IRQ_TO_PIN(irq);
-	write_giuint((uint16_t)1 << pin, GIUINTSTATL);
-	set_giuint(GIUINTENL, (uint16_t)1 << pin);
-
-	return 0;
-}
-
-static void shutdown_giuint_low_irq(unsigned int irq)
-{
-	clear_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-static void enable_giuint_low_irq(unsigned int irq)
-{
-	set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-#define disable_giuint_low_irq	shutdown_giuint_low_irq
-
-static void ack_giuint_low_irq(unsigned int irq)
-{
-	unsigned int pin;
-
-	pin = GIU_IRQ_TO_PIN(irq);
-	clear_giuint(GIUINTENL, (uint16_t)1 << pin);
-	write_giuint((uint16_t)1 << pin, GIUINTSTATL);
-}
-
-static void end_giuint_low_irq(unsigned int irq)
-{
-	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-static struct hw_interrupt_type giuint_low_irq_type = {
-	.typename	= "GIUINTL",
-	.startup	= startup_giuint_low_irq,
-	.shutdown	= shutdown_giuint_low_irq,
-	.enable		= enable_giuint_low_irq,
-	.disable	= disable_giuint_low_irq,
-	.ack		= ack_giuint_low_irq,
-	.end		= end_giuint_low_irq,
-};
-
-static unsigned int startup_giuint_high_irq(unsigned int irq)
-{
-	unsigned int pin;
-
-	pin = GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET);
-	write_giuint((uint16_t)1 << pin, GIUINTSTATH);
-	set_giuint(GIUINTENH, (uint16_t)1 << pin);
-
-	return 0;
-}
-
-static void shutdown_giuint_high_irq(unsigned int irq)
-{
-	clear_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET));
-}
-
-static void enable_giuint_high_irq(unsigned int irq)
-{
-	set_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET));
-}
-
-#define disable_giuint_high_irq	shutdown_giuint_high_irq
-
-static void ack_giuint_high_irq(unsigned int irq)
-{
-	unsigned int pin;
-
-	pin = GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET);
-	clear_giuint(GIUINTENH, (uint16_t)1 << pin);
-	write_giuint((uint16_t)1 << pin, GIUINTSTATH);
-}
-
-static void end_giuint_high_irq(unsigned int irq)
-{
-	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		set_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET));
-}
-
-static struct hw_interrupt_type giuint_high_irq_type = {
-	.typename	= "GIUINTH",
-	.startup	= startup_giuint_high_irq,
-	.shutdown	= shutdown_giuint_high_irq,
-	.enable		= enable_giuint_high_irq,
-	.disable	= disable_giuint_high_irq,
-	.ack		= ack_giuint_high_irq,
-	.end		= end_giuint_high_irq,
-};
-
-void vr41xx_enable_giuint(unsigned int pin)
-{
-	if (pin < GIUINT_HIGH_OFFSET)
-		enable_giuint_low_irq(GIU_IRQ(pin));
-	else
-		enable_giuint_high_irq(GIU_IRQ(pin));
-}
-
-void vr41xx_disable_giuint(unsigned int pin)
-{
-	if (pin < GIUINT_HIGH_OFFSET)
-		disable_giuint_low_irq(GIU_IRQ(pin));
-	else
-		disable_giuint_high_irq(GIU_IRQ(pin));
-}
-
-void vr41xx_set_irq_trigger(int pin, int trigger, int hold)
-{
-	uint16_t mask;
-
-	if (pin < GIUINT_HIGH_OFFSET) {
-		mask = (uint16_t)1 << pin;
-		if (trigger != TRIGGER_LEVEL) {
-        		set_giuint(GIUINTTYPL, mask);
-			if (hold == SIGNAL_HOLD)
-				set_giuint(GIUINTHTSELL, mask);
-			else
-				clear_giuint(GIUINTHTSELL, mask);
-			if (current_cpu_data.cputype == CPU_VR4133) {
-				switch (trigger) {
-				case TRIGGER_EDGE_FALLING:
-					set_giuint(GIUFEDGEINHL, mask);
-					clear_giuint(GIUREDGEINHL, mask);
-					break;
-				case TRIGGER_EDGE_RISING:
-					clear_giuint(GIUFEDGEINHL, mask);
-					set_giuint(GIUREDGEINHL, mask);
-					break;
-				default:
-					set_giuint(GIUFEDGEINHL, mask);
-					set_giuint(GIUREDGEINHL, mask);
-					break;
-				}
-			}
-		} else {
-			clear_giuint(GIUINTTYPL, mask);
-			clear_giuint(GIUINTHTSELL, mask);
-		}
-		write_giuint(mask, GIUINTSTATL);
-	} else {
-		mask = (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET);
-		if (trigger != TRIGGER_LEVEL) {
-			set_giuint(GIUINTTYPH, mask);
-			if (hold == SIGNAL_HOLD)
-				set_giuint(GIUINTHTSELH, mask);
-			else
-				clear_giuint(GIUINTHTSELH, mask);
-			if (current_cpu_data.cputype == CPU_VR4133) {
-				switch (trigger) {
-				case TRIGGER_EDGE_FALLING:
-					set_giuint(GIUFEDGEINHH, mask);
-					clear_giuint(GIUREDGEINHH, mask);
-					break;
-				case TRIGGER_EDGE_RISING:
-					clear_giuint(GIUFEDGEINHH, mask);
-					set_giuint(GIUREDGEINHH, mask);
-					break;
-				default:
-					set_giuint(GIUFEDGEINHH, mask);
-					set_giuint(GIUREDGEINHH, mask);
-					break;
-				}
-			}
-		} else {
-			clear_giuint(GIUINTTYPH, mask);
-			clear_giuint(GIUINTHTSELH, mask);
-		}
-		write_giuint(mask, GIUINTSTATH);
-	}
-}
-
-EXPORT_SYMBOL(vr41xx_set_irq_trigger);
-
-void vr41xx_set_irq_level(int pin, int level)
-{
-	uint16_t mask;
-
-	if (pin < GIUINT_HIGH_OFFSET) {
-		mask = (uint16_t)1 << pin;
-		if (level == LEVEL_HIGH)
-			set_giuint(GIUINTALSELL, mask);
-		else
-			clear_giuint(GIUINTALSELL, mask);
-		write_giuint(mask, GIUINTSTATL);
-	} else {
-		mask = (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET);
-		if (level == LEVEL_HIGH)
-			set_giuint(GIUINTALSELH, mask);
-		else
-			clear_giuint(GIUINTALSELH, mask);
-		write_giuint(mask, GIUINTSTATH);
-	}
-}
-
-EXPORT_SYMBOL(vr41xx_set_irq_level);
-
-static int giu_get_irq(unsigned int irq, struct pt_regs *regs)
-{
-	uint16_t pendl, pendh, maskl, maskh;
-	int i;
-
-	pendl = read_giuint(GIUINTSTATL);
-	pendh = read_giuint(GIUINTSTATH);
-	maskl = read_giuint(GIUINTENL);
-	maskh = read_giuint(GIUINTENH);
-
-	maskl &= pendl;
-	maskh &= pendh;
-
-	if (maskl) {
-		for (i = 0; i < 16; i++) {
-			if (maskl & ((uint16_t)1 << i))
-				return GIU_IRQ(i);
-		}
-	} else if (maskh) {
-		for (i = 0; i < 16; i++) {
-			if (maskh & ((uint16_t)1 << i))
-				return GIU_IRQ(i + GIUINT_HIGH_OFFSET);
-		}
-	}
-
-	printk(KERN_ERR "spurious GIU interrupt: %04x(%04x),%04x(%04x)\n",
-	       maskl, pendl, maskh, pendh);
-
-	atomic_inc(&irq_err_count);
-
-	return -1;
-}
-
-static int  __init vr41xx_giu_init(void)
-{
-	int i;
-
-	switch (current_cpu_data.cputype) {
-	case CPU_VR4111:
-	case CPU_VR4121:
-		giu_base = GIUIOSELL_TYPE1;
-		break;
-	case CPU_VR4122:
-	case CPU_VR4131:
-	case CPU_VR4133:
-		giu_base = GIUIOSELL_TYPE2;
-		break;
-	default:
-		printk(KERN_ERR "GIU: Unexpected CPU of NEC VR4100 series\n");
-		return -ENODEV;
-	}
-
-	for (i = 0; i < 32; i++) {
-		if (i < GIUINT_HIGH_OFFSET)
-			clear_giuint(GIUINTENL, (uint16_t)1 << i);
-		else
-			clear_giuint(GIUINTENH, (uint16_t)1 << (i - GIUINT_HIGH_OFFSET));
-	}
-
-	for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) {
-		if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET))
-			irq_desc[i].handler = &giuint_low_irq_type;
-		else
-			irq_desc[i].handler = &giuint_high_irq_type;
-	}
-
-	return cascade_irq(GIUINT_IRQ, giu_get_irq);
-}
-
-postcore_initcall(vr41xx_giu_init);


From ralf@linux-mips.org Fri Jul 15 18:19:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 18:20:16 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:4883 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226749AbVGORT7>; Fri, 15 Jul 2005 18:19:59 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6FHLCSW026100;
	Fri, 15 Jul 2005 18:21:12 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6FHLBOR026099;
	Fri, 15 Jul 2005 18:21:11 +0100
Date:	Fri, 15 Jul 2005 18:21:11 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] vr41xx: remove obsolete GIU driver
Message-ID: <20050715172110.GK2799@linux-mips.org>
References: <20050716001953.7c5e7568.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050716001953.7c5e7568.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8504
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 181
Lines: 8

On Sat, Jul 16, 2005 at 12:19:53AM +0900, Yoichi Yuasa wrote:

> This patch has removed obsolete GIU driver for vr41xx.
> Please apply this patch.

Applied.  Thanks Yoichi,

  Ralf

From ralf@linux-mips.org Fri Jul 15 19:06:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 19:07:04 +0100 (BST)
Received: from extgw-uk.mips.com ([IPv6:::ffff:62.254.210.129]:20491 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226727AbVGOSGp>; Fri, 15 Jul 2005 19:06:45 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6FI7xTx027662;
	Fri, 15 Jul 2005 19:07:59 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6FI7wKZ027661;
	Fri, 15 Jul 2005 19:07:58 +0100
Date:	Fri, 15 Jul 2005 19:07:58 +0100
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc:	ppopov@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Message-ID: <20050715180758.GL2799@linux-mips.org>
References: <20050714174806Z8226711-3678+3079@linux-mips.org> <20050716001621.6d9d607a.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050716001621.6d9d607a.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8505
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1182
Lines: 33

On Sat, Jul 16, 2005 at 12:16:21AM +0900, Yoichi Yuasa wrote:
> Date:	Sat, 16 Jul 2005 00:16:21 +0900
> From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> To:	ppopov@linux-mips.org
> Cc:	yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: text/plain; charset=US-ASCII
> 
> Hi Pete,
> 
> On Thu, 14 Jul 2005 18:48:00 +0100
> ppopov@linux-mips.org wrote:
> 
> > 
> > Log message:
> > 	Philips PNX8550 support: MIPS32-like core with 2 Trimedias on it.
> 
> I think the following include path is better.

>  
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>

What to use really depends on what you want.  I originally created the
mach-* directories to have a place platform-specific header files
instead of infinitely long #ifdef mess.  A buch of -I gcc options are
used to create a search path from the most specific to the most generic
files at the end.  If that's the intend, use the <file.h> form.  If
however the intend is to include a specific file then the prefered
form is <patch/mach-foo/file.h> which avoids the danger of accidently
picking up something else and also is slightly easier for the compiler.

  Ralf

From turja@mbnet.fi Fri Jul 15 22:51:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 22:52:12 +0100 (BST)
Received: from fep17.inet.fi ([IPv6:::ffff:194.251.242.242]:54715 "EHLO
	fep17.inet.fi") by linux-mips.org with ESMTP id <S8226750AbVGOVvz>;
	Fri, 15 Jul 2005 22:51:55 +0100
Received: from [127.0.0.1] ([80.223.109.59]) by fep17.inet.fi with ESMTP
          id <20050715215315.NCXZ26687.fep17.inet.fi@[127.0.0.1]>
          for <linux-mips@linux-mips.org>; Sat, 16 Jul 2005 00:53:15 +0300
Message-ID: <42D83063.3060505@mbnet.fi>
Date:	Sat, 16 Jul 2005 00:53:39 +0300
From:	Mikael Nousiainen <turja@mbnet.fi>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: New VINO video drivers for Indy
References: <42D4BF49.4040907@mbnet.fi> <20050715110021.GA15740@gaspode.automagically.de>
In-Reply-To: <20050715110021.GA15740@gaspode.automagically.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <turja@mbnet.fi>
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: 8506
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: turja@mbnet.fi
Precedence: bulk
X-list: linux-mips
Content-Length: 2373
Lines: 90

Markus Dahms wrote:

>Hello Mikael,
>
>  
>
>>I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).
>>    
>>
>
>That's what I've already waited for. Slowly 2.6.x should get usable for
>SGI machines :).
>
>  
>
>>Please test the driver and report the results so that bugs
>>(yes, I can promise there are lots of them :) can be squashed.
>>    
>>
>
>I only get a bla[nc]k image using the patched camsource or xawtv from
>from Debian Sarge with my IndyCam[1] :(. With the old driver for
>2.4.x I got some more results (striped, but at least an image...).
>I hope you could give me some hints where to start debugging...
>  
>
That's strange. There might be some problems with IndyCam initialization 
(register values),
but usually you should be able to get at least a very dark picture. 
Removing and reinstalling the
module (indycam.ko) reinitializes the camera so you can try that.
IndyCam seems to use some very odd logic to decide how bright the 
picture should be.
Try bringing some very bright light sources near the camera ?

I'm pretty sure the image capture works as it should as I've been doing 
a lot of testing
with IndyCam. Are you sure that the camera is a working one ?

Also note that xawtv isn't really a very usable application to test the 
driver as it doesn't
update listings for video standards and image controls when you change 
the input channel.

>| SGI VINO driver version 0.0.1
>| VINO with chip ID 11, revision 0 found
>| Philips SAA7191 driver version 0.0.1
>| SAA7191 initialized
>| SGI IndyCam driver version 0.0.1
>| IndyCam v1.0 detected
>| IndyCam initialized
>
>What I noticed, too:
>
>* you should really include a directory in your package, I (most people?)
>  did 'cd src/; tar zxvf vino-0.0.1.tar.gz' and screwed up my source
>  directory a bit.
>  
>
Yes, I noticed it was missing and the next release will include one. 
I'll be away (travelling) for
the next 2 weeks so it won't come out sooner than that.

>* (not so important) I cross-compile all kernel-related stuff. Although
>  'make -C $MIPSKERNELDIR SUBDIRS=`pwd`' is not as difficult, there
>  COULD be support for cross-compiling in the Makefile.
>
>  
>
I'm really not an expert with makefiles, but I'll see what I can do...

>Markus
>
>[1] yes, I opened the cover ;). channel was correct, too.
>
>  
>
That's good. :)

>>
>>
>>    
>>
>
>
>
>  
>



From dchau@mazunetworks.com Fri Jul 15 23:20:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 23:20:44 +0100 (BST)
Received: from mail.mazunetworks.com ([IPv6:::ffff:4.19.249.111]:20140 "EHLO
	mail.mazunetworks.com") by linux-mips.org with ESMTP
	id <S8226752AbVGOWU3>; Fri, 15 Jul 2005 23:20:29 +0100
Received: from [172.31.1.134] ([172.31.1.134])
	by mail.mazunetworks.com (8.12.11/8.12.11) with ESMTP id j6FM9Xgq022962
	for <linux-mips@linux-mips.org>; Fri, 15 Jul 2005 18:09:34 -0400
Message-ID: <42D836F8.8030209@mazunetworks.com>
Date:	Fri, 15 Jul 2005 18:21:44 -0400
From:	David Chau <dchau@mazunetworks.com>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Why is mmap()ed reserved memory so slow?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dchau@mazunetworks.com>
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: 8507
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: dchau@mazunetworks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 709
Lines: 17

Hi all,

I'm working on a driver for the Broadcom 1250, and I am using reserved 
memory for some data buffers. The board comes with 256 MB of RAM, so I 
boot Linux with "mem=253M" to reserve some RAM at the top of memory, and 
then mmap() /dev/mem starting at 253 MB.

The problem is that accessing this memory is ridiculously slow. A simple 
benchmark revealed that it takes about 200 cycles to read a 64-bit 
number. If I mmap() /dev/zero instead, a read takes under 3 cycles.

For those of you who knows how the Linux VM works, could you tell me why 
the memory access is so slow? It look like it might be invoking the 
page-fault handler on every read. How can I make memory access faster?

Thanks,
David

From dan@embeddedalley.com Fri Jul 15 23:33:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Jul 2005 23:34:09 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:11270 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226750AbVGOWdu>; Fri, 15 Jul 2005 23:33:50 +0100
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6FMLAmN023670;
	Fri, 15 Jul 2005 18:21:10 -0400
In-Reply-To: <42D836F8.8030209@mazunetworks.com>
References: <42D836F8.8030209@mazunetworks.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <dc678ee4c98d1fc3eb2cb1960b759f05@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: Why is mmap()ed reserved memory so slow?
Date:	Fri, 15 Jul 2005 18:35:11 -0400
To:	David Chau <dchau@mazunetworks.com>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
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: 8508
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@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1024
Lines: 29


On Jul 15, 2005, at 6:21 PM, David Chau wrote:

> For those of you who knows how the Linux VM works, could you tell me 
> why the memory access is so slow? It look like it might be invoking 
> the page-fault handler on every read. How can I make memory access 
> faster?

How about a little more info, like what kernel are you using and what 
are
the parameters you are sending to mmap()?

One of the things that happens here is /dev/mem is thinking this memory 
is
not real memory (because you said the system has only 253M of real
memory), so it treats it like IO space.  This causes changes to the 
attributes
of the pages, most notably the CCA type for cache or pipeline behavior,
which isn't what you want in this case.

The better way to approach this is to place an mmap() function in the
associated driver that works in conjunction with the application to gain
shared access as you expect.  This also closes a hole where an errant
application could write into unexpected places through /dev/mem.

Thanks.

	-- Dan


From pete_popov@yahoo.com Sat Jul 16 00:22:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 00:22:35 +0100 (BST)
Received: from web81403.mail.yahoo.com ([IPv6:::ffff:206.190.37.92]:29304 "HELO
	web81403.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8226755AbVGOXWJ>; Sat, 16 Jul 2005 00:22:09 +0100
Received: (qmail 96161 invoked by uid 60001); 15 Jul 2005 23:23:25 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=pxAGFQLcCpQOdzWapWhYICKVvceIxxpsAWA8Nk2rb4GOBIUW8H0LkEgzuDml4g6DsrsQFCC3XIk8TWdAdM36AgoeKm/MhXp71Kkoj2eS7Sg35A/qFlN+AiU6H5TD55U48OI7I2TN9HZJ0iRsw2o2Z4+0bIJbwf/d4eeU9zKNfVA=  ;
Message-ID: <20050715232325.96159.qmail@web81403.mail.yahoo.com>
Received: from [71.35.66.81] by web81403.mail.yahoo.com via HTTP; Fri, 15 Jul 2005 16:23:24 PDT
Date:	Fri, 15 Jul 2005 16:23:24 -0700 (PDT)
From:	Pete Popov <pete_popov@yahoo.com>
Subject: Re: CVS Update@linux-mips.org: linux
To:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>, ppopov@linux-mips.org
Cc:	yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
In-Reply-To: <20050716001621.6d9d607a.yuasa@hh.iij4u.or.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <pete_popov@yahoo.com>
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: 8509
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: pete_popov@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6063
Lines: 213



--- Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hi Pete,
> 
> On Thu, 14 Jul 2005 18:48:00 +0100
> ppopov@linux-mips.org wrote:
> 
> > 
> > Log message:
> > 	Philips PNX8550 support: MIPS32-like core with 2
> Trimedias on it.
> 
> I think the following include path is better.

Thanks :)! I thought I cleaned up everything ;)

Pete

> 
> Yoichi
> 
> Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> 
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> a/arch/mips/philips/pnx8550/common/gdb_hook.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 23:44:03.361056952 +0900
> @@ -31,7 +31,7 @@
>  #include <asm/serial.h>
>  #include <asm/io.h>
>  
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  static struct serial_state rs_table[RS_TABLE_SIZE]
> = {
>  	SERIAL_PORT_DFNS	/* Defined in serial.h */
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/int.c
> a/arch/mips/philips/pnx8550/common/int.c
> --- a-orig/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 23:44:32.008701848 +0900
> @@ -35,8 +35,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  extern asmlinkage void cp0_irqdispatch(void);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/pci.c
> a/arch/mips/philips/pnx8550/common/pci.c
> --- a-orig/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 23:44:52.444595120 +0900
> @@ -24,9 +24,9 @@
>  #include <linux/kernel.h>
>  #include <linux/init.h>
>  
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <pci.h>
> +#include <glb.h>
> +#include <nand.h>
>  
>  static struct resource pci_io_resource = {
>  	"pci IO space",
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> a/arch/mips/philips/pnx8550/common/platform.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 23:45:16.826888448 +0900
> @@ -17,9 +17,9 @@
>  #include <linux/init.h>
>  #include <linux/resource.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/usb.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <usb.h>
> +#include <uart.h>
>  
>  static struct resource pnx8550_usb_ohci_resources[]
> = {
>  	[0] = {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/proc.c
> a/arch/mips/philips/pnx8550/common/proc.c
> --- a-orig/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 23:45:33.076418144 +0900
> @@ -24,8 +24,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  
>  static int pnx8550_timers_read (char* page, char**
> start, off_t offset, int count, int* eof, void*
> data)
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/prom.c
> a/arch/mips/philips/pnx8550/common/prom.c
> --- a-orig/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 23:45:44.729646584 +0900
> @@ -15,7 +15,7 @@
>  #include <linux/string.h>
>  
>  #include <asm/bootinfo.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  /* #define DEBUG_CMDLINE */
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/reset.c
> a/arch/mips/philips/pnx8550/common/reset.c
> --- a-orig/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 23:45:55.884950720 +0900
> @@ -23,7 +23,7 @@
>  #include <linux/config.h>
>  #include <linux/slab.h>
>  #include <asm/reboot.h>
> -#include <asm/mach-pnx8550/glb.h>
> +#include <glb.h>
>  
>  void pnx8550_machine_restart(char *command)
>  {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/setup.c
> a/arch/mips/philips/pnx8550/common/setup.c
> --- a-orig/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 23:43:38.693806944 +0900
> @@ -33,11 +33,11 @@
>  #include <asm/pgtable.h>
>  #include <asm/time.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/uart.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <glb.h>
> +#include <int.h>
> +#include <pci.h>
> +#include <uart.h>
> +#include <nand.h>
>  
>  extern void prom_printf(char *fmt, ...);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/time.c
> a/arch/mips/philips/pnx8550/common/time.c
> --- a-orig/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 23:46:11.606560672 +0900
> @@ -31,8 +31,8 @@
>  #include <asm/div64.h>
>  #include <asm/debug.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/cm.h>
> +#include <int.h>
> +#include <cm.h>
>  
>  extern unsigned int mips_hpt_frequency;
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> a/arch/mips/philips/pnx8550/jbs/board_setup.c
> ---
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 02:47:59.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 23:46:28.102052976 +0900
> @@ -39,7 +39,7 @@
>  #include <asm/reboot.h>
>  #include <asm/pgtable.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> 
=== message truncated ===


From rolfliu@gmail.com Sat Jul 16 00:46:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 00:46:51 +0100 (BST)
Received: from wproxy.gmail.com ([IPv6:::ffff:64.233.184.198]:49767 "EHLO
	wproxy.gmail.com") by linux-mips.org with ESMTP id <S8226755AbVGOXqf> convert rfc822-to-8bit;
	Sat, 16 Jul 2005 00:46:35 +0100
Received: by wproxy.gmail.com with SMTP id i27so733437wra
        for <linux-mips@linux-mips.org>; Fri, 15 Jul 2005 16:47:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=Zyj02ah4xylmb/X52gooUVzmlzQJTISi6S+IrJvXHAiz9l0eC6dM+95+cCkJ+r10FyL40D+HE3dpi/Va76YKCouwi2O2Sj2Zopt52dxaImbHI5ightH78ME11HAMjKS9xzOjL+dwf0QZvmN+/ax1zvMA2qdQml3GcnvQxeK20hY=
Received: by 10.54.31.62 with SMTP id e62mr1303352wre;
        Fri, 15 Jul 2005 16:47:50 -0700 (PDT)
Received: by 10.54.71.11 with HTTP; Fri, 15 Jul 2005 16:47:50 -0700 (PDT)
Message-ID: <2db32b720507151647480ed75d@mail.gmail.com>
Date:	Fri, 15 Jul 2005 16:47:50 -0700
From:	rolf liu <rolfliu@gmail.com>
Reply-To: rolf liu <rolfliu@gmail.com>
To:	linux-mips@linux-mips.org
Subject: How to "make zImage" for db1550?
Cc:	rolf liu <rolfliu@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <rolfliu@gmail.com>
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: 8510
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: rolfliu@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 490
Lines: 12

Time to get rid of the NFS root fs. I want to put linux and root file
system into the flash. But I couldn't find the zImage target for linux
2.6.12 mipscvs.  What I should do?

Another question, the vmlinux created is more than 3MB, the default
"raw kernel" mtdblock is 2.75 MB. So could I change the size of "raw
kernel" in drivers/mtd/maps/alchemy-flash.c to 4MB or more? I hope the
yamon will not be overwritten then.

I searched the list and website, got no luck on this part. 

Thanks

From kanhu@innomedia.soft.net Sat Jul 16 08:22:30 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 08:22:49 +0100 (BST)
Received: from ns.innomedia.soft.net ([IPv6:::ffff:164.164.79.130]:26858 "EHLO
	gateway.innomedia.soft.net") by linux-mips.org with ESMTP
	id <S8226438AbVGPHWa>; Sat, 16 Jul 2005 08:22:30 +0100
Received: from [192.168.52.8] ([192.168.52.8])
	(authenticated bits=0)
	by gateway.innomedia.soft.net (8.12.11/8.12.11) with ESMTP id j6G7NqAY023599
	for <linux-mips@linux-mips.org>; Sat, 16 Jul 2005 12:53:52 +0530
Message-ID: <42D8B608.4020600@innomedia.soft.net>
Date:	Sat, 16 Jul 2005 12:53:52 +0530
From:	kanhu <kanhu@innomedia.soft.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Problem with loadable module
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.80/970/Wed Jul  6 21:30:45 2005
	clamav-milter version 0.80j
	on 127.0.0.1
X-Virus-Status:	Clean
Return-Path: <kanhu@innomedia.soft.net>
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: 8511
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: kanhu@innomedia.soft.net
Precedence: bulk
X-list: linux-mips
Content-Length: 1973
Lines: 56

Hi all,

I am using uClinux(uClinux-dist-20030305) on ARCH=mipsnommu and the 
CROSS_COMPILE=mipseb-linux- .I have installed the toolchain 
mipseb-linux-3.2.2-0.8.0.i386.rpm
I have written a simple loadable hello module and compiled it, It has 
been compiled successfully and when I try to load it by

/>insmod /lib/modules/hello
 It gives the following  error
======================
Using /lib/modules/hello
insmod: unresolved symbol _gp_disp
pid 25: failed 256
 =======================
What might be the problem ?

My Makefile looks like this
============================
TARGET = hello
OBJS =  hello.o
                                                                        
                                                 
CFLAGS = -DMODULE -D__KERNEL__ -Wl,-elf2flt -Dlinux -D__linux__ -Dunix 
-D__uClinux__ -DEMBED -DLINUX
CFLAGS += -I../../linux-2.4.x/include -I../../linux-2.4.x/include/linux
CFLAGS += -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
-fno-strict-aliasing -fno-common
CFLAGS += -fno-common -pipe -fno-builtin -D__linux__ -DNO_MM
CFLAGS += -nostdinc -msoft-float
CFLAGS += 
-I/opt/uClinux/toolchain/mipseb/3.2.2/lib/gcc-lib/mipseb-linux/3.2.2/include
CFLAGS += -DNDEBUG
                                                                        
                                                 
all: $(TARGET)
                                                                        
                                                 
$(TARGET): $(OBJS)
        $(LD) -r $(OBJS) -o $(TARGET)
                                                                        
                                                 
romfs:
        $(ROMFSINST) /lib/modules/$(TARGET)
                                                                        
                                                 
clean:
        -rm -f $(TARGET) *.elf *.gdb *.o
=======================================

Any idea to proceed with is welcome.



With Thanks & Regards
          Kanhu

From geert@linux-m68k.org Sat Jul 16 08:54:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 08:54:46 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:31996 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8226438AbVGPHy3>;
	Sat, 16 Jul 2005 08:54:29 +0100
Received: from numbat.sonytel.be (mail.sonytel.be [43.221.60.197])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id j6G7tnpr002968;
	Sat, 16 Jul 2005 09:55:49 +0200 (MEST)
Date:	Sat, 16 Jul 2005 09:55:41 +0200 (CEST)
From:	Geert Uytterhoeven <geert@linux-m68k.org>
To:	Linux/MIPS Development <linux-mips@linux-mips.org>
cc:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>, Andrew Morton <akpm@osdl.org>
Subject: [Linux-fbdev-devel] Re: 2.6.13-rc3-mm1 (fwd)
Message-ID: <Pine.LNX.4.62.0507160954510.4553@numbat.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.org>
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: 8512
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: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1762
Lines: 48


Guess this is where it really belongs...

---------- Forwarded message ----------
Date: Fri, 15 Jul 2005 16:23:49 -0700
From: Andrew Morton <akpm@osdl.org>
Reply-To: linux-fbdev-devel@lists.sourceforge.net
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: yuasa@hh.iij4u.or.jp, linux-kernel@vger.kernel.org,
    linux-fbdev-devel@lists.sourceforge.net,
    Antonino A. Daplas <adaplas@hotpop.com>
Subject: [Linux-fbdev-devel] Re: 2.6.13-rc3-mm1

Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:
>
> Hi Andrew
> 
> I got the following error.
> 
> make ARCH=mips oldconfig
> scripts/kconfig/conf -o arch/mips/Kconfig
> drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to 'tristate'
> 
> file drivers/char/speakup/Kconfig already scanned?
> make[1]: *** [oldconfig] Error 1
> make: *** [oldconfig] Error 2
> 

Well arch/mips/Kconfig is defining CONFIG_FB as bool and
drivers/video/Kconfig was changed a while ago to define it as tristate.  I
assume this failure also happens in linus's current tree.  

It seems odd that mips is privately duplicating the generic code's
definition.  Maybe that needs to be taken out of there.

I'll cc the fbdev guys - could someone please come up with fix?  It's a
showstopper for the MIPS architecture.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

From mad@automagically.de Sat Jul 16 12:26:27 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 12:26:42 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.188]:43759
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226776AbVGPL01>; Sat, 16 Jul 2005 12:26:27 +0100
Received: from pD95281BF.dip0.t-ipconnect.de [217.82.129.191] (helo=gaspode.madsworld.lan)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0MKwh2-1Dtkpj473w-0001wU; Sat, 16 Jul 2005 13:27:51 +0200
Received: from mad by gaspode.madsworld.lan with local (Exim 4.50)
	id 1Dtkpe-0003TA-3H
	for linux-mips@linux-mips.org; Sat, 16 Jul 2005 13:27:46 +0200
Date:	Sat, 16 Jul 2005 13:27:46 +0200
From:	Markus Dahms <mad@automagically.de>
To:	linux-mips@linux-mips.org
Subject: Re: New VINO video drivers for Indy
Message-ID: <20050716112745.GA12716@gaspode.automagically.de>
References: <42D4BF49.4040907@mbnet.fi> <20050715110021.GA15740@gaspode.automagically.de> <42D83063.3060505@mbnet.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42D83063.3060505@mbnet.fi>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:896705dcda322f33ae3752a7fdb3dc09
Return-Path: <mad@automagically.de>
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: 8513
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: mad@automagically.de
Precedence: bulk
X-list: linux-mips
Content-Length: 805
Lines: 20

Hello again,

>> I only get a bla[nc]k image ...
> That's strange. There might be some problems with IndyCam initialization 
> (register values),
> but usually you should be able to get at least a very dark picture.
> Removing and reinstalling the module (indycam.ko) reinitializes the
> camera so you can try that. IndyCam seems to use some very odd logic
> to decide how bright the picture should be.
> Try bringing some very bright light sources near the camera ?

For some reason it's working now. It's not significantly brighter, I
just checked the camera with kernel 2.4.x before booting 2.6.12.
If I can reproduce the failure I'll write it.
The picture has the same "quality" as with the other driver except
there _are_ fewer horizontal lines (they appear mostly on fast-moving
pictures).

Markus


From giometti@enneenne.com Sat Jul 16 13:40:42 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 13:41:00 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:39911 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226777AbVGPMkm>; Sat, 16 Jul 2005 13:40:42 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1Dtlza-0007lr-00
	for <linux-mips@linux-mips.org>; Sat, 16 Jul 2005 14:42:06 +0200
Date:	Sat, 16 Jul 2005 14:42:06 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	linux-mips <linux-mips@linux-mips.org>
Subject: Support for (au1100) 64-bit physical address space broken on 2.6.12?
Message-ID: <20050716124205.GA26127@enneenne.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn"
Content-Disposition: inline
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8514
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 8601
Lines: 249


--kVXhAStRUZ/+rrGn
Content-Type: multipart/mixed; boundary="s2ZSL+KKDSLx8OML"
Content-Disposition: inline


--s2ZSL+KKDSLx8OML
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

switching from linux-mips 2.6.12-rc3 to 2.6.12 I notice that the
following patch has been applied:

   http://www.linux-mips.org/archives/linux-mips/2005-06/msg00207.html

But, on my system, recompiling the source I noticed that compilation
stops with errors. Even downloading a clean version of source code
=66rom linux-mips's CVS and choosing, for instance, the board DB1100, I
got the same result.

The problem is that the above patch works well if the 64-bit physical
address space support is disabled, but, if enabled, it breaks
compilation stage.

Here what I get after getting source form CVS and doing the commands:

   # make pb1100_defconfig   (this board turn on CONFIG_64BIT_PHYS_ADDR opt=
ion)
   # make
   ...
   include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration o=
f 'fixup_bigphys_addr' follows non-static declaration
   include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared inline=
 after being called
   include/asm/pgtable.h:363: warning: previous declaration of 'fixup_bigph=
ys_addr' was here
   include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
   include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit declaration=
 of function `__fixup_bigphys_addr'
   arch/mips/au1000/common/setup.c: At top level:
   arch/mips/au1000/common/setup.c:159: error: conflicting types for '__fix=
up_bigphys_addr'
   include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit decl=
aration of '__fixup_bigphys_addr' was here
   arch/mips/au1000/common/setup.c: In function `__fixup_bigphys_addr':
   ...

After a little job I implemented the attached patch
(patch-64BIT_PHYS_ADDR) that works on my system on both settings
(CONFIG_64BIT_PHYS_ADDR on or off).

I don't know if it can resolve the above problem for others CPUs (I
tested it on au1100) but, at least, on this processor the PCMCIA
support now is functional. :)

I also suggest to apply the second patch (patch-PCMCIA_Kconfig) who
simply auto enable 64 bit support when choosing PCMCIA support.

Ciao,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--s2ZSL+KKDSLx8OML
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-64BIT_PHYS_ADDR
Content-Transfer-Encoding: quoted-printable

Index: arch/mips/au1000/common/setup.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/com=
mon/setup.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 setup.c
--- a/arch/mips/au1000/common/setup.c	2 Jul 2005 06:45:44 -0000	1.1.1.1
+++ b/arch/mips/au1000/common/setup.c	16 Jul 2005 12:27:18 -0000
@@ -152,38 +152,3 @@
 	while (au_readl(SYS_COUNTER_CNTRL) & SYS_CNTRL_T0S);
 	au_writel(0, SYS_TOYTRIM);
 }
-
-#if defined(CONFIG_64BIT_PHYS_ADDR)
-/* This routine should be valid for all Au1x based boards */
-phys_t __fixup_bigphys_addr(phys_t phys_addr, phys_t size)
-{
-	u32 start, end;
-
-	/* Don't fixup 36 bit addresses */
-	if ((phys_addr >> 32) !=3D 0) return phys_addr;
-
-#ifdef CONFIG_PCI
-	start =3D (u32)Au1500_PCI_MEM_START;
-	end =3D (u32)Au1500_PCI_MEM_END;
-	/* check for pci memory window */
-	if ((phys_addr >=3D start) && ((phys_addr + size) < end)) {
-		return (phys_t)((phys_addr - start) + Au1500_PCI_MEM_START);
-	}
-#endif
-
-	/* All Au1x SOCs have a pcmcia controller */
-	/* We setup our 32 bit pseudo addresses to be equal to the
-	 * 36 bit addr >> 4, to make it easier to check the address
-	 * and fix it.
-	 * The Au1x socket 0 phys attribute address is 0xF 4000 0000.
-	 * The pseudo address we use is 0xF400 0000. Any address over
-	 * 0xF400 0000 is a pcmcia pseudo address.
-	 */
-	if ((phys_addr >=3D 0xF4000000) && (phys_addr < 0xFFFFFFFF)) {
-		return (phys_t)(phys_addr << 4);
-	}
-
-	/* default nop */
-	return phys_addr;
-}
-#endif
Index: include/asm-mips/pgtable.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/include/asm-mips/pgt=
able.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 pgtable.h
--- a/include/asm-mips/pgtable.h	2 Jul 2005 06:47:30 -0000	1.1.1.1
+++ b/include/asm-mips/pgtable.h	16 Jul 2005 12:27:39 -0000
@@ -17,6 +17,7 @@
 #endif
=20
 #include <asm/pgtable-bits.h>
+#include <ioremap.h>
=20
 #define PAGE_NONE	__pgprot(_PAGE_PRESENT | _CACHE_CACHABLE_NONCOHERENT)
 #define PAGE_SHARED	__pgprot(_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \
@@ -360,7 +361,6 @@
 #endif
=20
 #ifdef CONFIG_64BIT_PHYS_ADDR
-extern phys_t fixup_bigphys_addr(phys_t phys_addr, phys_t size);
 extern int remap_pfn_range(struct vm_area_struct *vma, unsigned long from,=
 unsigned long pfn, unsigned long size, pgprot_t prot);
=20
 static inline int io_remap_page_range(struct vm_area_struct *vma,
Index: include/asm-mips/mach-au1x00/ioremap.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/include/asm-mips/mac=
h-au1x00/ioremap.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ioremap.h
--- a/include/asm-mips/mach-au1x00/ioremap.h	2 Jul 2005 06:47:31 -0000	1.1.=
1.1
+++ b/include/asm-mips/mach-au1x00/ioremap.h	16 Jul 2005 12:27:39 -0000
@@ -11,7 +11,42 @@
=20
 #include <linux/types.h>
=20
-#ifndef CONFIG_64BIT_PHYS_ADDR
+#ifdef CONFIG_64BIT_PHYS_ADDR
+/* This routine should be valid for all Au1x based boards */
+static inline phys_t __fixup_bigphys_addr(phys_t phys_addr, phys_t size)
+{
+#ifdef CONFIG_PCI
+	u32 start, end;
+#endif
+
+	/* Don't fixup 36 bit addresses */
+	if ((phys_addr >> 32) !=3D 0) return phys_addr;
+
+#ifdef CONFIG_PCI
+	start =3D (u32)Au1500_PCI_MEM_START;
+	end =3D (u32)Au1500_PCI_MEM_END;
+	/* check for pci memory window */
+	if ((phys_addr >=3D start) && ((phys_addr + size) < end)) {
+		return (phys_t)((phys_addr - start) + Au1500_PCI_MEM_START);
+	}
+#endif
+
+	/* All Au1x SOCs have a pcmcia controller */
+	/* We setup our 32 bit pseudo addresses to be equal to the
+	 * 36 bit addr >> 4, to make it easier to check the address
+	 * and fix it.
+	 * The Au1x socket 0 phys attribute address is 0xF 4000 0000.
+	 * The pseudo address we use is 0xF400 0000. Any address over
+	 * 0xF400 0000 is a pcmcia pseudo address.
+	 */
+	if ((phys_addr >=3D 0xF4000000) && (phys_addr < 0xFFFFFFFF)) {
+		return (phys_t)(phys_addr << 4);
+	}
+
+	/* default nop */
+	return phys_addr;
+}
+#else
 static inline phys_t __fixup_bigphys_addr(phys_t phys_addr, phys_t size)
 {
 	return phys_addr;

--s2ZSL+KKDSLx8OML
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-PCMCIA_Kconfig
Content-Transfer-Encoding: quoted-printable

Index: drivers/pcmcia/Kconfig
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/drivers/pcmcia/Kconf=
ig,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Kconfig
--- a/drivers/pcmcia/Kconfig	2 Jul 2005 06:46:44 -0000	1.1.1.1
+++ b/drivers/pcmcia/Kconfig	16 Jul 2005 12:27:31 -0000
@@ -137,6 +137,7 @@
 config PCMCIA_AU1X00
 	tristate "Au1x00 pcmcia support"
 	depends on SOC_AU1X00 && PCMCIA
+	select 64BIT_PHYS_ADDR
=20
 config PCMCIA_SA1100
 	tristate "SA1100 support"

--s2ZSL+KKDSLx8OML--

--kVXhAStRUZ/+rrGn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2QCdQaTCYNJaVjMRAt6JAJ43SzI2DhJ9h8mKRSUp7j+SNsAm5wCdHj8E
chV/HmC0ahgdhaXtv5Nb59Y=
=YBJh
-----END PGP SIGNATURE-----

--kVXhAStRUZ/+rrGn--

From giometti@enneenne.com Sat Jul 16 15:44:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 15:44:30 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:11427 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226777AbVGPOoJ>; Sat, 16 Jul 2005 15:44:09 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1Dtnv0-0005Jf-00; Sat, 16 Jul 2005 16:45:30 +0200
Date:	Sat, 16 Jul 2005 16:45:30 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Dan Malek <dan@embeddededge.com>
Cc:	Rodolfo Giometti <giometti@linux.it>, linux-mips@linux-mips.org
Subject: Re: power management status for au1100
Message-ID: <20050716144530.GD26127@enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com> <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="2E/hm+v6kSLEYT3h"
Content-Disposition: inline
In-Reply-To: <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8516
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1206
Lines: 43


--2E/hm+v6kSLEYT3h
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 12, 2005 at 11:52:30AM -0700, Dan Malek wrote:
> Now that you know the reason for the change, perhaps we
> should try to make it work properly :-)

Ok. :)

When trying to compile the PM support I noticed that function
calibrate_delay() into =ABarch/mips/au1000/common/power.c=BB overrides the
same function into =ABinit/calibrate.c=BB.

Can be a problem? Which one is the right function to be used?

Thanks,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--2E/hm+v6kSLEYT3h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2R2KQaTCYNJaVjMRAhnhAJ4zD4CUD6dFIddttiTaze/yVCdfSgCg4oj5
KA77yryS0TbGE6Lfi0Fmc00=
=BesP
-----END PGP SIGNATURE-----

--2E/hm+v6kSLEYT3h--

From giometti@enneenne.com Sat Jul 16 15:47:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 15:48:11 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:48036 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226777AbVGPOrx>; Sat, 16 Jul 2005 15:47:53 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1Dtnyg-0005N5-00; Sat, 16 Jul 2005 16:49:18 +0200
Date:	Sat, 16 Jul 2005 16:49:18 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Dan Malek <dan@embeddededge.com>
Cc:	linux-mips@linux-mips.org
Subject: Au1100 real time clock [was: power management status for au1100]
Message-ID: <20050716144918.GE26127@enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com> <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4C6bbPZ6c/S1npyF"
Content-Disposition: inline
In-Reply-To: <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8517
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1192
Lines: 40


--4C6bbPZ6c/S1npyF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 12, 2005 at 11:52:30AM -0700, Dan Malek wrote:
> This is an update AMD/Alchemy wanted so if you weren't using
> power management the timer would be available for other uses.

About this topic... I suppose that if I don't use PM support I can use
TOY timer as real time clock, but if I enable PM support (so TOY use
is reserved) should I use an external chip as system's real time
clock?

Thanks,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--4C6bbPZ6c/S1npyF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2R5uQaTCYNJaVjMRAtwVAJ4q/Inurox1XHpczyHlQ7w6XK9AywCbBCnB
lWgbGo/kDFcApNGpwy0RmAI=
=luDe
-----END PGP SIGNATURE-----

--4C6bbPZ6c/S1npyF--

From giometti@enneenne.com Sat Jul 16 16:18:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 16:18:50 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:60078 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226777AbVGPPS2>; Sat, 16 Jul 2005 16:18:28 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DtoSE-00067i-00; Sat, 16 Jul 2005 17:19:50 +0200
Date:	Sat, 16 Jul 2005 17:19:50 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Dan Malek <dan@embeddededge.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: power management status for au1100
Message-ID: <20050716151950.GF26127@enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com> <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jaTU8Y2VLE5tlY1O"
Content-Disposition: inline
In-Reply-To: <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8518
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 2392
Lines: 84


--jaTU8Y2VLE5tlY1O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Looking function mips_timer_interrupt() (which is the normal timer
interrupt when PM is not enabled) I noticed that it has called from
file =ABarch/mips/au1000/common/int-handler.S=BB as follow:

	...
        .text
        .set    macro
        .set    noat
        .align  5

NESTED(au1000_IRQ, PT_SIZE, sp)
        SAVE_ALL
        CLI                             # Important: mark KERNEL mode !

        mfc0    t0,CP0_CAUSE            # get pending interrupts
        mfc0    t1,CP0_STATUS           # get enabled interrupts
        and     t0,t1                   # isolate allowed ones

        andi    t0,0xff00               # isolate pending bits
        beqz    t0, 3f                  # spurious interrupt

        andi    a0, t0, CAUSEF_IP7
        beq     a0, zero, 1f
        move    a0, sp
        jal     mips_timer_interrupt
        j       ret_from_irq
	...

Looking at =ABCLI=BB implementation into =ABinclude/asm/stackframe.h=BB:

   /*
    * Move to kernel mode and disable interrupts.
    * Set cp0 enable bit as sign that we're running on the kernel stack
    */
		   .macro  CLI
		   mfc0    t0, CP0_STATUS
		   li      t1, ST0_CU0 | 0x1f
		   or      t0, t1
		   xori    t0, 0x1f
		   mtc0    t0, CP0_STATUS
		   irq_disable_hazard
		   .endm

I see that the CLI macro ensures that mips_timer_interrupt() will be
executed into =ABkernel mode=BB.

What do you think about that? Can it cause the error =ABBreak
instruction in kernel code in arch/mips/kernel/traps.c::do_bp, line
629[#1]:=BB?

If so, can someone help me in fixing such bug? I'm not a MIPS assembly
master! ;-p

Ciao,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--jaTU8Y2VLE5tlY1O
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2SWWQaTCYNJaVjMRAg/LAJ4ybFGl3NYmbruQhihgQNDw6v+yyACfcw9G
Fnw2qiWTNcnuhHeIqWr1zQY=
=RmQV
-----END PGP SIGNATURE-----

--jaTU8Y2VLE5tlY1O--

From ppopov@embeddedalley.com Sat Jul 16 16:41:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Jul 2005 16:41:42 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:7801
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226777AbVGPPlY>; Sat, 16 Jul 2005 16:41:24 +0100
Received: (qmail 92730 invoked from network); 16 Jul 2005 15:42:49 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 16 Jul 2005 15:42:49 -0000
Subject: Re: Support for (au1100) 64-bit physical address space broken on
	2.6.12?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20050716124205.GA26127@enneenne.com>
References: <20050716124205.GA26127@enneenne.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Sat, 16 Jul 2005 08:42:55 -0700
Message-Id: <1121528575.27121.3.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8519
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: 2253
Lines: 53

On Sat, 2005-07-16 at 14:42 +0200, Rodolfo Giometti wrote:
> Hello,
> 
> switching from linux-mips 2.6.12-rc3 to 2.6.12 I notice that the
> following patch has been applied:
> 
>    http://www.linux-mips.org/archives/linux-mips/2005-06/msg00207.html
> 
> But, on my system, recompiling the source I noticed that compilation
> stops with errors. Even downloading a clean version of source code
> from linux-mips's CVS and choosing, for instance, the board DB1100, I
> got the same result.
> 
> The problem is that the above patch works well if the 64-bit physical
> address space support is disabled, but, if enabled, it breaks
> compilation stage.

I fixed this is the latest tree a couple of days ago.

Pete

> Here what I get after getting source form CVS and doing the commands:
> 
>    # make pb1100_defconfig   (this board turn on CONFIG_64BIT_PHYS_ADDR option)
>    # make
>    ...
>    include/asm-mips/mach-au1x00/ioremap.h:25: warning: static declaration of 'fixup_bigphys_addr' follows non-static declaration
>    include/asm/pgtable.h:363: warning: 'fixup_bigphys_addr' declared inline after being called
>    include/asm/pgtable.h:363: warning: previous declaration of 'fixup_bigphys_addr' was here
>    include/asm-mips/mach-au1x00/ioremap.h: In function `fixup_bigphys_addr':
>    include/asm-mips/mach-au1x00/ioremap.h:26: warning: implicit declaration of function `__fixup_bigphys_addr'
>    arch/mips/au1000/common/setup.c: At top level:
>    arch/mips/au1000/common/setup.c:159: error: conflicting types for '__fixup_bigphys_addr'
>    include/asm-mips/mach-au1x00/ioremap.h:26: error: previous implicit declaration of '__fixup_bigphys_addr' was here
>    arch/mips/au1000/common/setup.c: In function `__fixup_bigphys_addr':
>    ...
> 
> After a little job I implemented the attached patch
> (patch-64BIT_PHYS_ADDR) that works on my system on both settings
> (CONFIG_64BIT_PHYS_ADDR on or off).
> 
> I don't know if it can resolve the above problem for others CPUs (I
> tested it on au1100) but, at least, on this processor the PCMCIA
> support now is functional. :)
> 
> I also suggest to apply the second patch (patch-PCMCIA_Kconfig) who
> simply auto enable 64 bit support when choosing PCMCIA support.
> 
> Ciao,
> 
> Rodolfo
> 


From giometti@enneenne.com Sun Jul 17 11:57:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Jul 2005 11:57:43 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:24296 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226742AbVGQK52>; Sun, 17 Jul 2005 11:57:28 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1Du6rF-0005kS-00; Sun, 17 Jul 2005 12:58:53 +0200
Date:	Sun, 17 Jul 2005 12:58:53 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Support for (au1100) 64-bit physical address space broken on 2.6.12?
Message-ID: <20050717105853.GA21844@enneenne.com>
References: <20050716124205.GA26127@enneenne.com> <1121528575.27121.3.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s"
Content-Disposition: inline
In-Reply-To: <1121528575.27121.3.camel@localhost.localdomain>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8520
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1103
Lines: 41


--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 16, 2005 at 08:42:55AM -0700, Pete Popov wrote:
> I fixed this is the latest tree a couple of days ago.

Great! :)

Did you already publish it? I checked the linux-mips CVS before
sending my patches but I saw nothing about it. :-o

Where can I get your patch in order to compare the two solutions?

Thanks,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2jntQaTCYNJaVjMRAj0MAJ0THPhdWL9Oq65ShR2CziY1NWUPdACcDGU8
roLud22sCYOlVPvj2RsAmbY=
=WGCQ
-----END PGP SIGNATURE-----

--SLDf9lqlvOQaIe6s--

From ppopov@embeddedalley.com Sun Jul 17 17:20:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Jul 2005 17:20:48 +0100 (BST)
Received: from smtp002.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.126]:51350
	"HELO smtp002.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226800AbVGQQU3>; Sun, 17 Jul 2005 17:20:29 +0100
Received: (qmail 26552 invoked from network); 17 Jul 2005 16:21:56 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp002.bizmail.yahoo.com with SMTP; 17 Jul 2005 16:21:56 -0000
Subject: Re: Support for (au1100) 64-bit physical address space broken on
	2.6.12?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20050717105853.GA21844@enneenne.com>
References: <20050716124205.GA26127@enneenne.com>
	 <1121528575.27121.3.camel@localhost.localdomain>
	 <20050717105853.GA21844@enneenne.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Sun, 17 Jul 2005 09:22:04 -0700
Message-Id: <1121617324.27121.36.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8521
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: 460
Lines: 15

On Sun, 2005-07-17 at 12:58 +0200, Rodolfo Giometti wrote:
> On Sat, Jul 16, 2005 at 08:42:55AM -0700, Pete Popov wrote:
> > I fixed this is the latest tree a couple of days ago.
> 
> Great! :)
> 
> Did you already publish it? I checked the linux-mips CVS before
> sending my patches but I saw nothing about it. :-o
> 
> Where can I get your patch in order to compare the two solutions?

Just do a cvs update in your directory and you'll get the patch.

Pete


From giometti@enneenne.com Mon Jul 18 08:53:03 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 08:53:17 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:50365 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226813AbVGRHxD>; Mon, 18 Jul 2005 08:53:03 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DuQSS-0007kx-00; Mon, 18 Jul 2005 09:54:36 +0200
Date:	Mon, 18 Jul 2005 09:54:35 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Support for (au1100) 64-bit physical address space broken on 2.6.12?
Message-ID: <20050718075435.GB21844@enneenne.com>
References: <20050716124205.GA26127@enneenne.com> <1121528575.27121.3.camel@localhost.localdomain> <20050717105853.GA21844@enneenne.com> <1121617324.27121.36.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F"
Content-Disposition: inline
In-Reply-To: <1121617324.27121.36.camel@localhost.localdomain>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8522
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1050
Lines: 39


--IrhDeMKUP4DT/M7F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 17, 2005 at 09:22:04AM -0700, Pete Popov wrote:
> Just do a cvs update in your directory and you'll get the patch.

Mmm... I just did as you suggest but I got nothing... ok, maybe it's a
my problem.

I'll take a better look to the on line CVS. :)

Ciao,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--IrhDeMKUP4DT/M7F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC22A7QaTCYNJaVjMRAuEEAJ9tMNXsoRFowkJQ/DH1NA4ynVoHFgCfQPlT
Ez8XijVtKXrLeW70HotXoyw=
=EP3O
-----END PGP SIGNATURE-----

--IrhDeMKUP4DT/M7F--

From jaypee@hotpop.com Mon Jul 18 10:56:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 10:56:17 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:7564 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226818AbVGRJ4A> convert rfc822-to-8bit; Mon, 18 Jul 2005 10:56:00 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id 4CBF81446DEE
	for <linux-mips@linux-mips.org>; Mon, 18 Jul 2005 09:57:24 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-2.hotpop.com (Postfix) with ESMTP
	id 65EA91449ED2; Mon, 18 Jul 2005 09:57:18 +0000 (UTC)
Date:	Mon, 18 Jul 2005 09:57:13 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	Bruno Randolf <bruno.randolf@4g-systems.biz>
Cc:	Clem Taylor <clem.taylor@gmail.com>,
	linux-mips <linux-mips@linux-mips.org>
References: <1121270402l.7656l.3l@cavan>
	<ecb4efd1050714171318ce81aa@mail.gmail.com> <1121415711l.5178l.3l@cavan>
	<200507151117.49012.bruno.randolf@4g-systems.biz>
In-Reply-To: <200507151117.49012.bruno.randolf@4g-systems.biz> (from
	bruno.randolf@4g-systems.biz on Fri Jul 15 10:17:44 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121680641l.13805l.1l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8523
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: 1024
Lines: 38

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/07/05 10:17:44, Bruno Randolf wrote:
> On Friday 15 July 2005 10:21, jaypee@hotpop.com wrote:
> > Yours is using ~30% cpu to send 100Mbps.
> > Mine is using 100% to send 66Mbps.
> 
> i remember that ethernet thruput dropped from nearly 100Mbps to about
> 60-70Mbps on our Au1500 based board, when we enabled
> CONFIG_NONCOHERENT_IO...

Thanks Bruno but I can't find that config option to select.
I did find CONFIG_
Changing from CONFIG_DMA_NONCOHERENT to CONFIG_DMA_COHERENT  make no  
difference, although I can see that if the kernel invalidates the cache
line for each packet on send there would be a performance hit.

Clem can you send me your .config to see if I can figure out why your  
setup works?

> 
> bruno
> 

- -- 
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC230BZDxnKy3oOpYRAjq2AJ49DO0KrqGmWcS1N1dHHLe2lOlEhgCeNyqw
aTRA+DA6FyMNakcLBt5oV88=
=TR4O
-----END PGP SIGNATURE-----




From zhuangyy@xianan.com.cn Mon Jul 18 11:04:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 11:04:42 +0100 (BST)
Received: from [IPv6:::ffff:218.94.38.154] ([IPv6:::ffff:218.94.38.154]:58255
	"EHLO xianan.com.cn") by linux-mips.org with ESMTP
	id <S8226818AbVGRKES>; Mon, 18 Jul 2005 11:04:18 +0100
Received: from [192.168.10.105] ([127.0.0.1]:36833)
	by xianan.com.cn with [XMail 1.21 ESMTP Server]
	id <SCED> for <linux-mips@linux-mips.org> from <zhuangyy@xianan.com.cn>;
	Mon, 18 Jul 2005 18:03:07 +0800
Message-ID: <42DB7E87.5000402@xianan.com.cn>
Date:	Mon, 18 Jul 2005 18:03:51 +0800
From:	ZHUANG YUYAO <zhuangyy@xianan.com.cn>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Jeroen Vreeken <pe1rxq@amsat.org>
Subject: ADM5120 kernel 2.6 porting
References: <200507122057.j6CKqmI7021129@mailbox8.ucsd.edu> <42D52E2D.6020305@amsat.org>
In-Reply-To: <42D52E2D.6020305@amsat.org>
Content-Type: multipart/mixed;
 boundary="------------040600060507070308060705"
Return-Path: <zhuangyy@xianan.com.cn>
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: 8524
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: zhuangyy@xianan.com.cn
Precedence: bulk
X-list: linux-mips
Content-Length: 21335
Lines: 1012

This is a multi-part message in MIME format.
--------------040600060507070308060705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Jeroen

I've made two patches to setup.c and pci-adm5120.c which are included in
your 050329 patch against linuxmips CVS
(http://sharon.esrac.ele.tue.nl/users/pe1rxq/linux-adm/linux-adm-20050329.diff 

BTW. this patch is against linuxmips CVS date 2005-03-29 instead of
revision 2.6.12-rc1.)

These two patches make adm5120 support compatible with the new
linux-mips plat_setup() implementation. Just apply these 2 patches after
linux-adm-20050329.diff. I've tested it with linuxmips CVS revision
2.6.12 and so far as I tested, it boots fine.

USB support is disabled in my kernel .config because I still do not know
how to get rid of these following compile errors:
   CC      drivers/usb/host/adm5120-hcd.o
drivers/usb/host/adm5120-hcd.c: In function `adm5120hcd_probe':
drivers/usb/host/adm5120-hcd.c:706: warning: implicit declaration of
function `usb_register_bus'
drivers/usb/host/adm5120-hcd.c:736: error: `USB_STATE_RUNNING'
undeclared (first use in this function)
drivers/usb/host/adm5120-hcd.c:736: error: (Each undeclared identifier
is reported only once
drivers/usb/host/adm5120-hcd.c:736: error: for each function it appears in.)
drivers/usb/host/adm5120-hcd.c:738: warning: implicit declaration of
function `hcd_register_root'
drivers/usb/host/adm5120-hcd.c:749: warning: implicit declaration of
function `usb_deregister_bus'
make[3]: *** [drivers/usb/host/adm5120-hcd.o] Error 1

Looks like USB_STATE_RUNNING no longer exists in new kernel sources.


Zhuang Yuyao
     2005-07-18


--------------040600060507070308060705
Content-Type: text/plain;
 name="pci-adm5120.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pci-adm5120.patch"

--- linux-2.6.12-050329-adm5120/arch/mips/pci/pci-adm5120.c	2005-07-17 20:35:33.000000000 -0600
+++ linux-2.6.12-adm5120/arch/mips/pci/pci-adm5120.c	2005-07-17 20:13:26.000000000 -0600
@@ -90,4 +90,4 @@
 	return 0;
 }
 
-early_initcall(adm5120_pci_setup);
+arch_initcall(adm5120_pci_setup);


--------------040600060507070308060705
Content-Type: text/plain;
 name="adm5120.setup.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="adm5120.setup.c.patch"

--- linux-2.6.12-050329-adm5120/arch/mips/adm5120/setup.c	2005-07-17 20:34:52.000000000 -0600
+++ linux-2.6.12-adm5120/arch/mips/adm5120/setup.c	2005-07-17 19:58:03.000000000 -0600
@@ -80,7 +80,7 @@
 	set_c0_status(ALLINTS);
 }
 
-static int __init adm5120_setup(void)
+void __init plat_setup(void)
 {
 	printk("ADM5120 board setup\n");
 
@@ -92,12 +92,8 @@
 	_machine_power_off = adm5120_power_off;
 
 	set_io_port_base(KSEG1);
-
-	return 0;
 }
 
-early_initcall(adm5120_setup);
-
 const char *get_system_type(void)
 {
 	return "ADM5120 Board";


--------------040600060507070308060705
Content-Type: text/plain;
 name="config.save"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="config.save"

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12
# Sun Jul 17 20:02:02 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

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

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

#
# Machine selection
#
CONFIG_MIPS_ADM5120=y
CONFIG_PCI_ADM5120=y
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_QEMU is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
# CONFIG_SIBYTE_SENTOSA is not set
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_NONCOHERENT=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
# CONFIG_CPU_MIPS32_R1 is not set
# CONFIG_CPU_MIPS64_R1 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
CONFIG_CPU_R4X00=y
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y

#
# Kernel type
#
CONFIG_MIPS32=y
# CONFIG_MIPS64 is not set
# CONFIG_64BIT is not set
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
# CONFIG_64BIT_PHYS_ADDR is not set
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
CONFIG_CPU_HAS_SYNC=y
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_NAMES is not set
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_ADM5120=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=5120
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="usr/root/"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_ROUTE_FWMARK is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# CONFIG_IP_TCPDIAG is not set
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_PHYSDEV=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_CONNMARK=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE_EBT_BROUTE=y
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_T_NAT=y
CONFIG_BRIDGE_EBT_802_3=y
CONFIG_BRIDGE_EBT_AMONG=y
CONFIG_BRIDGE_EBT_ARP=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_LIMIT=y
CONFIG_BRIDGE_EBT_MARK=y
CONFIG_BRIDGE_EBT_PKTTYPE=y
CONFIG_BRIDGE_EBT_STP=y
CONFIG_BRIDGE_EBT_VLAN=y
CONFIG_BRIDGE_EBT_ARPREPLY=y
CONFIG_BRIDGE_EBT_DNAT=y
CONFIG_BRIDGE_EBT_MARK_T=y
CONFIG_BRIDGE_EBT_REDIRECT=y
CONFIG_BRIDGE_EBT_SNAT=y
CONFIG_BRIDGE_EBT_LOG=y
CONFIG_BRIDGE_EBT_ULOG=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=y
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
# CONFIG_NET_ESTIMATOR is not set
# CONFIG_NET_CLS is not set
CONFIG_NET_CLS_ROUTE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
CONFIG_MIPS_ADM5120_ENET=y
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPPOE=y
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_LIBPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_ADM5120=y
CONFIG_ADM5120_NR_UARTS=2
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_ADM5120_GPIO=y

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_TEST=m

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y


--------------040600060507070308060705--

From ihollo@tom.com Mon Jul 18 11:08:35 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 11:09:00 +0100 (BST)
Received: from smtpr3.tom.com ([IPv6:::ffff:202.108.255.198]:16962 "HELO
	tom.com") by linux-mips.org with SMTP id <S8226818AbVGRKIf>;
	Mon, 18 Jul 2005 11:08:35 +0100
Received: from [192.168.10.105] (unknown [218.94.38.154])
	by bjapp4 (Coremail) with SMTP id HkCp9Zl+20JIACaa.1
	for <linux-mips@linux-mips.org>; Mon, 18 Jul 2005 18:04:29 +0800 (CST)
X-Originating-IP: [218.94.38.154]
Message-ID: <42DB7E98.2050800@tom.com>
Date:	Mon, 18 Jul 2005 18:04:08 +0800
From:	Zhuang Yuyao <ihollo@tom.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
CC:	Jeroen Vreeken <pe1rxq@amsat.org>
Subject: ADM5120 kernel 2.6 porting
References: <200507122057.j6CKqmI7021129@mailbox8.ucsd.edu> <42D52E2D.6020305@amsat.org>
In-Reply-To: <42D52E2D.6020305@amsat.org>
Content-Type: multipart/mixed;
 boundary="------------040802060704070003070002"
Return-Path: <ihollo@tom.com>
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: 8525
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: ihollo@tom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 21343
Lines: 1018

This is a multi-part message in MIME format.
--------------040802060704070003070002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Jeroen

I've made two patches to setup.c and pci-adm5120.c which are included in
your 050329 patch against linuxmips CVS
(http://sharon.esrac.ele.tue.nl/users/pe1rxq/linux-adm/linux-adm-20050329.diff 


BTW. this patch is against linuxmips CVS date 2005-03-29 instead of
revision 2.6.12-rc1.)

These two patches make adm5120 support compatible with the new
linux-mips plat_setup() implementation. Just apply these 2 patches after
linux-adm-20050329.diff. I've tested it with linuxmips CVS revision
2.6.12 and so far as I tested, it boots fine.

USB support is disabled in my kernel .config because I still do not know
how to get rid of these following compile errors:
    CC      drivers/usb/host/adm5120-hcd.o
drivers/usb/host/adm5120-hcd.c: In function `adm5120hcd_probe':
drivers/usb/host/adm5120-hcd.c:706: warning: implicit declaration of
function `usb_register_bus'
drivers/usb/host/adm5120-hcd.c:736: error: `USB_STATE_RUNNING'
undeclared (first use in this function)
drivers/usb/host/adm5120-hcd.c:736: error: (Each undeclared identifier
is reported only once
drivers/usb/host/adm5120-hcd.c:736: error: for each function it appears in.)
drivers/usb/host/adm5120-hcd.c:738: warning: implicit declaration of
function `hcd_register_root'
drivers/usb/host/adm5120-hcd.c:749: warning: implicit declaration of
function `usb_deregister_bus'
make[3]: *** [drivers/usb/host/adm5120-hcd.o] Error 1

Looks like USB_STATE_RUNNING no longer exists in new kernel sources.


Zhuang Yuyao
      2005-07-18



--------------040802060704070003070002
Content-Type: text/plain;
 name="pci-adm5120.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="pci-adm5120.patch"

--- linux-2.6.12-050329-adm5120/arch/mips/pci/pci-adm5120.c	2005-07-17 20:35:33.000000000 -0600
+++ linux-2.6.12-adm5120/arch/mips/pci/pci-adm5120.c	2005-07-17 20:13:26.000000000 -0600
@@ -90,4 +90,4 @@
 	return 0;
 }
 
-early_initcall(adm5120_pci_setup);
+arch_initcall(adm5120_pci_setup);



--------------040802060704070003070002
Content-Type: text/plain;
 name="adm5120.setup.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="adm5120.setup.c.patch"

--- linux-2.6.12-050329-adm5120/arch/mips/adm5120/setup.c	2005-07-17 20:34:52.000000000 -0600
+++ linux-2.6.12-adm5120/arch/mips/adm5120/setup.c	2005-07-17 19:58:03.000000000 -0600
@@ -80,7 +80,7 @@
 	set_c0_status(ALLINTS);
 }
 
-static int __init adm5120_setup(void)
+void __init plat_setup(void)
 {
 	printk("ADM5120 board setup\n");
 
@@ -92,12 +92,8 @@
 	_machine_power_off = adm5120_power_off;
 
 	set_io_port_base(KSEG1);
-
-	return 0;
 }
 
-early_initcall(adm5120_setup);
-
 const char *get_system_type(void)
 {
 	return "ADM5120 Board";



--------------040802060704070003070002
Content-Type: text/plain;
 name="config.save"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="config.save"

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12
# Sun Jul 17 20:02:02 2005
#
CONFIG_MIPS=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

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

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

#
# Machine selection
#
CONFIG_MIPS_ADM5120=y
CONFIG_PCI_ADM5120=y
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_DB1550 is not set
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_QEMU is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
# CONFIG_SIBYTE_SENTOSA is not set
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_NONCOHERENT=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_MIPS_L1_CACHE_SHIFT=5

#
# CPU selection
#
# CONFIG_CPU_MIPS32_R1 is not set
# CONFIG_CPU_MIPS64_R1 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
CONFIG_CPU_R4X00=y
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y

#
# Kernel type
#
CONFIG_MIPS32=y
# CONFIG_MIPS64 is not set
# CONFIG_64BIT is not set
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
# CONFIG_64BIT_PHYS_ADDR is not set
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
CONFIG_CPU_HAS_SYNC=y
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=y
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_NAMES is not set
CONFIG_MMU=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_ADM5120=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=5120
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="usr/root/"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_ROUTE_FWMARK is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
# CONFIG_IP_TCPDIAG is not set
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_PHYSDEV=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_CONNMARK=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE_EBT_BROUTE=y
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_T_NAT=y
CONFIG_BRIDGE_EBT_802_3=y
CONFIG_BRIDGE_EBT_AMONG=y
CONFIG_BRIDGE_EBT_ARP=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_LIMIT=y
CONFIG_BRIDGE_EBT_MARK=y
CONFIG_BRIDGE_EBT_PKTTYPE=y
CONFIG_BRIDGE_EBT_STP=y
CONFIG_BRIDGE_EBT_VLAN=y
CONFIG_BRIDGE_EBT_ARPREPLY=y
CONFIG_BRIDGE_EBT_DNAT=y
CONFIG_BRIDGE_EBT_MARK_T=y
CONFIG_BRIDGE_EBT_REDIRECT=y
CONFIG_BRIDGE_EBT_SNAT=y
CONFIG_BRIDGE_EBT_LOG=y
CONFIG_BRIDGE_EBT_ULOG=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
# CONFIG_NET_SCH_CBQ is not set
CONFIG_NET_SCH_HTB=y
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
# CONFIG_NET_ESTIMATOR is not set
# CONFIG_NET_CLS is not set
CONFIG_NET_CLS_ROUTE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
CONFIG_MIPS_ADM5120_ENET=y
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPPOE=y
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_LIBPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_ADM5120=y
CONFIG_ADM5120_NR_UARTS=2
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_ADM5120_GPIO=y

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE=""

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_TEST=m

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y



--------------040802060704070003070002--


From dan@embeddedalley.com Mon Jul 18 13:57:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 13:58:10 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:45578 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226823AbVGRM5y>; Mon, 18 Jul 2005 13:57:54 +0100
Received: from [192.168.87.101] (pool-141-154-51-3.bos.east.verizon.net [141.154.51.3])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6ICfmmN006847;
	Mon, 18 Jul 2005 08:41:50 -0400
In-Reply-To: <1121680641l.13805l.1l@cavan>
References: <1121270402l.7656l.3l@cavan> <ecb4efd1050714171318ce81aa@mail.gmail.com> <1121415711l.5178l.3l@cavan> <200507151117.49012.bruno.randolf@4g-systems.biz> <1121680641l.13805l.1l@cavan>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b30d00c05783e8ed4fc6dcb29563e232@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips <linux-mips@linux-mips.org>,
	Bruno Randolf <bruno.randolf@4g-systems.biz>,
	Clem Taylor <clem.taylor@gmail.com>
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: Au1550 ethernet throughput low
Date:	Mon, 18 Jul 2005 08:56:04 -0400
To:	jaypee@hotpop.com
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
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: 8526
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@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 676
Lines: 24


On Jul 18, 2005, at 5:57 AM, jaypee@hotpop.com wrote:

> Thanks Bruno but I can't find that config option to select.

It is no longer an option in 2.6.  All Au1xxx processors force
CONFIG_DMA_NONCOHERENT because some cases still
don't work correctly.

> Changing from CONFIG_DMA_NONCOHERENT to CONFIG_DMA_COHERENT  make no 
> difference,

It won't, because the Ethernet driver knows the hardware works
correctly for this peripheral and assumes coherent IO.

Any Ethernet performance differences among Au1xxx designs are
likely to be related to processor speed, the memory interface
configuration, or PHY issues (improperly configured or high
error rates).

Thanks.

	-- Dan


From jaypee@hotpop.com Mon Jul 18 14:41:04 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 14:41:28 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:55976 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226827AbVGRNlE>; Mon, 18 Jul 2005 14:41:04 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id BEC0313E1A80
	for <linux-mips@linux-mips.org>; Mon, 18 Jul 2005 13:42:33 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-2.hotpop.com (Postfix) with ESMTP
	id 87FA4143C1D0; Mon, 18 Jul 2005 13:41:18 +0000 (UTC)
Date:	Mon, 18 Jul 2005 13:41:13 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	Dan Malek <dan@embeddedalley.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
References: <1121270402l.7656l.3l@cavan>
	<ecb4efd1050714171318ce81aa@mail.gmail.com> <1121415711l.5178l.3l@cavan>
	<200507151117.49012.bruno.randolf@4g-systems.biz>
	<1121680641l.13805l.1l@cavan>
	<b30d00c05783e8ed4fc6dcb29563e232@embeddedalley.com>
In-Reply-To: <b30d00c05783e8ed4fc6dcb29563e232@embeddedalley.com> (from
	dan@embeddedalley.com on Mon Jul 18 13:56:04 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121694075l.13805l.6l@cavan>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-1In5esTQ4+fo7wTOUN8/"
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8527
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: 21058
Lines: 985

--=-1In5esTQ4+fo7wTOUN8/
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> Changing from CONFIG_DMA_NONCOHERENT to CONFIG_DMA_COHERENT  make no =20
>> difference,
>=20
> It won't, because the Ethernet driver knows the hardware works
> correctly for this peripheral and assumes coherent IO.
>=20
> Any Ethernet performance differences among Au1xxx designs are
> likely to be related to processor speed, the memory interface
> configuration, or PHY issues (improperly configured or high
> error rates).

I would agree but I see 100% throughput using YAMON on the same board. =20
So it isn't the PHY or mem interface or processor speed as these are =20
all configured from YAMON.

Even if I just send out rubbish packets (no memcpy) in au1000_xmit()
I don't get any better performance.

Basically for 40% of the time the MAC DMA is not busy and TX_ENABLE pin =20
is zero.

So for whatever reason the kernel can only send 60Mbps. It is not =20
limited by the MAC, it is limited by the speed that data is getting
through the IP stack.

My test just opens a socket and continually calls sendto().

There are no errors on either the MAC or PHY.

find attached my .config. If anyone has got this working
please post your config or send it me directly

Thanks
JP

- --=20
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC27F7ZDxnKy3oOpYRAs0PAJsFnrAAZWPTGRIZbogKUfeDgtOJ0wCgkjGY
mhcq/77dvLDGXvvE5E5z3ww=3D
=3DQ7t0
-----END PGP SIGNATURE-----


--=-1In5esTQ4+fo7wTOUN8/
Content-Type: text/plain; charset=us-ascii; name=.config
Content-Disposition: attachment; filename=.config
Content-Transfer-Encoding: quoted-printable

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc3
# Mon Jul 18 14:29:38 2005
#
CONFIG_MIPS=3Dy

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=3Dy
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=3Dy
CONFIG_BROKEN_ON_SMP=3Dy
CONFIG_INIT_ENV_ARG_LIMIT=3D32

#
# General setup
#
CONFIG_LOCALVERSION=3D"-scapa"
CONFIG_SWAP=3Dy
CONFIG_SYSVIPC=3Dy
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=3Dy
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=3Dy
CONFIG_KOBJECT_UEVENT=3Dy
CONFIG_IKCONFIG=3Dy
CONFIG_IKCONFIG_PROC=3Dy
CONFIG_EMBEDDED=3Dy
CONFIG_KALLSYMS=3Dy
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=3Dy
CONFIG_BUG=3Dy
CONFIG_BASE_FULL=3Dy
CONFIG_FUTEX=3Dy
CONFIG_EPOLL=3Dy
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=3Dy
CONFIG_CC_ALIGN_FUNCTIONS=3D0
CONFIG_CC_ALIGN_LABELS=3D0
CONFIG_CC_ALIGN_LOOPS=3D0
CONFIG_CC_ALIGN_JUMPS=3D0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=3D0

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

#
# Machine selection
#
# CONFIG_MIPS_MTX1 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_PB1200 is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
CONFIG_MIPS_SCAPA=3Dy
# CONFIG_MIPS_DB1200 is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MACH_JAZZ is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_3 is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_QEMU is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP27 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_SIBYTE_SWARM is not set
# CONFIG_SIBYTE_SENTOSA is not set
# CONFIG_SIBYTE_RHONE is not set
# CONFIG_SIBYTE_CARMEL is not set
# CONFIG_SIBYTE_PTSWARM is not set
# CONFIG_SIBYTE_LITTLESUR is not set
# CONFIG_SIBYTE_CRHINE is not set
# CONFIG_SIBYTE_CRHONE is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=3Dy
CONFIG_GENERIC_CALIBRATE_DELAY=3Dy
CONFIG_HAVE_DEC_LOCK=3Dy
CONFIG_DMA_COHERENT=3Dy
CONFIG_MIPS_DISABLE_OBSOLETE_IDE=3Dy
CONFIG_CPU_BIG_ENDIAN=3Dy
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_SYS_SUPPORTS_BIG_ENDIAN=3Dy
CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=3Dy
CONFIG_SOC_AU1550=3Dy
CONFIG_SOC_AU1X00=3Dy
CONFIG_MIPS_L1_CACHE_SHIFT=3D5

#
# CPU selection
#
CONFIG_CPU_MIPS32_R1=3Dy
# CONFIG_CPU_MIPS32_R2 is not set
# CONFIG_CPU_MIPS64_R1 is not set
# CONFIG_CPU_MIPS64_R2 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_SYS_SUPPORTS_32BIT_KERNEL=3Dy
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=3Dy

#
# Kernel type
#
CONFIG_MIPS32=3Dy
# CONFIG_MIPS64 is not set
# CONFIG_64BIT is not set
CONFIG_PAGE_SIZE_4KB=3Dy
# CONFIG_PAGE_SIZE_8KB is not set
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
CONFIG_CPU_HAS_PREFETCH=3Dy
CONFIG_64BIT_PHYS_ADDR=3Dy
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=3Dy
CONFIG_CPU_HAS_SYNC=3Dy
CONFIG_ARCH_FLATMEM_ENABLE=3Dy
CONFIG_SELECT_MEMORY_MODEL=3Dy
CONFIG_FLATMEM_MANUAL=3Dy
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=3Dy
CONFIG_FLAT_NODE_MEM_MAP=3Dy
CONFIG_PREEMPT_NONE=3Dy
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_HW_HAS_PCI=3Dy
# CONFIG_PCI is not set
CONFIG_MMU=3Dy

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#

#
# Executable file formats
#
CONFIG_BINFMT_ELF=3Dy
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=3Dy
# CONFIG_BINFMT_IRIX is not set
CONFIG_SECCOMP=3Dy
# CONFIG_PM is not set

#
# Networking
#
CONFIG_NET=3Dy

#
# Networking options
#
CONFIG_PACKET=3Dy
CONFIG_PACKET_MMAP=3Dy
CONFIG_UNIX=3Dy
CONFIG_XFRM=3Dy
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=3Dy
CONFIG_INET=3Dy
CONFIG_IP_MULTICAST=3Dy
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=3Dy
CONFIG_IP_PNP=3Dy
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=3Dy
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_IP_TCPDIAG is not set
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=3Dy
# CONFIG_IPV6 is not set
# CONFIG_NETFILTER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=3Dy
CONFIG_FW_LOADER=3Dy
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=3Dy
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=3Dy
CONFIG_MTD_PARTITIONS=3Dy
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=3Dy
CONFIG_MTD_BLOCK=3Dy
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=3Dy
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=3Dy
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=3Dy
CONFIG_MTD_MAP_BANK_WIDTH_2=3Dy
CONFIG_MTD_MAP_BANK_WIDTH_4=3Dy
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=3Dy
CONFIG_MTD_CFI_I2=3Dy
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=3Dy
CONFIG_MTD_CFI_AMDSTD_RETRY=3D0
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=3Dy
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_XIP is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_ALCHEMY=3Dy
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=3Dy
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=3Dy
CONFIG_BLK_DEV_RAM_COUNT=3D1
CONFIG_BLK_DEV_RAM_SIZE=3D8192
CONFIG_BLK_DEV_INITRD=3Dy
CONFIG_INITRAMFS_SOURCE=3D"$(SANDBOX)/target"
CONFIG_INITRAMFS_ROOT_UID=3D0
CONFIG_INITRAMFS_ROOT_GID=3D0
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=3Dy
CONFIG_IOSCHED_AS=3Dy
CONFIG_IOSCHED_DEADLINE=3Dy
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#

#
# Network device support
#
CONFIG_NETDEVICES=3Dy
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=3Dy
CONFIG_MII=3Dy
CONFIG_MIPS_AU1X00_ENET=3Dy

#
# Ethernet (1000 Mbit)
#

#
# Ethernet (10000 Mbit)
#

#
# Token Ring devices
#

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=3Dy

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=3Dm
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL_NONSTANDARD=3Dy
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
# CONFIG_AU1X00_GPIO is not set
# CONFIG_TS_AU1X00_ADS7846 is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_AU1X00=3Dy
CONFIG_SERIAL_AU1X00_CONSOLE=3Dy
CONFIG_SERIAL_CORE=3Dy
CONFIG_SERIAL_CORE_CONSOLE=3Dy
CONFIG_UNIX98_PTYS=3Dy
CONFIG_LEGACY_PTYS=3Dy
CONFIG_LEGACY_PTY_COUNT=3D256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#

#
# I2C support
#
CONFIG_I2C=3Dy
CONFIG_I2C_CHARDEV=3Dy

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=3Dy
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_AU1550 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_PCA_ISA is not set
CONFIG_I2C_SENSOR=3Dy

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=3Dy
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=3Dy
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=3Dy

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_MAESTRO is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=3Dy
CONFIG_USB_ARCH_HAS_OHCI=3Dy
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# File systems
#
CONFIG_EXT2_FS=3Dy
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=3Dy
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=3Dy
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set

#
# XFS support
#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=3Dy
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=3Dy
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=3Dy
CONFIG_PROC_KCORE=3Dy
CONFIG_SYSFS=3Dy
CONFIG_DEVPTS_FS_XATTR=3Dy
CONFIG_DEVPTS_FS_SECURITY=3Dy
CONFIG_TMPFS=3Dy
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=3Dy

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=3Dy
CONFIG_JFFS2_FS_DEBUG=3D0
CONFIG_JFFS2_FS_WRITEBUFFER=3Dy
CONFIG_JFFS2_COMPRESSION_OPTIONS=3Dy
CONFIG_JFFS2_ZLIB=3Dy
CONFIG_JFFS2_RTIME=3Dy
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=3Dy
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_CRAMFS=3Dy
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=3Dy
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=3Dy
CONFIG_LOCKD=3Dy
CONFIG_NFS_COMMON=3Dy
CONFIG_SUNRPC=3Dy
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=3Dy
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=3Dy
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=3Dy

#
# Native Language Support
#
CONFIG_NLS=3Dy
CONFIG_NLS_DEFAULT=3D"iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=3Dy
CONFIG_MAGIC_SYSRQ=3Dy
CONFIG_LOG_BUF_SHIFT=3D14
CONFIG_SCHEDSTATS=3Dy
CONFIG_DEBUG_SLAB=3Dy
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
CONFIG_CROSSCOMPILE=3Dy
CONFIG_CMDLINE=3D""
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_KGDB is not set
# CONFIG_RUNTIME_DEBUG is not set
# CONFIG_MIPS_UNCACHED is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC32=3Dy
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=3Dy
CONFIG_ZLIB_DEFLATE=3Dy
CONFIG_GENERIC_HARDIRQS=3Dy
CONFIG_GENERIC_IRQ_PROBE=3Dy


--=-1In5esTQ4+fo7wTOUN8/--



From david.sanchez@lexbox.fr Mon Jul 18 15:26:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 15:26:42 +0100 (BST)
Received: from laf31-5-82-235-130-100.fbx.proxad.net ([IPv6:::ffff:82.235.130.100]:40422
	"EHLO lexbox.fr") by linux-mips.org with ESMTP id <S8226827AbVGRO0Z> convert rfc822-to-8bit;
	Mon, 18 Jul 2005 15:26:25 +0100
Subject: undefined symbol '__divdi3' & '__moddi3' on linux kernel 2.6.10  (toolchain Linuxi386/Mips32)
Date:	Mon, 18 Jul 2005 16:25:45 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Message-ID: <17AB476A04B7C842887E0EB1F268111E01551B@xpserver.intra.lexbox.org>
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
X-MS-TNEF-Correlator: 
Thread-Topic: undefined symbol '__divdi3' & '__moddi3' on linux kernel 2.6.10  (toolchain Linuxi386/Mips32)
thread-index: AcWLpJW1Crzv+XqMRBKcfve/GxMtrQ==
From:	"David Sanchez" <david.sanchez@lexbox.fr>
To:	<linux-mips@linux-mips.org>
Return-Path: <david.sanchez@lexbox.fr>
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: 8528
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: david.sanchez@lexbox.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 808
Lines: 25

Hi,

I'm a newby on Linux/Mips more my English is very poor so sorry...
But I have a big problem (for me):

I want to cross-compile my linux kernel 2.6.10 on my PC i386 for mips32
(alchemy AU1550) CPU.
I developed a module that contains some operations on types loff_t (i.e
long long) such as div and mod. The code is in a foo.c file.

I successfully built a cross toolchain using:
The bin utils (Bintuils-2.15), the glibc headers (glibc-2.3.5) and the
gcc core (gcc-3.4.4).

The compilation of the kernel works but unfortunately the link generates
two error messages on the file foo.c:
Undefined reference to '__divdi3'
Undefined reference to '__moddi3'

What I'm doing wrong ? 
Why the gcc doesn't embed the symbol implementation ? 
And so where can I found an implementation ? 

Thanks for all your help


From dchau@mazunetworks.com Mon Jul 18 15:42:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 15:42:44 +0100 (BST)
Received: from mail.mazunetworks.com ([IPv6:::ffff:4.19.249.111]:32184 "EHLO
	mail.mazunetworks.com") by linux-mips.org with ESMTP
	id <S8226827AbVGROm3>; Mon, 18 Jul 2005 15:42:29 +0100
Received: from [172.31.1.134] ([172.31.1.134])
	by mail.mazunetworks.com (8.12.11/8.12.11) with ESMTP id j6IEVXNX019481;
	Mon, 18 Jul 2005 10:31:33 -0400
Message-ID: <42DBC030.7020600@mazunetworks.com>
Date:	Mon, 18 Jul 2005 10:44:00 -0400
From:	David Chau <dchau@mazunetworks.com>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Dan Malek <dan@embeddedalley.com>
CC:	linux-mips@linux-mips.org
Subject: Re: Why is mmap()ed reserved memory so slow?
References: <42D836F8.8030209@mazunetworks.com> <dc678ee4c98d1fc3eb2cb1960b759f05@embeddedalley.com>
In-Reply-To: <dc678ee4c98d1fc3eb2cb1960b759f05@embeddedalley.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dchau@mazunetworks.com>
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: 8529
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: dchau@mazunetworks.com
Precedence: bulk
X-list: linux-mips
Content-Length: 919
Lines: 26

Dan Malek wrote:

> How about a little more info, like what kernel are you using and what are
> the parameters you are sending to mmap()?

Linux (none) 2.4.31 #412 SMP Fri Jul 15 16:26:05 EDT 2005 mips unknown
(unmodified kernel from linux-mips.org).
It's running on the SB1 on a Broadcom 1250 board.

I mmap() with:
int mem_fd = open("/dev/mem", O_RDWR);
void* mem_base =
    mmap(NULL, DRIVER_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
         mem_fd, DRIVER_MEM_PHYS_BASE);
Where driver_mem_phys_base = 253M, and driver_mem_size=1M.

> The better way to approach this is to place an mmap() function in the
> associated driver that works in conjunction with the application to gain
> shared access as you expect.  This also closes a hole where an errant
> application could write into unexpected places through /dev/mem.


Could you point me to an example of this so I can figure out how to do it?

Thanks,
David

From maillist@jg555.com Mon Jul 18 16:48:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 16:49:17 +0100 (BST)
Received: from 64-30-195-78.dsl.linkline.com ([IPv6:::ffff:64.30.195.78]:37000
	"EHLO jg555.com") by linux-mips.org with ESMTP id <S8226831AbVGRPs6>;
	Mon, 18 Jul 2005 16:48:58 +0100
Received: from [172.16.0.55] ([::ffff:172.16.0.55])
  (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by jg555.com with esmtp; Mon, 18 Jul 2005 08:50:35 -0700
  id 00234001.42DBCFCB.0000771B
Message-ID: <42DBCFB0.4070703@jg555.com>
Date:	Mon, 18 Jul 2005 08:50:08 -0700
From:	Jim Gifford <maillist@jg555.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	Linux MIPS List <linux-mips@linux-mips.org>
Subject: glibc syscall patch
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <maillist@jg555.com>
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: 8530
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: maillist@jg555.com
Precedence: bulk
X-list: linux-mips
Content-Length: 245
Lines: 10

Just an FYI, the current glibc patch to fix the creation of syscall.h is 
being help up. For those parties interested take a look at the bugzilla.

http://sources.redhat.com/bugzilla/show_bug.cgi?id=758

-- 
----
Jim Gifford
maillist@jg555.com


From giometti@enneenne.com Mon Jul 18 17:18:15 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 17:18:30 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:654 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226831AbVGRQSP>; Mon, 18 Jul 2005 17:18:15 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DuYLN-0002ri-00; Mon, 18 Jul 2005 18:19:49 +0200
Date:	Mon, 18 Jul 2005 18:19:49 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Pete Popov <ppopov@embeddedalley.com>
Cc:	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Support for (au1100) 64-bit physical address space broken on 2.6.12?
Message-ID: <20050718161949.GB28995@enneenne.com>
References: <20050716124205.GA26127@enneenne.com> <1121528575.27121.3.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb"
Content-Disposition: inline
In-Reply-To: <1121528575.27121.3.camel@localhost.localdomain>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8531
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 1464
Lines: 50


--mxv5cy4qt+RJ9ypb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 16, 2005 at 08:42:55AM -0700, Pete Popov wrote:
> I fixed this is the latest tree a couple of days ago.

Something is still wrong... I just downloaded the whole linux-mips
tree from the CVS (to avoid conflics with my local reporitory) and
after the commands:

   # make pb1100_defconfig
   # make

I get:

   arch/mips/mm/ioremap.c: In function `__ioremap':
   include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlinin=
g failed in call to '__fixup_bigphys_addr': function body not available
   arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here
   make[1]: *** [arch/mips/mm/ioremap.o] Error 1
   make: *** [arch/mips/mm] Error 2

Ciao,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--mxv5cy4qt+RJ9ypb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC29alQaTCYNJaVjMRAnI2AJ9vIhAHnIxKYovhNOueRA+CERCrvACdHldM
kTClGe9evDdiRnkS377oZaU=
=v0ub
-----END PGP SIGNATURE-----

--mxv5cy4qt+RJ9ypb--

From ppopov@embeddedalley.com Mon Jul 18 17:28:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 17:28:47 +0100 (BST)
Received: from smtp005.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.175.82]:3971
	"HELO smtp005.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226834AbVGRQ23>; Mon, 18 Jul 2005 17:28:29 +0100
Received: (qmail 20472 invoked from network); 18 Jul 2005 16:30:07 -0000
Received: from unknown (HELO ?192.168.1.107?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp005.bizmail.sc5.yahoo.com with SMTP; 18 Jul 2005 16:30:06 -0000
Subject: Re: Support for (au1100) 64-bit physical address space broken on
	2.6.12?
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20050718161949.GB28995@enneenne.com>
References: <20050716124205.GA26127@enneenne.com>
	 <1121528575.27121.3.camel@localhost.localdomain>
	 <20050718161949.GB28995@enneenne.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Mon, 18 Jul 2005 09:30:05 -0700
Message-Id: <1121704205.4903.59.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8532
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: 1149
Lines: 30

On Mon, 2005-07-18 at 18:19 +0200, Rodolfo Giometti wrote:
> On Sat, Jul 16, 2005 at 08:42:55AM -0700, Pete Popov wrote:
> > I fixed this is the latest tree a couple of days ago.
> 
> Something is still wrong... I just downloaded the whole linux-mips
> tree from the CVS (to avoid conflics with my local reporitory) and
> after the commands:
> 
>    # make pb1100_defconfig
>    # make
> 
> I get:
> 
>    arch/mips/mm/ioremap.c: In function `__ioremap':
>    include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining failed in call to '__fixup_bigphys_addr': function body not available
>    arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here
>    make[1]: *** [arch/mips/mm/ioremap.o] Error 1
>    make: *** [arch/mips/mm] Error 2

Oh, pb boards ... I haven't done any maintenance on the Pb boards in
2.6. AMD wasn't interested in moving them forward and I don't have time
to build and test kernels for so many boards, so I'm not sure what to do
with them. The db1500/1550 should build just fine. Take a look at the
kernel support for those boards, and it shouldn't be too hard to update
the pb1100.

Thanks,

Pete


From macro@linux-mips.org Mon Jul 18 17:32:16 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 17:32:32 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:62219 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226834AbVGRQcQ>; Mon, 18 Jul 2005 17:32:16 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id C213FE1C9A; Mon, 18 Jul 2005 18:33:50 +0200 (CEST)
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 00548-03; Mon, 18 Jul 2005 18:33:50 +0200 (CEST)
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 843D0E1C96; Mon, 18 Jul 2005 18:33:50 +0200 (CEST)
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 j6IGXsF5010423;
	Mon, 18 Jul 2005 18:33:54 +0200
Date:	Mon, 18 Jul 2005 17:34:03 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Rodolfo Giometti <giometti@linux.it>
Cc:	Pete Popov <ppopov@embeddedalley.com>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: Support for (au1100) 64-bit physical address space broken on
 2.6.12?
In-Reply-To: <20050718161949.GB28995@enneenne.com>
Message-ID: <Pine.LNX.4.61L.0507181729050.527@blysk.ds.pg.gda.pl>
References: <20050716124205.GA26127@enneenne.com> <1121528575.27121.3.camel@localhost.localdomain>
 <20050718161949.GB28995@enneenne.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/982/Sun Jul 17 14:45:12 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8533
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: 520
Lines: 14

On Mon, 18 Jul 2005, Rodolfo Giometti wrote:

> I get:
> 
>    arch/mips/mm/ioremap.c: In function `__ioremap':
>    include/asm-mips/mach-au1x00/ioremap.h:15: sorry, unimplemented: inlining failed in call to '__fixup_bigphys_addr': function body not available
>    arch/mips/mm/ioremap.c:28: sorry, unimplemented: called from here
>    make[1]: *** [arch/mips/mm/ioremap.o] Error 1
>    make: *** [arch/mips/mm] Error 2

 Well, "extern inline __attribute__((always_inline))" certainly makes no 
sense.  Pete?

  Maciej

From macro@linux-mips.org Mon Jul 18 18:17:56 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 18:18:11 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:59396 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226838AbVGRRRz>; Mon, 18 Jul 2005 18:17:55 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 9E85DE1C9F; Mon, 18 Jul 2005 19:19:30 +0200 (CEST)
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 07033-05; Mon, 18 Jul 2005 19:19:30 +0200 (CEST)
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 602FDE1C96; Mon, 18 Jul 2005 19:19:30 +0200 (CEST)
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 j6IHJX2J011857;
	Mon, 18 Jul 2005 19:19:34 +0200
Date:	Mon, 18 Jul 2005 18:19:43 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Andy Isaacson <adi@hexapodia.org>,
	Ralf Baechle <ralf@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: [patch 3/5] SiByte fixes for 2.6.12
In-Reply-To: <Pine.LNX.4.61L.0506301712410.28331@blysk.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.61L.0507141744040.31857@blysk.ds.pg.gda.pl>
References: <20050622230137.GA17954@broadcom.com>
 <Pine.LNX.4.61L.0506231202130.17155@blysk.ds.pg.gda.pl>
 <20050623194826.GA23653@hexapodia.org> <Pine.LNX.4.61L.0506301712410.28331@blysk.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/982/Sun Jul 17 14:45:12 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8534
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: 138
Lines: 7

On Thu, 30 Jun 2005, Maciej W. Rozycki wrote:

>  Unless there are objections I'd like to apply this patch.

 Thus it's now in.

  Maciej

From jaypee@hotpop.com Mon Jul 18 18:24:24 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 18:24:42 +0100 (BST)
Received: from smtp-out.hotpop.com ([IPv6:::ffff:38.113.3.61]:5320 "EHLO
	smtp-out.hotpop.com") by linux-mips.org with ESMTP
	id <S8226838AbVGRRYY> convert rfc822-to-8bit; Mon, 18 Jul 2005 18:24:24 +0100
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103])
	by smtp-out.hotpop.com (Postfix) with SMTP id 7CAAE1454656
	for <linux-mips@linux-mips.org>; Mon, 18 Jul 2005 17:25:52 +0000 (UTC)
Received: from cavan (unknown [62.253.252.7])
	by smtp-2.hotpop.com (Postfix) with ESMTP
	id A751A145439B; Mon, 18 Jul 2005 17:25:50 +0000 (UTC)
Date:	Mon, 18 Jul 2005 17:25:50 +0000
From:	jaypee@hotpop.com
Subject: Re: Au1550 ethernet throughput low
To:	Clem Taylor <clem.taylor@gmail.com>, linux-mips@linux-mips.org
References: <1121270402l.7656l.3l@cavan>
	<ecb4efd1050714171318ce81aa@mail.gmail.com> <1121415711l.5178l.3l@cavan>
	<200507151117.49012.bruno.randolf@4g-systems.biz>
	<1121680641l.13805l.1l@cavan> <ecb4efd105071809082628bb27@mail.gmail.com>
In-Reply-To: <ecb4efd105071809082628bb27@mail.gmail.com> (from
	clem.taylor@gmail.com on Mon Jul 18 17:08:20 2005)
X-Mailer: Balsa 2.3.3
Message-Id: <1121707552l.13805l.10l@cavan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
X-HotPOP: -----------------------------------------------
                   Sent By HotPOP.com FREE Email
             Get your FREE POP email at www.HotPOP.com
          -----------------------------------------------
Return-Path: <jaypee@hotpop.com>
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: 8535
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: 726
Lines: 34

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 18/07/05 17:08:20, Clem Taylor wrote:
> 
> Here's what I'm using... This is for the development kernel, I haven't
> created the release kernel config yet. Our board is called 'aquila' as
> referred to in the config file.
> 
>                         --Clem
> 

Thanks Clem,

I've fixed it. I turn off kernel debugging and it works a treat.
Doh! So easy.

Thank you everyone for your posts.
This was sending me round the bend.

- -- 
mailto:jaypee@hotpop.com
http://www.jaypee.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC2+YgZDxnKy3oOpYRAgM6AJ9HsvTNfyu1yUCFurAyWVUW2YRmjQCfag3c
eBMrNLBWaIzIE+ARD8GClFQ=
=413X
-----END PGP SIGNATURE-----




From giometti@enneenne.com Mon Jul 18 18:29:20 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 18:29:36 +0100 (BST)
Received: from 81-174-11-161.f5.ngi.it ([IPv6:::ffff:81.174.11.161]:16295 "EHLO
	zaigor.enneenne.com") by linux-mips.org with ESMTP
	id <S8226838AbVGRR3U>; Mon, 18 Jul 2005 18:29:20 +0100
Received: from giometti by zaigor.enneenne.com with local (Exim 3.36 #1 (Debian))
	id 1DuZS8-0005Ny-00; Mon, 18 Jul 2005 19:30:53 +0200
Date:	Mon, 18 Jul 2005 19:30:52 +0200
From:	Rodolfo Giometti <giometti@linux.it>
To:	Dan Malek <dan@embeddededge.com>
Cc:	linux-mips@linux-mips.org
Subject: Power Management for au1100 fixed! :)
Message-ID: <20050718173052.GC28995@enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com> <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9UV9rz0O2dU/yYYn"
Content-Disposition: inline
In-Reply-To: <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
Organization: Programmi e soluzioni GNU/Linux
X-PGP-Key: gpg --keyserver keyserver.penguin.de --recv-keys D25A5633
User-Agent: Mutt/1.5.6+20040722i
Return-Path: <giometti@enneenne.com>
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: 8536
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: giometti@linux.it
Precedence: bulk
X-list: linux-mips
Content-Length: 8382
Lines: 272


--9UV9rz0O2dU/yYYn
Content-Type: multipart/mixed; boundary="+xNpyl7Qekk2NvDX"
Content-Disposition: inline


--+xNpyl7Qekk2NvDX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 12, 2005 at 11:52:30AM -0700, Dan Malek wrote:
> Now that you know the reason for the change, perhaps we
> should try to make it work properly :-)

Ok, Fixed! :)

Here you can see the patch. Please note that I also fixed some type
mismatches and some comments.

Ciao,

Rodolfo

--=20

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

--+xNpyl7Qekk2NvDX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=patch-PM_CONFIG
Content-Transfer-Encoding: quoted-printable

Index: arch/mips/au1000/common/irq.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/com=
mon/irq.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- a/arch/mips/au1000/common/irq.c	2 Jul 2005 06:45:44 -0000	1.1.1.1
+++ b/arch/mips/au1000/common/irq.c	18 Jul 2005 17:16:57 -0000	1.2
@@ -83,7 +83,7 @@
 void	(*board_init_irq)(void);
=20
 #ifdef CONFIG_PM
-extern void counter0_irq(int irq, void *dev_id, struct pt_regs *regs);
+extern irqreturn_t counter0_irq(int irq, void *dev_id, struct pt_regs *reg=
s);
 #endif
=20
 static DEFINE_SPINLOCK(irq_lock);
@@ -293,29 +293,32 @@
 };
=20
 #ifdef CONFIG_PM
-void startup_match20_interrupt(void (*handler)(int, void *, struct pt_regs=
 *))
+void startup_match20_interrupt(irqreturn_t (*handler)(int, void *, struct =
pt_regs *))
 {
+	struct irq_desc *desc =3D &irq_desc[AU1000_TOY_MATCH2_INT];
+
 	static struct irqaction action;
+	memset(&action, 0, sizeof(struct irqaction));
+
 	/* This is a big problem.... since we didn't use request_irq
 	   when kernel/irq.c calls probe_irq_xxx this interrupt will
 	   be probed for usage. This will end up disabling the device :(
=20
-       Give it a bogus "action" pointer -- this will keep it from
+           Give it a bogus "action" pointer -- this will keep it from
 	   getting auto-probed!
=20
-       By setting the status to match that of request_irq() we
-       can avoid it.  --cgray
+           By setting the status to match that of request_irq() we
+           can avoid it.  --cgray
 	*/
 	action.dev_id =3D handler;
-	action.flags =3D 0;
-	action.mask =3D 0;
+	action.flags =3D SA_INTERRUPT;
+	cpus_clear(action.mask);
 	action.name =3D "Au1xxx TOY";
 	action.handler =3D handler;
 	action.next =3D NULL;
=20
-	irq_desc[AU1000_TOY_MATCH2_INT].action =3D &action;=20
-	irq_desc[AU1000_TOY_MATCH2_INT].status=20
-		 &=3D ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING | IRQ_INPROGRESS);
+	desc->action =3D &action;=20
+	desc->status &=3D ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING | IRQ_INP=
ROGRESS);
=20
 	local_enable_irq(AU1000_TOY_MATCH2_INT);
 }
Index: arch/mips/au1000/common/power.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/com=
mon/power.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- a/arch/mips/au1000/common/power.c	2 Jul 2005 06:45:44 -0000	1.1.1.1
+++ b/arch/mips/au1000/common/power.c	18 Jul 2005 17:16:57 -0000	1.2
@@ -34,11 +34,13 @@
 #include <linux/pm.h>
 #include <linux/slab.h>
 #include <linux/sysctl.h>
+#include <linux/jiffies.h>
=20
 #include <asm/string.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/system.h>
+#include <asm/cacheflush.h>
 #include <asm/mach-au1x00/au1000.h>
=20
 #ifdef CONFIG_PM
@@ -50,7 +52,7 @@
 #  define DPRINTK(fmt, args...)
 #endif
=20
-static void calibrate_delay(void);
+static void au1000_calibrate_delay(void);
=20
 extern void set_au1x00_speed(unsigned int new_freq);
 extern unsigned int get_au1x00_speed(void);
@@ -260,7 +262,7 @@
 }
=20
 static int pm_do_sleep(ctl_table * ctl, int write, struct file *file,
-		       void *buffer, size_t * len)
+		       void __user *buffer, size_t * len, loff_t *ppos)
 {
 	int retval =3D 0;
 #ifdef SLEEP_TEST_TIMEOUT
@@ -294,7 +296,7 @@
 }
=20
 static int pm_do_suspend(ctl_table * ctl, int write, struct file *file,
-			 void *buffer, size_t * len)
+			 void __user *buffer, size_t * len, loff_t *ppos)
 {
 	int retval =3D 0;
=20
@@ -313,7 +315,7 @@
=20
=20
 static int pm_do_freq(ctl_table * ctl, int write, struct file *file,
-		      void *buffer, size_t * len)
+		      void __user *buffer, size_t * len, loff_t *ppos)
 {
 	int retval =3D 0, i;
 	unsigned long val, pll;
@@ -408,14 +410,14 @@
=20
=20
 	/* We don't want _any_ interrupts other than
-	 * match20. Otherwise our calibrate_delay()
+	 * match20. Otherwise our au1000_calibrate_delay()
 	 * calculation will be off, potentially a lot.
 	 */
 	intc0_mask =3D save_local_and_disable(0);
 	intc1_mask =3D save_local_and_disable(1);
 	local_enable_irq(AU1000_TOY_MATCH2_INT);
 	spin_unlock_irqrestore(&pm_lock, flags);
-	calibrate_delay();
+	au1000_calibrate_delay();
 	restore_local_and_enable(0, intc0_mask);
 	restore_local_and_enable(1, intc1_mask);
 	return retval;
@@ -455,7 +457,7 @@
    better than 1% */
 #define LPS_PREC 8
=20
-static void calibrate_delay(void)
+static void au1000_calibrate_delay(void)
 {
 	unsigned long ticks, loopbit;
 	int lps_precision =3D LPS_PREC;
Index: arch/mips/au1000/common/time.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/develop/cvs_private/linux-mips-exadron/arch/mips/au1000/com=
mon/time.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- a/arch/mips/au1000/common/time.c	2 Jul 2005 06:45:44 -0000	1.1.1.1
+++ b/arch/mips/au1000/common/time.c	18 Jul 2005 17:16:57 -0000	1.2
@@ -63,8 +63,11 @@
 static unsigned int timerhi =3D 0, timerlo =3D 0;
=20
 #ifdef CONFIG_PM
-#define MATCH20_INC 328
-extern void startup_match20_interrupt(void (*handler)(int, void *, struct =
pt_regs *));
+#if HZ < 100 || HZ > 1000
+#error "unsupported HZ value! Must be in [100,1000]"
+#endif
+#define MATCH20_INC (328*100/HZ) /* magic number 328 is for HZ=3D100... */
+extern void startup_match20_interrupt(irqreturn_t (*handler)(int, void *, =
struct pt_regs *));
 static unsigned long last_pc0, last_match20;
 #endif
=20
@@ -116,17 +119,16 @@
 }
=20
 #ifdef CONFIG_PM
-void counter0_irq(int irq, void *dev_id, struct pt_regs *regs)
+irqreturn_t counter0_irq(int irq, void *dev_id, struct pt_regs *regs)
 {
 	unsigned long pc0;
 	int time_elapsed;
 	static int jiffie_drift =3D 0;
=20
-	kstat.irqs[0][irq]++;
 	if (au_readl(SYS_COUNTER_CNTRL) & SYS_CNTRL_M20) {
 		/* should never happen! */
-		printk(KERN_WARNING "counter 0 w status eror\n");
-		return;
+		printk(KERN_WARNING "counter 0 w status error\n");
+		return IRQ_NONE;
 	}
=20
 	pc0 =3D au_readl(SYS_TOYREAD);
@@ -163,6 +165,8 @@
 		update_process_times(user_mode(regs));
 #endif
 	}
+
+	return IRQ_HANDLED;
 }
=20
 /* When we wakeup from sleep, we have to "catch up" on all of the
@@ -439,7 +443,7 @@
 		au_sync();
 		while (au_readl(SYS_COUNTER_CNTRL) & SYS_CNTRL_M20);
=20
-		/* setup match20 to interrupt once every 10ms */
+		/* setup match20 to interrupt once every HZ */
 		last_pc0 =3D last_match20 =3D au_readl(SYS_TOYREAD);
 		au_writel(last_match20 + MATCH20_INC, SYS_TOYMATCH2);
 		au_sync();

--+xNpyl7Qekk2NvDX--

--9UV9rz0O2dU/yYYn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC2+dMQaTCYNJaVjMRAvCOAKDfiTuP5gvNW0F5q3SO+CEOSkc9uQCeND4m
i9WZ9oG6QBf0IiirzQWwYMg=
=9+GP
-----END PGP SIGNATURE-----

--9UV9rz0O2dU/yYYn--

From bryan.althouse@3phoenix.com Mon Jul 18 19:52:09 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 19:52:33 +0100 (BST)
Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:226 "EHLO
	rwcrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8226843AbVGRSwJ>; Mon, 18 Jul 2005 19:52:09 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (rwcrmhc12) with SMTP
          id <2005071818533901400353h3e>; Mon, 18 Jul 2005 18:53:40 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: mips64 crosstool
Date:	Mon, 18 Jul 2005 14:53:36 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWHZSfad2BSW7ZHSgK2kHba95oicQEYtSEA
In-Reply-To: <6097c4905071221414a929ed2@mail.gmail.com>
Message-Id: <20050718185209Z8226843-3678+3416@linux-mips.org>
To:	unlisted-recipients:; (no To-header on input)
Return-Path: <bryan.althouse@3phoenix.com>
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: 8537
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 779
Lines: 16

Many thanks to everyone who has helped me on this issue. 

I ended up abandoning the crosstool approach.  It supports mips32 well, but
not mips64.  Linux from scratch has a very good step by step procedure for
building a tool chain for mips64.  I was able to build with very little
headaches.  Unfortunately, I have not yet been able to execute any programs
compiled with the tool chain.  I'm not sure where I went wrong. 

PMC sierra is working on an update for their tool chain.  They have supplied
me with a "beta" version tool chain that has solved my problems.  Now, I am
able to compile with -mabi=64 and -lpthread.  The executable no longer
Segfaults.  Since I'm past this problem, I will probably not spend much more
time trying to build a working tool chain.

Bryan   


From linux-mips-bounce@linux-mips.org Mon Jul 18 19:59:57 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 20:00:16 +0100 (BST)
Received: from laf31-5-82-235-130-100.fbx.proxad.net ([IPv6:::ffff:82.235.130.100]:52193
	"EHLO lexbox.fr") by linux-mips.org with ESMTP id <S8226842AbVGRS75>;
	Mon, 18 Jul 2005 19:59:57 +0100
Received: from mail pickup service by lexbox.fr with Microsoft SMTPSVC;
	 Mon, 18 Jul 2005 21:00:26 +0200
Delivered-To: lexbox.fr-david.sanchez@lexbox.fr
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
Cc:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: RE: mips64 crosstool
Date:	Mon, 18 Jul 2005 21:00:26 +0200
MIME-Version: 1.0
Message-ID: <000001c58bca$f50976e0$0300a8c0@intra.lexbox.org>
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Thread-Index: AcWHZSfad2BSW7ZHSgK2kHba95oicQEYtSEA
In-Reply-To: <6097c4905071221414a929ed2@mail.gmail.com>
To:	<unlisted-recipients:>,
	<no To-header on input>,
	"IMB Recipient 1" <mspop3connector.david.sanchez@lexbox.fr>
X-archive-position: 8537
X-ecartis-version: Ecartis v1.0.0
X-original-sender: bryan.althouse@3phoenix.com
Precedence: bulk
Content-Class: urn:content-classes:message
X-list:	linux-mips
Importance: normal
Priority: normal
X-OriginalArrivalTime: 18 Jul 2005 19:00:26.0078 (UTC) FILETIME=[F50BE7E0:01C58BCA]
Return-Path: <linux-mips-bounce@linux-mips.org>
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: 8538
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 782
Lines: 19

Many thanks to everyone who has helped me on this issue. 

I ended up abandoning the crosstool approach.  It supports mips32 well, but
not mips64.  Linux from scratch has a very good step by step procedure for
building a tool chain for mips64.  I was able to build with very little
headaches.  Unfortunately, I have not yet been able to execute any programs
compiled with the tool chain.  I'm not sure where I went wrong. 

PMC sierra is working on an update for their tool chain.  They have supplied
me with a "beta" version tool chain that has solved my problems.  Now, I am
able to compile with -mabi=64 and -lpthread.  The executable no longer
Segfaults.  Since I'm past this problem, I will probably not spend much more
time trying to build a working tool chain.

Bryan   





From basicmark@yahoo.com Mon Jul 18 21:12:55 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Jul 2005 21:13:15 +0100 (BST)
Received: from web30312.mail.mud.yahoo.com ([IPv6:::ffff:68.142.201.230]:47990
	"HELO web30312.mail.mud.yahoo.com") by linux-mips.org with SMTP
	id <S8226846AbVGRUMz>; Mon, 18 Jul 2005 21:12:55 +0100
Received: (qmail 82567 invoked by uid 60001); 18 Jul 2005 20:14:29 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=riu4F9OdGAziNtIxucR+RC2zE/TUcK29IKdphzY/aTT63+kiwBy5nf0wLZaduzK8z3DXhE6NzlVMyjXokEvdaW0IRhGJhzkrxhuXs2i2urIqUYkLRj4Ixuz0ussSzzzDx4wUrj11Ljsd6VCqwLW83Unr2/SMuZ/XloAkwp01Dqg=  ;
Message-ID: <20050718201429.82565.qmail@web30312.mail.mud.yahoo.com>
Received: from [62.253.64.19] by web30312.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 21:14:28 BST
Date:	Mon, 18 Jul 2005 21:14:28 +0100 (BST)
From:	Mark Underwood <basicmark@yahoo.com>
Subject: Linux 2.6.11.5 on R3912 problems
To:	LKML <linux-kernel@vger.kernel.org>,
	'Linux/MIPS Development' <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <basicmark@yahoo.com>
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: 8539
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: basicmark@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 4273
Lines: 129

Hi,

I have now been trying to get Linux 2.6.11.5 (built
with gcc 3.3.3 and binutils 2.15.91.0.2) up and
running on my Helio PDA, a MIPS R3912 based ASSP (the
emulator to be exact) and have been stuck at the last
step for a while now :-(. 

The kernel runs up fine, the problem starts when init
is started. Bellow is my kernel log up to freeing
init.

Uncompressing
Linux............................................
done, booting the kernel.
done decompressing kernel.
e_entry: 8016b000, e_ehsize: 52, e_phentsize 32,
e_phnum 2,
e_shentsize 40, e_shnum 25
copying 0x10c320 bytes from file offset 0x80 to
address 0x80040000
zeroing from 8014c320 to to 8014c320, 0x0 bytes
copying 0x36084 bytes from file offset 0x10e000 to
address 0x8014e000
zeroing from 80184084 to to 80198b58, 0x14ad4 bytes
done loading kernel, about to jump in!
mips_machgroup 0x00000017, mips_machtype 0x00000000
arcs_cmdline: root=1f01 console=ttyS0,115200n8
Linux version 2.6.11.5 (mark@stargate) (gcc version
3.3.3) #297 Mon Jul 18 20:19
:39 UTC 2005
V nasty hack. The Emulator doesn't report which subset
of the TX39 family it bel
ongs to :,-(. I hope the hardware does!
Forcing cpu type to CPU_TX3912
CPU revision is: 00002200
Determined physical RAM map:
 memory: 00267000 @ 00199000 (usable)
 memory: 00400000 @ 02000000 (usable)
 memory: 00200000 @ 9fc00000 (ROM data)
Built 1 zonelists
Kernel command line: root=1f01 console=ttyS0,115200n8
Primary instruction cache 1kB, linesize 16 bytes
Primary data cache 1kB, linesize 4 bytes
Synthesized TLB handler (17 instructions).
Synthesized TLB load handler fastpath (37
instructions).
Synthesized TLB store handler fastpath (37
instructions).
Synthesized TLB modify handler fastpath (29
instructions).
PID hash table entries: 256 (order: 8, 4096 bytes)
r39xx_set_termios
Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
Memory: 6168k/6556k available (981k kernel code, 348k
reserved, 212k data, 104k
init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
Checking for 'wait' instruction...  unavailable.
cpu_wait = 0x0
Linux NoNET1.0 for Linux 2.6
schedule = 0x801327f8. ret = 0
Can't analyze prologue code at 80133ea0
schedule_timeout = 0x80133ea0. ret = -1
sleep_on = 0x8013395c. ret = 0
sleep_on_timeout = 0x80133a54. ret = 0
wait_for_completion = 0x80133148. ret = 0
Serial: r39xx internal UART driver $
r39xx_config_port
r39xx_request_port
ttyS0 at MMIO 0x0r39xx_type
 (irq = 74) is a R39XX
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
Helio Boot ROM: 0x00200000 at 0x9fc00000
helio_mtd_map.virt 0x9fc00000
Helio Boot ROM: probing for ROM
Creating 2 MTD partitions on "Helio Boot ROM":
0x00000000-0x00097eec : "Bootloader + Kernel"
mtd: Giving out device 0 to Bootloader + Kernel
0x00097eec-0x0013deec : "cramfs Filesystem"
mtd: Giving out device 1 to cramfs Filesystem
block2mtd: version $Revision: 1.23 $
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 104k freed

I have had to write a UART driver so I thought the
problem might be with that so I put lots of debug in
tty layer, serial_core and my driver to see what was
going on. After doing this and changing the interrupt
handler (int-handler.S) I saw the echo that I had put
in my inittab.
So I started to remove debug and found it stopped
working. The strange thing is that it stops before it
gets as far as sending the echo from inittab.
If I don’t have enough debug the kernel stops just
before printing out:

Algorithmics/MIPS FPU Emulator v1.5

When I connect to the emulator with GDB and look at
the registers I find the CPU is still running and is
in cpu_idle.
I wondered if it might be a timer/task scheduler
related problem but as it gets passed the bogomips
calculation the timer must be working.

Any help would be great as I have been stuck here for
a while.

Many Thanks,

Mark



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

From dan@embeddedalley.com Tue Jul 19 02:00:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 02:01:01 +0100 (BST)
Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:1292 "EHLO
	penguin.netx4.com") by linux-mips.org with ESMTP
	id <S8226852AbVGSBAp>; Tue, 19 Jul 2005 02:00:45 +0100
Received: from [192.168.253.28] (tibook.embeddededge.com [192.168.253.28])
	by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id j6J0m3mN007940;
	Mon, 18 Jul 2005 20:48:04 -0400
In-Reply-To: <20050718173052.GC28995@enneenne.com>
References: <20050712142202.GB9234@gundam.enneenne.com> <20050712181013.GC9234@gundam.enneenne.com> <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com> <20050718173052.GC28995@enneenne.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1f5157240f623e21b61131958e19042d@embeddedalley.com>
Content-Transfer-Encoding: 7bit
Cc:	linux-mips@linux-mips.org
From:	Dan Malek <dan@embeddedalley.com>
Subject: Re: Power Management for au1100 fixed! :)
Date:	Mon, 18 Jul 2005 21:02:28 -0400
To:	Rodolfo Giometti <giometti@linux.it>
X-Mailer: Apple Mail (2.622)
Return-Path: <dan@embeddedalley.com>
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: 8540
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@embeddedalley.com
Precedence: bulk
X-list: linux-mips
Content-Length: 235
Lines: 14


On Jul 18, 2005, at 1:30 PM, Rodolfo Giometti wrote:

> Ok, Fixed! :)

Thanks.

> Here you can see the patch. Please note that I also fixed some type
> mismatches and some comments.

Looks good.  I asked Pete to push it in.

	-- Dan


From michaelanburaj@hotmail.com Tue Jul 19 07:41:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 07:41:54 +0100 (BST)
Received: from bay107-f33.bay107.hotmail.com ([IPv6:::ffff:64.4.51.43]:48822
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8226856AbVGSGlg>; Tue, 19 Jul 2005 07:41:36 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 18 Jul 2005 23:43:17 -0700
Message-ID: <BAY107-F3324FE3490CA2192FD631BC9D40@phx.gbl>
Received: from 64.4.51.220 by by107fd.bay107.hotmail.msn.com with HTTP;
	Tue, 19 Jul 2005 06:43:17 GMT
X-Originating-IP: [64.4.51.220]
X-Originating-Email: [michaelanburaj@hotmail.com]
X-Sender: michaelanburaj@hotmail.com
In-Reply-To: <20030510194942.GH27494@lug-owl.de>
From:	"Michael Anburaj" <michaelanburaj@hotmail.com>
To:	linux-mips@linux-mips.org
Cc:	embeddedeng@yahoo.com
Subject: Re: 4kc machine check
Date:	Mon, 18 Jul 2005 23:43:17 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 19 Jul 2005 06:43:17.0714 (UTC) FILETIME=[254CE320:01C58C2D]
Return-Path: <michaelanburaj@hotmail.com>
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: 8541
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: michaelanburaj@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6170
Lines: 167

Hi,

I am seeing what Greg Weeks saw and emailed couple of months back.

source: linux-mips CVS source pulled using TAGS <linux_2_6_11 through 
linux_2_6_12>\
Board: MIPS 4Kc Atlas
Bootloader: Redboot or YAMON
kernel parameters: console=ttyS0,115200 rd_start=0x80400000 rd_size=0x3f0ffc
kernel load address: 0x80100000 ~ 0x803xxxxx
ramdisk image: 0x80400000 ~ 0x807fcfff

I tried couple of linux-mips CVS versions & these are the results:

version linux_2_6_12 & newer do not print any messages on the console, but 
causes an exception. verions between linux_2_6_11 & linux_2_6_12 (all the 
_r1,2,3s), when loading the ramdisk (initrd) it fails (console dump included 
at the bottom).

I tried loading compressed and non-compressed ext2 files as ramdisk – but 
the problem stays. I don’t know if this is due to something I am doing wrong 
or it’s a known issue.

Please help me!

Thanks,
-Mike.

Clipping from the console:

LINUX started...
Linux version 2.6.10-rc2 (root@localhost.localdomain) (gcc version 2.95.4 
200105CPU revision is: 00018001
Determined physical RAM map:
memory: 00001000 @ 00000000 (reserved)
memory: 000ff000 @ 00001000 (ROM data)
memory: 00286000 @ 00100000 (reserved)
memory: 00c7a000 @ 00386000 (usable)
Initial ramdisk at: 0x80400000 (4182015 bytes)
Built 1 zonelists
Kernel command line: console=ttyS0,115200 rd_start=0x80400000 
rd_size=0x3fcfff
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, linesize 16 bytes.
Synthesized TLB handler (19 instructions).
PID hash table entries: 128 (order: 7, 2048 bytes)
CPU frequency 80.00 MHz
Using 40.000 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 8020k/12776k available (1776k kernel code, 4736k reserved, 379k 
data, 3)Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction...  available.
checking if image is initramfs...it isn't (bad gzip magic numbers); looks 
like dFreeing initrd memory: 4083k freed
NET: Registered protocol family 16
Can't analyze prologue code at 802ba92c
SCSI subsystem initialized
PCI: Bus 1, bridge: 0000:00:0f.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
??ttyS0 at I/O 0x1f000900 (irq = 1) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4084KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing prom memory: 1020kb freed
Freeing unused kernel memory: 1364k freed
Got mcheck at 0042ebec
Cpu 0
$ 0   : 00000000 1000fc00 00000000 0048b1b6
$ 4   : 1000f209 0048b1a0 00000063 00000000
$ 8   : 0004a770 00405481 2aaad47c 2abe4828
$12   : 00000309 0ab969fb 00000001 2abe6df8
$16   : 1000f1ec 7fff79c0 1000f2ec 1000f1e8
$20   : 7fff7f24 00000002 00000000 00430000
$24   : 2abe1798 2ac29770
$28   : 1000a6e0 7fff75a0 004069a0 0042eb8c
Hi    : 00000224
Lo    : 0002a9b1
epc   : 0042ebec 0x42ebec     Not tainted
ra    : 0042eb8c 0x42eb8c
Status: 0020fc13    USER EXL IE
Cause : 00800060
PrId  : 00018001

Index:  0 pgmask=4kb va=2ab3c000 asid=17
                        [pa=009d3000 c=3 d=0 v=1 g=0]
                        [pa=00000000 c=0 d=0 v=0 g=0]

Index:  1 pgmask=4kb va=2aaac000 asid=17
                        [pa=0036b000 c=3 d=0 v=1 g=0]
                        [pa=0031d000 c=3 d=0 v=1 g=0]

Index:  2 pgmask=4kb va=0042e000 asid=17
                        [pa=00014000 c=3 d=0 v=1 g=0]
                        [pa=0055e000 c=3 d=0 v=0 g=0]

Index:  3 pgmask=4kb va=2ac2a000 asid=17
                        [pa=00013000 c=3 d=0 v=0 g=0]
                        [pa=00015000 c=3 d=0 v=1 g=0]

Index:  4 pgmask=4kb va=2aaa8000 asid=17
                        [pa=00c4e000 c=3 d=0 v=1 g=0]
                        [pa=00004000 c=3 d=0 v=1 g=0]

Index:  5 pgmask=4kb va=2aaec000 asid=17
                        [pa=00369000 c=3 d=0 v=1 g=0]
                        [pa=00c53000 c=3 d=0 v=1 g=0]

Index:  6 pgmask=4kb va=2abe6000 asid=17
                        [pa=009dd000 c=3 d=0 v=0 g=0]
                        [pa=00c44000 c=3 d=0 v=1 g=0]

Index:  7 pgmask=4kb va=7fff6000 asid=17
                        [pa=00000000 c=0 d=0 v=0 g=0]
                        [pa=0033e000 c=3 d=1 v=1 g=0]

Index:  8 pgmask=4kb va=1000e000 asid=17
                        [pa=0001c000 c=3 d=0 v=0 g=0]
                        [pa=0001a000 c=3 d=0 v=1 g=0]

Index:  9 pgmask=4kb va=0048a000 asid=17
                        [pa=00349000 c=3 d=0 v=0 g=0]
                        [pa=0055f000 c=3 d=0 v=1 g=0]

Index: 10 pgmask=4kb va=2ac28000 asid=17
                        [pa=009cc000 c=3 d=0 v=0 g=0]
                        [pa=0085c000 c=3 d=0 v=1 g=0]

Index: 11 pgmask=4kb va=10002000 asid=17
                        [pa=00021000 c=3 d=1 v=1 g=0]
                        [pa=00556000 c=3 d=0 v=0 g=0]

Index: 12 pgmask=4kb va=00404000 asid=17
                        [pa=00c40000 c=3 d=0 v=0 g=0]
                        [pa=00c41000 c=3 d=0 v=1 g=0]

Index: 13 pgmask=4kb va=2abe4000 asid=17
                        [pa=00c43000 c=3 d=0 v=1 g=0]
                        [pa=009db000 c=3 d=0 v=0 g=0]

Index: 15 pgmask=4kb va=2ab90000 asid=17
                        [pa=00363000 c=3 d=0 v=1 g=0]
                        [pa=0000d000 c=3 d=0 v=1 g=0]

Kernel panic - not syncing: Caught Machine Check exception - caused by 
multiple.



From ppopov@embeddedalley.com Tue Jul 19 08:05:45 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 08:06:05 +0100 (BST)
Received: from smtp007.bizmail.sc5.yahoo.com ([IPv6:::ffff:66.163.170.10]:18794
	"HELO smtp007.bizmail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8226859AbVGSHFp>; Tue, 19 Jul 2005 08:05:45 +0100
Received: (qmail 56861 invoked from network); 19 Jul 2005 07:07:26 -0000
Received: from unknown (HELO ?192.168.1.100?) (ppopov@embeddedalley.com@63.194.214.47 with plain)
  by smtp007.bizmail.sc5.yahoo.com with SMTP; 19 Jul 2005 07:07:26 -0000
Subject: Re: Power Management for au1100 fixed! :)
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Dan Malek <dan@embeddedalley.com>
Cc:	Rodolfo Giometti <giometti@linux.it>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <1f5157240f623e21b61131958e19042d@embeddedalley.com>
References: <20050712142202.GB9234@gundam.enneenne.com>
	 <20050712181013.GC9234@gundam.enneenne.com>
	 <a2882b70a3d6c0f32728086e0c63764c@embeddededge.com>
	 <20050718173052.GC28995@enneenne.com>
	 <1f5157240f623e21b61131958e19042d@embeddedalley.com>
Content-Type: text/plain
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 19 Jul 2005 00:07:24 -0700
Message-Id: <1121756845.7285.69.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@embeddedalley.com>
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: 8542
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: 425
Lines: 17

On Mon, 2005-07-18 at 21:02 -0400, Dan Malek wrote:
> On Jul 18, 2005, at 1:30 PM, Rodolfo Giometti wrote:
> 
> > Ok, Fixed! :)
> 
> Thanks.
> 
> > Here you can see the patch. Please note that I also fixed some type
> > mismatches and some comments.
> 
> Looks good.  I asked Pete to push it in.

arch/mips/au1000/common/irq.c didn't apply cleanly. I applied it
manually. Rodolfo, do a cvs update and give it a try :)

Pete


From david.sanchez@lexbox.fr Tue Jul 19 10:41:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 10:41:27 +0100 (BST)
Received: from laf31-5-82-235-130-100.fbx.proxad.net ([IPv6:::ffff:82.235.130.100]:62961
	"EHLO lexbox.fr") by linux-mips.org with ESMTP id <S8226859AbVGSJlI> convert rfc822-to-8bit;
	Tue, 19 Jul 2005 10:41:08 +0100
Subject: RE: undefined symbol '__divdi3' & '__moddi3' on linux kernel 2.6.10  (toolchain Linuxi386/Mips32)
Date:	Tue, 19 Jul 2005 11:40:32 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-ID: <17AB476A04B7C842887E0EB1F268111E015520@xpserver.intra.lexbox.org>
X-MS-Has-Attach: 
Content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Thread-Topic: undefined symbol '__divdi3' & '__moddi3' on linux kernel 2.6.10  (toolchain Linuxi386/Mips32)
thread-index: AcWLpJW1Crzv+XqMRBKcfve/GxMtrQAoPf+g
From:	"David Sanchez" <david.sanchez@lexbox.fr>
To:	"David Sanchez" <david.sanchez@lexbox.fr>
Cc:	<linux-mips@linux-mips.org>
Return-Path: <david.sanchez@lexbox.fr>
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: 8543
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: david.sanchez@lexbox.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 1330
Lines: 36


As you can see I'm a real newby so I take a long time to find the macro do_div() in the linux kernel. This macro does all I want and using it will avoid gcc to emits the symbols '__divdi3' and '__moddi3'...

Thanks

-----Message d'origine-----
De : linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] De la part de David Sanchez
Envoyé : lundi 18 juillet 2005 16:30
À : linux-mips@linux-mips.org
Objet : undefined symbol '__divdi3' & '__moddi3' on linux kernel 2.6.10 (toolchain Linuxi386/Mips32)

Hi,

I'm a newby on Linux/Mips more my English is very poor so sorry...
But I have a big problem (for me):

I want to cross-compile my linux kernel 2.6.10 on my PC i386 for mips32
(alchemy AU1550) CPU.
I developed a module that contains some operations on types loff_t (i.e
long long) such as div and mod. The code is in a foo.c file.

I successfully built a cross toolchain using:
The bin utils (Bintuils-2.15), the glibc headers (glibc-2.3.5) and the
gcc core (gcc-3.4.4).

The compilation of the kernel works but unfortunately the link generates
two error messages on the file foo.c:
Undefined reference to '__divdi3'
Undefined reference to '__moddi3'

What I'm doing wrong ? 
Why the gcc doesn't embed the symbol implementation ? 
And so where can I found an implementation ? 

Thanks for all your help


From nsekhar@ti.com Tue Jul 19 11:02:21 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 11:02:43 +0100 (BST)
Received: from go4.ext.ti.com ([IPv6:::ffff:192.91.75.132]:4817 "EHLO
	go4.ext.ti.com") by linux-mips.org with ESMTP id <S8226859AbVGSKCV> convert rfc822-to-8bit;
	Tue, 19 Jul 2005 11:02:21 +0100
Received: from dlep52.itg.ti.com ([157.170.170.57])
	by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j6JA44mg023968
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 05:04:04 -0500 (CDT)
Received: from dlep90.itg.ti.com (localhost [127.0.0.1])
	by dlep52.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6JA43dn011191
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 05:04:04 -0500 (CDT)
Received: from dbde01.ent.ti.com (localhost [127.0.0.1])
	by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j6JA42cE028059
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 05:04:03 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: Updating RTC with date command
Date:	Tue, 19 Jul 2005 15:34:01 +0530
Message-ID: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Updating RTC with date command
Thread-Index: AcWMSPfolCjiFsEMTcyVqhslHFL+aA==
From:	"Nori, Soma Sekhar" <nsekhar@ti.com>
To:	<linux-mips@linux-mips.org>
Return-Path: <nsekhar@ti.com>
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: 8544
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: nsekhar@ti.com
Precedence: bulk
X-list: linux-mips
Content-Length: 899
Lines: 25


Hi,

I am trying to add RTC (ds1338) support to 2.6.10 mips kernel
running on my 4kec board.

I have populated the rtc_{get|set}_time and rtc_set_mmss pointers 
and the date command shows the time correctly (as read from the RTC).

However, when I try to update the time using date -s <time string> 
the RTC does not get updated. (shows the old time when I boot-up again)

In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
but that call is made only when STA_UNSYNC is _not_ set in time_status
variable. do_settimeofday/sys_stime _set_ this flag so the timer 
interrupt does not call rtc_set_mmss. 	

In all, I could not figure out any other invocation of rtc_set_time or 
rtc_set_mmss which could be setting the time in my case.

Can somebody please help me understand how the RTC is supposed to be
updated after user changes the time using the date command?

Thanks,
Sekhar Nori

From macro@linux-mips.org Tue Jul 19 13:00:44 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 13:01:02 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:21512 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226868AbVGSMAo>; Tue, 19 Jul 2005 13:00:44 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 1A80EE1CBF; Tue, 19 Jul 2005 14:02:22 +0200 (CEST)
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 13276-08; Tue, 19 Jul 2005 14:02:21 +0200 (CEST)
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 DC09FE1CBD; Tue, 19 Jul 2005 14:02:21 +0200 (CEST)
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 j6JC2ONo022206;
	Tue, 19 Jul 2005 14:02:24 +0200
Date:	Tue, 19 Jul 2005 13:02:30 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Michael Anburaj <michaelanburaj@hotmail.com>
Cc:	linux-mips@linux-mips.org, embeddedeng@yahoo.com
Subject: Re: 4kc machine check
In-Reply-To: <BAY107-F3324FE3490CA2192FD631BC9D40@phx.gbl>
Message-ID: <Pine.LNX.4.61L.0507191301220.10363@blysk.ds.pg.gda.pl>
References: <BAY107-F3324FE3490CA2192FD631BC9D40@phx.gbl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/984/Tue Jul 19 11:16:09 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8545
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: 193
Lines: 9

On Mon, 18 Jul 2005, Michael Anburaj wrote:

> I am seeing what Greg Weeks saw and emailed couple of months back.
[...]
> Please help me!

 There was a patch send then, wasn't there?

  Maciej

From bryan.althouse@3phoenix.com Tue Jul 19 14:51:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 14:51:39 +0100 (BST)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:21998 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8226926AbVGSNvW>; Tue, 19 Jul 2005 14:51:22 +0100
Received: from ba3pi (pcp0010731669pcs.howard01.md.comcast.net[69.243.71.130])
          by comcast.net (sccrmhc11) with SMTP
          id <2005071913530001100qj8uce>; Tue, 19 Jul 2005 13:53:01 +0000
From:	"Bryan Althouse" <bryan.althouse@3phoenix.com>
To:	"'Linux/MIPS Development'" <linux-mips@linux-mips.org>
Subject: remote debugging: "Reply contains invalid hex digit 59"
Date:	Tue, 19 Jul 2005 09:52:57 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcWMaSsvbERBhjYxS7eDdrjjDpDV1Q==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Message-Id: <20050719135122Z8226926-3678+3493@linux-mips.org>
Return-Path: <bryan.althouse@3phoenix.com>
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: 8546
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: bryan.althouse@3phoenix.com
Precedence: bulk
X-list: linux-mips
Content-Length: 735
Lines: 27


Is anyone doing remote debugging for mips?  

I start the gdbserver on mips with:  
    gdbserver 192.168.2.39:2222 ./hello_loop
This produces:
    Process ./hello_loop created; pid = 158

On my PC, I type:
    ddd --debugger mips64-linux-gnu-gdb hello_loop
    (at gdb prompt) target remote 192.168.2.55:2222

This produces:
    (on gdb prompt) Couldn't establish connection to remote target
     Reply contains invalid hex digit 59
    (on mips) Remote debugging from host 192.168.2.39
     Readchar: Got EOF
     Remote side has terminated connection.  GDBserver will reopen the
connection. 

This problem is also described here:
http://mailman.uclinux.org/pipermail/uclinux-dev/2004-April/025421.html

Any ideas?  Thanks!

Bryan


From ralf@linux-mips.org Tue Jul 19 14:56:58 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 14:57:14 +0100 (BST)
Received: from localhost.localdomain ([IPv6:::ffff:127.0.0.1]:34777 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226929AbVGSN46>; Tue, 19 Jul 2005 14:56:58 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6ILq4md005132
	for <linux-mips@linux-mips.org>; Mon, 18 Jul 2005 17:52:05 -0400
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6IApltD001128;
	Mon, 18 Jul 2005 06:51:47 -0400
Date:	Mon, 18 Jul 2005 06:51:47 -0400
From:	Ralf Baechle <ralf@linux-mips.org>
To:	David Chau <dchau@mazunetworks.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Why is mmap()ed reserved memory so slow?
Message-ID: <20050718105147.GA12254@linux-mips.org>
References: <42D836F8.8030209@mazunetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42D836F8.8030209@mazunetworks.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8547
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1006
Lines: 26

On Fri, Jul 15, 2005 at 06:21:44PM -0400, David Chau wrote:

> I'm working on a driver for the Broadcom 1250, and I am using reserved 
> memory for some data buffers. The board comes with 256 MB of RAM, so I 
> boot Linux with "mem=253M" to reserve some RAM at the top of memory, and 
> then mmap() /dev/mem starting at 253 MB.
> 
> The problem is that accessing this memory is ridiculously slow. A simple 
> benchmark revealed that it takes about 200 cycles to read a 64-bit 
> number.

mmap will create uncached mappings for anything above the highest RAM
address.

> If I mmap() /dev/zero instead, a read takes under 3 cycles.

Because you have a cache hits.  No RAM is that fast.

Above 200 cycles really is how horribly slow RAM is compared to a moderatly
clocked system.

> For those of you who knows how the Linux VM works, could you tell me why 
> the memory access is so slow? It look like it might be invoking the 
> page-fault handler on every read. How can I make memory access faster?

  Ralf

From ralf@linux-mips.org Tue Jul 19 15:29:22 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 15:29:38 +0100 (BST)
Received: from localhost.localdomain ([IPv6:::ffff:127.0.0.1]:38365 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226872AbVGSO3W>; Tue, 19 Jul 2005 15:29:22 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6JEVBVI006296;
	Tue, 19 Jul 2005 10:31:11 -0400
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6JEVAj5006295;
	Tue, 19 Jul 2005 10:31:10 -0400
Date:	Tue, 19 Jul 2005 10:31:10 -0400
From:	Ralf Baechle <ralf@linux-mips.org>
To:	"Nori, Soma Sekhar" <nsekhar@ti.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
Message-ID: <20050719143110.GD3108@linux-mips.org>
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8548
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1017
Lines: 25

On Tue, Jul 19, 2005 at 03:34:01PM +0530, Nori, Soma Sekhar wrote:

> I am trying to add RTC (ds1338) support to 2.6.10 mips kernel
> running on my 4kec board.
> 
> I have populated the rtc_{get|set}_time and rtc_set_mmss pointers 
> and the date command shows the time correctly (as read from the RTC).
> 
> However, when I try to update the time using date -s <time string> 
> the RTC does not get updated. (shows the old time when I boot-up again)
> 
> In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
> but that call is made only when STA_UNSYNC is _not_ set in time_status
> variable. do_settimeofday/sys_stime _set_ this flag so the timer 
> interrupt does not call rtc_set_mmss. 	
> 
> In all, I could not figure out any other invocation of rtc_set_time or 
> rtc_set_mmss which could be setting the time in my case.
> 
> Can somebody please help me understand how the RTC is supposed to be
> updated after user changes the time using the date command?

Not at all.  Try man hwclock.

  Ralf

From alex.gonzalez@packetvision.com Tue Jul 19 15:31:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 15:32:00 +0100 (BST)
Received: from mra03.ch.as12513.net ([IPv6:::ffff:82.153.252.25]:55711 "EHLO
	mra03.ch.as12513.net") by linux-mips.org with ESMTP
	id <S8226872AbVGSObl>; Tue, 19 Jul 2005 15:31:41 +0100
Received: from localhost (localhost [127.0.0.1])
	by mra03.ch.as12513.net (Postfix) with ESMTP id 4EAC7D421C
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 15:33:20 +0100 (BST)
Received: from mra03.ch.as12513.net ([127.0.0.1])
 by localhost (mra03.ch.as12513.net [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 01860-01-4 for <linux-mips@linux-mips.org>;
 Tue, 19 Jul 2005 15:33:19 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra03.ch.as12513.net (Postfix) with ESMTP id 03782D4291
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 15:33:17 +0100 (BST)
Subject: Re: remote debugging: "Reply contains invalid hex digit 59"
From:	Alex Gonzalez <alex.gonzalez@packetvision.com>
To:	linux-mips@linux-mips.org
In-Reply-To: <1121783462.12629.10.camel@euskadi.packetvision>
References: <20050719135122Z8226926-3678+3493@linux-mips.org>
	 <1121783462.12629.10.camel@euskadi.packetvision>
Content-Type: text/plain
Message-Id: <1121783718.12629.12.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Tue, 19 Jul 2005 15:35:19 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <alex.gonzalez@packetvision.com>
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: 8549
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: alex.gonzalez@packetvision.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1230
Lines: 39

I have seen something similar in our platform when the gdb on the host
computer was not compiled correctly.

For example it may be cross-compiled for mips n32 while the gdbserver is
compiled for o32, or similar incompatibilities.

I would double check that the toolchains used to compile the host gdb
and target gdbserver match.

Alex
> 
> On Tue, 2005-07-19 at 14:52, Bryan Althouse wrote:
> > Is anyone doing remote debugging for mips?  
> > 
> > I start the gdbserver on mips with:  
> >     gdbserver 192.168.2.39:2222 ./hello_loop
> > This produces:
> >     Process ./hello_loop created; pid = 158
> > 
> > On my PC, I type:
> >     ddd --debugger mips64-linux-gnu-gdb hello_loop
> >     (at gdb prompt) target remote 192.168.2.55:2222
> > 
> > This produces:
> >     (on gdb prompt) Couldn't establish connection to remote target
> >      Reply contains invalid hex digit 59
> >     (on mips) Remote debugging from host 192.168.2.39
> >      Readchar: Got EOF
> >      Remote side has terminated connection.  GDBserver will reopen the
> > connection. 
> > 
> > This problem is also described here:
> > http://mailman.uclinux.org/pipermail/uclinux-dev/2004-April/025421.html
> > 
> > Any ideas?  Thanks!
> > 
> > Bryan
> > 


From linux-mips@packetvision.com Tue Jul 19 15:32:29 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 15:32:55 +0100 (BST)
Received: from mra03.ch.as12513.net ([IPv6:::ffff:82.153.252.25]:29344 "EHLO
	mra03.ch.as12513.net") by linux-mips.org with ESMTP
	id <S8226872AbVGSOc2>; Tue, 19 Jul 2005 15:32:28 +0100
Received: from localhost (localhost [127.0.0.1])
	by mra03.ch.as12513.net (Postfix) with ESMTP id CBFC1D42D2
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 15:34:07 +0100 (BST)
Received: from mra03.ch.as12513.net ([127.0.0.1])
 by localhost (mra03.ch.as12513.net [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id 03382-01-8 for <linux-mips@linux-mips.org>;
 Tue, 19 Jul 2005 15:34:06 +0100 (BST)
Received: from euskadi.packetvision (unknown [82.152.104.245])
	by mra03.ch.as12513.net (Postfix) with ESMTP id 0A751D4514
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 15:34:06 +0100 (BST)
Subject: Re: remote debugging: "Reply contains invalid hex digit 59"
From:	Alex Gonzalez <linux-mips@packetvision.com>
To:	'Linux/MIPS Development' <linux-mips@linux-mips.org>
In-Reply-To: <20050719135122Z8226926-3678+3493@linux-mips.org>
References: <20050719135122Z8226926-3678+3493@linux-mips.org>
Content-Type: text/plain
Message-Id: <1121783767.12629.14.camel@euskadi.packetvision>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) 
Date:	Tue, 19 Jul 2005 15:36:07 +0100
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk
Return-Path: <linux-mips@packetvision.com>
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: 8550
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: 1175
Lines: 40

I have seen something similar in our platform when the gdb on the host
computer was not compiled correctly.

For example it may be cross-compiled for mips n32 while the gdbserver is
compiled for o32, or similar incompatibilities.

I would double check that the toolchains used to compile the host gdb
and target gdbserver match.

Alex

On Tue, 2005-07-19 at 14:52, Bryan Althouse wrote:
> Is anyone doing remote debugging for mips?  
> 
> I start the gdbserver on mips with:  
>     gdbserver 192.168.2.39:2222 ./hello_loop
> This produces:
>     Process ./hello_loop created; pid = 158
> 
> On my PC, I type:
>     ddd --debugger mips64-linux-gnu-gdb hello_loop
>     (at gdb prompt) target remote 192.168.2.55:2222
> 
> This produces:
>     (on gdb prompt) Couldn't establish connection to remote target
>      Reply contains invalid hex digit 59
>     (on mips) Remote debugging from host 192.168.2.39
>      Readchar: Got EOF
>      Remote side has terminated connection.  GDBserver will reopen the
> connection. 
> 
> This problem is also described here:
> http://mailman.uclinux.org/pipermail/uclinux-dev/2004-April/025421.html
> 
> Any ideas?  Thanks!
> 
> Bryan
> 



From drow@nevyn.them.org Tue Jul 19 15:37:28 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 15:37:50 +0100 (BST)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:32391 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8226878AbVGSOh2>;
	Tue, 19 Jul 2005 15:37:28 +0100
Received: from drow by nevyn.them.org with local (Exim 4.52)
	id 1DutFX-0000zC-2P; Tue, 19 Jul 2005 10:39:11 -0400
Date:	Tue, 19 Jul 2005 10:39:11 -0400
From:	Daniel Jacobowitz <dan@debian.org>
To:	Bryan Althouse <bryan.althouse@3phoenix.com>
Cc:	'Linux/MIPS Development' <linux-mips@linux-mips.org>
Subject: Re: remote debugging: "Reply contains invalid hex digit 59"
Message-ID: <20050719143911.GA3684@nevyn.them.org>
References: <20050719135122Z8226926-3678+3493@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050719135122Z8226926-3678+3493@linux-mips.org>
User-Agent: Mutt/1.5.8i
Return-Path: <drow@nevyn.them.org>
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: 8551
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: 625
Lines: 21

On Tue, Jul 19, 2005 at 09:52:57AM -0400, Bryan Althouse wrote:
> 
> Is anyone doing remote debugging for mips?  
> 
> I start the gdbserver on mips with:  
>     gdbserver 192.168.2.39:2222 ./hello_loop
> This produces:
>     Process ./hello_loop created; pid = 158
> 
> On my PC, I type:
>     ddd --debugger mips64-linux-gnu-gdb hello_loop
>     (at gdb prompt) target remote 192.168.2.55:2222

Gdbserver doesn't have MIPS64 support merged.  Assuming you're using
MIPS64, as suggested by the above, then it won't work.

There are patches floating around, but I haven't had time...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

From jbglaw@lug-owl.de Tue Jul 19 15:40:53 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 15:41:14 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:40609 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8226872AbVGSOkv>;
	Tue, 19 Jul 2005 15:40:51 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 5154CF0078; Tue, 19 Jul 2005 16:42:30 +0200 (CEST)
Date:	Tue, 19 Jul 2005 16:42:30 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
Message-ID: <20050719144230.GE20065@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com> <20050719143110.GD3108@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="idY8LE8SD6/8DnRI"
Content-Disposition: inline
In-Reply-To: <20050719143110.GD3108@linux-mips.org>
X-Operating-System: Linux mail 2.6.11.10lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
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: 8552
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: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2262
Lines: 64


--idY8LE8SD6/8DnRI
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-07-19 10:31:10 -0400, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Jul 19, 2005 at 03:34:01PM +0530, Nori, Soma Sekhar wrote:
> > However, when I try to update the time using date -s <time string>=20
> > the RTC does not get updated. (shows the old time when I boot-up again)

Right, expected. date -s  sets the time of the running system, not the
system's HW time.

> > In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
> > but that call is made only when STA_UNSYNC is _not_ set in time_status
> > variable. do_settimeofday/sys_stime _set_ this flag so the timer=20
> > interrupt does not call rtc_set_mmss. =09

Right. HW clock updating is somewhat supposed to work IFF ntp is
running.

> > Can somebody please help me understand how the RTC is supposed to be
> > updated after user changes the time using the date command?
>=20
> Not at all.  Try man hwclock.

hwclock is the userspace utility to manually once set the time. In
normal operation, this should only be called _once_, after the system is
switched on for the very first time.

During lifetime, ntpd should execute and thus the system's current time
will be written to the HW clock every now and then. Additionally, most
distributions seem to also update the HW clock at system shutdown time.

So the correct solution to your problem is to either shutdown once
(workaround) or keep ntpd running (the solution[tm]).

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 fuer einen Freien Staat voll Freier B=C3=BCrger" | im Internet! |   im Ira=
k!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--idY8LE8SD6/8DnRI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC3RFWHb1edYOZ4bsRAjQ+AJ4krygs9PqCkNdxEgfUiTZV3Au4WwCgjUrr
yJIMZ8CnATfboZAjak1yIDU=
=aS7c
-----END PGP SIGNATURE-----

--idY8LE8SD6/8DnRI--

From macro@linux-mips.org Tue Jul 19 16:04:31 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 16:04:47 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:36621 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226834AbVGSPEb>; Tue, 19 Jul 2005 16:04:31 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id 28C4FE1CB8; Tue, 19 Jul 2005 17:06:10 +0200 (CEST)
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 15467-03; Tue, 19 Jul 2005 17:06:10 +0200 (CEST)
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 BA633E1CB5; Tue, 19 Jul 2005 17:06:09 +0200 (CEST)
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 j6JF6CHB027715;
	Tue, 19 Jul 2005 17:06:13 +0200
Date:	Tue, 19 Jul 2005 16:06:21 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
In-Reply-To: <20050719144230.GE20065@lug-owl.de>
Message-ID: <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl>
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com>
 <20050719143110.GD3108@linux-mips.org> <20050719144230.GE20065@lug-owl.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.61L.0507191602281.10363@blysk.ds.pg.gda.pl>
X-Virus-Scanned: ClamAV 0.85.1/984/Tue Jul 19 11:16:09 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8553
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: 1317
Lines: 31

On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:

> hwclock is the userspace utility to manually once set the time. In
> normal operation, this should only be called _once_, after the system is
> switched on for the very first time.

 Well, `hwclock' should normally be used to update the RTC every time 
after a manual system clock update.

> During lifetime, ntpd should execute and thus the system's current time
> will be written to the HW clock every now and then. Additionally, most

 Note that ntpd only updates minutes and seconds and then only if the 
difference is small -- to account for the existence of time zones and a 
system-specific relation between the time recoreded by the system and one 
handled by the RTC.  Also the feature is broken by design -- ntpd 
shouldn't do that at all in principle and in practice it leads to the 
system time being corrupted on some machines using an RTC interrupt for 
the system timer tick.

> distributions seem to also update the HW clock at system shutdown time.

 Which is where it should really happen.

> So the correct solution to your problem is to either shutdown once
> (workaround) or keep ntpd running (the solution[tm]).

 I think you've got the figures reversed (well, it's useful to have ntpd 
running, but it should not fiddle with the RTC).

  Maciej

From jbglaw@lug-owl.de Tue Jul 19 16:18:23 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 16:18:41 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:35038 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8226884AbVGSPSX>;
	Tue, 19 Jul 2005 16:18:23 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id A1B67F0075; Tue, 19 Jul 2005 17:20:08 +0200 (CEST)
Date:	Tue, 19 Jul 2005 17:20:08 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
Message-ID: <20050719152008.GG20065@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com> <20050719143110.GD3108@linux-mips.org> <20050719144230.GE20065@lug-owl.de> <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="m972NQjnE83KvVa/"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl>
X-Operating-System: Linux mail 2.6.11.10lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
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: 8554
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: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 3197
Lines: 87


--m972NQjnE83KvVa/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-07-19 16:06:21 +0100, Maciej W. Rozycki <macro@linux-mips.org>=
 wrote:
> On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:
>=20
> > hwclock is the userspace utility to manually once set the time. In
> > normal operation, this should only be called _once_, after the system is
> > switched on for the very first time.
>=20
>  Well, `hwclock' should normally be used to update the RTC every time=20
> after a manual system clock update.

Which of course should only be done once. Ever :)

> > During lifetime, ntpd should execute and thus the system's current time
> > will be written to the HW clock every now and then. Additionally, most
>=20
>  Note that ntpd only updates minutes and seconds and then only if the=20
> difference is small -- to account for the existence of time zones and a=
=20
> system-specific relation between the time recoreded by the system and one=
=20
> handled by the RTC.  Also the feature is broken by design -- ntpd=20
> shouldn't do that at all in principle and in practice it leads to the=20
> system time being corrupted on some machines using an RTC interrupt for=
=20
> the system timer tick.

Aren't we expected to keep UTC time inside the HW clock? So there's no
problem with timezones.  Also, if your timer interrupt source it that
broken that ntpd cannot track it, then you're having more servere
problems...

> > distributions seem to also update the HW clock at system shutdown time.
>=20
>  Which is where it should really happen.

I disagree. IFF there's a known good time, it's acceptable to write it
into a backing HW clock. In case there isn't (any longer), it's probably
better to not write to the HW clock at all. Probably it's contents is
better than a wrongly manually adjusted local date setting...

I do trust ntpd, but do I trust someone who looks at it's watch?

> > So the correct solution to your problem is to either shutdown once
> > (workaround) or keep ntpd running (the solution[tm]).
>=20
>  I think you've got the figures reversed (well, it's useful to have ntpd=
=20
> running, but it should not fiddle with the RTC).

Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make
the kernel set it internally), but for sure I don't want the HW clock
being set by hand (except very first power-up of the system) and by no
means if local time came up from a manual process.

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
fuer einen Freien Staat voll Freier Buerger" | im Internet! |   im Irak!   =
O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--m972NQjnE83KvVa/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC3RooHb1edYOZ4bsRArUpAJ0WbflH/Vn45E4CRaiaIwD6gDy9KgCfaq5V
xd2zhvQVYbp842YFF4jhY3Q=
=sbhH
-----END PGP SIGNATURE-----

--m972NQjnE83KvVa/--

From gill.robles@exterity.co.uk Tue Jul 19 17:03:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:04:01 +0100 (BST)
Received: from [IPv6:::ffff:62.253.252.7] ([IPv6:::ffff:62.253.252.7]:18596
	"EHLO exterity.co.uk") by linux-mips.org with ESMTP
	id <S8226887AbVGSQDn> convert rfc822-to-8bit; Tue, 19 Jul 2005 17:03:43 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: SNR calculation in stv0299 driver
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date:	Tue, 19 Jul 2005 17:08:10 +0100
Message-ID: <CEA5455795C8AA44AA1E18EF32379B210BA979@exterity-serv1.Exterity.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SNR calculation in stv0299 driver
Thread-Index: AcWMfA7+zUQuRUwsRJCe8P1oYSmlsg==
From:	"Gill Robles-Thome" <gill.robles@exterity.co.uk>
To:	<linux-mips@linux-mips.org>
Return-Path: <gill.robles@exterity.co.uk>
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: 8555
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: gill.robles@exterity.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 610
Lines: 24

Hi -

Can anyone explain the algorithm used to calculate the SNR for the
stv0299 driver? Ie


	case FE_READ_SNR:
	{
		s32 snr = 0xffff - ((stv0299_readreg (i2c, 0x24) << 8)
				   | stv0299_readreg (i2c, 0x25));
		snr = 3 * (snr - 0xa100);
		*((u16*) arg) = (snr > 0xffff) ? 0xffff :
				(snr < 0) ? 0 : snr;
		break;
	}
 

I don't understand where the 0xa100 value comes from, or why the result
is them multiplied by 3!  Registers 0x24 and 0x25 are apparently "Noise
Indicator" registers, but the stv0299 specification doesn't explain very
well how these registers should be used.

Thanks for your help,
Gill

From francis_moreau2000@yahoo.fr Tue Jul 19 17:26:11 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:26:30 +0100 (BST)
Received: from web25801.mail.ukl.yahoo.com ([IPv6:::ffff:217.12.10.186]:2643
	"HELO web25801.mail.ukl.yahoo.com") by linux-mips.org with SMTP
	id <S8226889AbVGSQ0L>; Tue, 19 Jul 2005 17:26:11 +0100
Received: (qmail 58118 invoked by uid 60001); 19 Jul 2005 16:27:51 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.fr;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=g8P2tZD3G/H9RLoYGrKa/ULrjnj6uzRPJ3y/ukBf8St8ChGR+A26mpAw7ABgNpMmzHAVwzY1jtGr3k9aQSCoYVE3mXvAmbPSqW6lh3H/owrx7FgM5dpV9cTJoUER3tFvbplNXi8p9zCL3dNEDoTgvL3q4rnjH8Y39cnKP2aRyoI=  ;
Message-ID: <20050719162751.58116.qmail@web25801.mail.ukl.yahoo.com>
Received: from [217.167.142.149] by web25801.mail.ukl.yahoo.com via HTTP; Tue, 19 Jul 2005 18:27:51 CEST
Date:	Tue, 19 Jul 2005 18:27:51 +0200 (CEST)
From:	moreau francis <francis_moreau2000@yahoo.fr>
Subject: wrong tags in cvs.
To:	linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <francis_moreau2000@yahoo.fr>
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: 8556
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: francis_moreau2000@yahoo.fr
Precedence: bulk
X-list: linux-mips
Content-Length: 375
Lines: 17

Hi,

It seems that files issued with the merge with linux 2.6.13-rcX have been
incorrectly tagged with linux_2_6_12-rcX tags.

thanks,

        Francis


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

From hellokishore@gmail.com Tue Jul 19 17:29:08 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:29:23 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.203]:22414 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226889AbVGSQ3I> convert rfc822-to-8bit;
	Tue, 19 Jul 2005 17:29:08 +0100
Received: by zproxy.gmail.com with SMTP id n1so1190583nzf
        for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 09:30:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=naMJeIiUZAmYXUd+/7mKtj1PSe5G6hAIOdZnZfKH9mFWdGDJDBTUCFMqjgQGSPHyg37jfHpjSp37lHjWQMzY+t8TnQFIf483G/nBeTtziv4c/XP6EbptP86kgsZlRc0l4So/yznhgWCXYlPjzTl6evUOF6Jnq9wN9laqhVRKlcU=
Received: by 10.36.105.13 with SMTP id d13mr1000563nzc;
        Tue, 19 Jul 2005 09:30:21 -0700 (PDT)
Received: by 10.36.47.11 with HTTP; Tue, 19 Jul 2005 09:30:20 -0700 (PDT)
Message-ID: <f07e6e05071909301c212ab4@mail.gmail.com>
Date:	Tue, 19 Jul 2005 22:00:20 +0530
From:	Kishore K <hellokishore@gmail.com>
Reply-To: Kishore K <hellokishore@gmail.com>
To:	linux-mips@linux-mips.org
Subject: bal instruction in gcc 3.x
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Return-Path: <hellokishore@gmail.com>
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: 8557
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: hellokishore@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 650
Lines: 30

We are facing a problem when U-boot is compiled with gcc 3.x

U-boot  uses the following instruction in one of the files.

bal jump_to_symbol

This code gets compiled without any problem with gcc2. However, if I
compile the code
with gcc3, it exits with the error "Cannot branch to unknown symbol".

What should we do to circumvent this problem ?

I replaced 

bal jump_to_symbol 

by

la t9, jump_to_symbol
jalr t9

Then code gets compiled properly without any problem. Please let me
know, whether this
is correct way of fixing the problem. I am newbie to MIPS assembly
language. Why this
change is required with gcc 3.x compiler ?


TIA,
--kishore

From macro@linux-mips.org Tue Jul 19 17:38:54 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:39:10 +0100 (BST)
Received: from pollux.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.7]:1289 "EHLO
	pollux.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226889AbVGSQiy>; Tue, 19 Jul 2005 17:38:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by pollux.ds.pg.gda.pl (Postfix) with ESMTP
	id ED406E1CBD; Tue, 19 Jul 2005 18:40:34 +0200 (CEST)
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 15248-04; Tue, 19 Jul 2005 18:40:34 +0200 (CEST)
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 B7954E1CB9; Tue, 19 Jul 2005 18:40:34 +0200 (CEST)
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 j6JGedLa030778;
	Tue, 19 Jul 2005 18:40:39 +0200
Date:	Tue, 19 Jul 2005 17:40:48 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@linux-mips.org>
To:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
In-Reply-To: <20050719152008.GG20065@lug-owl.de>
Message-ID: <Pine.LNX.4.61L.0507191645510.10363@blysk.ds.pg.gda.pl>
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com>
 <20050719143110.GD3108@linux-mips.org> <20050719144230.GE20065@lug-owl.de>
 <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl> <20050719152008.GG20065@lug-owl.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: ClamAV 0.85.1/984/Tue Jul 19 11:16:09 2005 on piorun.ds.pg.gda.pl
X-Virus-Status:	Clean
X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl
Return-Path: <macro@linux-mips.org>
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: 8558
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: 3280
Lines: 71

On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:

> >  Well, `hwclock' should normally be used to update the RTC every time 
> > after a manual system clock update.
> 
> Which of course should only be done once. Ever :)

 Well, depending on whether the system is networked or not.  If it is, 
it's not needed at all as you fetch the initial setting over NTP, too.  If 
it's not, then unfortunately it's needed every time you notice the clock 
has skewed too much.

> >  Note that ntpd only updates minutes and seconds and then only if the 
> > difference is small -- to account for the existence of time zones and a 
> > system-specific relation between the time recoreded by the system and one 
> > handled by the RTC.  Also the feature is broken by design -- ntpd 
> > shouldn't do that at all in principle and in practice it leads to the 
> > system time being corrupted on some machines using an RTC interrupt for 
> > the system timer tick.
> 
> Aren't we expected to keep UTC time inside the HW clock? So there's no

 It's a good idea, but whether it's feasible or not is unfortunately 
system-specific.

> problem with timezones.  Also, if your timer interrupt source it that
> broken that ntpd cannot track it, then you're having more servere
> problems...

 Huh?  The time source is correct if let to run freely, but modifying the 
time stored in RTC may disturb it.  This is e.g. the case with the 
Motorola MC146818 and its clones which are rather common chips -- any 
system using their periodic interrupt for the system clock tick suffers 
from this problem.

> > > distributions seem to also update the HW clock at system shutdown time.
> > 
> >  Which is where it should really happen.
> 
> I disagree. IFF there's a known good time, it's acceptable to write it
> into a backing HW clock. In case there isn't (any longer), it's probably
> better to not write to the HW clock at all. Probably it's contents is
> better than a wrongly manually adjusted local date setting...

 Something has to preserve the clock across reboots and power-offs.  
Which of the sources is to be trusted more is a matter of a local policy 
and neither the kernel nor tools should force any particular one.

> I do trust ntpd, but do I trust someone who looks at it's watch?

 Well, I do trust myself ultimately...

> > > So the correct solution to your problem is to either shutdown once
> > > (workaround) or keep ntpd running (the solution[tm]).
> > 
> >  I think you've got the figures reversed (well, it's useful to have ntpd 
> > running, but it should not fiddle with the RTC).
> 
> Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make
> the kernel set it internally), but for sure I don't want the HW clock
> being set by hand (except very first power-up of the system) and by no
> means if local time came up from a manual process.

 If ntpd has been running with a good reference it must have disciplined 
the system clock, so it should have a smaller drift than the RTC.  So it 
should be safe to store the former into the latter at a shutdown (but 
that's a policy).  Otherwise nothing can be told about both clocks and the 
system's administrator should decide.  In the end I think the decision 
should be left up to the administrator in all cases.

  Maciej

From ralf@linux-mips.org Tue Jul 19 17:43:00 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:43:16 +0100 (BST)
Received: from localhost.localdomain ([IPv6:::ffff:127.0.0.1]:35210 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226895AbVGSQnA>; Tue, 19 Jul 2005 17:43:00 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6JGSrmX008937;
	Tue, 19 Jul 2005 12:28:54 -0400
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6JGSrpO008936;
	Tue, 19 Jul 2005 12:28:53 -0400
Date:	Tue, 19 Jul 2005 12:28:52 -0400
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Gill Robles-Thome <gill.robles@exterity.co.uk>
Cc:	linux-mips@linux-mips.org
Subject: Re: SNR calculation in stv0299 driver
Message-ID: <20050719162852.GA8758@linux-mips.org>
References: <CEA5455795C8AA44AA1E18EF32379B210BA979@exterity-serv1.Exterity.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CEA5455795C8AA44AA1E18EF32379B210BA979@exterity-serv1.Exterity.local>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8559
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 300
Lines: 9

On Tue, Jul 19, 2005 at 05:08:10PM +0100, Gill Robles-Thome wrote:

> Can anyone explain the algorithm used to calculate the SNR for the
> stv0299 driver? Ie

You may want to post such questions to a list that's actually related
such as the Linux TV list, see your friendly MAINTAINERS file.

  Ralf

From ralf@linux-mips.org Tue Jul 19 17:43:41 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 17:44:08 +0100 (BST)
Received: from localhost.localdomain ([IPv6:::ffff:127.0.0.1]:35210 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226892AbVGSQnD>; Tue, 19 Jul 2005 17:43:03 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6JGiRJ7009503;
	Tue, 19 Jul 2005 12:44:27 -0400
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6JGiRPT009502;
	Tue, 19 Jul 2005 12:44:27 -0400
Date:	Tue, 19 Jul 2005 12:44:27 -0400
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Kishore K <hellokishore@gmail.com>
Cc:	linux-mips@linux-mips.org
Subject: Re: bal instruction in gcc 3.x
Message-ID: <20050719164427.GB8758@linux-mips.org>
References: <f07e6e05071909301c212ab4@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f07e6e05071909301c212ab4@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8560
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 1243
Lines: 39

On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:

> We are facing a problem when U-boot is compiled with gcc 3.x
> 
> U-boot  uses the following instruction in one of the files.
> 
> bal jump_to_symbol
> 
> This code gets compiled without any problem with gcc2. However, if I
> compile the code
> with gcc3, it exits with the error "Cannot branch to unknown symbol".
> 
> What should we do to circumvent this problem ?
> 
> I replaced 
> 
> bal jump_to_symbol 
> 
> by
> 
> la t9, jump_to_symbol
> jalr t9
> 
> Then code gets compiled properly without any problem. Please let me
> know, whether this
> is correct way of fixing the problem. I am newbie to MIPS assembly
> language. Why this
> change is required with gcc 3.x compiler ?

FIrst of all, gcc doesn't care at all about your assembler code, that's
the assembler which you must have changed along with that.

There used to be no relocation type to represent a branch to an external
symbol in an ELF file which is why gas is throwing an error message, so
gas is throwing an error message.  Latest gas fixed that shortcoming.
I think there was a bug in somewhat older gas which resulted in such
invalid code actually being accepted even though it shouldn't have been.

  Ralf

From hellokishore@gmail.com Tue Jul 19 18:18:33 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 18:18:49 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.199]:1549 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8226892AbVGSRSd> convert rfc822-to-8bit;
	Tue, 19 Jul 2005 18:18:33 +0100
Received: by zproxy.gmail.com with SMTP id s1so1197904nze
        for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 10:20:09 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=hGlBxirc/tX5XzzL5NPKXJzVxehuyfzU3mSSAiMOyUs9RSCy8HdRC7QCizNlplSK49vXAB7/I5aR0F3spvOJaNeuhtHVPFUz12KsPG2m/Eq8mgOQ6EaYb8Ahy6j/1T5f8ZxBx5KOq/y14ausFZAJCsmsK0oAMwxCsOJF6+ShLbk=
Received: by 10.36.33.13 with SMTP id g13mr4534480nzg;
        Tue, 19 Jul 2005 10:19:49 -0700 (PDT)
Received: by 10.36.47.11 with HTTP; Tue, 19 Jul 2005 10:19:48 -0700 (PDT)
Message-ID: <f07e6e05071910194bab9b16@mail.gmail.com>
Date:	Tue, 19 Jul 2005 22:49:48 +0530
From:	Kishore K <hellokishore@gmail.com>
Reply-To: Kishore K <hellokishore@gmail.com>
To:	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: bal instruction in gcc 3.x
Cc:	linux-mips@linux-mips.org
In-Reply-To: <20050719164427.GB8758@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <f07e6e05071909301c212ab4@mail.gmail.com>
	 <20050719164427.GB8758@linux-mips.org>
Return-Path: <hellokishore@gmail.com>
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: 8561
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: hellokishore@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1877
Lines: 58

On 7/19/05, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:
> 
> > We are facing a problem when U-boot is compiled with gcc 3.x
> >
> > U-boot  uses the following instruction in one of the files.
> >
> > bal jump_to_symbol
> >
> > This code gets compiled without any problem with gcc2. However, if I
> > compile the code
> > with gcc3, it exits with the error "Cannot branch to unknown symbol".
> >
> > What should we do to circumvent this problem ?
> >
> > I replaced
> >
> > bal jump_to_symbol
> >
> > by
> >
> > la t9, jump_to_symbol
> > jalr t9
> >
> > Then code gets compiled properly without any problem. Please let me
> > know, whether this
> > is correct way of fixing the problem. I am newbie to MIPS assembly
> > language. Why this
> > change is required with gcc 3.x compiler ?
> 
> FIrst of all, gcc doesn't care at all about your assembler code, that's
> the assembler which you must have changed along with that.
> 
> There used to be no relocation type to represent a branch to an external
> symbol in an ELF file which is why gas is throwing an error message, so
> gas is throwing an error message.  Latest gas fixed that shortcoming.
> I think there was a bug in somewhat older gas which resulted in such
> invalid code actually being accepted even though it shouldn't have been.
> 
>   Ralf

Thank you very much for the reply.

First of all code got compiled only after removing the option
-mips-allow-branch-to-undefined from Makefile. If this option is
included, compilation fails saying that option is invalid. I am using
binutils-2.14.90.06.
Same problem is observed even with binutils 2.15.94.0.2.2. 

Do you mean to say that no change is required in the code snippet 

bal jump_to_symbol

and code should get compiled with the latest assembler without any
problem. Please clearify.

TIA,
--kishore

From mad@automagically.de Tue Jul 19 19:19:18 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 19:19:35 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.186]:24543
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226897AbVGSSTR>; Tue, 19 Jul 2005 19:19:17 +0100
Received: from pD952892F.dip0.t-ipconnect.de [217.82.137.47] (helo=gaspode.madsworld.lan)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0ML29c-1DuwiC1hHh-0000T7; Tue, 19 Jul 2005 20:21:00 +0200
Received: from mad by gaspode.madsworld.lan with local (Exim 4.50)
	id 1DuwiE-00011A-Uh; Tue, 19 Jul 2005 20:21:02 +0200
Date:	Tue, 19 Jul 2005 20:21:02 +0200
From:	Markus Dahms <mad@automagically.de>
To:	"Maciej W. Rozycki" <macro@linux-mips.org>
Cc:	linux-mips@linux-mips.org
Subject: Re: 2.6 on IP22 (Indy)
Message-ID: <20050719182102.GA3727@gaspode.automagically.de>
References: <20050627100757.GA27679@gaspode.automagically.de> <Pine.LNX.4.61L.0506271401280.15406@blysk.ds.pg.gda.pl> <20050627141842.GA28236@gaspode.automagically.de> <Pine.LNX.4.61L.0506271632380.23903@blysk.ds.pg.gda.pl> <20050628062107.GA8665@gaspode.automagically.de> <Pine.LNX.4.61L.0506280918380.13758@blysk.ds.pg.gda.pl> <20050628102013.GA10442@gaspode.automagically.de> <Pine.LNX.4.61L.0506281204190.13758@blysk.ds.pg.gda.pl> <20050628170425.GA5189@gaspode.automagically.de> <Pine.LNX.4.61L.0506291747550.31188@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0506291747550.31188@blysk.ds.pg.gda.pl>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:896705dcda322f33ae3752a7fdb3dc09
Return-Path: <mad@automagically.de>
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: 8562
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: mad@automagically.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1040
Lines: 28

Hello Maciej,

[R4600PC problems]
> Well, they are not meant to be errata-compatible. ;-)  I haven't been 
> able to locate any reference for tlbp being problematic on the R4600, in 
> particular not in the chip errata document, and the old handlers used to 
> have a nop before that instruction unconditionally (perhaps just in case 
> ;-) ), so the problem was covered.  If it fixes the problem for you, then 
> it should probably be applied, too.

I just built a 64-bit kernel from clean CVS and had to apply the patch
below again to get it to userspace. Maybe it just hides the real error
but at least "it works for me" [tm].
Please apply to CVS if there are no objections.

Markus

--- a/arch/mips/mm/tlbex.c    2005-07-19 20:12:32.000000000 +0200
+++ b/arch/mips/mm/tlbex.c    2005-07-19 20:10:29.000000000 +0200
@@ -779,6 +779,7 @@
 static __init void __attribute__((unused)) build_tlb_probe_entry(u32 **p)
 {
    switch (current_cpu_data.cputype) {
+   case CPU_R4600:
    case CPU_R5000:
    case CPU_R5000A:
    case CPU_NEVADA:


From mad@automagically.de Tue Jul 19 19:33:59 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 19:34:16 +0100 (BST)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.171]:33023
	"EHLO moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8226897AbVGSSd7>; Tue, 19 Jul 2005 19:33:59 +0100
Received: from pD952892F.dip0.t-ipconnect.de [217.82.137.47] (helo=gaspode.madsworld.lan)
	by mrelayeu.kundenserver.de with ESMTP (Nemesis),
	id 0MKxQS-1DuwwR3Lk8-0006SS; Tue, 19 Jul 2005 20:35:43 +0200
Received: from mad by gaspode.madsworld.lan with local (Exim 4.50)
	id 1DuwwU-00011n-JH
	for linux-mips@linux-mips.org; Tue, 19 Jul 2005 20:35:46 +0200
Date:	Tue, 19 Jul 2005 20:35:46 +0200
From:	Markus Dahms <mad@automagically.de>
To:	linux-mips@linux-mips.org
Subject: module loading on 64-bit kernel
Message-ID: <20050719183546.GA3923@gaspode.automagically.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:896705dcda322f33ae3752a7fdb3dc09
Return-Path: <mad@automagically.de>
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: 8563
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: mad@automagically.de
Precedence: bulk
X-list: linux-mips
Content-Length: 709
Lines: 22

Hello together,

do I need other module-init-tools for a 64-bit kernel than I need for
32-bit?
When trying to load a module I get the following output:
| insmod: error inserting \
| '/lib/modules/2.6.13-rc3-mad-mips-1-64/kernel/fs/isofs/isofs.ko': -1 \
| Cannot allocate memory

in dmesg:
| allocation failed: out of vmalloc space - use vmalloc=<size> to increase \
| size.

It happens with every module. If I'd need other tools these messages are
confusing. I didn't try "vmalloc=..." as I think module loading wouldn't
be "disabled" in such a way by default...

If I need special 64-bit module-init-tools, is there a way to build them
without a 64-bit glibc as all of my userspace stuff is 32-bit?

Markus


From ths@networkno.de Tue Jul 19 20:19:26 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 20:19:43 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:33676 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226729AbVGSTTZ>;
	Tue, 19 Jul 2005 20:19:25 +0100
Received: from port-195-158-170-19.dynamic.qsc.de ([195.158.170.19] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1DuxeL-0005um-00
	for linux-mips@linux-mips.org; Tue, 19 Jul 2005 21:21:05 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1DuxeL-0002SB-H8
	for linux-mips@linux-mips.org; Tue, 19 Jul 2005 21:21:05 +0200
Date:	Tue, 19 Jul 2005 21:21:05 +0200
To:	linux-mips@linux-mips.org
Subject: Re: module loading on 64-bit kernel
Message-ID: <20050719192105.GF2071@hattusa.textio>
References: <20050719183546.GA3923@gaspode.automagically.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050719183546.GA3923@gaspode.automagically.de>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8564
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 769
Lines: 25

Markus Dahms wrote:
> Hello together,
> 
> do I need other module-init-tools for a 64-bit kernel than I need for
> 32-bit?
> When trying to load a module I get the following output:
> | insmod: error inserting \
> | '/lib/modules/2.6.13-rc3-mad-mips-1-64/kernel/fs/isofs/isofs.ko': -1 \
> | Cannot allocate memory
> 
> in dmesg:
> | allocation failed: out of vmalloc space - use vmalloc=<size> to increase \
> | size.

This seems to be a bug which crept in for (at least) 64bit Indy kernels
in IIRC 2.6.12-rc3.

> It happens with every module. If I'd need other tools these messages are
> confusing. I didn't try "vmalloc=..." as I think module loading wouldn't
> be "disabled" in such a way by default...

It happens also for any significant memory pressure.


Thiemo

From ralf@linux-mips.org Tue Jul 19 20:47:10 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 20:47:30 +0100 (BST)
Received: from H239.C78.B0.tor.eicat.ca ([IPv6:::ffff:72.0.78.239]:55238 "EHLO
	bacchus.net.dhis.org") by linux-mips.org with ESMTP
	id <S8226904AbVGSTrK>; Tue, 19 Jul 2005 20:47:10 +0100
Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1])
	by bacchus.net.dhis.org (8.13.4/8.13.1) with ESMTP id j6JJmkNj005817;
	Tue, 19 Jul 2005 15:48:47 -0400
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.13.4/8.13.4/Submit) id j6JJmgt6005810;
	Tue, 19 Jul 2005 15:48:42 -0400
Date:	Tue, 19 Jul 2005 15:48:42 -0400
From:	Ralf Baechle <ralf@linux-mips.org>
To:	Markus Dahms <mad@automagically.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: module loading on 64-bit kernel
Message-ID: <20050719194842.GC2771@linux-mips.org>
References: <20050719183546.GA3923@gaspode.automagically.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050719183546.GA3923@gaspode.automagically.de>
User-Agent: Mutt/1.4.2.1i
Return-Path: <ralf@linux-mips.org>
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: 8565
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: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
Content-Length: 934
Lines: 24

On Tue, Jul 19, 2005 at 08:35:46PM +0200, Markus Dahms wrote:

> do I need other module-init-tools for a 64-bit kernel than I need for
> 32-bit?
> When trying to load a module I get the following output:
> | insmod: error inserting \
> | '/lib/modules/2.6.13-rc3-mad-mips-1-64/kernel/fs/isofs/isofs.ko': -1 \
> | Cannot allocate memory
> 
> in dmesg:
> | allocation failed: out of vmalloc space - use vmalloc=<size> to increase \
> | size.
> 
> It happens with every module. If I'd need other tools these messages are
> confusing. I didn't try "vmalloc=..." as I think module loading wouldn't
> be "disabled" in such a way by default...
> 
> If I need special 64-bit module-init-tools, is there a way to build them
> without a 64-bit glibc as all of my userspace stuff is 32-bit?

You don't need. In fact the nice thing about module-init-tools is that
they're file format agnostic so didn't need any changes for MIPS porting.

  Ralf

From ppopov@embeddedalley.com Tue Jul 19 20:51:25 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 20:51:46 +0100 (BST)
Received: from smtp001.bizmail.yahoo.com ([IPv6:::ffff:216.136.172.125]:7294
	"HELO smtp001.bizmail.yahoo.com") by linux-mips.org with SMTP
	id <S8226907AbVGSTvZ>; Tue, 19 Jul 2005 20:51:25 +0100
Received: (qmail 40249 invoked from network); 19 Jul 2005 19:53:09 -0000
Received: from unknown (HELO ?192.168.1.100?) (ppopov@embeddedalley.com@71.128.175.242 with plain)
  by smtp001.bizmail.yahoo.com with SMTP; 19 Jul 2005 19:53:09 -0000
Subject: Re: bal instruction in gcc 3.x
From:	Pete Popov <ppopov@embeddedalley.com>
Reply-To: ppopov@embeddedalley.com
To:	Kishore K <hellokishore@gmail.com>
Cc:	Ralf Baechle <ralf@linux-mips.org>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <f07e6e05071910194bab9b16@mail.gmail.com>
References: <f07e6e05071909301c212ab4@mail.gmail.com>
	 <20050719164427.GB8758@linux-mips.org>
	 <f07e6e05071910194bab9b16@mail.gmail.com>
Content-Type: multipart/mixed; boundary="=-0sqhL2MLABQ9jtjNc0JA"
Organization: Embedded Alley Solutions, Inc
Date:	Tue, 19 Jul 2005 12:53:06 -0700
Message-Id: <1121802786.7285.88.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-4) 
Return-Path: <ppopov@embeddedalley.com>
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: 8566
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: 3432
Lines: 144


--=-0sqhL2MLABQ9jtjNc0JA
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


Try the attached patch instead.

Pete

On Tue, 2005-07-19 at 22:49 +0530, Kishore K wrote:
> On 7/19/05, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Tue, Jul 19, 2005 at 10:00:20PM +0530, Kishore K wrote:
> > 
> > > We are facing a problem when U-boot is compiled with gcc 3.x
> > >
> > > U-boot  uses the following instruction in one of the files.
> > >
> > > bal jump_to_symbol
> > >
> > > This code gets compiled without any problem with gcc2. However, if I
> > > compile the code
> > > with gcc3, it exits with the error "Cannot branch to unknown symbol".
> > >
> > > What should we do to circumvent this problem ?
> > >
> > > I replaced
> > >
> > > bal jump_to_symbol
> > >
> > > by
> > >
> > > la t9, jump_to_symbol
> > > jalr t9
> > >
> > > Then code gets compiled properly without any problem. Please let me
> > > know, whether this
> > > is correct way of fixing the problem. I am newbie to MIPS assembly
> > > language. Why this
> > > change is required with gcc 3.x compiler ?
> > 
> > FIrst of all, gcc doesn't care at all about your assembler code, that's
> > the assembler which you must have changed along with that.
> > 
> > There used to be no relocation type to represent a branch to an external
> > symbol in an ELF file which is why gas is throwing an error message, so
> > gas is throwing an error message.  Latest gas fixed that shortcoming.
> > I think there was a bug in somewhat older gas which resulted in such
> > invalid code actually being accepted even though it shouldn't have been.
> > 
> >   Ralf
> 
> Thank you very much for the reply.
> 
> First of all code got compiled only after removing the option
> -mips-allow-branch-to-undefined from Makefile. If this option is
> included, compilation fails saying that option is invalid. I am using
> binutils-2.14.90.06.
> Same problem is observed even with binutils 2.15.94.0.2.2. 
> 
> Do you mean to say that no change is required in the code snippet 
> 
> bal jump_to_symbol
> 
> and code should get compiled with the latest assembler without any
> problem. Please clearify.
> 
> TIA,
> --kishore
> 

--=-0sqhL2MLABQ9jtjNc0JA
Content-Disposition: attachment; filename=mips_jalr.diff
Content-Type: text/x-patch; name=mips_jalr.diff; charset=utf-8
Content-Transfer-Encoding: 7bit

--- start.S	2004-02-06 17:27:17.000000000 -0800
+++ start.S~jalr	2005-01-29 16:13:18.000000000 -0800
@@ -234,21 +234,35 @@
 	li	t0, CONF_CM_UNCACHED
 	mtc0	t0, CP0_CONFIG
 
+	/* Initialize GOT pointer.
+	 */
+	bal	1f
+	nop
+	.word	_GLOBAL_OFFSET_TABLE_ - 1f + 4
+1:
+	move	gp, ra
+	lw	t1, 0(ra)
+	add	gp, t1
+
+
 #ifdef CONFIG_INCA_IP
 	/* Disable INCA-IP Watchdog.
 	 */
-	bal	disable_incaip_wdt
+	la	t9, disable_incaip_wdt
+	jalr	t9
 	nop
 #endif
 
 	/* Initialize any external memory.
 	 */
-	bal	memsetup
+	la	t9, memsetup
+	jalr	t9
 	nop
 
 	/* Initialize caches...
 	 */
-	bal	mips_cache_reset
+	la	t9, mips_cache_reset
+	jalr	t9
 	nop
 
 	/* ... and enable them.
@@ -260,21 +274,13 @@
 	/* Set up temporary stack.
 	 */
 	li	a0, CFG_INIT_SP_OFFSET
-	bal	mips_cache_lock
+	la	t9, mips_cache_lock
+	jalr	t9
 	nop
 
 	li	t0, CFG_SDRAM_BASE + CFG_INIT_SP_OFFSET
 	la	sp, 0(t0)
 
-	/* Initialize GOT pointer.
-	 */
-	bal	1f
-	nop
-	.word	_GLOBAL_OFFSET_TABLE_ - 1f + 4
-1:
-	move	gp, ra
-	lw	t1, 0(ra)
-	add	gp, t1
 	la	t9, board_init_f
 	j	t9
 	nop

--=-0sqhL2MLABQ9jtjNc0JA--


From geoman@gentoo.org Tue Jul 19 23:29:06 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 23:29:26 +0100 (BST)
Received: from lennier.cc.vt.edu ([IPv6:::ffff:198.82.162.213]:22997 "EHLO
	lennier.cc.vt.edu") by linux-mips.org with ESMTP
	id <S8226909AbVGSW3G>; Tue, 19 Jul 2005 23:29:06 +0100
Received: from steiner.cc.vt.edu (IDENT:mirapoint@evil-steiner.cc.vt.edu [10.1.1.14])
	by lennier.cc.vt.edu (8.12.11/8.12.11) with ESMTP id j6JMUXqB007361
	for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 18:30:43 -0400
Received: from [192.168.1.2] (68-232-96-93.chvlva.adelphia.net [68.232.96.93])
	by steiner.cc.vt.edu (MOS 3.6.4-CR)
	with ESMTP id DNH04891 (AUTH spbecker);
	Tue, 19 Jul 2005 18:30:31 -0400 (EDT)
Message-ID: <42DD7F06.8020403@gentoo.org>
Date:	Tue, 19 Jul 2005 18:30:30 -0400
From:	"Stephen P. Becker" <geoman@gentoo.org>
User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050719)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:	linux-mips@linux-mips.org
Subject: Re: module loading on 64-bit kernel
References: <20050719183546.GA3923@gaspode.automagically.de> <20050719192105.GF2071@hattusa.textio>
In-Reply-To: <20050719192105.GF2071@hattusa.textio>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <geoman@gentoo.org>
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: 8567
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: geoman@gentoo.org
Precedence: bulk
X-list: linux-mips
Content-Length: 581
Lines: 18


> This seems to be a bug which crept in for (at least) 64bit Indy kernels
> in IIRC 2.6.12-rc3.

I'm fairly certain it happened with the initial 2.6.11-rc1 import.  I'd 
have to go back and double check to be 100% on that.

>>It happens with every module. If I'd need other tools these messages are
>>confusing. I didn't try "vmalloc=..." as I think module loading wouldn't
>>be "disabled" in such a way by default...
> 
> 
> It happens also for any significant memory pressure.

...including significant use of dd, mounting of ricerfs partitions, 
mounting of swap, etc.

-Steve

From jbglaw@lug-owl.de Tue Jul 19 23:58:50 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Jul 2005 23:59:08 +0100 (BST)
Received: from lug-owl.de ([IPv6:::ffff:195.71.106.12]:29352 "EHLO lug-owl.de")
	by linux-mips.org with ESMTP id <S8226909AbVGSW6t>;
	Tue, 19 Jul 2005 23:58:49 +0100
Received: by lug-owl.de (Postfix, from userid 1001)
	id 614FDF0071; Wed, 20 Jul 2005 01:00:32 +0200 (CEST)
Date:	Wed, 20 Jul 2005 01:00:32 +0200
From:	Jan-Benedict Glaw <jbglaw@lug-owl.de>
To:	linux-mips@linux-mips.org
Subject: Re: Updating RTC with date command
Message-ID: <20050719230032.GB24635@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <CBD77117272E1249BFDC21E33D555FDC06018D@dbde01.ent.ti.com> <20050719143110.GD3108@linux-mips.org> <20050719144230.GE20065@lug-owl.de> <Pine.LNX.4.61L.0507191555360.10363@blysk.ds.pg.gda.pl> <20050719152008.GG20065@lug-owl.de> <Pine.LNX.4.61L.0507191645510.10363@blysk.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="s9fJI615cBHmzTOP"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61L.0507191645510.10363@blysk.ds.pg.gda.pl>
X-Operating-System: Linux mail 2.6.11.10lug-owl 
X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
X-gpg-key: wwwkeys.de.pgp.net
X-Echelon-Enable: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
X-TKUeV: howto poison arsenous mail psychological biological nuclear warfare test the bombastical terror of flooding the spy listeners explosion sex drugs and rock'n'roll
User-Agent: Mutt/1.5.9i
Return-Path: <jbglaw@lug-owl.de>
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: 8568
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: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips
Content-Length: 5828
Lines: 161


--s9fJI615cBHmzTOP
Content-Type: multipart/mixed; boundary="0eh6TmSyL6TZE2Uz"
Content-Disposition: inline


--0eh6TmSyL6TZE2Uz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-07-19 17:40:48 +0100, Maciej W. Rozycki <macro@linux-mips.org>=
 wrote:
> On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:
> > >  Note that ntpd only updates minutes and seconds and then only if the=
=20
> > > difference is small -- to account for the existence of time zones and=
 a=20
> > > system-specific relation between the time recoreded by the system and=
 one=20
> > > handled by the RTC.  Also the feature is broken by design -- ntpd=20
> > > shouldn't do that at all in principle and in practice it leads to the=
=20
> > > system time being corrupted on some machines using an RTC interrupt f=
or=20
> > > the system timer tick.
> >=20
> > Aren't we expected to keep UTC time inside the HW clock? So there's no
>=20
>  It's a good idea, but whether it's feasible or not is unfortunately=20
> system-specific.

The base year may change, but for the rest, aren't there Windows boxes
on one hand (using local time in RTC) and all other OSses using UTC in
there?

> > problem with timezones.  Also, if your timer interrupt source it that
> > broken that ntpd cannot track it, then you're having more servere
> > problems...
>=20
>  Huh?  The time source is correct if let to run freely, but modifying the=
=20
> time stored in RTC may disturb it.  This is e.g. the case with the=20
> Motorola MC146818 and its clones which are rather common chips -- any=20
> system using their periodic interrupt for the system clock tick suffers=
=20
> from this problem.

The main problem is that there are several time sources in a modern
machine, and these are somewhat unsynchronized. Pick one and correct it,
the others will look fucked up. ...or keep correcting them all. There's
just a difference of usage. Some time sources are used only every now
and then (like the HW clock), others all the time (like the calculated
time, tick'ed by the timer interrupt) or only in very specific
situations (in-processor cycle counters). Some systems won't even
generate timer interrupts at all, but always ask specific hardware
whenever a timestamp is needed.

What I care most about is that there's a well-behaving time being
returned by time() or gettimeofday(), usually generated (on PeeCees)
=66rom the timer interrupt.  This should be corrected to be as good as
possible, usually through the help of ntpd.

The long-term time sources (like the HW clock) should be updated, too,
but it's contents only needs to be correct any now and then; for sure,
there isn't such a high need for strong monotony as there is in the
gettimeofday() interface. Thus, updating it every 11 minutes from the
system time IFF it's properly sync'ed seems reasonable to me. For sure,
I don't want a bad time being written to it. Maybe it would be wise to
have a "last known-good time" timestamp for it, though, to refuse using
it IFF it's a clock suspected to be horribly wrong (like the famous
146818)...

>  Something has to preserve the clock across reboots and power-offs. =20
> Which of the sources is to be trusted more is a matter of a local policy=
=20
> and neither the kernel nor tools should force any particular one.

You're right on this, but keep in mind that some machines don't rely on
a RTC at all. They ask you to enter current time+date manually and will
try to sync it with a better time source some time later.

> > I do trust ntpd, but do I trust someone who looks at it's watch?
>=20
>  Well, I do trust myself ultimately...

/* No comment on this :-)  */

>  If ntpd has been running with a good reference it must have disciplined=
=20
> the system clock, so it should have a smaller drift than the RTC.  So it=
=20
> should be safe to store the former into the latter at a shutdown (but=20
> that's a policy).  Otherwise nothing can be told about both clocks and th=
e=20
> system's administrator should decide.  In the end I think the decision=20
> should be left up to the administrator in all cases.

With "modern" RTCs, even disciplining them isn't easy. Ever kept an eye
on the frequency value? Depending on your mainboard's quality, you may
use it as a quite precise thermometer... Link the attached script into
your /etc/munin/plugins/ and have fun :)

MfG, JBG

--=20
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             =
_ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  =
_ _ O
 fuer einen Freien Staat voll Freier B=C3=BCrger" | im Internet! |   im Ira=
k!   O O O
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)=
);

--0eh6TmSyL6TZE2Uz
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename=local-ntp_frequency

#!/bin/sh

export PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin:$PATH

case "$1" in
	autoconf)
		echo no
		;;
	config)
		echo 'graph_title NTP frequency'
		echo 'graph_vlabel freq'
		echo 'graph_category NTP'
		echo 'graph_info This graph shows the frequency (mis-clocking) of the local timer source.'
		echo 'graph_scale no'
		echo 'frequency.label Frequency'
		echo 'frequency.info Current Frequency.'
		;;
	*)
		FREQUENCY="`echo rv | ntpq -n | tr ',' $'\n' | grep freq | cut -f 2 -d '='`"
		echo "frequency.value ${FREQUENCY}"
		;;
esac

exit 0


--0eh6TmSyL6TZE2Uz--

--s9fJI615cBHmzTOP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC3YYQHb1edYOZ4bsRAu1IAKCQUEGrspnk5EQXpnKY4k8i4CxcqwCcD3SI
b5AXMp47fA1vH5XRTdfeGHY=
=0Dey
-----END PGP SIGNATURE-----

--s9fJI615cBHmzTOP--

From ths@networkno.de Wed Jul 20 02:43:43 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Jul 2005 02:44:00 +0100 (BST)
Received: from mx02.qsc.de ([IPv6:::ffff:213.148.130.14]:8378 "EHLO
	mx02.qsc.de") by linux-mips.org with ESMTP id <S8226915AbVGTBnn>;
	Wed, 20 Jul 2005 02:43:43 +0100
Received: from port-195-158-170-19.dynamic.qsc.de ([195.158.170.19] helo=hattusa.textio)
	by mx02.qsc.de with esmtp (Exim 3.35 #1)
	id 1Dv3eI-0003dA-00; Wed, 20 Jul 2005 03:45:26 +0200
Received: from ths by hattusa.textio with local (Exim 4.52)
	id 1Dv3eH-0005Nc-Ij; Wed, 20 Jul 2005 03:45:25 +0200
Date:	Wed, 20 Jul 2005 03:45:25 +0200
To:	Markus Dahms <mad@automagically.de>
Cc:	linux-mips@linux-mips.org
Subject: Re: 2.6 on IP22 (Indy)
Message-ID: <20050720014525.GI2071@hattusa.textio>
References: <Pine.LNX.4.61L.0506271401280.15406@blysk.ds.pg.gda.pl> <20050627141842.GA28236@gaspode.automagically.de> <Pine.LNX.4.61L.0506271632380.23903@blysk.ds.pg.gda.pl> <20050628062107.GA8665@gaspode.automagically.de> <Pine.LNX.4.61L.0506280918380.13758@blysk.ds.pg.gda.pl> <20050628102013.GA10442@gaspode.automagically.de> <Pine.LNX.4.61L.0506281204190.13758@blysk.ds.pg.gda.pl> <20050628170425.GA5189@gaspode.automagically.de> <Pine.LNX.4.61L.0506291747550.31188@blysk.ds.pg.gda.pl> <20050719182102.GA3727@gaspode.automagically.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050719182102.GA3727@gaspode.automagically.de>
User-Agent: Mutt/1.5.9i
From:	Thiemo Seufer <ths@networkno.de>
Return-Path: <ths@networkno.de>
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: 8569
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: ths@networkno.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1258
Lines: 34

Markus Dahms wrote:
> Hello Maciej,
> 
> [R4600PC problems]
> > Well, they are not meant to be errata-compatible. ;-)  I haven't been 
> > able to locate any reference for tlbp being problematic on the R4600, in 
> > particular not in the chip errata document, and the old handlers used to 
> > have a nop before that instruction unconditionally (perhaps just in case 
> > ;-) ), so the problem was covered.  If it fixes the problem for you, then 
> > it should probably be applied, too.
> 
> I just built a 64-bit kernel from clean CVS and had to apply the patch
> below again to get it to userspace. Maybe it just hides the real error
> but at least "it works for me" [tm].
> Please apply to CVS if there are no objections.
> 
> Markus
> 
> --- a/arch/mips/mm/tlbex.c    2005-07-19 20:12:32.000000000 +0200
> +++ b/arch/mips/mm/tlbex.c    2005-07-19 20:10:29.000000000 +0200
> @@ -779,6 +779,7 @@
>  static __init void __attribute__((unused)) build_tlb_probe_entry(u32 **p)
>  {
>     switch (current_cpu_data.cputype) {
> +   case CPU_R4600:
>     case CPU_R5000:
>     case CPU_R5000A:
>     case CPU_NEVADA:

FWIW, this patch makes no difference for my Indy with R4600 v2.0, it still
hangs, usually while or shortly after mounting filesystems.


Thiemo

From maxim.osipov@gmail.com Wed Jul 20 05:23:36 2005
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Jul 2005 05:23:55 +0100 (BST)
Received: from zproxy.gmail.com ([IPv6:::ffff:64.233.162.205]:43890 "EHLO
	zproxy.gmail.com") by linux-mips.org with ESMTP id <S8224774AbVGTEXg> convert rfc822-to-8bit;
	Wed, 20 Jul 2005 05:23:36 +0100
Received: by zproxy.gmail.com with SMTP id r28so1329355nza
        for <linux-mips@linux-mips.org>; Tue, 19 Jul 2005 21:25:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=E4NMp+dIZnedw0pU3XNEr2nMiwet2QEQ2m0p0bXxPxi3uZsn1irc1vkxnrGi8EK3wZr1pqM0sWsRchWsCYZTsO66+Ppaq6pbd9VRgrZ6vpEJUpaCwVNF6fMlQ74YaWojWacX85OKtXzRfjrmsKyDzVeoTWh/Q2/0Z3DPUy8xtE4=
Received: by 10.36.105.13 with SMTP id d13mr1487256nzc;
        Tue, 19 Jul 2005 21:24:52 -0700 (PDT)
Received: by 10.36.160.10 with HTTP; Tue, 19 Jul 2005 21:24:51 -0700 (PDT)
Message-ID: <6097c490507192124647cd9b3@mail.gmail.com>
Date:	Wed, 20 Jul 2005 04:24:51 +0000
From:	Maxim Osipov <maxim.osipov@gmail.com>
Reply-To: maxim@mox.ru
To:	Daniel Jacobowitz <dan@debian.org>
Subject: Re: remote debugging: "Reply contains invalid hex digit 59"
Cc:	Bryan Althouse <bryan.althouse@3phoenix.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
In-Reply-To: <20050719143911.GA3684@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
References: <20050719135122Z8226926-3678+3493@linux-mips.org>
	 <20050719143911.GA3684@nevyn.them.org>
Return-Path: <maxim.osipov@gmail.com>
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: 8570
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: maxim.osipov@gmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 857
Lines: 32

Daniel,

At the time when I was looking into this problem, I was unable to find
any patches. Could you please point me to one?

BR,
Maxim

On 7/19/05, Daniel Jacobowitz <dan@debian.org> wrote:
> On Tue, Jul 19, 2005 at 09:52:57AM -0400, Bryan Althouse wrote:
> >
> > Is anyone doing remote debugging for mips?
> >
> > I start the gdbserver on mips with:
> >     gdbserver 192.168.2.39:2222 ./hello_loop
> > This produces:
> >     Process ./hello_loop created; pid = 158
> >
> > On my PC, I type:
> >     ddd --debugger mips64-linux-gnu-gdb hello_loop
> >     (at gdb prompt) target remote 192.168.2.55:2222
> 
> Gdbserver doesn't have MIP